Re: [openstack-dev] [magnum] Containers lifecycle management
> -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 +, 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
Re: [openstack-dev] [magnum] Containers lifecycle management
On 06/04/16 15:54 +, 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? Flavio -- @flaper87 Flavio Percoco signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [magnum] Containers lifecycle management
> -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 > > Sorry if I got something wrong, > 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
[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. 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? - Is there a way to create a container, transparently, on whatever backend using Magnum's API? Sorry if I got something wrong, Flavio -- @flaper87 Flavio Percoco signature.asc Description: PGP signature __ 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
