[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