extra_create_args for rax module

[Josh Smift]

We want to use the rax module to create instances of the "Memory" flavor,
and are getting an error like

msg: Policy doesn't allow memory_flavor:create:image_backed to be performed.

when we try. https://github.com/chef/knife-rackspace/issues/91 looks like
a similar issue for Chef, where they concluded that

If you use any of the compute or memory flavors, the only available boot
source is boot-from-volume.

and

To support these flavors, we'll need the ability to specify
boot-from-volume from knife-rackspace.

Separately, when we opened a Rackspace ticket about this, the tech there
said

The takeaway is that image_id should be present but blank, and you need
a block_device_mapping parameter (or boot_image_id if you were using a
Ruby based tool).

Does the Ansible rax module support this, possibly with extra_create_args?
If so, anyone have an example of how exactly to use it?
http://docs.ansible.com/rax_module.html just says "A hash of key/value
pairs to be used when creating a new server. This is considered an
advanced option, use it wisely and with caution. (added in Ansible 1.6)"
and the rax module code didn't seem to have any other obvious details.

-Josh (j...@care.com)



This email is intended for the person(s) to whom it is addressed and may contain information that is PRIVILEGED or CONFIDENTIAL. Any unauthorized use, distribution, copying, or disclosure by any person other than the addressee(s) is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and delete the message and any attachments from your system.

[Matt Martz]

Josh,

Ansible 1.8 does not support boot from volume for rax servers.  1.9 will however support this properly:

https://github.com/ansible/ansible-modules-core/pull/798

https://github.com/ansible/ansible/pull/10259

extra_create_args unfortunately doesn't give you full enough control over the module to boot from volume, due to variable checking and what is sent to the API previously.

In order to use this functionality now, it requires current devel of both of the above referenced repositories, or at minimum, copying all affected files from those PRs into a 1.8 install.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/21735.33044.533474.419497%40gargle.gargle.HOWL.
For more options, visit https://groups.google.com/d/optout.

--

Matt Martz
@sivel
sivel.net

[Josh Smift]

MM> Ansible 1.8 does not support boot from volume for rax servers. 1.9
MM> will however support this properly:
MM>
MM> https://github.com/ansible/ansible-modules-core/pull/798
MM> https://github.com/ansible/ansible/pull/10259
MM>
MM> extra_create_args unfortunately doesn't give you full enough control
MM> over the module to boot from volume, due to variable checking and what
MM> is sent to the API previously.

Aha, ok, cool. I'm playing with a clone of devel, and making some
progress, but one thing we're having trouble with is using rax.py to get
our inventory. I'm using the rax.py from devel, and it seems to be failing
with a pyrax exception:

pyrax.exceptions.BadRequest: n/a (HTTP 400)

I can send along the full stack trace if need be. We have pyrax installed
via pip, and it's version 1.6.2. Do we need a newer version?

[Josh Smift]

JBS> I'm playing with a clone of devel, and making some progress, but one
JBS> thing we're having trouble with is using rax.py to get our inventory.
JBS> I'm using the rax.py from devel, and it seems to be failing with a
JBS> pyrax exception:
JBS>
JBS> pyrax.exceptions.BadRequest: n/a (HTTP 400)

This appears to have been a connectivity problem, since resolved. Never mind!