Integrating OpenStack Networking and OpenStack Compute

[Carl Perry]

As we start adding Quantum^H^H^H^H^H^HOpenStack Networking (man I miss
codenames) support to our cookbooks, I'm thinking we may want to adopt
the same "wrap+extend" strategy with OpenStack Compute that we do with
OpenStack Networking. The reason for this is networking drivers. Almost
all of the networking drivers require configuration changes to nova.conf
in order for it to integrate. This makes me think we might want to
simply have a bare compute cookbook, and then you install another that
wraps it for the correct networking options (ex "compute-ovs",
"compute-midonet", "compute-ryu").

Thoughts? Is this already getting too complicated? If so, alternatives?

-Carl

[Craig Tracey]

Hi Carl, 

This is also a concern of mine. I am interesting in hacking on the idea that you had proposed a while back: using the newly implemented conf.d support that I believe is part of Oslo.  I like this idea, but I may be assuming a few things - namely that conf.d support works seamlessly across various platforms/packages as well as that nova.conf is sufficiently composable to handle this kind of tweaking in a sensible manner.

Does this sound like a reasonable activity to you?

Best,

Craig

  -Carl

--
You received this message because you are subscribed to the Google Groups "opscode-chef-openstack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opscode-chef-open...@googlegroups.com.
To post to this group, send email to opscode-che...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/opscode-chef-openstack/51A6B3E2.1040308%40edolnx.net?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Carl Perry]

I was thinking this would need to be implemented with conf.d either way - all the projects support it, we just need to add a line to the main configuration file to use the conf.d directory. However, what writes the contents of that directory is the issue. The networking piece would have to be custom to each plugin, and instead of having all that code in the compute cookbook it may be better to use the wrapper pattern we are adopting elsewhere. We could also make it the responsibility of the plugin's cookbook to have a recipe which writes the nova.conf.d/networking file. There are advantages and disadvantages to both:

Wrapping has the advantage of explicitly knowing there is only one driver called. The disadvantage is lots of wrappers and slightly more obfuscation of code.

A recipe in the driver cookbook has the advantage of all the code for the networking driver being the same place. The disadvantages are easier to use more than one accidentally, and adding another entry to the run list for the node.

I'm fine with either approach, I'd just like some feedback before taking one :)

  -Carl

To view this discussion on the web visit https://groups.google.com/d/msgid/opscode-chef-openstack/CAFMAOgDpry2tPVuEwFBEV6iRAaj%2BgHVfooEtn7robV9F65tkhg%40mail.gmail.com?hl=en.