Open Stack

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?

Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160406/a3dc4af0/attachment.pgp>