[openstack-dev] [tripleo] Blueprints moved out to Rocky
aschultz at redhat.com
Fri Dec 15 18:39:16 UTC 2017
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
> 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 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 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:
> 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.
> Yours Tony.
>  https://docs.docker.com/registry/spec/manifest-v2-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
More information about the OpenStack-dev