Open Stack

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 <tony at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171215/9fd345ff/attachment.html>