On Thu, Dec 14, 2017 at 5:01 PM, Tony Breeds <t...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev