<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>On "production-grade":</div><div id="AppleMailSignature"><br></div><div>On Feb 5, 2016, at 6:23 AM, Tim Bell <<a href="mailto:Tim.Bell@cern.ch">Tim.Bell@cern.ch</a>> wrote:<br></div><blockquote type="cite"><div><div><div><div id="MAC_OUTLOOK_SIGNATURE"></div></div></div></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:12pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Dean Troyer<br><span style="font-weight:bold">Reply-To: </span> "OpenStack Development Mailing List (not for usage questions)"<br><span style="font-weight:bold">Date: </span> Friday 5 February 2016 at 14:57<br><span style="font-weight:bold">To: </span> "OpenStack Development Mailing List (not for usage questions)"<br><span style="font-weight:bold">Subject: </span> Re: [openstack-dev] [all] [tc] "No Open Core" in 2016<br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><font color="#5856d6">[...]</font><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>'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.</div></div></div></div></div></blockquote></span></blockquote><div><br></div><div>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."</div><div><br></div><div>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:</div><div><br></div><div>- tests must be run against an OpenStack-certified cloud containing at minimum 20 compute nodes, 1 TB block storage, 1 TB object storage</div><div>- 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 </div><div>- tests must demonstrate service resiliency when faced with common component failures such as: compute node failure, storage failure, network failure, etc.</div><div><br></div><div>(all numbers here are to show the level of specificity needed, are completely made up, and should be chosen more appropriately than that)</div><div><br></div><div>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.</div><div><br></div><div>--j</div><br><blockquote type="cite"><span id="OLK_SRC_BODY_SECTION"><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><div><div dir="ltr"><div class="gmail_extra"><div><br></div><div>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.</div></div></div></div></div></blockquote></span><div><br></div><div>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.</div><div><br></div><div>Tim</div><div><br></div><span id="OLK_SRC_BODY_SECTION"><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><div><div dir="ltr"><div class="gmail_extra"><div><br></div><div>dt</div><div><br></div>
-- <br><div class="gmail_signature"><br>
Dean Troyer<br><a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a><br></div></div></div></div></div></blockquote></span>
</blockquote><blockquote type="cite"><div><span>__________________________________________________________________________</span><br><span>OpenStack Development Mailing List (not for usage questions)</span><br><span>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe</span><br><span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br></div></blockquote></body></html>