Open Stack

On Mon, Feb 15, 2016 at 2:05 PM, John Trowbridge <trown at 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
--