[openstack-dev] [kolla] Mesos orchestration as discussed at mid cycle (action required from core reviewers)

Michal Rostecki mrostecki at mirantis.com
Tue Nov 3 06:44:59 UTC 2015


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 <gokrokvertskhov at mirantis.com
> <mailto:gokrokvertskhov at mirantis.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org
> <mailto:openstack-dev at lists.openstack.org>>
> Date: Monday, November 2, 2015 at 3:47 PM
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org
> <mailto:openstack-dev at 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 <jpeeler at redhat.com
> <mailto:jpeeler at redhat.com>> wrote:
>
>     On Mon, Nov 2, 2015 at 12:02 PM, Steven Dake (stdake)
>     <stdake at cisco.com <mailto:stdake at 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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



More information about the OpenStack-dev mailing list