Open Stack

On Wed, Dec 13, 2017 at 03:01:41PM -0700, Alex Schultz wrote:
> I assume since some of this work was sort of done earlier outside of
> tripleo and does not affect the default installation path that most
> folks will consume, it shouldn't be impacting to general testing or
> increase regressions. My general requirement for anyone who needed an
> FFE for functionality that isn't essential is that it's off by
> default, has minimal impact to the existing functionality and we have
> a rough estimate on feature landing.  Do you have idea when you expect
> to land this functionality? Additionally the patches seem to be
> primarily around the ironic integration so have those been sorted out?

Sadly this is going to be more impactful on x86 and anyone will like,
and I appologise for not raising these issues before now.

There are 3 main aspects:
1. Ironic integration/provisioning setup.
   1.1 Teaching ironic inspector how to deal with ppc64le memory
       detection.  There are a couple of approaches there but they don't
       directly impact tripleo
   1.2 I think there will be some work with puppet-ironic to setup the
       introspection dnsmasq in a way that's compatible with mulri-arch.
       right now this is the introduction of a new tag (based on options
       in the DHCP request and then sending diffent responses in the
       presense/absence of that.  Verymuch akin to the ipxe stuff there
       today.
   1.3 Helping tripleo understadn that there is now more than one
       deply/overcloud image and correctly using that.  These are mostly
       covered with the review Mark published but there is the backwards
       compat/corner cases to deal with.
   1.4 Right now ppc64le has very specific requirements with respect to
       the boot partition layout. Last time I checked these weren't
       handled by default in ironic.  The smiple workaround here is to
       make the overcloud image on ppc64le a whole disk rather than
       single partition and I think given the scope of everythign else
       that's the most likley outcome for queens.

2. Containers.
   Here we run in to several issues not least of which is my general
   lack of understanding of containers but the challenges as I
   understand them are:
   2.1 Having a venue to build/publish/test ppc64le container builds.
       This in many ways is tied to the CI issue below, but all of the
       potential solutions require some conatiner image for ppc64le to
       be available to validate that adding them doesn't impact x86_64.
   2.2 As I understand it the right way to do multi-arch containers is
       with an image manifest or manifest list images[1]  There are so
       many open questions here.
       2.2.1 If the container registry supports manifest lists when we
             pull them onto the the undercloud can we get *all*
             layers/objects - or will we just get the one that matches
             the host CPU?
       2.2.2 If the container registry doesn't support manifest list
             images, can we use somethign like manifest-tool[2] to pull
             "nova" from multiple registreies or orgs on the same
             registry and combine them into a single manifest image on
             the underclud?
       2.2.3 Do we give up entirely on manifest images and just have
             multiple images / tags on the undercloud for example:
                nova:latest
                nova:x86_64_latest
                nova:ppc64le_64_latest
             and have the deployed node pull the $(arch)_latest tag
             first and if $(arch) == x86_64 pull the :latest tag if the
             first pull failed?
   2.3 All the things I can't describe/know about 'cause I haven't
       gotten there yet.
3. CI
   There isn't any ppc64le CI for tripleo and frankly there wont be in
   the forseeable future.  Given the CI that's inplace on x86 we can
   confidently assert that we won't break x86 but the code paths we add
   for power will largely be untested (beyonf unit tests) and any/all
   issues will have to be caught by downstream teams.

So as you can see the aim is to have minimal impact on x86_64 and
default to the existing behaviour in the absence of anything
specifically requesting multi-arch support.  but minimal *may* be > none
:(

As to code ETAs realistically all of the ironic related code will be
public by m3 but probably not merged, and the containers stuff is
somewhat dpenedant on that work / direction from the community on how to
handle the points I enumerated.


Yours Tony.

[1] https://docs.docker.com/registry/spec/manifest-v2-2/
[2] https://github.com/estesp/manifest-tool