<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, 3 Apr 2018 at 13:53 Dan Prince <<a href="mailto:dprince@redhat.com">dprince@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Apr 3, 2018 at 10:00 AM, Javier Pena <<a href="mailto:jpena@redhat.com" target="_blank">jpena@redhat.com</a>> wrote:<br>
><br>
>> Greeting folks,<br>
>><br>
>> During the last PTG we spent time discussing some ideas around an All-In-One<br>
>> installer, using 100% of the TripleO bits to deploy a single node OpenStack<br>
>> very similar with what we have today with the containerized undercloud and<br>
>> what we also have with other tools like Packstack or Devstack.<br>
>><br>
>> <a href="https://etherpad.openstack.org/p/tripleo-rocky-all-in-one" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/tripleo-rocky-all-in-one</a><br>
>><br>
><br>
> I'm really +1 to this. And as a Packstack developer, I'd love to see this as a<br>
> mid-term Packstack replacement. So let's dive into the details.<br>
<br>
Curious on this one actually, do you see a need for continued<br>
baremetal support? Today we support both baremetal and containers.<br>
Perhaps "support" is a strong word. We support both in terms of<br>
installation but only containers now have fully supported upgrades.<br>
<br>
The interfaces we have today still support baremetal and containers<br>
but there were some suggestions about getting rid of baremetal support<br>
and only having containers. If we were to remove baremetal support<br>
though, Could we keep the Packstack case intact by just using<br>
containers instead?<br>
<br>
Dan<br></blockquote><div><br></div><div>Hey couple thoughts..</div><div>1.  I've added this topic to the RDO meeting tomorrow. </div><div>2.  Just a thought, the "elf owl" is the worlds smallest owl at least according to the internets   Maybe the all in one could be nick named tripleo elf?  Talon is cool too.  </div><div>3.  From a CI perspective, I see this being very help with:</div><div>  a: faster run times generally, but especially for an upgrade tests.  It may be possible to have upgrades gating tripleo projects again.</div><div>  b: enabling more packaging tests to be done with TripleO</div><div>  c: If developers dig it, we have a better chance at getting TripleO into other project's check jobs / third party jobs where current requirements and run times are prohibitive. </div><div>  d: Generally speaking replacing packstack / devstack in devel and CI workflows  where it still exists.</div><div>  e: Improved utilization of our resources in RDO-Cloud</div><div><br></div><div>It would be interesting to me to see more design and a little more thought into the potential use cases before we get far along.  Looks like there is a good start to that here [2].</div><div>I'll add some comments with the potential use cases for CI.</div><div><br></div><div>/me is very happy to see this moving! Thanks all</div><div><br></div><div></div><div></div><div></div><div></div><div></div><div></div><div></div><div></div><div></div><div>[1] <a href="https://en.wikipedia.org/wiki/Elf_owl">https://en.wikipedia.org/wiki/Elf_owl</a></div><div><span style="">[2] </span><a href="https://review.openstack.org/#/c/547038/1/doc/source/install/advanced_deployment/all_in_one.rst">https://review.openstack.org/#/c/547038/1/doc/source/install/advanced_deployment/all_in_one.rst</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
>> One of the problems that we're trying to solve here is to give a simple tool<br>
>> for developers so they can both easily and quickly deploy an OpenStack for<br>
>> their needs.<br>
>><br>
>> "As a developer, I need to deploy OpenStack in a VM on my laptop, quickly and<br>
>> without complexity, reproducing the same exact same tooling as TripleO is<br>
>> using."<br>
>> "As a Neutron developer, I need to develop a feature in Neutron and test it<br>
>> with TripleO in my local env."<br>
>> "As a TripleO dev, I need to implement a new service and test its deployment<br>
>> in my local env."<br>
>> "As a developer, I need to reproduce a bug in TripleO CI that blocks the<br>
>> production chain, quickly and simply."<br>
>><br>
><br>
> "As a packager, I want an easy/low overhead way to test updated packages with TripleO bits, so I can make sure they will not break any automation".<br>
><br>
>> Probably more use cases, but to me that's what came into my mind now.<br>
>><br>
>> Dan kicked-off a doc patch a month ago:<br>
>> <a href="https://review.openstack.org/#/c/547038/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/547038/</a><br>
>> And I just went ahead and proposed a blueprint:<br>
>> <a href="https://blueprints.launchpad.net/tripleo/+spec/all-in-one" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/tripleo/+spec/all-in-one</a><br>
>> So hopefully we can start prototyping something during Rocky.<br>
>><br>
>> Before talking about the actual implementation, I would like to gather<br>
>> feedback from people interested by the use-cases. If you recognize yourself<br>
>> in these use-cases and you're not using TripleO today to test your things<br>
>> because it's too complex to deploy, we want to hear from you.<br>
>> I want to see feedback (positive or negative) about this idea. We need to<br>
>> gather ideas, use cases, needs, before we go design a prototype in Rocky.<br>
>><br>
><br>
> I would like to offer help with initial testing once there is something in the repos, so count me in!<br>
><br>
> Regards,<br>
> Javier<br>
><br>
>> Thanks everyone who'll be involved,<br>
>> --<br>
>> Emilien Macchi<br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>