On Mon, Feb 15, 2016 at 2:05 PM, John Trowbridge <tr...@redhat.com> wrote: > Howdy, > > The spec to replace instack-virt-setup[1] got me thinking about the > relationship between RDO and TripleO. Specifically, when thinking about > where to store/create an undercloud.qcow2 image, and if this effort is > worth duplicating. > > Originally, I agreed with the comments on the spec wrt the fact that we > do not want to rely on RDO artifacts for TripleO CI. However, we do > exactly that already. Delorean packages are 100% a RDO artifact. So it > seems a bit odd to say we do not want to rely on an image that is really > just a bunch of those other artifacts, that we already rely on, rolled > up into a qcow.
That's fair I suppose. It just felt a bit like adding dependencies in the wrong direction, and I would prefer to see the undercloud image generated directly via tripleo-ci. Isn't the plan to push more of the Delorean package git repo sources under the OpenStack namespace in the future? If so, and things are moving in that direction then I figured it would be better to have less dependencies on the RDO side, and use as much of the existing tripleo-ci as possible. I was advocating for using tripleo-ci to build the undercloud image, because we know it can and already does (we just doesn't save it), so we should default to using tripleo-ci instead of RDO CI. tripleo-ci doesn't build a whole delorean snapshot of master today (we only build a small subset of the packages we're testing for that CI run), so in that case, we use the RDO hosted one. I'm not saying tripleo-ci should build a whole deloean repo by any means. Just that in the specific case of the undercloud image, tripleo-ci is more or less already building that, so we should save and reuse it. > > On the other hand, it seems a bit odd that we rely on delorean packages > at all. This creates a bit of a sticky situation for RDO. Take the case > where RDO has identified all issues that need to be fixed to work with > HEAD of master, but some patches have not merged yet. It should be ok > for RDO to put a couple .patch files in the packaging, and be on our > merry way until those are merged upstream and can be removed. I actually think that the trunk packaging shouldn't ever do that. It should be 100% straight from trunk with no patches. -- -- James Slagle -- __________________________________________________________________________ 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
