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 __________________________________________________________________________ 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