[openstack-dev] TC candidacy

Steven Dake (stdake) stdake at cisco.com
Tue Oct 4 08:01:37 UTC 2016


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.
________________________________________
From: Emilien Macchi <emilien at 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 <emilien at redhat.com> wrote:
> On Mon, Oct 3, 2016 at 2:50 PM, Clay Gerrard <clay.gerrard at gmail.com> wrote:
>>
>>
>> On Tue, Sep 27, 2016 at 2:52 PM, Emilien Macchi <emilien at 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-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list