Open Stack

On Thu, Dec 14, 2017 at 5:01 PM, Tony Breeds <tony at bakeyournoodle.com> wrote:
> 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.
>

Perhaps we can start reviewing the items and those with little to no
impact we can merge for the remainder of the cycle. I know
realistically everything has an impact so it'll be >0, but lets try
and keep it as close to 0 as possible.  I know we've already merged
some arch support stuff this cycle but it does seem doubtful that
it'll be properly fully supported in TripleO by the end of Queens. I
think it best to leave the blueprint slated for Rocky-1 unless we get
some sudden movement on patches.  Please continue to propose patches
for review and let's make sure they work in a backwards compatible
fashion with extra eyes on upgrade impacts.

Thanks,
-Alex

>
> Yours Tony.
>
> [1] https://docs.docker.com/registry/spec/manifest-v2-2/
> [2] https://github.com/estesp/manifest-tool
>
> __________________________________________________________________________
> 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