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


1. https://www.youtube.com/watch?v=ZY8hnMnUDjU&feature=youtu.be&t=379
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to