Can "travis-worker" for openstack backend spin up VM instance using "volume"

[ghatwala]

Hi All,

In an Openstack environment , would there be a worker support in spinning up VM instance using "volume" as "booting source" besides "image".

As seen from here - https://github.com/travis-ci/worker/blob/master/backend/openstack.go. It appears to me that feature support of "booting from volume" is not present. Seems this booting option is yet to be added from here - https://github.com/rackspace/gophercloud/tree/master/openstack/compute/v2/extensions/bootfromvolume

Please let me know if my understanding is correct and what are the plans if any to add below options for "openstack" backend.

1. Select Boot Source --> "volume"
2. Delete Volume on Instance Delete --> "yes" or "no" (options)

[michal-at-travisci]

Hi @ghatwala

Could you elaborate on use case behind question?

[ghatwala]

Hi @michal-at-travisci - Giving some history here - This request originated from a Travis/power build slowness for "containerd" - containerd/containerd#3491 (comment).

Analysis proved that the power jobs were failing at OSU whereas passing at PDC ( We have two openstack based data centers ( PDC and OSU ) for supporting power builds at travis-ci.org )
Further analysis of OSU env pointed to HDD being the culprit , alternative suggested was to use SSD available there to spin with VMs via travis-worker hosted there for openstack backend.

As we know worker with openstack backend currently lacks the support to spin up VMs with "booting from volume" option , as that feature support was not added from here -
https://github.com/rackspace/gophercloud/tree/master/openstack/compute/v2/extensions/bootfromvolume

So wanted to know

• if anyone at travis has tried adding "booting from volume" support for worker ( openstack backend based ) ?

• Is there some sort of whitelist mechanism using which a specific project's travis builds(power only) can be routed to a specific place ( AFAIK , there's just one power queue created at Travis-scheduler which caters to both PDC and OSU (https://github.com/travis-ci/travis-scheduler/blob/master/spec/travis/queue_spec.rb#L32 ). This workaround if implemented will get the containerd's travis job - https://travis-ci.org/containerd/containerd/jobs/568051827 to PDC environment wherein it always passes.

Please let me know your opinion/thoughts ?

[clnperez]

Whatever happened to all this investigation? :D

[ghatwala]

@clnperez - FYI , Above option was needed when Travis workers (for ppc64le) were running on a openstack backend , However post github universe , Travis officially supports LXD containers builds now( workers are at IBM cloud now). There is still the older legacy job queue active at Travis which caters to VM based jobs at "travis-ci.org" , however the plan is move everyone to new backend (LXD) as early as possible. There is a future plan to give option to user to deploy power jobs on LXD containers or VM will let @michal-at-travisci to add more .