gce: support preemptible instances

[jparal]

it seems that libcloud supports preemptible instances on GCE using ex_preemptible argument:

http://libcloud.readthedocs.org/en/latest/compute/drivers/gce.html

any plans on supporting this in salt-cloud? thx

[jfindlay]

@jparal, thanks for reporting. I think this is something that we can support.

[cconrad]

+1

[rodoyle]

+1

It appears that the kwargs dictionary in the gce client is simply not bringing in the 'ex_preemptible' setting. It could be as simple as extending this, though how to test it properly escapes me at the moment.

[OrlandoArcapix]

Just quickly patched this in to gce.py and tested working okay:

index 9a4f5e3..e7bfa10 100644
--- a/salt/cloud/clouds/gce.py
+++ b/salt/cloud/clouds/gce.py
@@ -2255,7 +2255,9 @@ def request_instance(vm_):
             'ex_service_accounts': config.get_cloud_config_value(
                 'ex_service_accounts', vm_, __opts__, default=None),
             'ex_can_ip_forward': config.get_cloud_config_value(
-                'ip_forwarding', vm_, __opts__, default=False
+                'ip_forwarding', vm_, __opts__, default=False),
+           'ex_preemptible': config.get_cloud_config_value(
+               'preemptible', vm_, __opts__, default=False
             )
         })
         if kwargs.get('ex_disk_type') not in ('pd-standard', 'pd-ssd'):

Together with the option in the cloud-profile

  preemptible: true

User test results after creating one with "preemptible: true" and one without preemptible set as an option:

$ gcloud compute instances list | egrep '(preempt|NAME)'
NAME                 ZONE            MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP     STATUS
notpreempttest01     europe-west1-b  n1-standard-1               xx.xxx.x.x   xxx.xxx.xxx.xx  RUNNING
preempttest01        europe-west1-b  n1-standard-1  true         xx.xxx.x.x   xxx.xxx.xx.x    RUNNING

Looks like it will require libcloud > 0.20.0: https://libcloud.readthedocs.io/en/latest/changelog.html#id31

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.