From: Angus Salkeld <asalk...@mirantis.com<mailto:asalk...@mirantis.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Monday, November 2, 2015 at 4:18 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [kolla] Mesos orchestration as discussed at mid cycle (action required from core reviewers)
On Tue, Nov 3, 2015 at 3:04 AM Steven Dake (stdake) <std...@cisco.com<mailto:std...@cisco.com>> wrote: Hey folks, We had an informal vote at the mid cycle from the core reviewers, and it was a majority vote, so we went ahead and started the process of the introduction of mesos orchestration into Kolla. For background for our few core reviewers that couldn’t make it and the broader community, Angus Salkeld has committed himself and 3 other Mirantis engineers full time to investigate if Mesos could be used as an orchestration engine in place of Ansible. We are NOT dropping our Ansible implementation in the short or long term. Kolla will continue to lead with Ansible. At some point in Mitaka or the N cycle we may move the ansible bits to a repository called “kolla-ansible” and the kolla repository would end up containing the containers only. The general consensus was that if folks wanted to add additional orchestration systems for Kolla, they were free to do so if they did the development and made a commitment to maintaining one core reviewer team with broad expertise among the core reviewer team of how these various systems work. Angus has agreed to the following 1. A new team called “kolla-mesos-core” with 2 members. One of the members is Angus Salkeld, the other is selected by Angus Salkeld since this is a cookie cutter empty repository. This is typical of how new projects would operate, but we don’t want a code dump and instead want an integrated core team. To prevent a situation which the current Ansible expertise shy away from the Mesos implementation, the core reviewer team has committed to reviewing the mesos code to get a feel for it. 2. Over the next 6-8 weeks these two folks will strive to join the Kolla core team by typical means 1) irc participation 2) code generation 3) effective and quality reviews 4) mailing list participation 3. Angus will create a technical specification which will we will roll-call voted and only accepted once a majority of core review team is satisfied with the solution. I'll get stuck into this now. 1. The kolla-mesos deliverable will be under Kolla governance and be managed by the Kolla core reviewer team after the kolla-mesos-core team is deprecated. 2. If the experiment fails, kolla-mesos will be placed in the attic. There is no specific window for the experiments, it is really up to Angus to decide if the technique is viable down the road. 3. For the purpose of voting, the kolla-mesos-core team won’t be permitted to vote (on things like this or other roll-call votes in the community) until they are “promoted” to the koala-core reviewer team. The core reviewer team has agreed to the following 1. Review patches in kolla-mesos repository 2. Actively learn how the mesos orchestration system works in the context of Kolla 3. Actively support Angus’s effort in the existing Kolla code base as long as it is not harmful to the Kolla code base We all believe this will lead to a better outcome then Mirantis developing some code on their own and later dumping it into the Kolla governance or operating as a fork. Absolutely. I’d like to give the core reviewers another chance to vote since the voting was semi-rushed. I am +1 given the above constraints. I think this will help Kolla grow and potentially provide a better (or arguably different) orchestration system and is worth the investigation. At no time will we put the existing Kolla Ansible + Docker goodness into harms way, so I see no harm in an independent repository especially if the core reviewer team strives to work as one team (rather then two independent teams with the same code base). Abstaining is the same as voting as –1, so please vote one way or another with a couple line blob about your thoughts on the idea. Note of the core reviewers there, we had 7 +1 votes (and we have a 9 individual core reviewer team so there is already a majority but I’d like to give everyone an opportunity weigh in). Thanks for doing this Steve, we want to do this as much as possible in the open (we only have a very basic bits of PoC code, we will get stuck into getting this code up ASAP - and pushing it forward). Blame the core team :) I suspect you will end up retrying a lot of patterns we tried and failed with Kubernetes. Kubernetes eventually was found to be non-viable by the delivery of this 2 week project: https://github.com/sdake/compute-upgrade Documented in this blog: http://sdake.io/2015/01/28/an-atomic-upgrade-process-for-openstack-compute-nodes/ Regards -steve Here is the review for the new repo: https://review.openstack.org/#/c/240433 Angus Regards -steve __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ 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
