Open Stack

We created a new board where we'll track the efforts for the all-in-one
installer:
https://trello.com/b/iAHhAgjV/tripleo-all-in-one-installer

Note: please do not use the containerized undercloud dashboard for these
tasks, it is a separated effort.
Feel free to join the board and feed the backlog!

Thanks,

On Thu, Apr 5, 2018 at 10:02 AM, Dan Prince <dprince at redhat.com> wrote:

> On Thu, Apr 5, 2018 at 12:24 PM, Emilien Macchi <emilien at redhat.com>
> wrote:
> > On Thu, Apr 5, 2018 at 4:37 AM, Dan Prince <dprince at redhat.com> wrote:
> >
> >> Much of the work on this is already there. We've been using this stuff
> >> for over a year to dev/test the containerization efforts for a long
> >> time now (and thanks for your help with this effort). The problem I
> >> think is how it is all packaged. While you can use it today it
> >> involves some tricks (docker in docker), or requires you to use an
> >> extra VM to minimize the installation footprint on your laptop.
> >>
> >> Much of the remaining work here is really just about packaging and
> >> technical debt. If we put tripleoclient and heat-monolith into a
> >> container that solves much of the requirements problems and
> >> essentially gives you a container which can transform Heat templates
> >> to Ansible. From the ansible side we need to do a bit more work to
> >> mimimize our dependencies (i.e. heat hooks). Using a virtual-env would
> >> be one option for developers if we could make that work. I lighter set
> >> of RPM packages would be another way to do it. Perhaps both...
> >> Then a smaller wrapper around these things (which I personally would
> >> like to name) to make it all really tight.
> >
> >
> > So if I summarize the discussion:
> >
> > - A lot of positive feedback about the idea and many use cases, which is
> > great.
> >
> > - Support for non-containerized services is not required, as long as we
> > provide a way to update containers with under-review patches for
> developers.
>
> I think we still desire some (basic no upgrades) support for
> non-containerized baremetal at this time.
>
> >
> > - We'll probably want to breakdown the "openstack undercloud deploy"
> process
> > into pieces
> > * start an ephemeral Heat container
>
> It already supports this if use don't use the --heat-native option,
> also you can customize the container used for heat via
> --heat-container-image. So we already have this! But rather than do
> this I personally prefer the container to have python-tripleoclient
> and heat-monolith in it. That way everything everything is in there to
> generate Ansible templates. If you just use Heat you are missing some
> of the pieces that you'd still have to install elsewhere on your host.
> Having them all be in one scoped container which generates Ansible
> playbooks from Heat templates is better IMO.
>
> > * create the Heat stack passing all requested -e's
> > * run config-download and save the output
> >
> > And then remove undercloud specific logic, so we can provide a generic
> way
> > to create the config-download playbooks.
>
> Yes. Lets remove some of the undercloud logic. But do note that most
> of the undercloud specific login is now in undercloud_config.py anyway
> so this is mostly already on its way.
>
> > This generic way would be consumed by the undercloud deploy commands but
> > also by the new all-in-one wrapper.
> >
> > - Speaking of the wrapper, we will probably have a new one. Several names
> > were proposed:
> > * openstack tripleo deploy
> > * openstack talon deploy
> > * openstack elf deploy
>
> The wrapper could be just another set of playbooks. That we give a
> name too... and perhaps put a CLI in front of as well.
>
> >
> > - The wrapper would work with deployed-server, so we would noop Neutron
> > networks and use fixed IPs.
>
> This would be configurable I think depending on which templates were
> used. Noop as a default for developer deployments but do note that
> some services like Neutron aren't going to work unless you have some
> basic network setup. Noop is useful if you prefer to do this manually,
> but our os-net-config templates are quite useful to automate things.
>
> >
> > - Investigate the packaging work: containerize tripleoclient and
> > dependencies, see how we can containerized Ansible + dependencies (and
> > eventually reduce them at strict minimum).
> >
> > Let me know if I missed something important, hopefully we can move things
> > forward during this cycle.
> > --
> > Emilien Macchi
>



-- 
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180426/0fb0c9de/attachment.html>