[Rdo-list] packstack future

[Jeff Peeler]

On Tue, Sep 8, 2015 at 10:42 AM, James Slagle <jslagle at redhat.com> wrote:

> On Mon, Sep 07, 2015 at 02:07:56PM +0100, Steven Hardy wrote:
> > Hi Tim,
> >
> > On Sun, Sep 06, 2015 at 07:35:30AM +0000, Tim Bell wrote:
> > >    Reading the RDO September newsletter, I noticed a mail thread
> > >    (https://www.redhat.com/archives/rdo-list/2015-August/msg00032.html)
> on
> > >    the future of packstack vs rdo-manager.
> > >
> > >    We use packstack to spin up small OpenStack instances for
> development and
> > >    testing. Typical cases are to have a look at the features of the
> latest
> > >    releases or do some prototyping of an option we've not tried yet.
> > >
> > >    It was not clear to me based on the mailing list thread as to how
> this
> > >    could be done using rdo-manager unless you already have the
> undercloud
> > >    configiured by RDO.
> >
> > >    Has there been any further discussions around packstack future ?
> >
> > Thanks for raising this - I am aware that a number of folks have been
> > thinking about this topic (myself included), but I don't think we've yet
> > reached a definitive consensus re the path forward yet.
> >
> > Here's my view on the subject:
> >
> > 1. Packstack is clearly successful, useful to a lot of folks, and does
> > satisfy a use-case currently not well served via rdo-manager, so IMO we
> > absolutely should maintain it until that is no longer the case.
> >
> > 2. Many people are interested in easier ways to stand up PoC environments
> > via rdo-manager, so we do need to work on ways to make that easier (or
> even
> > possible at all in the single-node case).
> >
> > 3. It would be really great if we could figure out (2) in such a way as
> to
> > enable a simple migration path from packstack to whatever the PoC mode of
> > rdo-manager ends up being, for example perhaps we could have an rdo
> manager
> > interface which is capable of consuming a packstack answer file?
> >
> > Re the thread you reference, it raises a number of interesting questions,
> > particularly the similarities/differences between an all-in-one packstack
> > install and an all-in-one undercloud install;
> >
> > >From an abstract perspective, installing an all-in-one undercloud looks
> a
> > lot like installing an all-in-one packstack environment, both sets of
> tools
> > take a config file, and create a puppet-configured all-in-one OpenStack.
> >
> > But there's a lot of potential complexity related to providing a
> > flexible/configurable deployment (like packstack) vs an opinionated
> > bootstrap environment (e.g the current instack undercloud environment).
>
> Besides there being some TripleO related history (which I won't bore
> everyone
> with), the above is a big reason why we didn't just use packstack
> originally to
> install the all-in-one undercloud.
>
> As you point out, the undercloud installer is very opinionated by design.
> It's
> not meant to be a flexible all-in-one *OpenStack* installer, nor do I
> think we
> want to turn it into one. That would just end up in reimplementing
> packstack.
>
> >
> > There are a few possible approaches:
> >
> > - Do the work to enable a more flexibly configured undercloud, and just
> >   have that as the "all in one" solution
>
> -1 :).
>
> > - Have some sort of transient undercloud (I'm thinking a container) which
> >   exists only for the duration of deploying the all-in-one overcloud, on
> >   the local (pre-provisioned, e.g not via Ironic) host.  Some prototyping
> >   of this approach has already happened [1] which I think James Slagle
> has
> >   used to successfully deploy TripleO templates on pre-provisioned nodes.
>
> Right, so my thinking was to leverage the work (or some part of it) that
> Jeff
> Peeler has done on the standalone Heat container as a bootstrap mechanism.
> Once
> that container is up, you can use Heat to deploy to preprovisoned nodes
> that
> already have an OS installed. Not only would this be nice for POC's, there
> are
> also real use cases where dedicated provisioning networks are not
> available, or
> there's no access to ipmi/drac/whatever.
>

Perhaps off topic, but are people still interested in the Heat standalone
container work? I never received any replies on the openstack-dev list when
I asked for direction on how to best integrate with TripleO. I need to
bring it up to date to work with recent changes of Kolla (and will do so if
people are interested after getting the ironic containers completed).

http://lists.openstack.org/pipermail/openstack-dev/2015-August/071613.html


>
> It would also provide a solution on how to orchestrate an HA undercloud as
> well.
>
> Note that the node running the bootstrap Heat container itself could
> potentially be reused, providing for the true all-in-one.
>
> I do have some hacked on templates I was working with, and had made enough
> progress to where I was able to get the preprovisoned nodes to start
> applying the
> SoftwareDeployments from Heat after I manually configured
> os-collect-config on
> each node.
>
> I'll get those in order and push up a WIP patch.
>
> There are a lot of wrinkles here still, things like how to orchestrate the
> manual config you still have to do on each node (have to configure
> os-collect-config with a stack id), and assumptions on network setup, etc.
>
> >
> > The latter approach is quite interesting, because it potentially
> maintains
> > a greater degree of symmetry between the minimal PoC install and real
> > production deployments (e.g you'd use the same heat templates etc), it
> > could also potentially provide easier access to features as they are
> added
> > to overcloud templates (container integration, as an example), vs
> > integrating new features in two places.
> >
> > Overall at this point I think there are still many unanswered questions
> > around enabling the PoC use-case for rdo-manager (and, more generally
> > making TripleO upstream more easily consumable for these kinds of
> > use-cases).  I hope/expect we'll have a TripleO session on this at the
> > forthcoming summit, where we refine the various ideas people have been
> > investigating, and define the path forward wrt PoC deployments.
>
> So I did just send out the etherpad link for our session planning for Tokyo
> this morning to openstack-dev :)
>
> https://etherpad.openstack.org/p/tripleo-mitaka-proposed-sessions
>
> I'll add a bullet item about this point.
>
> >
> > Hopefully that is somewhat helpful, and thanks again for re-starting this
> > discussion! :)
> >
> > Steve
> >
> > [1] https://etherpad.openstack.org/p/noop-softwareconfig
> >
> --
> -- James Slagle
> --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20150908/b7f48579/attachment.html>