On 01/29/2016 09:40 AM, Dan Prince wrote: > On Fri, 2016-01-29 at 08:17 -0500, Emilien Macchi wrote: >> Hi, >> >> I'm wondering why don't we use Mitaka CI tested repository [1]. >> IIRC, TripleO is currently using a snapshot which is updated >> asynchronously by TripleO CI folks. >> The problem is that we're not consistent with what RDO CI is testing. >> In >> my memory and tell me if I'm wrong but it happens we're using an old >> snapshot of packages which is older that is actually tested & >> verified >> by RDO CI. >> >> The benefit of using this tested repo would be: >> * this repository is already gated by Weirdo [2] which is running the >> same jobs as Puppet OpenStack CI. >> * you would not have less jobs failures, because RDO CI would have >> detected bugs before. >> * tripleo folks could focus a bit more on features & bugfixes in >> TripleO >> itself, rather than debugging CI issues and slowing down the review >> process. >> * Puppet OpenStack CI became really stable since we're using this >> repository. We have a very few number of issues since then. >> >> Though, something I don't like in my proposal: >> * tripleo would not bring short feedback to RDO folks if something is >> broken >> >> But is TripleO supposed to debug other projects in the same time? >> Don't >> we have enough challenges in our project? >> >> This would be a temporary solution I think, until TripleO would be >> part >> of other upstream project gate (nova, etc) maybe one day. >> But at this time, I honestly think TripleO (which is an installer) >> folks, spend too much time at debugging CI for some reasons that are >> related to projects outside tripleo (puppet modules, openstack bugs, >> packaging issues, etc). >> >> This is just a proposal and an idea to help TripleO folks to focus on >> their review process, instead of debugging CI failures every week. > > The problem I think is largly due to the fact that the RDO CI doesn't > test the same things we do in the TripleO CI. It is essentially a > different CI system. > > Because the CI systems are different different breakages happen when > you try to update one component vs. another. This is why we have to > maintain 'current-tripleo' separately between RDO and TripleO. > > I agree it would be nice if we could consolidate on a single repository > across these projects. It would allow us to focus on review more... > (less CI fixing). > > Perhaps a test matrix comparing the two CI systems would help us get > them closer to parity with what is covered. Even better would be just > simply contributing to the same CI systems and scripts. >
I think contributing to the same scripts would be a big win. From the 'undercloud install' on, it is totally feasible for both CI systems to use the same script right now. I am working on using tripleo.sh in rdoci, which modulo the different environment setups, would get us to the above goal. If we could then get tripleoci consuming the same pre-built undercloud.qcow2 that rdoci is using[1], I think the environment differences would be negligible. [1] https://ci.centos.org/artifacts/rdo/images/mitaka/delorean/stable/undercloud.qcow2 > Dan > >> >> >> Thanks for reading so far. >> Your feedback and comments are more than welcome. >> >> [1] http://trunk.rdoproject.org/centos7/current-passed-ci/delorean.re >> po >> [2] https://github.com/redhat-openstack/weirdo >> _____________________________________________________________________ >> _____ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs >> cribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > 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 > __________________________________________________________________________ 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