> -----Original Message----- > From: Jay Pipes [mailto:jaypi...@gmail.com] > Sent: 26 September 2014 22:51 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] Thoughts on OpenStack Layers and a Big Tent > model > > Heh, I just got off the phone with Monty talking about this :) Comments > inline... > > On 09/22/2014 03:11 PM, Tim Bell wrote: > > The quality designation is really important for the operator community > > who are trying to work out what we can give to our end users. > > So, I think it's important to point out here that there are three different > kinds of > operators/deployers: > > * Ones who use a distribution of OpenStack (RDO, UCA, MOS, Nebula, Piston, > etc) > * Ones who use Triple-O > * Ones who go it alone and install (via source, a mixture of source and > packages, via config management like Chef or Puppet, etc) > > In reality, you are referring to the last group, since operators in the first > group > are saying "we are relying on a distribution to make informed choices about > what is ready for prime time because we tested these things together". > Operators in the second group are really only HP right now, AFAICT, and > Triple- > O's "opinion" on the production readiness of the things it deploys in the > undercloud are roughly equal to "all of the integrated release that the TC > defines". > > I personally think that if an operator is choosing to be in the third group, > then > they are taking on the responsibility of testing what they deploy in a > staging/test > environment in order to validate that it meets their own requirements. In > other > words, the onus of determining whether something is production ready is on > their own shoulders. If the operator chose to deploy OpenStack on top of a > vanilla/custom Linux distribution instead of Red Hat, Ubuntu, OpenSUSE, or > whatever, we would not complain to the Linux kernel community that they have > not made quality designations available for all the pieces we decided to put > in > our custom Linux distribution. Likewise, I think that is the role of OpenStack > distributions: the choices and options that the distributor makes are a > result of > testing certain things together and the distributor's opinion of quality. If a > deployer of OpenStack chooses to go it alone and not use an OpenStack > distribution, that's totally cool, but I don't believe it should be the > OpenStack > developer community's responsibility to vouch for the production readiness of > each component of OpenStack. > > Now, Monty has a big problem with this idea. I know, because he just told me > he > does :) Monty thinks this attitude of relying on OpenStack distributions to > make > choices about production quality of OpenStack components leads inevitably to > "open core" opportunities, with some companies choosing to label a few > upstream components as production quality and others (the ones the company > developed internally) as their production quality choices. > > I happen to doubt that relying on OpenStack distributions to make these > choices > will lead to open core stuff. >
I think there is a hybrid model in addition to your 3 listed of those who take a distribution for the core functions and are then cherry picking the other components according to the cloud they wish to offer. Thus, a distribution would define a base code set complying with the standard APIs and then deployers can select from a stackforge like repository for additional function not in the distribution. An example would be if you used RDO to deploy your cloud and then the Murano package from stackforge to give additional function not in the distribution. Puppetlabs recently announced 'approved' modules (http://www.infoq.com/news/2014/09/puppet-approved-modules) which are intended to help select modules which are not part of the core set but have had a good track record in production. Clearly, there is a difference in governance between the projects which would need a different mechanism for gathering the overall state such as some crowd-sourcing approach like Drupal does. Tim > Best, > -jay > > > Offering early helps to establish the real-life experience and give > > good feedback on the designs. However, the operator then risks > > leaving their users orphaned if the project does not get a sustainable > > following or significant disruption if the APIs change. > > > > The packaging teams are key here as well. When do Ubuntu and Red Hat > > work out the chain of pre-reqs etc. to produce installable packages, > > packstack/juju tool support ? > > > > We do need to have some way to show that an layer #2 package is ready > > for prime time production and associated criteria (packages available, > > docs available, >1 company communities, models for HA and scale, ...) > > > > Tim > > > > > > > > > > _______________________________________________ OpenStack-dev > mailing > > list OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
