Michal/Steve,
could you elaborate about choosing Marathon vs Aurora vs custom scheduler (to implement very precise control around placement/failures/etc)? ‹ Egor On 11/2/15, 22:44, "Michal Rostecki" <mroste...@mirantis.com> wrote: >Hi, > >+1 to what Steven said about Kubernetes. > >I'd like to add that these 3 things (pid=host, net=host, -v) are >supported by Marathon, so probably it's much less problematic for us >than Kubernetes at this moment. > >Regards, >Michal > >On 11/03/2015 12:18 AM, Steven Dake (stdake) wrote: >> Gosh, >> >> Kubernetes as an underlay is an interesting idea. We tried it for the >> first 6 months of Kolla¹s existence and it almost killed the project. >> Essentially kubernetes lacks support for pid=host, net=host, and v >> bind mounting. All 3 are required to deliver an operational OpenStack. >> >> This is why current Kolla goes with a bare metal underlay all docker >> options we need are available. >> >> Regards >> -steve >> >> >> From: Georgy Okrokvertskhov <gokrokvertsk...@mirantis.com >> <mailto:gokrokvertsk...@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 3:47 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) >> >> Hi Steve, >> >> Thank you for the update. This is really interesting direction for >>Kolla. >> 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. >> >> Thanks >> Gosha >> >> On Mon, Nov 2, 2015 at 2:00 PM, Jeff Peeler <jpee...@redhat.com >> <mailto:jpee...@redhat.com>> wrote: >> >> On Mon, Nov 2, 2015 at 12:02 PM, 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 >> > >> > 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. >> > 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 >> > 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. >> > 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. >> > 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. >> > 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 >> > >> > Review patches in kolla-mesos repository >> > Actively learn how the mesos orchestration system works in the >>context of >> > Kolla >> > 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. >> > >> > 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). >> >> As one of the core reviewers who couldn't make the summit, this >>sounds >> like a very exciting direction to go in. I'd love to see more docs >>(I >> realize it's still early) on how mesos will be utilized and what >> additional frameworks may be used as well. Is kubernetes planned to >>be >> part of this mix since mesos works with it now? >> >> >>_________________________________________________________________________ >>_ >> 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 >> >> >> >> >> -- >> Georgy Okrokvertskhov >> Architect, >> OpenStack Platform Products, >> Mirantis >> http://www.mirantis.com <http://www.mirantis.com/> >> Tel. +1 650 963 9828 >> Mob. +1 650 996 3284 >> >> >> >>_________________________________________________________________________ >>_ >> 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 >> > >__________________________________________________________________________ >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 __________________________________________________________________________ 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