Hi Hongbin,
The proposal sounds reasonable: basically it provides an agnostic
alternative to the single command line that a user can invoke with docker
or kubectl. If the user needs more advanced support (environment
variables, volumes, network, ...), we would defer to the COE support and
the user would need to pick one.
I also notice that the command does not specify a bay. If this is the
intention, this could also cover another use case that I hear frequently
when talking about Magnum:
"I just want to run some containers, I don't want to have to create a bay
or figure out what goes into a bay model"
In this case, there is probably a default bay model and a default bay
that would be created on the first invocation. The command would take some
extra time the first time, but afterward it should be fast. The default
configuration would come with Magnum, or be set by the cloud provider.
Ton,
From: Hongbin Lu <hongbin...@huawei.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date: 12/10/2015 08:01 PM
Subject: Re: [openstack-dev] Mesos Conductor using container-create
operations
Hi Ton,
Thanks for the feedback. Here is a clarification. The proposal is neither
for using existing DSL to express a container, nor for investing a new DSL.
Instead, I proposed to hide the complexity of existing DSLs and expose a
simple API to users. For example, if users want to create a container, they
could type something like:
magnum container-create –name XXX –image XXX –command XXX
Magnum will process the request and translate it to COE-specific API calls.
For k8s, we could dynamically generate a pod with a single container and
fill the pod with the inputted values (image, command, etc.). Similarly, in
marathon, we could generate an app based on inputs. A key advantage of that
is simple and doesn’t require COE-specific knowledge.
Best regards,
Hongbin
From: Ton Ngo [mailto:t...@us.ibm.com]
Sent: December-10-15 8:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Mesos Conductor using container-create
operations
I think extending the container object to Mesos via command like
container-create is a fine idea. Going into details, however, we run into
some complication.
1. The user would still have to choose a DSL to express the container. This
would have to be a kube and/or swarm DSL since we don't want to invent a
new one.
2. For Mesos bay in particular, kube or swarm may be running on top of
Mesos along side with Marathon, so somewhere along the line, Magnum has to
be able to make the distinction and handle things appropriately.
We should think through the scenarios carefully to come to agreement on how
this would work.
Ton Ngo,
Inactive hide details for Hongbin Lu ---12/09/2015 03:09:23 PM---As Bharath
mentioned, I am +1 to extend the "container" objectHongbin Lu ---12/09/2015
03:09:23 PM---As Bharath mentioned, I am +1 to extend the "container"
object to Mesos bay. In addition, I propose
From: Hongbin Lu <hongbin...@huawei.com>
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
Date: 12/09/2015 03:09 PM
Subject: Re: [openstack-dev] Mesos Conductor using container-create
operations
As Bharath mentioned, I am +1 to extend the “container” object to Mesos
bay. In addition, I propose to extend “container” to k8s as well (the
details are described in this BP [1]). The goal is to promote this API
resource to be technology-agnostic and make it portable across all COEs. I
am going to justify this proposal by a use case.
Use case:
I have an app. I used to deploy my app to a VM in OpenStack. Right now, I
want to deploy my app to a container. I have basic knowledge of container
but not familiar with specific container tech. I want a simple and
intuitive API to operate a container (i.e. CRUD), like how I operated a VM
before. I find it hard to learn the DSL introduced by a specific COE
(k8s/marathon). Most importantly, I want my deployment to be portable
regardless of the choice of cluster management system and/or container
runtime. I want OpenStack to be the only integration point, because I don’t
want to be locked-in to specific container tech. I want to avoid the risk
that a specific container tech being replaced by another in the future.
Optimally, I want Keystone to be the only authentication system that I need
to deal with. I don't want the extra complexity to deal with additional
authentication system introduced by specific COE.
Solution:
Implement "container" object for k8s and mesos bay (and all the COEs
introduced in the future).
That's it. I would appreciate if you can share your thoughts on this
proposal.
[1] https://blueprints.launchpad.net/magnum/+spec/unified-containers
Best regards,
Hongbin
From: bharath thiruveedula [mailto:bharath_...@hotmail.com]
Sent: December-08-15 11:40 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] Mesos Conductor using container-create operations
Hi,
As we have discussed in last meeting, we cannot continue with changes in
container-create[1] as long as we have suitable use case. But I honestly
feel to have some kind of support for mesos + marathon apps, because magnum
supports COE related functionalities for docker swarm (container-create)
and k8s (pod-create, rc-create..) but not for mesos bays.
As hongbin suggested, we use the existing functionality of container-create
and support in mesos-conductor. Currently we have container-create only for
docker swarm bay. Let's have support for the same command for mesos bay
with out any changes in client side.
Let me know your suggestions.
Regards
Bharath T
__________________________________________________________________________
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 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 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
