Bug 988451

Summary: [Doc] Add a hostgroup to Foreman for a deploying an OpenStack Controller node with Quantum
Product: Red Hat OpenStack Reporter: Stephen Gordon <sgordon>
Component: doc-Deploying_OpenStack_Enterprise_EnvironmentsAssignee: Tahlia Richardson <trichard>
Status: CLOSED CURRENTRELEASE QA Contact: ecs-bugs
Severity: medium Docs Contact:
Priority: medium    
Version: 5.0 (RHEL 6)CC: adahms, ccrouch, jguiditt, jlabocki, rhos-maint, slong, trichard, yeylon
Target Milestone: ---Keywords: Documentation, Triaged
Target Release: 5.0 (RHEL 7)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 970283 Environment:
Last Closed: 2014-10-15 00:01:27 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 970283    
Bug Blocks: 1010310, 1049118    

Description Stephen Gordon 2013-07-25 15:50:28 UTC
+++ 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-26 00:38:59 UTC
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

Comment 3 Jason Guiditta 2013-12-02 15:31:11 UTC
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 23:44:35 UTC
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

Comment 5 Martin Lopes 2013-12-05 01:14:52 UTC
*** Bug 1033238 has been marked as a duplicate of this bug. ***

Comment 6 Summer Long 2014-01-10 06:54:38 UTC
Will do this together with the other foreman-neutron updates.

Comment 7 Summer Long 2014-01-19 23:31:15 UTC
Scott, I believe you've already done this one together with Mike's other updates, will just need to update the ticket.