<div dir="ltr">I have <a href="https://blueprints.launchpad.net/mistral/+spec/mistral-workflow-executions-yaql-function">https://blueprints.launchpad.net/mistral/+spec/mistral-workflow-executions-yaql-function</a> almost all implemented and I would like submit an FFE for it<div><br></div><div>Cheers,</div><div> Adriano</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 15, 2017 at 12:01 AM, Tony Breeds <span dir="ltr"><<a href="mailto:tony@bakeyournoodle.com" target="_blank">tony@bakeyournoodle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Dec 13, 2017 at 03:01:41PM -0700, Alex Schultz wrote:<br>
> I assume since some of this work was sort of done earlier outside of<br>
> tripleo and does not affect the default installation path that most<br>
> folks will consume, it shouldn't be impacting to general testing or<br>
> increase regressions. My general requirement for anyone who needed an<br>
> FFE for functionality that isn't essential is that it's off by<br>
> default, has minimal impact to the existing functionality and we have<br>
> a rough estimate on feature landing. Do you have idea when you expect<br>
> to land this functionality? Additionally the patches seem to be<br>
> primarily around the ironic integration so have those been sorted out?<br>
<br>
</span>Sadly this is going to be more impactful on x86 and anyone will like,<br>
and I appologise for not raising these issues before now.<br>
<br>
There are 3 main aspects:<br>
1. Ironic integration/provisioning setup.<br>
1.1 Teaching ironic inspector how to deal with ppc64le memory<br>
detection. There are a couple of approaches there but they don't<br>
directly impact tripleo<br>
1.2 I think there will be some work with puppet-ironic to setup the<br>
introspection dnsmasq in a way that's compatible with mulri-arch.<br>
right now this is the introduction of a new tag (based on options<br>
in the DHCP request and then sending diffent responses in the<br>
presense/absence of that. Verymuch akin to the ipxe stuff there<br>
today.<br>
1.3 Helping tripleo understadn that there is now more than one<br>
deply/overcloud image and correctly using that. These are mostly<br>
covered with the review Mark published but there is the backwards<br>
compat/corner cases to deal with.<br>
1.4 Right now ppc64le has very specific requirements with respect to<br>
the boot partition layout. Last time I checked these weren't<br>
handled by default in ironic. The smiple workaround here is to<br>
make the overcloud image on ppc64le a whole disk rather than<br>
single partition and I think given the scope of everythign else<br>
that's the most likley outcome for queens.<br>
<br>
2. Containers.<br>
Here we run in to several issues not least of which is my general<br>
lack of understanding of containers but the challenges as I<br>
understand them are:<br>
2.1 Having a venue to build/publish/test ppc64le container builds.<br>
This in many ways is tied to the CI issue below, but all of the<br>
potential solutions require some conatiner image for ppc64le to<br>
be available to validate that adding them doesn't impact x86_64.<br>
2.2 As I understand it the right way to do multi-arch containers is<br>
with an image manifest or manifest list images[1] There are so<br>
many open questions here.<br>
2.2.1 If the container registry supports manifest lists when we<br>
pull them onto the the undercloud can we get *all*<br>
layers/objects - or will we just get the one that matches<br>
the host CPU?<br>
2.2.2 If the container registry doesn't support manifest list<br>
images, can we use somethign like manifest-tool[2] to pull<br>
"nova" from multiple registreies or orgs on the same<br>
registry and combine them into a single manifest image on<br>
the underclud?<br>
2.2.3 Do we give up entirely on manifest images and just have<br>
multiple images / tags on the undercloud for example:<br>
nova:latest<br>
nova:x86_64_latest<br>
nova:ppc64le_64_latest<br>
and have the deployed node pull the $(arch)_latest tag<br>
first and if $(arch) == x86_64 pull the :latest tag if the<br>
first pull failed?<br>
2.3 All the things I can't describe/know about 'cause I haven't<br>
gotten there yet.<br>
3. CI<br>
There isn't any ppc64le CI for tripleo and frankly there wont be in<br>
the forseeable future. Given the CI that's inplace on x86 we can<br>
confidently assert that we won't break x86 but the code paths we add<br>
for power will largely be untested (beyonf unit tests) and any/all<br>
issues will have to be caught by downstream teams.<br>
<br>
So as you can see the aim is to have minimal impact on x86_64 and<br>
default to the existing behaviour in the absence of anything<br>
specifically requesting multi-arch support. but minimal *may* be > none<br>
:(<br>
<br>
As to code ETAs realistically all of the ironic related code will be<br>
public by m3 but probably not merged, and the containers stuff is<br>
somewhat dpenedant on that work / direction from the community on how to<br>
handle the points I enumerated.<br>
<br>
<br>
Yours Tony.<br>
<br>
[1] <a href="https://docs.docker.com/registry/spec/manifest-v2-2/" rel="noreferrer" target="_blank">https://docs.docker.com/<wbr>registry/spec/manifest-v2-2/</a><br>
[2] <a href="https://github.com/estesp/manifest-tool" rel="noreferrer" target="_blank">https://github.com/estesp/<wbr>manifest-tool</a><br>
<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>