On Tue, Oct 4, 2016 at 4:01 AM, Steven Dake (stdake) <std...@cisco.com> wrote: > Emilen, > > You say "the previous *PTL* of an OpenStack installation automation project" > as if there were only one previous PTL :) There are many previous PTLs of > OpenStack automation projects. I feel the question was directed at me, so > I'll answer.
( I didn't ask for it but Clay Gerrard did. I also gave my insights, waiting for others previous PTL, like you, to give thoughts too. ) > ________________________________________ > From: Emilien Macchi <emil...@redhat.com> > Sent: Monday, October 3, 2016 8:03 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] TC candidacy > > On Mon, Oct 3, 2016 at 5:01 PM, Emilien Macchi <emil...@redhat.com> wrote: >> On Mon, Oct 3, 2016 at 2:50 PM, Clay Gerrard <clay.gerr...@gmail.com> wrote: >>> >>> >>> On Tue, Sep 27, 2016 at 2:52 PM, Emilien Macchi <emil...@redhat.com> wrote: >>>> >>>> >>>> - Make sure it works outside Devstack. >>>> >>>> There is a huge gap between what is tested by Devstack gate and what >>>> operators >>>> deploy on the field. This gap tends to stretch the feedback loop between >>>> developers and operators. As a community, we might want to reduce this >>>> gap >>>> and make OpenStack testing more effective and more realistic. >>>> That's an area of focus I would like to work and spread over OpenStack >>>> projects if I'm elected. >>>> >>> >>> This is a really interesting platform point. It's been a concern in he >>> community since *at least* Vancouver [1]. We've had lots of different >>> viewpoints towards project install-ability raised this election: >>> >>> John Dickenson says installation of projects should go horizontal [2] >>> Monty Taylor says services oriented deployment teams are the wasteful >>> exception [3] >>> John Griffith says how the TC approaches services oriented OpenStack will be >>> an important factor in the future definition of OpenStack and it's relevancy >>> [4] >>> >> >> Before I start replying to the questions, I would like to note that >> I'm not against Devstack and I still see some value of such a project. >> Devstack has been so far the first deployment tool that is used by >> OpenStack continuous integration, my point is really about adding more >> CI coverage. >> >>> Do you think this is an important topic for OpenStack right now? I'd be >>> really interested to hear any *new* insights from the previous PTL of *one* >>> of OpenStack's installation automation projects? What could or should be >>> done to reduce the bias/reliance towards a devstack or an >>> "openstack-all-in-one" deployment model? Can or should the TC be the >>> champion of the discussion around "how to install" OpenStack? How much of >>> an impact does choices made in *testing* effect the install-ability and >>> ease-of-use of OpenStack in general? >> > > In my early history as a leader prior to OpenStack, I believed exceptions > were the norm. I then read Clayton Christensen's Harvard Business Review > article "How will you measure your life?"[1] and it fundamentally changed my > thinking on exceptions. (Full disclosure, I graduated from Northern Arizona > University in 1998, not Harvard in 2010). I would encourage everyone first > to read the article "How will you measure your life?" and vote afterwards. > Please do vote - without your vote, your voice isn't heard on how you want > the OpenStack TC to function. The short version of Christensen's theory is > exceptions lead to more exceptions lead to more exceptions leads to an > untenable situation with all sorts of negative outcomes. I was actually > suffering through this exact scenario in my early career and one of my > greatest mentors pointed me at this article which put me on the right track. > > Now I give awareness of it to you. > > Kolla has been led exception free since day 0. I have hope this continues > into the future since I have elected not to run to serve as PTL of Kolla and > instead focus on serving as a TC member if elected. > > Unfortunately answering your questions is an exception in and to itself. > However, I also believe in being direct and honest with individuals as you > can see in my self-nomination to the TC and have a strong disdain for > individuals that waste time by avoiding questions, so I'll answer. > > What should be done about the reliance as devstack as gating mechanism for > all OpenStack software? I proposed an answer here [2] essentially asking > core reviewers and PTLs of projects interested in being consumed by various > individuals interested in using the software these projects produced to > contribute to Kolla (or pick your operational deployment manager of choice) > to fill out the big tent. That thread had a wildly successful outcome for > Kolla - 15 new services implemented in Newton! The obvious next step is now > to gate on these services in various service defined as "Core". Answer: Let > the projects themselves sort it out with a whole bunch of help from the > rockin openstack-infra team. The TC need not be involved. > > Should the TC pick winners and losers by defining the "one true way" to > install OpenStack assuming everyone plays by the same rules? Feels like an > exception to me of the TC charter. Answer no. > > How much of an impact does testing make in the ability to install OpenStack? > Answer: Not all that much. ODMs either installs or they don't. ODM's either > upgrade or they don't. ODMs either reconfigures or they don't. This is a 20 > minute test in Kolla -> enable all services, deploy, upgrade, reconfigure. > > The real question is "Does it work?" after deploy/upgrade/reconfigure. This > is where the hard testing comes in, whether manual or automated. Manual > testing does scale well enough with the growth of the big tent to keep up > with current big tent growth. It is mostly what Kolla uses and I feel the > Kolla team can keep up with the growth of the big tent in spite of the curve > balls thrown our way on a weekly basis. If I didn't feel this way, I > wouldn't have added kolla-kubernetes to Kolla's governance repository. > Clearly automated testing is superior. > > If you make one choice today that you want to change your life for the > better, click the link [1] below. > > [1] > https://d6d5dc73-a-62cb3a1a-s-sites.googlegroups.com/site/philosophypsychologymanagement/documents/Howwillyoumeasureyourlife.pdf?attachauth=ANoY7criy1MlWLqImb6rrCGWI0eeRJVjAFtQK_zFSX_r9biW1IiCNu0iMLD0OfJ3wD0z-vzMv5GVOFAwGHCxpcTgfrlm1tB2mmlbkt4aWqQ-PV9ed6-cnlw2OEdUZkJVZ68cVxdp8y1kAksIZ3jGN_tCRKFOPCqRwmH-7i4YVvq1zt-MnCnporrs00YipWRdQQeeS1EtUP8Pm9gW2Rl0QhRDgstsyMAcLjN2Y5ObCQhBpmpxtgE0G0AUnsIDNIteznVJmidp5MMKGdz7kZMunwoDtxv2J4lyXg%3D%3D&attredirects=0 > > [2] http://lists.openstack.org/pipermail/openstack-dev/2016-March/090546.html > > Regards, > -steve > >> 1) Do you think this is an important topic for OpenStack right now? >> Yes. Making sure that OpenStack can be installed, upgraded and >> operated outside devstack is in my opinion an important long-term >> topic that needs to be addressed right now. >> >> 2) What could or should be done to reduce the bias/reliance towards a >> devstack or an "openstack-all-in-one" deployment model? >> Some projects (Heat, Ironic, etc) already run non-devstack jobs, >> example given with TripleO. >> I'm not going to make advertising for this project but it's an example >> of installer that deploys a good set of service with uses-cases close >> to production: multinode, SSL, IPv6, upgrade testing, network >> isolation, etc. >> We could see more of it in OpenStack, where projects like TripleO, >> Kolla, Fuel, etc, could run their CI jobs in projects like Nova or >> Swift for example. >> It would reduce the feedback loop between developers and operators >> when something breaks (backward compatibility testing is a good >> use-case), or increase coverage (things that Devstack doesn't test). > > I'm actually proposing to run TripleO multinode job in Nova experimental jobs: > https://review.openstack.org/#/c/381322/ > It's non-voting and run at demand, so we're not breaking anything. > > tripleo-ci-centos-7-nonha-multinode is a CI job that takes ~40-60 > minutes (we're working on reducing its runtime) and deploy TripleO in > multinode environment. > I think it would be a good start to see if non-devstack jobs would > bring useful feedback. > >> 3) Can or should the TC be the champion of the discussion around "how >> to install" OpenStack? >> I don't think so. To me, it's up to our community to decide how to >> install OpenStack. >> The deployment tool (ansible versus chef versus puppet, etc) is >> something that we can't choose on behalf of our operators, because >> they already have tools to manage their existing infrastructure. >> Where TC could help, is to drive OpenStack deployment tools projects >> to increase their impact in OpenStack testing with a final goal of >> reducing the feedback loop between devs & ops. >> >> 4) How much of an impact does choices made in *testing* effect the >> install-ability and ease-of-use of OpenStack in general? >> - evaluate how a project does respect backward compatibility in >> configuration and APIs. >> - evaluate if projects can actually be upgraded by using operator and >> not something that operators don't use (devstack / grenade). >> That's the two things that directly came into my mind. >> >>> Somewhat unrelated. Do you have any personal thoughts/insights on how you >>> believe OpenStack should approach potentially disruptive or "competing" >>> design in general - like ansible/puppet or even Kolla? >> >> I don't think Ansible / Puppet OpenStack / Kolla / TripleO / Fuel / >> (...) compete in design, but they rather fit (or match) the needs of >> people who deploy OpenStack in production. >> In my experience of deployment, I've seen many cases where a company >> already used Ansible (or Puppet or Chef, etc) in their infrastructure, >> and picked the same tool to deploy OpenStack, to accelerate their >> adoption and facilitate their deployment team. >> Such a diversity is in my opinion awesome as long as we directly >> consume what is produced by upstream projects and report immediate >> feedback with CI and horizontal collaboration. >> >> I hope I answered to the questions, and if not please let me know, I'm >> always open for questions and feedback. >> >> Thanks, >> -- >> Emilien Macchi > > > > -- > 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 -- 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
