Open Stack

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.

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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190516/89d575d3/attachment.sig>