Open Stack

One more note I missed in the previous email.

On Jul 15, 2016, at 1:46 PM, Ben Nemec <openstack at nemebean.com<mailto:openstack at nemebean.com>> wrote:

I think this probably makes sense, but some more thoughts inline.

On 07/15/2016 03:13 PM, Stephane Miller wrote:
To better support diskimage-builder based IPA images going forward, we'd
like to move the ironic-agent element into the ironic-python-agent
repository. This will involve:

- Improving support for having multiple copies of an element, so that we
may deprecate the diskimage-builder repository copy of the element. See
this change and related: https://review.openstack.org/#/c/334785
- Moving the element into the repository. This change has been proposed
as https://review.openstack.org/#/c/335583/
- Deprecating the diskimage-builder copy of the element (TBD)
- Adding tests to gate IPA changes on DIB builds (TBD)

We could potentially add tripleo-ci to the IPA repo, which would take
care of this.  As an added bonus, it could cover both the introspection
and deployment use cases for IPA.

On the other hand, if a separate Ironic job were added to cover this,
tripleo could stop ever building new IPA images in CI except in the
promote jobs when we bump our version of IPA.  This would delay our
finding problems with IPA element changes, but realistically I'm not
sure how many of those are happening these days anyway.  I'd expect that
most changes are happening in IPA itself, which we don't currently CI.


We already have a well-established pattern for testing multiple ramdisks under IPA, and this "workflow" already basically works for DIB, however, is extremely awkward in terms of co-gating changes (such as needing to add dependencies to utilize new IPA features). Here's a basic breakdown:

We set IRONIC_BUILD_DEPLOY_RAMDISK to true, which instructs the Ironic devstack plugin to build a new ramdisk instead of downloading and using a prebuilt ramdisk from tarballs.openstack.org<http://tarballs.openstack.org>. Which ramdisk gets built is determined by IRONIC_RAMDISK_TYPE. For DIB, we already have all the code for a job to run this way (in fact; it'd be interesting to go ahead and add a non-voting version of this job). https://github.com/openstack/ironic/blob/master/devstack/lib/ironic#L1185

There's no need for new approaches to how IPA does CI to test this; the desire to have the DIB element in-tree is simply to allow parallelism with the other build methods (which maintain their build and dependencies in-tree) and to prevent a situation where IPA changes are blocked on DIB element changes merging into another repo. This is the same approach used for Ironic in devstack (plugins-in-tree) and that is being worked on for Ironic in tempest, and I don't want to repeat mistakes of CI past of having us blocked on merging packages on another project's core team. (Regardless of how friendly or responsive you are :D).

Thanks,
Jay Faulkner
OSIC

- Add upload of DIB-built images to tarballs.openstack.org<http://tarballs.openstack.org>
<http://tarballs.openstack.org> (TBD)

We would also need to resolve https://review.openstack.org/#/c/334042/

I'm not clear why, but the ironic-agent element was given special
treatment in disk-image-create (which is evil, but what's done is done)
and we'd need to figure out why and a solution that wouldn't require
referencing an out-of-tree element in diskimage-builder.


Many IPA deployers currently use DIB based IPA images using the
ironic-agent element. However, IPA does not officially support DIB - IPA
changes are not tested against DIB, nor are DIB-built images published.

tripleo-ci actually does publish images, but they aren't well publicized
at this point, and it only does so when we promote a repo.


This has the following disadvantages:

- The DIB element is not versioned along with IPA, resulting in
potential version mismatch and breakage
- ironic-agent element changes are not tested with DIB prior to merge

This isn't true today.  tripleo-ci runs against all diskimage-builder
changes and uses an IPA ramdisk.  The version mismatch is a legit
problem with the current setup, although I'm not aware of any actual
breakages that have happened (which doesn't necessarily mean they
haven't :-).


Understandably, tripleo and other projects may have concerns with regard
to this change. I hope to start a discussion here so that those concerns
can be addressed. Further in-depth discussion of this issue can be found
in the relevant launchpad bug:
https://bugs.launchpad.net/ironic-python-agent/+bug/1590935

Thanks,
Stephane


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160716/c4f224e2/attachment.html>