<div dir="ltr">+1 to Georgy, we may need a framework on top of Mesos to enable Mesos manage long running services and have the capability of scaling, ha etc and Marathon is a good choice. Thanks.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 3, 2015 at 6:47 AM, Georgy Okrokvertskhov <span dir="ltr"><<a href="mailto:gokrokvertskhov@mirantis.com" target="_blank">gokrokvertskhov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Steve,<div><br></div><div>Thank you for the update. This is really interesting direction for Kolla.</div><div>I agree with Jeff. It is interesting to see what other frameworks will be used. I suspect Marathon framework is under consideration as it adds most of the application centric functionality like HA\restarter, scaling and rolling-restarts\upgrades. Kubernetes might be also a good candidate for that.</div><div><br></div><div>Thanks</div><div>Gosha</div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Mon, Nov 2, 2015 at 2:00 PM, Jeff Peeler <span dir="ltr"><<a href="mailto:jpeeler@redhat.com" target="_blank">jpeeler@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On Mon, Nov 2, 2015 at 12:02 PM, Steven Dake (stdake) <<a href="mailto:stdake@cisco.com" target="_blank">stdake@cisco.com</a>> wrote:<br>
> Hey folks,<br>
><br>
> We had an informal vote at the mid cycle from the core reviewers, and it was<br>
> a majority vote, so we went ahead and started the process of the<br>
> introduction of mesos orchestration into Kolla.<br>
><br>
> For background for our few core reviewers that couldn’t make it and the<br>
> broader community, Angus Salkeld has committed himself and 3 other Mirantis<br>
> engineers full time to investigate if Mesos could be used as an<br>
> orchestration engine in place of Ansible.  We are NOT dropping our Ansible<br>
> implementation in the short or long term.  Kolla will continue to lead with<br>
> Ansible.  At some point in Mitaka or the N cycle we may move the ansible<br>
> bits to a repository called “kolla-ansible” and the kolla repository would<br>
> end up containing the containers only.<br>
><br>
> The general consensus was that if folks wanted to add additional<br>
> orchestration systems for Kolla, they were free to do so if they did the<br>
> development and made a commitment to maintaining one core reviewer team with<br>
> broad expertise among the core reviewer team of how these various systems<br>
> work.<br>
><br>
> Angus has agreed to the following<br>
><br>
> A new team called “kolla-mesos-core” with 2 members.  One of the members is<br>
> Angus Salkeld, the other is selected by Angus Salkeld since this is a cookie<br>
> cutter empty repository.  This is typical of how new projects would operate,<br>
> but we don’t want a code dump and instead want an integrated core team.  To<br>
> prevent a situation which the current Ansible expertise shy away from the<br>
> Mesos implementation, the core reviewer team has committed to reviewing the<br>
> mesos code to get a feel for it.<br>
> Over the next 6-8 weeks these two folks will strive to join the Kolla core<br>
> team by typical means 1) irc participation 2) code generation 3) effective<br>
> and quality reviews 4) mailing list participation<br>
> Angus will create a technical specification which will we will roll-call<br>
> voted and only accepted once a majority of core review team is satisfied<br>
> with the solution.<br>
> The kolla-mesos deliverable will be under Kolla governance and be managed by<br>
> the Kolla core reviewer team after the kolla-mesos-core team is deprecated.<br>
> If the experiment fails, kolla-mesos will be placed in the attic.  There is<br>
> no specific window for the experiments, it is really up to Angus to decide<br>
> if the technique is viable down the road.<br>
> For the purpose of voting, the kolla-mesos-core team won’t be permitted to<br>
> vote (on things like this or other roll-call votes in the community) until<br>
> they are “promoted” to the koala-core reviewer team.<br>
><br>
><br>
> The core reviewer team has agreed to the following<br>
><br>
> Review patches in kolla-mesos repository<br>
> Actively learn how the mesos orchestration system works in the context of<br>
> Kolla<br>
> Actively support Angus’s effort in the existing Kolla code base as long as<br>
> it is not harmful to the Kolla code base<br>
><br>
> We all believe this will lead to a better outcome then Mirantis developing<br>
> some code on their own and later dumping it into the Kolla governance or<br>
> operating as a fork.<br>
><br>
> I’d like to give the core reviewers another chance to vote since the voting<br>
> was semi-rushed.<br>
><br>
> I am +1 given the above constraints.  I think this will help Kolla grow and<br>
> potentially provide a better (or arguably different) orchestration system<br>
> and is worth the investigation.  At no time will we put the existing Kolla<br>
> Ansible + Docker goodness into harms way, so I see no harm in an independent<br>
> repository especially if the core reviewer team strives to work as one team<br>
> (rather then two independent teams with the same code base).<br>
><br>
> Abstaining is the same as voting as –1, so please vote one way or another<br>
> with a couple line blob about your thoughts on the idea.<br>
><br>
> Note of the core reviewers there, we had 7 +1 votes (and we have a 9<br>
> individual core reviewer team so there is already a majority but I’d like to<br>
> give everyone an opportunity weigh in).<br>
<br>
</div></div>As one of the core reviewers who couldn't make the summit, this sounds<br>
like a very exciting direction to go in. I'd love to see more docs (I<br>
realize it's still early) on how mesos will be utilized and what<br>
additional frameworks may be used as well. Is kubernetes planned to be<br>
part of this mix since mesos works with it now?<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr"><font color="#999999"><span style="background-color:rgb(255,255,255)">Georgy Okrokvertskhov<br>
Architect,<br><span style="font-family:arial;font-size:small">OpenStack Platform Products,</span><br>
Mirantis</span><br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. <a href="tel:%2B1%20650%20963%209828" value="+16509639828" target="_blank">+1 650 963 9828</a><br>
Mob. <a href="tel:%2B1%20650%20996%203284" value="+16509963284" target="_blank">+1 650 996 3284</a></font><br></div></div>
</font></span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Thanks,<br><br></div>Jay Lau (Guangya Liu)<br></div></div></div></div>
</div>