Open Stack

On 23/04/15 23:25, James Slagle wrote:
> On Tue, Apr 21, 2015 at 5:23 PM, Ben Nemec <openstack at nemebean.com> wrote:
>> On 04/20/2015 04:39 PM, Steve Baker wrote:
>>> I've been spending some time getting quintupleo working on top of a Juno
>>> RDO OpenStack. I'm at a point now where I think it is worth putting
>>> effort into making it easy for anyone to try this.
>> \o/
>>
>>> Ben Nemec has done the hard work of proving this is possible[1]
>>> resulting in the repo he uses to bring up an environment which behaves
>>> like a baremetal env[2]
>>>
>>> I'd like to build on this to create a new upstream repo aimed at setting
>>> up an environment which is ready for undercloud and overcloud installation.
>>>
>>> For rdo-management, using it would be documented in its own section of
>>> the Setup chapter[3]
>>>
>>> Ben's heat templates bring up BMC and baremetal nodes. I've been
>>> extending those to also define the undercloud network and a bare
>>> undercloud node ready for undercloud installation (or optionally an
>>> image-based undercloud).  Another future enhancement could be to figure
>>> out how to use only a single nova server serve all of the BMC requests
>>> (possibly with one server having a neutron port per baremetal it is
>>> managing)
>>>
>>> This will still require patching the nethercloud until we can find a way
>>> of upstreaming those changes. The repo can at least be where those
>>> patches live for now.
>>>
>>> So my questions for now would be:
>>>
>>> What should the repo be called? quintuplo-setup?
>> Or just quintupleo.  I doubt we're going to have a lot of problems with
>> name collisions. :-)
>>
>>> Where should it live? git openstack in the openstack namespace? github
>>> rdo-management?
>> I'm not sure, but a few thoughts:
>>
>> It requires hackery of the underlying cloud.  I'm wondering if that
>> disqualifies it from the openstack namespace.
>>
>> It's only known to work with the instack-undercloud workflow.  In theory
>> that means it should be able to work with devtest, but at the moment we
>> haven't actually used the two together.  Which makes me wonder if it
>> should just go in the rdo-management tree, but on the other hand I know
>> there are people interested in it outside of RDO, so I'm not sure that's
>> a perfect fit either.
>>
>> So given that I'm pretty undecided about where this belongs, maybe
>> stackforge would be a good choice until we decide where it's going?
> We've already had a lot of discussion around the spec[1], and it's
> approved, so stackforge seems like the wrong place to me.
>
> Quintupleo feels more incubator-ish. So why not tripleo-incubator? A
> separate directory with the documentation and templates would probably
> be a good start.
OK, I've started with this:
https://review.openstack.org/#/c/177032/

which is a combination a stripped-back rdo-management documentation and 
this:
https://github.com/steveb/quintupleo


> As for the hacks on the underlying projects, I'd say
> propose them to the affected projects in gerrit (even if WIP'd for
> now), and then document how to setup a cloud with those patches.
They are a directory of patches to juno and kilo for now, ie
https://review.openstack.org/#/c/177032/1/quintupleo/patches/kilo/README.md

> Getting the proposed patches out there (if not done already)  would
> probably help us work through what it's going to take to eventually
> get them landed, or if we need to go an entirely different direction.
I wonder if the neutron patch would be better telling the user to switch 
to the noop firewall driver, but that hammer might be too big.

> [1] http://specs.openstack.org/openstack/tripleo-specs/specs/juno/tripleo-on-openstack.html
>