These are (obvious) examples, the point is to come up with a detailed list of release criteria.

We also have this checklist: https://www.rdoproject.org/rdo/release-checklist/ This is mostly marketing type stuff. Since what we produce is software, we need to be sure that when we produce it, we do a great job of telling the world about it. These are things that we can do to amplify what we already naturally do, and make sure that we don't drop things that are boring or routine. --Rich On 01/12/2016 08:01 AM, Haïkel wrote: -- Rich Bowen - rbowen(a)redhat.com OpenStack Community Liaison http://rdoproject.org/

2016-01-12 15:34 GMT+01:00 Mohammed Arafa <mohammed.arafa(a)gmail.com&gt;: Yes, through improving our test days scenarios.

I am resurrecting this thread, because we did not get any feedback the first time around, and it is coming up on the time we will need to define our official mitaka release as done. I have been thinking about the technical criteria for TripleO (RIP RDO-Manager), and I think my previous proposal is not CI'able with a 32G RAM virt setup. I think we need to have our technical definition of done aligned with what we can actually CI. A collection of my thoughts on this topic: * A 5 node virt setup barely fits on a 32G RAM host now, and this is the minimum for HA (undercloud + 3x control + 1x compute). * There are not enough resources left over in the above scenario to have reliable tempest results, since we run tempest from the undercloud. * Ceph is included in the original proposal, but I don't think we should be including Ceph in or DoD for RDO until the packages are available from a CentOS SIG. (We currently pull them from EPEL). * We also need some post-deploy validation specific to Ceph, since it is not covered by tempest except in an indirect way. One possible solution for mitaka that could be stretched for future releases would be: * Deploy 3 node virt setup (undercloud + control + compute) using the pacemaker environment, and run some specific list of tempest tests that optimizes component coverage with minimal resource usage. * Deploy 5 node virt setup (undercloud + 3x control + compute), and run the pingtest from tripleo.sh. By using the pacemaker environment for the 3 node setup, we would at least be testing that the pacemaker code path works. We would potentially miss some issues where steps should only get performed on one of the three control nodes, so we also do a real HA setup with only basic validation. In any case, we need to define something as the mitaka release is rapidly approaching. I will add this to the meeting agenda for this week. On 01/19/2016 06:49 AM, John Trowbridge wrote: