User story:

As a user participating in the OSD GCP Virt Tech Preview, I want to have the ability to change the secure boot setting when creating a secondary machine pool inside a OSD GCP cluster so that I can use C3 machine instances.

Additional information

Machine pools inherit the secure boot setting from the cluster. If a cluster is created with secure boot enabled, the new C3 machine types cannot be used when creating a machine pool.

Adding the ability to change the secure boot will allow customers participating to the Tech Preview phase to create machine pools using the newly introduced machine types.

The machine pool level secure boot will be implemented behind a feature flag but it can be considered as a prerequisite for OSD GCP Virt. It will be released to everyone, not only to the Tech Preview participants.

Acceptance criteria:

• When creating a new machine pool for OSD GCP clusters, a new secure boot field will be shown in the machine pool form. 
• The default value of secure boot will be inherited from the cluster
• The user will be able to change the initial setting (turning on or off secure boot)
• We are going to include the `secure_boot` property inside the payload to create the machine pool only if the value is different from the one inherited from the cluster. We are going to do this to keep the distinction between machine pools inheriting the setting and machine pools overriding it.
• The secure boot setting of a machine pool cannot be changed after its creation. The field must be disabled when editing a machine pool. The secure boot value of an existing machine pool will be retrieved from the machine pool if present, otherwise it will be the one inherited from the cluster.

Mockups/Design (if available)

See initial mockup here

The same field we use inside the cluster creation wizard will be added to the machine pool form.

Labels/tooltips to be confirmed.

The same field will be displayed as disabled when editing machine pools. We have to add to the tooltip or below the field description that secure boot cannot be changed after creating a machine pool.

Out of scope

No contextual validation must be provided by the UI at this time.

When trying to create a new secondary machine pool using a machine type not compatible with the existing secure boot setting, the back-end will handle the error with a pre-flight check and the request to create the machine pool will fail. 

At this point we are not showing the secure boot property of machine pools inside the machine pool list of a cluster.

Implementation notes

APIs already support providing the secure boot setting when creating a machine pool.

The endpoint is:

POST api/clusters_mgmt/v1/clusters/{cluster_id}/machine_pools

The payload will include the secure boot setting like this:

{
   ...
   gcp: {
     secure_boot: true,
   },
}

The secure boot setting must be included only if it's different from the cluster one. Otherwise we will just let the MP inherit the configuration from the cluster.