[tc][kolla][kayobe] Feedback request: kayobe seeking official status
Hi,
The Kayobe project [1] seeks to become an official OpenStack project during the Train cycle.
Kayobe is a deployment tool that uses Kolla Ansible and Bifrost to deploy a containerised OpenStack control plane to bare metal. The project was started 2 years ago to fill in some gaps in Kolla Ansible, and has since been used for a number of production deployments. It's frequently deployed in Scientific Computing environments, but is not limited to this. We ran a packed workshop on Kayobe at the Denver summit and got some great feedback, with many people agreeing that it makes Kolla Ansible easier to adopt in environments with no existing provisioning system. We use OpenStack development workflows, including IRC, the mailing list, opendev, zuul, etc.
We see two options for becoming an official OpenStack project:
1. become a deliverable of the Kolla project 2. become an official top level OpenStack project
Given the affinity with the Kolla project I feel that option 1 seems natural. However, I do not want to use influence as PTL to force this approach.
There is currently only one person (me) who is a member of both core teams, although all kayobe cores are active in the Kolla community. I would not expect core memberships to change, although we would probably end up combining IRC channels, meetings and design sessions. I would hope that combining these communities would be to the benefit of both.
Please provide feedback on this matter - whether positive or negative.
Thanks, Mark
W dniu 05.06.2019 o 11:11, Mark Goddard pisze:
The Kayobe project [1] seeks to become an official OpenStack project during the Train cycle.
We see two options for becoming an official OpenStack project:
- become a deliverable of the Kolla project
- become an official top level OpenStack project
Please provide feedback on this matter - whether positive or negative.
As Kolla core I support both options. If Kayobe became kolla/kayobe then I will be fine. Similar with openstack/kayobe project.
Mark Goddard wrote:
[...] We see two options for becoming an official OpenStack project:
- become a deliverable of the Kolla project
- become an official top level OpenStack project
Given the affinity with the Kolla project I feel that option 1 seems natural. However, I do not want to use influence as PTL to force this approach. [...]
From a governance perspective, the two options are definitely possible.
Kayobe can be seen as one of the Kolla-derived deployment tools, or it can be seen as a new deployment tool combining two existing projects (Kolla and Bifrost). Project teams are cheap: the best solution is the one that best aligns to the social reality.
So I'd say the decision depends on how much independence Kayobe wants to have from Kolla. Having a separate project team will for example make it easier to have separate meetings, but harder to have common meetings. How much of a separate team is Kayobe from Kolla? How much do you want it to stay that way?
On Thu, 6 Jun 2019 at 09:27, Thierry Carrez thierry@openstack.org wrote:
Mark Goddard wrote:
[...] We see two options for becoming an official OpenStack project:
- become a deliverable of the Kolla project
- become an official top level OpenStack project
Given the affinity with the Kolla project I feel that option 1 seems natural. However, I do not want to use influence as PTL to force this approach. [...]
From a governance perspective, the two options are definitely possible.
Kayobe can be seen as one of the Kolla-derived deployment tools, or it can be seen as a new deployment tool combining two existing projects (Kolla and Bifrost). Project teams are cheap: the best solution is the one that best aligns to the social reality.
So I'd say the decision depends on how much independence Kayobe wants to have from Kolla. Having a separate project team will for example make it easier to have separate meetings, but harder to have common meetings. How much of a separate team is Kayobe from Kolla? How much do you want it to stay that way?
Right now the intersection of the core teams is only me. While all Kayobe contributors are familiar with Kolla projects, the reverse is not true. This is partly because Kolla and/or Kolla Ansible can be used without Kayobe, and partly because Kayobe is a newer project which typically gets adopted at the beginning of a cloud deployment.
It certainly seems to make sense from the Kayobe community perspective to join these communities. I think the question the Kolla team needs to ask is whether the benefit of a more complete set of tooling is worth the overhead of adding a new deliverable that may not be used by all contributors or in all deployments.
-- Thierry Carrez (ttx)
---- On Thu, 06 Jun 2019 17:49:44 +0900 Mark Goddard mark@stackhpc.com wrote ----
On Thu, 6 Jun 2019 at 09:27, Thierry Carrez thierry@openstack.org wrote:
Mark Goddard wrote:
[...] We see two options for becoming an official OpenStack project:
- become a deliverable of the Kolla project
- become an official top level OpenStack project
Given the affinity with the Kolla project I feel that option 1 seems natural. However, I do not want to use influence as PTL to force this approach. [...]
From a governance perspective, the two options are definitely possible.
Kayobe can be seen as one of the Kolla-derived deployment tools, or it can be seen as a new deployment tool combining two existing projects (Kolla and Bifrost). Project teams are cheap: the best solution is the one that best aligns to the social reality.
So I'd say the decision depends on how much independence Kayobe wants to have from Kolla. Having a separate project team will for example make it easier to have separate meetings, but harder to have common meetings. How much of a separate team is Kayobe from Kolla? How much do you want it to stay that way?
Right now the intersection of the core teams is only me. While all Kayobe contributors are familiar with Kolla projects, the reverse is not true. This is partly because Kolla and/or Kolla Ansible can be used without Kayobe, and partly because Kayobe is a newer project which typically gets adopted at the beginning of a cloud deployment.
It certainly seems to make sense from the Kayobe community perspective to join these communities. I think the question the Kolla team needs to ask is whether the benefit of a more complete set of tooling is worth the overhead of adding a new deliverable that may not be used by all contributors or in all deployments.
With my quick read on technical relation between Kolla-ansible and Kayobe, options1 make much sense to me too. It can give more benefits of working more closely and handle the dependencies and future roadmap etc.
And having a completely separate team (in Kayobe case you have some overlap too even only you but that can increase in future) for repo under the same project is not new. We have a lot of existing projects which maintain the separate team for their different repo/deliverables without overlap.
There are more extra work you need to consider if you go with a separate Project. For example, PTL things and its responsibility. I would say we can avoid that in Kayobe case because of its technical mission/relation to Kolla-ansible.
-gmann
-- Thierry Carrez (ttx)
participants (4)
-
gmann＠ghanshyammann.com
-
Marcin Juszkiewicz
-
Mark Goddard
-
Thierry Carrez