I have https://blueprints.launchpad.net/mistral/+spec/mistral-workflow-executions-yaql-function almost all implemented and I would like submit an FFE for it
Cheers, Adriano On Fri, Dec 15, 2017 at 12:01 AM, 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. > > > 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
