[openstack-dev] TC candidacy

Emilien Macchi emilien at redhat.com
Tue Oct 4 03:03:45 UTC 2016


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?
>
> 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



More information about the OpenStack-dev mailing list