+++ This bug was initially created as a clone of Bug #970283 +++ The version Foreman which will ship in RHOS3.0 will have support built in for two "hostgroups" (i.e. templates to which machines can be associated with) 1) All-in-one controller node: Includes all of the basic OpenStack services: nova, keystone, glance, horizon etc. Uses nova-networking. 2) Compute node: Includes services sufficient to allow the machine to be used as a host for compute instances So there is no out-of-the box support for Quantum, though customers are free to use the base puppet classes to create their own hostgroup which deploys quantum related services. Note: such hostgroups have not been tested as part of RHOS3.0 When discussing what options there were to support quantum we came up with the following options: > Hostgroups Option 1) > a) all-in-one controller node with nova networking (but with the ability, > through Foreman variables, to disable nova networking) > b) quantum server node > c) compute node > > Hostgroups Option 2) > a) all-in-one controller node with nova networking (just what we have today) > b) all-in-one controller node with quantum (nova networking is not > present/permanently disabled) > c) compute node > > Some potential customer deployment scenarios could be: > > One machine with 1a) and lots with 1c) > or > One machine with 1a) (disable nova networking) and one machine with 1b) and > lots with 1c) > > alternatively: > > One machine 2a) and lots with 2c) > One machine 2b) and lots with 2c) >
Hi Jason, Could you describe BZ#970283's impact to hostgroup definitions in Havana? i.e. Is Neutron being added to the Openstack Controller definition, or is there a new "Networking Node" hostgroup definition? Thanks, Martin
Martin, the Neutron support in current form adds 3 new host groups in foreman, as you saw: 1. Neutron Controller - this has all the same services as the Nova Networking controllers, but with neutron server enabled instead of nova networking 2. Networker Node - this is basically the neutron agents (dhcp, metadata, l3), as described here: http://docs.openstack.org/havana/install-guide/install/yum/content/neutron-install.dedicated-network-node.html 3. Compute node - again, this is the same as the previous compute node using nova networking, but with the required bits to have it use neutron and point at the neutron server, as well as the ova agent (bridge uplinks and mappings). Note that we are considering consolidating these back into a single set of host groups for maintenance purposes, in which case the above would still be true with the following tweak to how it appears: Nova Networking Version: 1. Controller, set networking type to nova_networking 2. Compute node, set networking type to nova_networking Neutron Version: 1. Controller, set networking type to neutron 2. Networker node, same as described above 3. Compute node, set networking type to neutron I am not sure we will be able to land this in time, but it would make a difference from your perspective only in that there would be a smaller list of host groups, with a small extra bit of config to decide which type of networking the user wants to use. Let me know if further information is needed here.
On 03/12/13 03:01 -0500, Martin Lopes wrote: >Hi Jason, > >Thanks for getting me up to speed. Is the host group consolidation likely to happen in Havana? > >cheers, >Martin Yes, it is likely to happen for havana, there is a patch under review right now which I am hopeful will be able to get into our next rpm release (perhaps end of this week, beginning of next, I haven't been given a certain time to request an updated one). Note that this BZ is related, so the list of host groups would become shorter as part of this: https://bugzilla.redhat.com/show_bug.cgi?id=1033232 -j
*** Bug 1033238 has been marked as a duplicate of this bug. ***
Will do this together with the other foreman-neutron updates.
Scott, I believe you've already done this one together with Mike's other updates, will just need to update the ticket.