-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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
