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

Michal Rostecki mrostecki at mirantis.com
Tue Nov 3 18:01:43 UTC 2015


Egor,

I don't have much experience with Aurora, but as far as I see, it 
doesn't support mounting volumes from host yet:

https://issues.apache.org/jira/browse/AURORA-1107

In my opinion we should try to investigate currently existing frameworks 
which meets our main criteria before making decision about creating our 
own scheduler. Just to not re-invent things.

Regards,
Michal

On 11/03/2015 06:35 PM, Egor Guz wrote:
> 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" <mrostecki at 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 <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
>>>
>>
>> __________________________________________________________________________
>> 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