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" <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
