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