Open Stack

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