[openstack-dev] [tripleo] Adventures in QuintupleO
sbaker at redhat.com
Thu Apr 23 23:21:11 UTC 2015
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.
>>> Ben Nemec has done the hard work of proving this is possible
>>> resulting in the repo he uses to bring up an environment which behaves
>>> like a baremetal env
>>> 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
>>> 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
>>> 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
>> 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, 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:
which is a combination a stripped-back rdo-management documentation and
> 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
> 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.
>  http://specs.openstack.org/openstack/tripleo-specs/specs/juno/tripleo-on-openstack.html
More information about the OpenStack-dev