settingsLogin | Registersettings

[openstack-dev] TC candidacy

0 votes

This is my candidacy for a position on the OpenStack Technical
Committee.

https://review.openstack.org/378054

For those who don't know me, it has been 4 years that I have been
consistently working on OpenStack to make deployments production-ready:

  • Puppet OpenStack core contributor, and ex-PTL (18 months).

Writing Puppet modules that allow operators to deploy OpenStack in production.

  • TripleO core contributor, and current PTL.

Contribute to TripleO which is an OpenStack installer used by operators to
deploy and operate OpenStack.

  • OpenStack Infrastructure contributor.

Improving Continuous Integration for different projects in OpenStack.

Here are some aspects that motivate me to be part of TC:

  • 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.

  • Keep horizontal collaboration.

While our technical areas of focus might be different, our main goal is to
make OpenStack better and it's important our governance reflects it.
I believe that collaboration works [1] and we have seen positive results over
the last cycles. I would like TC to keep supporting such efforts and
continue to
make OpenStack a great forum to work.

  • Share my experience with Technical Committee.

Being PTL during 18 months, I contributed to drive Puppet OpenStack project to
success [2] and I learned so much about communication and technical leadership.
If I'm elected I'll do my best to re-use this experience from my
previous roles in
OpenStack. I've been learning on the go and plan to continue that way by
keeping my mind open to feedback.

  • Represent all family members.

Because I've worked on different areas of OpenStack (CI, deployments, testing,
etc), I'll represent the voice of any community member: developers, deployers,
operators and users. I believe in making decisions by wearing
different hats and
find the best solution for everyone.

Over the last years, I've helped into building communities of people who
aim to make OpenStack better. I would be honored to serve as a TC member.

Thank you for your consideration,

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-June/066544.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-September/103372.html
--
Emilien Macchi


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Sep 27, 2016 in openstack-dev by emilien_at_redhat.co (36,940 points)   2 7 13
retagged Jan 26, 2017

11 Responses

0 votes

I'd like to throw in my hat to serve the community as a TC member.

My name is Jim Rollenhagen, but I'm better known in the community as jroll.
I've worked in many environments, from 20-person startup to massive
corporations. For the past three years, I've been working on OpenStack at
Rackspace. I primarily work on ironic (where I just started my third term as
PTL), but also dabble heavily in Nova, and try to contribute to cross-project
teams (mostly infra, QA, and Oslo) when I can.

I believe the primary objective of the TC should be to serve the community.
There's a few things we can immediately do to improve. First is the ongoing
effort to document principles and expectations. There's a massive amount of
shared understanding among the leaders in our community (and especially the
current TC) that isn't necessarily known or shared by the rest of the
community. We need to write down the current state of that. The principles
document does this well; but that's only the start. We need to continue to
document expectations for projects in the big tent, expectations for PTLs and
liaisons, and where we want OpenStack to be long term. We often focus on the
short term without thinking about how things support our longer-term goals, and
I'd like to fix that by writing down our vision for the future.

Over the last year, folks keep talking about the big tent, and how it has
watered down the meaning or focus of OpenStack. This is true today, at some
level. However, I believe this is short-term pain while we are moving to a
better place. I don't believe the solution is to go back to the old way of
life. Rather, we should roll forward and help to make the big tent better.
Going back will only create more confusion, and will bring the TC back to the
days of evaluating the usefulness and technical excellence of projects - which
we already have found is untenable. We have common ways of doing many things,
but those aren't well-documented and so newer projects simply do things the way
they think is best, or fastest, or the way it's done in the first project they
look to source ideas from. For example, I know of at least two or three ways
that microversioning is implemented. There are two ways projects are
implementing rolling upgrades. And that might be okay; but they need to be
documented somewhere that all projects can benefit from. We should even go
further, and build frameworks for common things like these that OpenStack
projects tend to value. I believe the TC (working with folks like the
architecture WG, etc) could (and should!) be the body to help implement and
drive this sort of work. The new goals process is one step toward this, and I
think it's a great start. If we can truly make the big tent a more coherent set
of projects, I think it will be a huge win for everyone - not just developers
that need a home for their project.

The ironic project went through incubation just before the big tent went into
effect, and as such was one of the first projects to need to work with some of
the constraints (i.e., not be a first-class member of many of the cross-project
teams). We've implemented devstack and tempest plugins, in-tree API reference,
and in-tree install guide. To accomplish some of these, we needed to contribute
both code and documentation into these projects. I think my experience there
helps me relate to newer big tent projects that struggle with some of these
initiatives. I look forward to leading efforts to make this less of a burden on
projects.

I would be honored to serve the community from a TC seat, if elected. Whether
or not I am elected, I hope to work on some or all of these items over the next
two cycles, but I believe I will be in a better position to get these done from
within the TC.

// jim


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 28, 2016 by Jim_Rollenhagen (12,800 points)   2 3 3
0 votes

On Tue, Sep 27, 2016 at 2:52 PM, Emilien Macchi emilien@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]

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?

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?

-Clay

  1. https://www.youtube.com/watch?v=ZY8hnMnUDjU&feature=youtu.be&t=379

  2. http://lists.openstack.org/pipermail/openstack-dev/2016-September/104815.html

  3. http://lists.openstack.org/pipermail/openstack-dev/2016-September/104844.html

  4. http://lists.openstack.org/pipermail/openstack-dev/2016-September/104833.html

    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 3, 2016 by Clay_Gerrard (5,800 points)   1 2 3
0 votes

On Mon, Oct 3, 2016 at 2:50 PM, Clay Gerrard clay.gerrard@gmail.com wrote:
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?

I'll bounce on that too.

I think part of the problem is that the OpenStack projects develops
and tests against Devstack and if it works there, they mostly call it
a day.
Sort of exaggerating but I hope you understand.

The reality is that you don't go in production with Devstack.

Users and operators tend to go in production in one of three ways:
1) Manually (ouch) with documentation available on docs.o.o, usually
using packages provided by Debian, Ubuntu or RDO on CentOS
2) Purpose-built "home" made installation layer using high-level
configuration management modules (OSA, Puppet, Chef, etc.), that
install either from source or from distro packages
3) Using actual installers that often wrap around what is provided in

2 but not exclusively (TripleO, Packstack, Kolla, Fuel, etc.)

The reason why "It worked in Devstack" has become a meme is because
historically, the developer community has not paid a lot of attention
to make sure #1 through #3 still work as a result of their changes.
I've been told numerous times as a maintainer/developer and user of #2
and #3 that I ought to keep up with the release notes if my stuff is
broken.

Thankfully, I think reception to issues/bugs has gotten better over
the course of Newton.
However, it still takes a considerable amount of time to track issues,
sometimes with projects we are not familiar with at all, and get the
required information to file a comprehensible report.

Sometimes the problem is in the project, sometimes in the
configuration management module (i.e, deprecation, non-backwards
compatible change, etc.), sometimes in packaging (RDO/UCA/Debian),
sometimes elsewhere.
This is all very complex.

I like to think we have an excellent test coverage matrix in
puppet-openstack 1 covering both RDO and UCA with multiple projects,
different backends, ipv6, SSL, etc.
We've started levering that coverage in Tempest already where Puppet
has 3 non-voting jobs to help provide input.

I think we could do better and I'm confident we /can/ do better.

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 3, 2016 by dms_at_redhat.com (3,780 points)   3 4
0 votes

On Mon, Oct 3, 2016 at 2:50 PM, Clay Gerrard clay.gerrard@gmail.com wrote:

On Tue, Sep 27, 2016 at 2:52 PM, Emilien Macchi emilien@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?

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).

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


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 3, 2016 by emilien_at_redhat.co (36,940 points)   2 7 13
0 votes

On Mon, Oct 3, 2016 at 5:01 PM, Emilien Macchi emilien@redhat.com wrote:
On Mon, Oct 3, 2016 at 2:50 PM, Clay Gerrard clay.gerrard@gmail.com wrote:

On Tue, Sep 27, 2016 at 2:52 PM, Emilien Macchi emilien@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?

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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 4, 2016 by emilien_at_redhat.co (36,940 points)   2 7 13
0 votes

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@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@redhat.com wrote:
On Mon, Oct 3, 2016 at 2:50 PM, Clay Gerrard clay.gerrard@gmail.com wrote:

On Tue, Sep 27, 2016 at 2:52 PM, Emilien Macchi emilien@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 4, 2016 by Steven_Dake_(stdake) (24,540 points)   2 13 26
0 votes

On Tue, Oct 4, 2016 at 4:01 AM, Steven Dake (stdake) stdake@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@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@redhat.com wrote:

On Mon, Oct 3, 2016 at 2:50 PM, Clay Gerrard clay.gerrard@gmail.com wrote:

On Tue, Sep 27, 2016 at 2:52 PM, Emilien Macchi emilien@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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 4, 2016 by emilien_at_redhat.co (36,940 points)   2 7 13
0 votes

On 10/3/2016 10:03 PM, Emilien Macchi wrote:

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.

I'll repeat here what I asked in the review above: on what kinds of
changes should nova developers and reviewers think to run the
experimental queue job for tripleo? Since the experimental queue is
on-demand we generally only run it for specific changes that aren't
tested by our normal check/gate jobs. Like we have an lxc job in the
experimental queue and that's fairly straight-forward on when to run it,
similar with neutron + dvr + multinode.

But what would prompt me to run the tripleo job on a nova change? Things
that impact upgrades? Configuration option changes, like dropping
deprecated configuration options or changing their default behavior?

--

Thanks,

Matt Riedemann


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 4, 2016 by Matt_Riedemann (48,320 points)   3 10 25
0 votes

On Tue, Oct 4, 2016 at 8:59 AM, Matt Riedemann
mriedem@linux.vnet.ibm.com wrote:
On 10/3/2016 10:03 PM, Emilien Macchi wrote:

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.

I'll repeat here what I asked in the review above: on what kinds of changes
should nova developers and reviewers think to run the experimental queue job
for tripleo? Since the experimental queue is on-demand we generally only run
it for specific changes that aren't tested by our normal check/gate jobs.
Like we have an lxc job in the experimental queue and that's fairly
straight-forward on when to run it, similar with neutron + dvr + multinode.

But what would prompt me to run the tripleo job on a nova change? Things
that impact upgrades? Configuration option changes, like dropping deprecated
configuration options or changing their default behavior?

Generally speaking, making sure it works fine outside the gate is in
my opinion an interesting information, as we know developers tend to
take care of devstack only (and I understand why).
But yes, things like:
- making sure a change is backward compatible outside devstack
(configuration or behaviors): using TripleO job now, but why not Kolla
or another tool in the Big Tent?
- test real upgrades, looking at sdake's reply it seems like Kolla has
a bunch of jobs for that.

Also I proposed to use the experimental pipeline right now because I
like to iterate. If we see some benefits and results, I would be in
favor of moving the jobs to the check pipeline, as non-voting.

Thanks Matt for being open of such a change,
--
Emilien Macchi


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 4, 2016 by emilien_at_redhat.co (36,940 points)   2 7 13
0 votes

On Tue, Oct 4, 2016 at 8:59 AM, Matt Riedemann
mriedem@linux.vnet.ibm.com wrote:
On 10/3/2016 10:03 PM, Emilien Macchi wrote:

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.

I'll repeat here what I asked in the review above: on what kinds of changes
should nova developers and reviewers think to run the experimental queue job
for tripleo? Since the experimental queue is on-demand we generally only run
it for specific changes that aren't tested by our normal check/gate jobs.
Like we have an lxc job in the experimental queue and that's fairly
straight-forward on when to run it, similar with neutron + dvr + multinode.

But what would prompt me to run the tripleo job on a nova change? Things
that impact upgrades? Configuration option changes, like dropping deprecated
configuration options or changing their default behavior?

I haven't exactly answered to the question.
I guess a Nova developer would run the job when making changes such as
removing an option or a feature.
Also it would be useful when deprecating something widely used, and
make sure it still works outside Devstack.

Thanks,

--

Thanks,

Matt Riedemann


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 4, 2016 by emilien_at_redhat.co (36,940 points)   2 7 13
...