On 4/3/18 9:57 PM, Wesley Hayutin wrote:


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

    On Tue, Apr 3, 2018 at 10:00 AM, Javier Pena <jp...@redhat.com
    <mailto: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?

    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:
    openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
    <http://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://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://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



--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__________________________________________________________________________
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

Reply via email to