Open Stack

On "production-grade":

> On Feb 5, 2016, at 6:23 AM, Tim Bell <Tim.Bell at cern.ch> wrote:
> 
> From: Dean Troyer
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> Date: Friday 5 February 2016 at 14:57
> To: "OpenStack Development Mailing List (not for usage questions)"
> Subject: Re: [openstack-dev] [all] [tc] "No Open Core" in 2016
>> [...]
>> Of course, the devil is in the details, especially around what I mean by "fully-functional" and "production-grade". Is it just an API/stability thing, or does performance/scalability come into account ? There will always be some subjectivity there, but I think it's a good place to start.
> 
> I think defining 'fully-functional' is easy enough until you allow 'vendor extensions' into the API.  But there is still an amount of objective criteria to look at to make it something that a group of, say 13 judges, might arrive at a reasonable answer.
> 
> 'Production-grade' is more subjective, especially with the size of deployment differences in 'production' for a bunch of other things.  But again, it is one of those things that reasonably technical people will generally arrive at a useful conclusion .  Existing components (DB, message queues, etc) can point at known production deployments as evidence; new components have a harder sell.

I'm in complete support of requiring any device in OpenStack to have a "production-grade" free-software-based configuration; I'd also say that this should be the default configuration for "pure upstream" OpenStack. I don't see this as conflicting at all with vendor distros or deployments, which may change underlying components and configuration freely as long as the result meets the standards for "production-grade."

I'd be (strongly) in favor of defining a target deployment configuration and size which we find representative of the minimum bar for "production-grade." Anything less concrete and specific becomes more nuisance than help. I'd hope that specs might look like the following:

- tests must be run against an OpenStack-certified cloud containing at minimum 20 compute nodes, 1 TB block storage, 1 TB object storage
- tests must demonstrate service responsiveness, stability, and reliability while VMs, compute volumes, object store objects, and networks are created/destroyed at a rate of 50/second in any combination while maintaining 99.9%+ service availability, <1% error rate, and response latency of <100ms  
- tests must demonstrate service resiliency when faced with common component failures such as: compute node failure, storage failure, network failure, etc.

(all numbers here are to show the level of specificity needed, are completely made up, and should be chosen more appropriately than that)

I also think these are things that we should be regularly testing for core OpenStack services, and that I'd be happy to see as part of DefCore someday.

--j

> 
> For a time many projects used SQLite as a reference implementation for testing DB functionality, and have moved away from that (completely? I'm not sure) as we all agree it really is not a production-grade implementation.  That is an easy example, but as a community we have crossed this bridge multiple times already and will be able to do it again.
> 
> This could also be covered by needing scaleable as well as fully-functional and production grade. Again, it would be subjective but it would avoid reference implementations that only work at devstack scale.
> 
> Tim
> 
> 
> dt
> 
> -- 
> 
> Dean Troyer
> dtroyer at gmail.com
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160205/593de10c/attachment.html>