[openstack-dev] [tripleo] Blueprints moved out to Rocky
tony at bakeyournoodle.com
Fri Dec 15 00:01:04 UTC 2017
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.
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
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.
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.
More information about the OpenStack-dev