On Mon, Oct 3, 2016 at 5:01 PM, Emilien Macchi <emil...@redhat.com> wrote: > On Mon, Oct 3, 2016 at 2:50 PM, Clay Gerrard <clay.gerr...@gmail.com> wrote: >> >> >> 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] >> > > 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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
