[openstack-dev] [TripleO] Thoughts about the relationship between RDO and TripleO

John Trowbridge trown at redhat.com
Mon Feb 15 21:16:48 UTC 2016



On 02/15/2016 02:50 PM, James Slagle wrote:
> 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.
>

There has been some talk of doing this, but I do not think anyone
currently working on RDO has time to be PTL of an openstack project. I'm
also not sure this would just be delorean packaging branches. My
understanding was that we would move all the branches upstream. In any
case, there is no movement on this right now.

> 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.
>

Right I agree that it would be great if tripleo-ci was producing this
image. Then RDO could just be a consumer of it. Having solved this
problem for RDO though, I can say there are some pieces of it that are
non-trivial. Where to store the images is a big one. Does TripleO have
somewhere we can store images that would be used by both TripleO and
downstream consumers?

Efficiently creating the image is also not as simple as just taking what
we currently have in tripleo-ci and saving it off before `openstack
undercloud install` is run. We build the overcloud images and install
all of the packages after that in tripleo-ci currently. Those two steps
are the majority of the time, so saving an image before then does not
buy much.

It might be worth splitting out a second spec solely dedicated to how we
can efficiently build an undercloud.qcow2. This could be more process
oriented, ie what an efficient list of steps is, rather than a specific
tool to implement that process.
>>
>> 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.
> 
I agree in principle, but it seems weird that it is not even really the
RDO community's decision to make. This example was really just meant to
show that for better or worse the two projects are co-dependent in both
directions. Which then made me wonder where is the line?

It seems like if the undercloud.qcow2 is simply a collection of packages
pre-installed in an image that allow deploying TripleO it is not all
that different than a RPM repository. Note, there are some things in the
current image build that fall outside of that, but I think it might be a
better effort to fix those things in RDO than it would be to reinvent
what is already in RDO in TripleO.



More information about the OpenStack-dev mailing list