Open Stack

> -----Original Message-----
> From: Flavio Percoco [mailto:flavio at redhat.com]
> Sent: April-06-16 12:16 PM
> To: Hongbin Lu
> Cc: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum] Containers lifecycle management
> 
> On 06/04/16 15:54 +0000, Hongbin Lu wrote:
> >
> >
> >> -----Original Message-----
> >> From: Flavio Percoco [mailto:flavio at redhat.com]
> >> Sent: April-06-16 9:14 AM
> >> To: openstack-dev at lists.openstack.org
> >> Subject: [openstack-dev] [magnum] Containers lifecycle management
> >>
> >>
> >> Greetings,
> >>
> >> I'm fairly new to Magnum and I hope my comments below are accurate.
> >>
> >> After reading some docs, links and other references, I seem to
> >> understand the Magnum team has a debate on whether providing
> >> abstraction for containers lifecycle is something the project should
> >> do or not. There's a patch that attempts to remove PODs and some
> >> debates on whether `container-*` commands are actually useful or not.
> >
> >FYI, according to the latest decision [1][2], below is what it will be:
> >* The k8s abstractions (pod/service/replication controller) will be
> removed. Users will need to use native tool (i.e. kubectl) to consume
> the k8s service.
> >* The docker swarm abstraction (container) will be moved to a
> separated driver. In particular, there will be two drivers for
> operators to select. The first driver will have minimum functionality
> (i.e. provision/manage/delete the swarm cluster). The second driver
> will have additional APIs to manage container resources in the swarm
> bay.
> >
> >[1] https://wiki.openstack.org/wiki/Magnum/NativeAPI
> >[2] https://etherpad.openstack.org/p/magnum-native-api
> >
> >>
> >> Based on the above, I wanted to understand what would be the
> >> recommended way for services willing to consume magnum to run
> >> containers? I've been digging a bit into what would be required for
> >> Trove to consume Magnum and based on the above, it seems the answer
> >> is that it should support either docker, k8s or mesos instead.
> >>
> >> - Is the above correct?
> >
> >I think it is correct. At current stage, Trove needs to select a bay
> type (docker swarm, k8s or mesos). If the use case is to manage a
> single container, it is recommended to choose the docker swarm bay type.
> >
> >> - Is there a way to create a container, transparently, on whatever
> >> backend using
> >>   Magnum's API?
> >
> >At current stage, it is impossible. There is a blueprint [3] for
> proposing to unify the heterogeneity of different bay types, but we are
> in disagreement on whether Magnum should provide such functionality.
> You are welcome to contribute your use cases if you prefer to have it
> implemented.
> >
> >[3] https://blueprints.launchpad.net/magnum/+spec/unified-containers
> 
> Thanks for the clarifications Hongbin.
> 
> Would it make sense to have the containers abstraction do this for
> other bays too?

This is a controversial topic. The Magnum team have discussed it before and we are in disagreement. I have proposed to re-discuss it in the design summit (requested topic #16).

[1] https://etherpad.openstack.org/p/magnum-newton-design-summit-topics

> 
> Flavio
> 
> --
> @flaper87
> Flavio Percoco