Open Stack

-1 to not having a separate kolla-kubernetes repo.

> The kubernetes codebase will be maintained in the https://github.com/openstack/kolla repository under the kubernees top level directory.

I don't agree here.  This needs to be its own repo.

> I feel we made a couple errors with the creation of Kolla-mesos that I feel needs correction. Our first error the kolla-mesos-core team made a lack of a diversely affiliated team membership developing the code base. The above list has 
> significant diversity. 

I don't think diversity is a requirement for an alternative deployment tool to be created in the Kolla community. It would be great, I agree, but sometimes communities are diverse and sometimes they arn't.  Kolla can't require that. It's not in kolla's mission statement.  

> The second error is that the repository was split in the first place. 
> This resulted in a separate ABI to the containers being implemented which was a sore spot for me personally. We did our best to build both 
> sides of the bridge here, but this time I'd like the bridge between these two interests and set of individuals to be fully built before beginning. 

Kolla cores are there to guard the gate and we can only recommend a way to build a deployment tool around the Kolla containers. The creation of the alternative ABI was a Kolla-mesos choice. Therefore, next time the kolla cores, myself included, need to be more active in the discussion around the ABI in other deployment tools trying to consume kolla containers.  I agree that it would be great to unify around one consumption method of the containers, but that's not a guarantee.

> As such, I'd ask the existing kolla-core team to trust my judgement on this point and 
> roll with it. We can always change the structure later if this model doesn't work out as I expect it will, but if we started with split repos and a changed structure to begin with, we can't go back to a non-split repo as the action is 
> irreversible according to dims. 
> I know this proposal may seem uncomfortable for our existing kolla-core team. I can assure you based upon twenty years of open source participation this will result in a better outcome. We had talked about splitting the repositories, 
> and our plan around that is to punt until such action is absolutely necessary. Keeping things in one repository can always be split later, but a premature split can never be undone without losing git commit history. 

I don't agree. A lot of people in the community liked the split of kolla-kubernetes until the project reaches a point where Kolla cores need to revisit the repo split action.  Then, Kolla cores vote to pull kolla-kubernetes in or vote to split out kolla-ansible. Ansible still hasn't been split out and a unified CLI will guarantee both kolla-ansible and kolla-kubernetes will never be split. That's not a punt. We may lose some git history, but adding 30 new cores to kolla will do more damage to the project.

It's not a matter of trusting judgment. Everyone kolla core has +1 or -1. We'll see if other cores agree.

> We will mark the kubernetes orchestration in Kolla as experimental until existing feature parity is achieved in the kolla CLI tool. After the initial implementation is ready, we will mark it as ready for evaluation . At the conclusion 
> of Newton, assuming the implementation works well, we will mark the implementation as "production ready", just as our current Ansible orchestrated implementation is recorded. 
>
> ** All CLI features of the kolla-ansible shell script to be implemented for "ready-for-evaluation" stage. ** 
>
> This includes the following CLI operations where they make sense: 
>
>
>    1. Prechecks 
>    2. mariadb_recvoery 
>    3. Deploy 
>    4. Post-deploy 
>    5. Pull 
>    6. Upgrade 
>    7. Reconfgiure 
>    8. Certificates 
> As part of this change, I will be submitting a change to rename kolla-ansible to kolla with appropriate documentation changes. This one shell script will in the future will read from globals.yml a yaml variable which is 
> "orchestratoin_engine" which may be either ansible or kubernetes. In this way, the terminology I strongly dislike "first class citizen" will be removed from our lexicon in the Kolla repository. Instead of first class/second class 
> citizen, we will have all orchestration systems as "first class citizens" with varying levels of maturity. 

There will always be tools out there that choose not to join the Kolla repo.  Pulling in a deployment tool that wants to use Kolla's containers is a mistake.  Everyone has the same level of access to kolla's containers.  In my mind, one repo doesn't send this message.

> Please vote +1 if in favor, -1 if not in favor. 7 votes will trigger early closing of the vote and the creation of the kubernetes directory with a README.rst. The voting will remain open for 1 week until May 6th unless a majority is 
> reached prior to the voting window closing. I would appreciate a quick turnaround on the voting so the work can begin rapidly. If you have arguments with this approach I'd like to hear them. If they involve the concept of trust, I'd 
> ask you to keep in mind we are a community working towards a common goal with common objectives, and to trust until given reason otherwise . 

Trust isn't the issue here. The spec that people signed up for says "Create kolla-kubernetes repo".

In this thread there seems to be two votes.  One is the split repo discussion Kolla had at summit. The second is to create kolla-kubernetes. I'm all for creating kolla-kubernetes, given that I wrote the spec, but will defer to the core team as to whether this should be in kolla or kolla-kubernetes. 

Thanks,
Ryan