Re: [openstack-dev] Fwd: [tripleo] PTG session about All-In-One installer: recap & roadmap

[Emilien Macchi]

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  wrote:

> On Thu, Apr 5, 2018 at 12:24 PM, Emilien Macchi 
> wrote:
> > On Thu, Apr 5, 2018 at 4:37 AM, Dan Prince  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
__
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

Re: [openstack-dev] Fwd: [tripleo] PTG session about All-In-One installer: recap & roadmap

[Dan Prince]

On Thu, Apr 5, 2018 at 12:24 PM, Emilien Macchi  wrote:
> On Thu, Apr 5, 2018 at 4:37 AM, Dan Prince  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

__
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

Re: [openstack-dev] Fwd: [tripleo] PTG session about All-In-One installer: recap & roadmap

[Wesley Hayutin]

On Thu, 5 Apr 2018 at 12:25 Emilien Macchi  wrote:

> On Thu, Apr 5, 2018 at 4:37 AM, Dan Prince  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.
>

Hrm..  I was just speaking to Alfredo about this.  We may need to have a
better understanding of the various ecosystems where TripleO is in play
here to have a fully informed decision.
By ecosystem I'm referring to RDO, centos, and upstream and the containers
used in deployments.  I suspect a non-containerized deployment may still be
required, but looking for the packaging team to weigh in.


>
> - We'll probably want to breakdown the "openstack undercloud deploy"
> process into pieces
> * start an ephemeral Heat container
> * 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.
> 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 would work with deployed-server, so we would noop Neutron
> networks and use fixed IPs.
>
> - 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
> __
> 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
>
__
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

Re: [openstack-dev] Fwd: [tripleo] PTG session about All-In-One installer: recap & roadmap

[Emilien Macchi]

On Thu, Apr 5, 2018 at 4:37 AM, Dan Prince  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.

- We'll probably want to breakdown the "openstack undercloud deploy"
process into pieces
* start an ephemeral Heat container
* 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.
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 would work with deployed-server, so we would noop Neutron
networks and use fixed IPs.

- 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
__
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