+1 for aligning efforts between Triple-O and RDO Manager around CI. There's been a *lot* of work (trown++) towards RDO Manager CI and it'd be great if Triple O could benefit from that. Like Emilien said, our test coverage for promoting a set of packages to "current-passed-ci" is huge already and will keep on improving.
David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Fri, Jan 29, 2016 at 10:42 AM, John Trowbridge <tr...@redhat.com> wrote: > > > 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 __________________________________________________________________________ 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