Open Stack

On Tue, Apr 3, 2018 at 9:23 AM, James Slagle <james.slagle at gmail.com> wrote:
> On Mon, Apr 2, 2018 at 9:05 PM, Dan Prince <dprince at redhat.com> wrote:
>> On Thu, Mar 29, 2018 at 5:32 PM, Emilien Macchi <emilien at redhat.com> wrote:
>>> Greeting folks,
>>>
>>> During the last PTG we spent time discussing some ideas around an All-In-One
>>> installer, using 100% of the TripleO bits to deploy a single node OpenStack
>>> very similar with what we have today with the containerized undercloud and
>>> what we also have with other tools like Packstack or Devstack.
>>>
>>> https://etherpad.openstack.org/p/tripleo-rocky-all-in-one
>>>
>>> One of the problems that we're trying to solve here is to give a simple tool
>>> for developers so they can both easily and quickly deploy an OpenStack for
>>> their needs.
>>>
>>> "As a developer, I need to deploy OpenStack in a VM on my laptop, quickly
>>> and without complexity, reproducing the same exact same tooling as TripleO
>>> is using."
>>> "As a Neutron developer, I need to develop a feature in Neutron and test it
>>> with TripleO in my local env."
>>> "As a TripleO dev, I need to implement a new service and test its deployment
>>> in my local env."
>>> "As a developer, I need to reproduce a bug in TripleO CI that blocks the
>>> production chain, quickly and simply."
>>>
>>> Probably more use cases, but to me that's what came into my mind now.
>>>
>>> Dan kicked-off a doc patch a month ago:
>>> https://review.openstack.org/#/c/547038/
>>> And I just went ahead and proposed a blueprint:
>>> https://blueprints.launchpad.net/tripleo/+spec/all-in-one
>>> So hopefully we can start prototyping something during Rocky.
>>
>> I've actually started hacking a bit here:
>>
>> https://github.com/dprince/talon
>>
>> Very early and I haven't committed everything yet. (Probably wouldn't
>> have announced it to the list yet but it might help some understand
>> the use case).
>>
>> I'm running this on my laptop to develop TripleO containers with no
>> extra VM involved.
>>
>> P.S. We should call it Talon!
>>
>> Dan
>>
>>>
>>> Before talking about the actual implementation, I would like to gather
>>> feedback from people interested by the use-cases. If you recognize yourself
>>> in these use-cases and you're not using TripleO today to test your things
>>> because it's too complex to deploy, we want to hear from you.
>>> I want to see feedback (positive or negative) about this idea. We need to
>>> gather ideas, use cases, needs, before we go design a prototype in Rocky.
>>
>> Sorry dude. Already prototyping :)
>
> A related use case to all this work that takes it a step further:
>
> I think it would be useful if we could eventually further break down
> "openstack undercloud deploy" into just the pieces needed to:
>
> - start an ephemeral Heat container
> - create the Heat stack passing all requested -e's
> - run config-download and save the output

Yes! This pretty similar what we outlined at the PTG here [1] (lines 21-23):

The high level workflow of here is already possible now if you use the
new --output-only option to config download [2] and is exactly what I
was doing with the Talon prototype. Essentially trying to take it as
far as possible with our existing commands and then bring that to the
group as a "how do we want to package this better?".

One difference I've taken is instead of using a Heat container I
instead use a python-tripleoclient container (which I aim to push to
Kolla if I can whittle it down). This has the benefit of letting you
do everything in a single container. Also I needed a few other
cherry-picks [3] to pull it off to do things like make it so that
docker-puppet.py consumes puppet-tripleo from within the container
instead of bind mounting it from the host, and disabling puppet from
running on the host machine entirely (something I do not want on my
laptop).

The nice thing about all of this is you end up with a self-contained
'Heat template -> Ansible' generator that can translate a set of heat
templates into ansible playbooks which you then just run. What it does
highlight however is perhaps there are still some dependencies that
must be on each host in order for our Ansible playbooks to work.
Things like paunch, and most of the heat-agent hooks still need to be
on each host OS or the resulting playbooks won't work. Continuing the
work to convert things to pure Ansible without requiring any
heat-agents to be installed would make things even nicer I think. But
as it stands today it is already a nice way to hack on
tripleo-heat-templates in a very tight loop. No VMs or quickstart
required.

Dan

[1] https://etherpad.openstack.org/p/tripleo-rocky-all-in-one
[2] http://git.openstack.org/cgit/openstack/python-tripleoclient/commit/?id=50a093247742be896bbbeb91408eeaf0362b5085
[3] https://github.com/dprince/talon/blob/master/containers/tripleoclient/tripleoclient.sh#L31

>
> Essentially removing the undercloud specific logic (or all-in-one
> specific logic in this case) from "openstack undercloud deploy" and
> resulting in a generic way to create the config-download playbooks for
> any given TripleO stack (openstack tripleo depoy?). This would be
> possible when using deployed-server, noop'ing Neutron networks, and
> using fixed IP's as those are the only OpenStack resources actually
> created by Heat when using a full undercloud.
>
> This would allow one to consume the ansible playbooks for a multinode
> overcloud using an ephemeral Heat.
>
> The same generic tooling could then be used to deploy an actual
> undercloud, any all-in-one configuration, or any overcloud
> configuration.
>
> --
> -- James Slagle
> --
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev