Open Stack

On 16/May/2019 12:40, Cédric Jeanneret wrote:
>
>
> On 5/7/19 11:07 AM, Mark Goddard wrote:
> > Hi,
> >
> > This is a summary of the ad-hoc cross project session between the
> > OpenStack Ansible and Kolla teams.
> >
> > It occurred to me that our two teams likely face similar challenges, and
> > there are areas we could collaborate on. I've tagged TripleO also since
> > the same applies there.
> >
> > [Collaboration on approach to features]
> > This was my main reason for proposing the session - there are features
> > and changes that all deployment tools need to make. Examples coming up
> > include support for upgrade checkers and IPv6. Rather than work in
> > isolation and solve the same problem in different ways, perhaps we could
> > share our experiences. The implementations will differ, but providing a
> > reasonably consistent feel between deployment tools can't be a bad thing.
> >
> > As a test case, we briefly discussed our experience with the upgrade
> > checker support added in Stein, and found that our expectation of how it
> > would work was fairly aligned in the room, but not aligned with how I
> > understand it to actually work (it's more of a post-upgrade check than a
> > pre-upgrade check).
>
> Hello! I'm pretty sure the new Validation Framework can help here, since
> we intend to provide a pre|post deploy|update|upgrade way to run
> validations.

To be more precise, that's not really *new* as TripleO runs validations
since Newton.

> Feel free to ping me if you want (Tengu on #tripleo) - or just ask
> questions in here :).
>
> Since we want to extend the framework to not only cover tripleo and
> openstack, that would be a good start with kolla imho :)
>
> >
> > I was also able to point the OSA team at the placement migration code
> > added to Kolla in the Stein release, which should save them some time,
> > and provide more eyes on our code.
> >
> > I'd like to pursue this more collaborative approach during the Train
> > release where it fits. Upgrade checkers seems a good place to start, but
> > am open to other ideas such as IPv6 or Python 3.
> >
> > [OSA in Kayobe]
> > This was my wildcard - add support for deploying OpenStack via OSA in
> > Kayobe as an alternative to Kolla Ansible. It could be a good fit for
> > those users who want to use OSA but don't have a provisioning system.
> > This wasn't true of anyone in the room, and lack of resources deters
> > from 'build it and they will come'. Still, the seed is planted, it may
> > yet grow.
> >
> > [Sharing Ansible roles]
> > mnaser had an interesting idea: add support for deploying kolla
> > containers to the OSA Ansible service roles. We could then use those
> > roles within Kolla Ansible to avoid duplication of code. There is
> > definitely some appeal to this in theory. In practice however I feel
> > that the two deployment models are sufficiently different that it would
> > add significantly complexity to both projects. Part of the (relative)
> > simplicity and regularity of Kolla Ansible is enabled by handing off
> > installation and other tasks to Kolla.
> >
> > One option that might work however is sharing some of the lower level
> > building blocks. mnaser offered to make a PoC for
> > using https://github.com/openstack/ansible-config_template to generate
> > configuration in Kolla Ansible in place of merge_config and merge_yaml.
> > It requires some changes to that role to support merging a list of
> > source template files. We'd also need to add an external dependency to
> > our 'monorepo', or 'vendor' the module - trade offs to make in
> > complexity vs. maintaining our own module.
> >
> > I'd like to thank the OSA team for hosting the discussion - it was great
> > to meet the team and share experience.
> >
> > Cheers,
> > Mark
>
> --
> Cédric Jeanneret
> Software Engineer - OpenStack Platform
> Red Hat EMEA
> https://www.redhat.com/
>





Gaël,

--
Gaël Chamoulaud (He/Him/His)
.::. Senior Software Engineer .::. OpenStack .::. DFG UI & Validations .::.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190516/8aad43ce/attachment.sig>