On 4/3/18 9:57 PM, Wesley Hayutin wrote:
On Tue, 3 Apr 2018 at 13:53 Dan Prince <[email protected]
<mailto:[email protected]>> wrote:
On Tue, Apr 3, 2018 at 10:00 AM, Javier Pena <[email protected]
<mailto:[email protected]>> 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
>>
>
> I'm really +1 to this. And as a Packstack developer, I'd love to
see this as a
> mid-term Packstack replacement. So let's dive into the details.
Curious on this one actually, do you see a need for continued
baremetal support? Today we support both baremetal and containers.
Perhaps "support" is a strong word. We support both in terms of
installation but only containers now have fully supported upgrades.
The interfaces we have today still support baremetal and containers
but there were some suggestions about getting rid of baremetal support
and only having containers. If we were to remove baremetal support
though, Could we keep the Packstack case intact by just using
containers instead?
Dan
Hey couple thoughts..
1. I've added this topic to the RDO meeting tomorrow.
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.
+1 for elf as a smallest owl :)
3. From a CI perspective, I see this being very help with:
a: faster run times generally, but especially for an upgrade tests.
It may be possible to have upgrades gating tripleo projects again.
b: enabling more packaging tests to be done with TripleO
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.
d: Generally speaking replacing packstack / devstack in devel and CI
workflows where it still exists.
e: Improved utilization of our resources in RDO-Cloud
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].
I'll add some comments with the potential use cases for CI.
/me is very happy to see this moving! Thanks all
[1] https://en.wikipedia.org/wiki/Elf_owl
[2]
https://review.openstack.org/#/c/547038/1/doc/source/install/advanced_deployment/all_in_one.rst
>
>> 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."
>>
>
> "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".
>
>> 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.
>>
>> 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.
>>
>
> I would like to offer help with initial testing once there is
something in the repos, so count me in!
>
> Regards,
> Javier
>
>> Thanks everyone who'll be involved,
>> --
>> Emilien Macchi
>>
>>
__________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Best regards,
Bogdan Dobrelya,
Irc #bogdando
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
