Bug 988451 - [Doc] Add a hostgroup to Foreman for a deploying an OpenStack Controller node with Quantum
[Doc] Add a hostgroup to Foreman for a deploying an OpenStack Controller node...
Product: Red Hat OpenStack
Classification: Red Hat
Component: doc-Deploying_OpenStack_Enterprise_Environments (Show other bugs)
5.0 (RHEL 6)
Unspecified Unspecified
medium Severity medium
: ---
: 5.0 (RHEL 7)
Assigned To: Tahlia Richardson
: Documentation, Triaged
: 1033238 (view as bug list)
Depends On: 970283
Blocks: 1010310 1049118
  Show dependency treegraph
Reported: 2013-07-25 11:50 EDT by Stephen Gordon
Modified: 2016-04-26 13:53 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 970283
Last Closed: 2014-10-14 20:01:27 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Stephen Gordon 2013-07-25 11:50:28 EDT
+++ 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)
Comment 2 Martin Lopes 2013-11-25 19:38:59 EST
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?

Comment 3 Jason Guiditta 2013-12-02 10:31:11 EST
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.
Comment 4 Martin Lopes 2013-12-04 18:44:35 EST
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?

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:

Comment 5 Martin Lopes 2013-12-04 20:14:52 EST
*** Bug 1033238 has been marked as a duplicate of this bug. ***
Comment 6 Summer Long 2014-01-10 01:54:38 EST
Will do this together with the other foreman-neutron updates.
Comment 7 Summer Long 2014-01-19 18:31:15 EST
Scott, I believe you've already done this one together with Mike's other updates, will just need to update the ticket.

Note You need to log in before you can comment on or make changes to this bug.