> -----Original Message----- > From: Flavio Percoco [mailto:fla...@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:fla...@redhat.com] > >> Sent: April-06-16 9:14 AM > >> To: openstack-dev@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 __________________________________________________________________________ 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
