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
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:
On 01/12/2016 05:09 AM, Haïkel wrote:
> In an effort to improve RDO release process, we came accross the idea
> of having a defined definition of done.
> What are the criteria to decide if a release of RDO is DONE?
> * RDO installs w/ packstack
> * RDO installs w/ RDO Manager
For RDO Manager, I would propose the following detailed criteria:
* Deploys with 3 controllers in HA with at least 1 ceph node and 1
* The above setup passes 100% of tempest smoke tagged tests (w/
* A skipfile is allowed for tempest, but every entry in the skipfile
must be associated with a Bugzilla. In order to be allowed under DoD,
the associated Bugzilla must be deemed a non-blocker.
* There must be documentation on rdoproject.org
that can be followed
without workaround to get to this setup outside of CI.
> * Documentation is up to date
> etc ....
> I added the topic to the RDO meeting agenda, but I'd like to enlarge
> the discussion outside the pool of people coming
> to the meetings and even technical contributors.
> Rdo-list mailing list
> To unsubscribe: rdo-list-unsubscribe(a)redhat.com