Open Stack

On Tue, 3 Apr 2018 at 13:53 Dan Prince <dprince at redhat.com> wrote:

> On Tue, Apr 3, 2018 at 10:00 AM, Javier Pena <jpena 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
> >>
> >
> > 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.
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:
> OpenStack-dev-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180403/4d39aa6d/attachment.html>