----- Original Message -----
> On Tue, Apr 3, 2018 at 10:00 AM, Javier Pena <jp...@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
> > 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?
I don't have a strong opinion on this. As long as we can update containers with
under-review packages, I guess we should be ok. That said, I still think some
kind of baremetal support is a good idea to catch co-installability issues, if
it is not very expensive to mantain.
> >> 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: 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
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
OpenStack Development Mailing List (not for usage questions)