... On "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. The scale could be defined on the basis of the survey data. The reference implementation should be able to address at least X% of deployments. I can think of at least one project which was not suitable for use at a reasonable size configuration and not being able to demonstrate this would have saved a lot of grief in the ops community as well as ensuring the project addressed the issue early. (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 dtro...@gmail.com __________________________________________________________________________ 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
smime.p7s
Description: S/MIME cryptographic signature
__________________________________________________________________________ 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
