Open Stack

Emilien,

Understood  and thanks for the clarification; looks like mail threading problem with lookout.  This outlook client is not very good for mailing lists.

Regards
-steve


From: Emilien Macchi <emilien at redhat.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Date: Tuesday, October 4, 2016 at 4:46 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] TC candidacy

On Tue, Oct 4, 2016 at 4:01 AM, Steven Dake (stdake) <stdake at cisco.com<mailto:stdake at 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 <emilien at redhat.com<mailto: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<mailto:emilien at redhat.com>> wrote:
On Mon, Oct 3, 2016 at 2:50 PM, Clay Gerrard <clay.gerrard at gmail.com<mailto:clay.gerrard at gmail.com>> wrote:


On Tue, Sep 27, 2016 at 2:52 PM, Emilien Macchi <emilien at redhat.com<mailto: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<mailto: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<mailto:OpenStack-dev-request at 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-request at lists.openstack.org<mailto: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/20161004/4343da50/attachment.html>