On 23/04/15 23:25, James Slagle wrote:
On Tue, Apr 21, 2015 at 5:23 PM, Ben Nemec <openst...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
