🐾 Add a "fast create plan" form

[yaacov]

Current state:
when creating a plan, a user need to use a multi step wizard

Issue:
a migration plan always start from choosing a list of vms to migrate from a source provider, it makes sense to add an option to "fast create" a plan from a source provider details page.

Fix:
add a button in the vms tab of source providers that will open a "fast create" from

[yaacov]

note:
first PR, adding option to sellect vms: #796

[yaacov]

Update:
the form will take a
source provider - none editable
source vms list - none editable

target provider - default to this cluster, editable
target namespace - default to current namespace, editable

storage map - default to all source storage types mapped to "prefered storage class"
editable
network map - default to all networks mapped to "prefered NAD" TBD #821
editable

no hooks

[create ans start button] - will create a plan and start a migration
[create and customize button] - will create a plan and jump to details view with options to editing the mappings and hooks

[yaacov]

Update II:
#821 - how to choose a "prefered NAD" when creating a network mapping default target

"preferred storage class" - is defined by an annotation on the storage class, if missing default to first storage class

[yaacov]

Update:
#822 - implementing first step:

• create a "create plan" page
• fields for first step:
  • name: default to [name of source provider]-[short hash] with "pencil" icon for editing the name
  • source provider as a resource link with label
  • vms: [N] vms selected + info icon that will open a modal
    • modal with a table of seleced vms, table has same columns and filtes as vms table

first step:
- no need for description

second step:
- target provider selector, default to "host" provider, show the resource link, with a "pencil" icon to open modal to change the target
- target namespace selector, default to current namespace, show the resource link with a "pencil" icon to open modal to change the target

cc:// @rszwajko

[yaacov]

third step:

• create a component for editing maps, with an editable varied length list, for example see aditing pods in create deployment form, ( "deployments" -> "create deployment")

forth step:
use the new component to add network and storage mappings,
in our case the default mappings will have the default lists (editable):

• each source network will be mapped to default network
• each source storage will be mapped to default storage

example hooks:

• hook to get a list of source networks
• hook to get a list of source storages
• hook to get a list of target network
• hook to get a list of target storages
• hook to get default target storage
• hood to get default target network

[yaacov]

@liranr23 @ahadas hi, do you know what is the specific annotation/label on the storage class that we will use to find the "prefered" storage class ?

[yaacov]

do you know what is the specific annotation/label on the storage class that we will use to find the "prefered" storage class ?

on the storageclass CR there is an annotation:

annotations:
    storageclass.kubevirt.io/is-default-virt-class: 'true'

[liranr23]

i am not aware of anything from our end?
the default is storageclass.kubernetes.io/is-default-class: 'true' from my point of view. but maybe i am missing something.

[yaacov]

but maybe i am missing something.

no, storageclass.kubernetes.io/is-default-class: 'true' is what was looking for

[yaacov]

@rszwajko , hi,

about default NAD:

def get default network for virtualization():
  if we have NAD defined in target namespace of target cluster:
      return the first NAD sorted alphabetically.  
  else:
      return Pod network

cc:// @ahadas WDYT ^^ ?

[rszwajko]

@yaacov @ahadas

about default NAD:

This heuristics may lead to security issues i.e. for VMs that should use specific networks.
IMHO if we need a default then let's use the Pod network. May prevent the VM from starting but seems safe.

[yaacov]

@rszwajko ok, let's go with pod network, we can update the logic in later time

[yaacov]

@rszwajko hi,

here is a screenshot from the "create deployment" page, the "create plan" should look and feel similar:
see: "Workloads -> Deployments -> Create Deployment"
form header and sections:

form section for creating a sub resource, like our mappings:

[yaacov]

Notes:
a. In the case of deployment they implemented a yaml view, we can add it in some future
b. The added the name of the container above the container spec, it looks easy to implement in our case:
so we can add NetworkMap: [NP] name... above the mapping list input

p.s.
name of networkMap and storageMap (and hook that we will not create here) objects is the same as the plan name, no need to add "map" as postfix or suffix because it has a different kind, so no overlapping names

[yaacov]

Note:
when editing the new plan name - remember to validate a valid k8s name + no plan with this name exist in this namespace

[yaacov]

Ref: #690 - make sure all sources net and storage are mapped when creating the default mappings

[yaacov]

Notes from demo for 2.6 milestone:
a. create a warning/error https://www.patternfly.org/components/alert when the mappings are re-set by changing the target.
b. create a warning/error for mappings we know are problematic:
- missing mappings for storage or network known to be used by vms
- empty mappings, even if the vms don't use any storage or mappings

[rszwajko]

@liranr23 @bennyz @ahadas @bkhizgiy
Below extra validations that we could implement to check the plan before creating. Please vote by giving thumbs up/down.

[rszwajko]

(error) Equivalent of VMNetworksNotMapped

[rszwajko]

(error) Equivalent of VMStorageNotMapped

[rszwajko]

(error) Equivalent of VMMultiplePodNetworkMappings

[rszwajko]

(error) Target namespace is the same as source namespace - a case where source provider and target provider are the same resource or point to the same environment (checked by comparing spec.url )

[liranr23]

(error) Target namespace is the same as source namespace - a case where source provider and target provider are the same resource or point to the same environment (checked by comparing spec.url )

is it even possible? i guess it's only OCP to OCP @bennyz

[rszwajko]

@liranr23

i guess it's only OCP to OCP

right. this is a special case of migrating VMs in the same k8s cluster (between different namespaces).

[yaacov]

Addressed by #899