On 06/04/16 15:54 +0000, Hongbin Lu wrote:
-----Original Message----- From: Flavio Percoco [mailto:[email protected]] Sent: April-06-16 9:14 AM To: [email protected] 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-apiBased 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? Flavio -- @flaper87 Flavio Percoco
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
