[ptg][kolla][openstack-ansible][tripleo] PTG cross-project summary
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).
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
Let's see what this all gives indeed :)
I'd like to thank the OSA team for hosting the discussion - it was great to meet the team and share experience.
Thanks for being there, and for being open to discussion. It was a pleasure to see you in those conversations!
Regards, Jean-Philippe Evrard
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
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 .::.
On Thu, 16 May 2019 at 11:41, Cédric Jeanneret cjeanner@redhat.com 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.
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 :)
Hi Cedric. The validation framework is based around this new tempest
ansible role, correct? Presumably each deployment tool would provide a its own entry point on top of that. How does the pre/post deploy etc affect what validations are run? Is that up to the deployment tool, or defined in the ansible role, or somewhere else?
On 5/16/19 3:53 PM, Mark Goddard wrote:
On Thu, 16 May 2019 at 11:41, Cédric Jeanneret <cjeanner@redhat.com mailto:cjeanner@redhat.com> 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. 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 :)Hi Cedric. The validation framework is based around this new tempest ansible role, correct? Presumably each deployment tool would provide a its own entry point on top of that. How does the pre/post deploy etc affect what validations are run? Is that up to the deployment tool, or defined in the ansible role, or somewhere else?
So for now we "only" have a (fairly) good integration with the "openstack tripleo" subcommand[1].
Currently, we're mainly using plain ansible roles and playbook, being launched by Mistral. We intend to allow non-Mistral runs (Work In Progress) and, in not too far future hopefully, to provide a descent python library within the tripleo-validations package for a better integration. It's still early, we still need to put things together, but if we can already raise awareness and interest for this work, it will help getting more involvement and time in order to provide a great bundle :).
If you want to know more, you can already have a look at the new doc[1].
Does it help a bit understanding the possibilities?
Cheers,
C.
[1] https://docs.openstack.org/tripleo-docs/latest/validations/index.html (note: we will probably add some more inputs in there)
On Thu, 16 May 2019 at 14:59, Cédric Jeanneret cjeanner@redhat.com wrote:
On 5/16/19 3:53 PM, Mark Goddard wrote:
On Thu, 16 May 2019 at 11:41, Cédric Jeanneret <cjeanner@redhat.com mailto:cjeanner@redhat.com> 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 arefeatures
> and changes that all deployment tools need to make. Examplescoming 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 theupgrade
> checker support added in Stein, and found that our expectation of how it > would work was fairly aligned in the room, but not aligned withhow 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 :)Hi Cedric. The validation framework is based around this new tempest ansible role, correct? Presumably each deployment tool would provide a its own entry point on top of that. How does the pre/post deploy etc affect what validations are run? Is that up to the deployment tool, or defined in the ansible role, or somewhere else?
So for now we "only" have a (fairly) good integration with the "openstack tripleo" subcommand[1].
Currently, we're mainly using plain ansible roles and playbook, being launched by Mistral. We intend to allow non-Mistral runs (Work In Progress) and, in not too far future hopefully, to provide a descent python library within the tripleo-validations package for a better integration. It's still early, we still need to put things together, but if we can already raise awareness and interest for this work, it will help getting more involvement and time in order to provide a great bundle :).
If you want to know more, you can already have a look at the new doc[1].
Does it help a bit understanding the possibilities?
Thanks for following up Cedric, that is quite useful. I'll take a look through.
Cheers,
C.
[1] https://docs.openstack.org/tripleo-docs/latest/validations/index.html (note: we will probably add some more inputs in there) -- Cédric Jeanneret Software Engineer - OpenStack Platform Red Hat EMEA https://www.redhat.com/
participants (4)
-
Cédric Jeanneret
-
Gaël Chamoulaud
-
Jean-Philippe Evrard
-
Mark Goddard