Sahara/PluggableProvisioning/ClusterLifecycle
Contents
Cluster Lifecycle for Templates Mode
The ‘cluster’ object is passed as an argument to several functions. It could be used to both get cluster configuration and change it. During these invocations the object has some fields blank.
validate_cluster(...) and update_infra(...) both receive cluster with the same set of fields set. The validate_cluster(...) must not change the cluster object, while update_infra(...) can (and for some fields must) do some adjustments. Below is the list of fields which will not be set at the time of invocation. All comments stating that plugin can or must adjust some field are for update_infra(...) function only:
- image - plugin must set that field. It is assumed that plugin set this field to either default_image from parent cluster object or an image obtained from Image Registry.
- instances. At that point cluster instances are not yet created.
The plugin could completely rewrite node_groups field. It is assumed that the plugin will use this ability to add specs for management nodes if needed or something like that.
configure_cluster(...) and start_cluster(...) both receive ‘cluster’ object with all fields set.
Cluster Lifecycle for Config File Mode
The previous section covered cluster creation with templates. This section elaborates on creating cluster from provider-specific config file.
In this mode, user starts creating cluster with providing provider-specific configuration file. Savanna passes that file to the plugin’s convert(...) method along with empty ‘cluster’ object. Plugin is expected to parse cluster configuration from the file and populate ‘cluster’ object with cluster topology.
After convert(...) returns, Savanna shows the cluster dialog to the user. In the dialog user can change number of nodes and flavors of node groups. See cluster mockups on the wiki for clarity. After user submits the form, the flow goes through the same cycle as for Templates mode, except one thing:
Neither cluster_configs nor node_configs will be provided to the plugin. It is up to the plugin if it uses these fields. Alternatively plugin can save the config file in extra field and use it later.
Cluster Lifecycle Colourgram
Below is the description of Savanna core and plugin’s responsibility for cluster object for each phase of its lifecycle. Color legend for fields:
colour | is set | modifiable | must be specified? |
---|---|---|---|
black | yes | - | - |
grey | - | - | - |
underlined blue | yes | yes | - |
blue | - | yes | - |
red | - | yes | yes |
convert(cluster)
cluster: name plugin_name default_image cluster_configs node_groups: name flavor image node_processes node_configs anti_affinity_group count instances: id ip credentials extra extra extra
validate_cluster(cluster)
cluster: name plugin_name default_image cluster_configs node_groups: name flavor image node_processes node_configs anti_affinity_group count instances: id ip credentials extra extra extra
update_infra(cluster)
cluster: name plugin_name default_image cluster_configs node_groups: name flavor image node_processes node_configs anti_affinity_group count instances: id ip credentials extra extra extra
configure_cluster(cluster), start_cluster(cluster)
cluster: name plugin_name default_image cluster_configs node_groups: name flavor image node_processes node_configs anti_affinity_group count instances: id ip credentials extra extra extra