Open Stack

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

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