Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Adrian Otto]

Magnum is not a COE installer. It offers multi tenancy from the ground up, is 
well integrated with OpenStack services, and more COE features pre-configured 
than you would get with an ordinary stock deployment. For example, magnum 
offers integration with keystone that allows developer self-service to get a 
native container service in a few minutes with the same ease as getting a 
database server from Trove. It allows cloud operators to set up the COE 
templates in a way that they can be used to fit policies of that particular 
cloud.

Keeping a COE working with OpenStack requires expertise that the Magnum team 
has codified across multiple options.

--
Adrian

On Apr 23, 2016, at 2:55 PM, Hongbin Lu 
<hongbin...@huawei.com<mailto:hongbin...@huawei.com>> wrote:

I am not necessary agree with the viewpoint below, but that is the majority 
viewpoints when I was trying to sell Magnum to them. There are people who 
interested in adopting Magnum, but they ran away after they figured out what 
Magnum actually offers is a COE deployment service. My takeaway is COE 
deployment is not the real pain, and there are several alternatives available 
(Heat, Ansible, Chef, Puppet, Juju, etc.). Limiting Magnum to be a COE 
deployment service might prolong the existing adoption problem.

Best regards,
Hongbin

From: Georgy Okrokvertskhov [mailto:gokrokvertsk...@mirantis.com]
Sent: April-20-16 6:51 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
abstraction for all COEs

If Magnum will be focused on installation and management for COE it will be 
unclear how much it is different from Heat and other generic orchestrations.  
It looks like most of the current Magnum functionality is provided by Heat. 
Magnum focus on deployment will potentially lead to another Heat-like  API.
Unless Magnum is really focused on containers its value will be minimal for 
OpenStack users who already use Heat/Orchestration.


On Wed, Apr 20, 2016 at 3:12 PM, Keith Bray 
<keith.b...@rackspace.com<mailto:keith.b...@rackspace.com>> wrote:
Magnum doesn¹t have to preclude tight integration for single COEs you
speak of.  The heavy lifting of tight integration of the COE in to
OpenStack (so that it performs optimally with the infra) can be modular
(where the work is performed by plug-in models to Magnum, not performed by
Magnum itself. The tight integration can be done by leveraging existing
technologies (Heat and/or choose your DevOps tool of choice:
Chef/Ansible/etc). This allows interested community members to focus on
tight integration of whatever COE they want, focusing specifically on the
COE integration part, contributing that integration focus to Magnum via
plug-ins, without having to actually know much about Magnum, but instead
contribute to the COE plug-in using DevOps tools of choice.   Pegging
Magnum to one-and-only one COE means there will be a Magnum2, Magnum3,
etc. project for every COE of interest, all with different ways of kicking
off COE management.  Magnum could unify that experience for users and
operators, without picking a winner in the COE space ‹ this is just like
Nova not picking a winner between VM flavors or OS types.  It just
facilitates instantiation and management of thins.  Opinion here:  The
value of Magnum is in being a light-weight/thin API, providing modular
choice and plug-ability to COE provisioning and management, thereby
providing operators and users choice of COE instantiation and management
(via the bay concept), where each COE can be as tightly or loosely
integrated as desired by different plug-ins contributed to perform the COE
setup and configurations.  So, Magnum could have two or more swarm plug-in
options contributed to the community.. One overlays generic swarm on VMs.
The other swarm plug-in could instantiate swarm tightly integrated to
neutron, keystone, etc on to bare metal.  Magnum just facilities a plug-in
model with thin API to offer choice of CEO instantiation and management.
The plug-in does the heavy lifting using whatever methods desired by the
curator.

That¹s my $0.2.

-Keith

On 4/20/16, 4:49 PM, "Joshua Harlow" 
<harlo...@fastmail.com<mailto:harlo...@fastmail.com>> wrote:

>Thierry Carrez wrote:
>> Adrian Otto wrote:
>>> This pursuit is a trap. Magnum should focus on making native container
>>> APIs available. We should not wrap APIs with leaky abstractions. The
>>> lowest common denominator of all COEs is an remarkably low value API
>>> that adds considerable complexity to Magnum that will not
>>> strategically advance OpenStack. If we instead focus our effort on
>>> making the COEs work better on OpenStack, that would be a winning
>>> strategy. Support and compliment our various COE ecosystems.
>
>So I'm all for avoiding 'wrap APIs with leaky abstractions' and 'making
>

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Hongbin Lu]

> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: April-23-16 12:23 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> abstraction for all COEs
> 
> On 21/04/16 23:34 +, Fox, Kevin M wrote:
> >Amrith,
> >
> >Very well thought out. Thanks. :)
> >
> >I agree a nova driver that let you treat containers the same way as
> vm's, bare metal, and lxc containers would be a great thing, and if it
> could plug into magnum managed clusters well, would be awesome.
> >
> >I think a bit of the conversation around it gets muddy when you start
> talking about the philosophy between lxc and docker containers. They
> are very different. lxc containers typically are heavy weight. You
> think of them more as a vm without the kernel. Multiple daemons run in
> them, you have a regular init system, etc. This isn't bad. It has some
> benefits. But it also has some drawbacks.
> >
> >Docker's philosophy of software deployment has typically been much
> different then that, and doesn't lend itself to launching that way with
> nova. With docker, each individual services gets its own container, and
> are co'scheduled. Not at the ip level but even lower at the
> unix/filesystem level.
> >
> >For example, with Trove, architected with the docker philosophy, you
> might have two containers, one for mysql which exports its unix socket
> to a second container for the guest agent, which talks to mysql over
> the shared socket. The benefit with this is, you only need one guest
> agent container for all of your different types of databases (mysql,
> postgres,mongodb,etc). Your db and your guest agent can even be
> different distro's and still will work. Its then also very easy to
> upgrade just the guest agent container without affecting the db
> container at all. You just delete/recreate that container, leaving the
> other container alone.
> 
> There are ways to make the agent and the database run under the same
> docker container. In my local tests, I've tried both ways and I
> certainly prefer the one that provides separate containers for the
> agent and the database instance.
> As you mentioned below, this can't be architected under the same nova
> API but it could likely be architected under the same containers API as
> this philosophy is shared by other COEs.
> 
> >So, when you architect docker containers using this phylosophy, you
> can't really use nova as is, as an abstraction. You can't share unix
> sockets between container instances... But, this kind of functionality
> is very common in all the COE's and should be able to be easily made
> into an abstraction that all current COE's can easily launch. Hence
> thinking it might be best put in Magnum. A nova extension may work
> too... not sure. But seems more natural in Magnum to me.
> 
> I'm on the boat of folks that think it'd be nice to have a single API
> to manage *containers lifecycle*. TBH, I'd hate to see yet another
> service/project being created for this BUT I could see why some folks
> would prefer that over adding these APIs to Magnum.

I don't like to see another service/project as well. IMHO, Magnum claimed to be 
a container service so it should be within the scope of Magnum. However, if the 
majority wants to push it out, it is fine with me.

> 
> For a long time I pitched what Amrith said below. Most users shouldn't
> care whether their compute resource is a container, a bare metal node
> or a VM.
> Unfortunately, the current APIs don't allow for abstracting compute
> resources well enough. For those users that do care, then access to the
> native API must be provided (YAY, Magnum does this).
> 
> As far as the Trove use case goes, I believe a common API would do most
> of the job but there are things that access to the native API would do
> better. For example:
> 
> - Managing One Agent: Many Instances deployments.
> - Managing containers upgrades (whether it's a db instance upgrade or
> an agent upgrade)
> 
> Flavio
> 
> >Thanks,
> >Kevin
> >
> >
> >From: Amrith Kumar [amr...@tesora.com]
> >Sent: Thursday, April 21, 2016 2:21 PM
> >To: OpenStack Development Mailing List (not for usage questions)
> >Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> >abstraction for all COEs
> >
> >As I was preparing some thoughts for the Board/TC meeting on Sunday
> that will discuss this topic, I made the notes below and was going to
> post them on a topic specific etherpad but I didn't find one.
> >
> >I want to represent the view point

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Hongbin Lu]

I am not necessary agree with the viewpoint below, but that is the majority 
viewpoints when I was trying to sell Magnum to them. There are people who 
interested in adopting Magnum, but they ran away after they figured out what 
Magnum actually offers is a COE deployment service. My takeaway is COE 
deployment is not the real pain, and there are several alternatives available 
(Heat, Ansible, Chef, Puppet, Juju, etc.). Limiting Magnum to be a COE 
deployment service might prolong the existing adoption problem.

Best regards,
Hongbin

From: Georgy Okrokvertskhov [mailto:gokrokvertsk...@mirantis.com]
Sent: April-20-16 6:51 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
abstraction for all COEs

If Magnum will be focused on installation and management for COE it will be 
unclear how much it is different from Heat and other generic orchestrations.  
It looks like most of the current Magnum functionality is provided by Heat. 
Magnum focus on deployment will potentially lead to another Heat-like  API.
Unless Magnum is really focused on containers its value will be minimal for 
OpenStack users who already use Heat/Orchestration.


On Wed, Apr 20, 2016 at 3:12 PM, Keith Bray 
<keith.b...@rackspace.com<mailto:keith.b...@rackspace.com>> wrote:
Magnum doesn¹t have to preclude tight integration for single COEs you
speak of.  The heavy lifting of tight integration of the COE in to
OpenStack (so that it performs optimally with the infra) can be modular
(where the work is performed by plug-in models to Magnum, not performed by
Magnum itself. The tight integration can be done by leveraging existing
technologies (Heat and/or choose your DevOps tool of choice:
Chef/Ansible/etc). This allows interested community members to focus on
tight integration of whatever COE they want, focusing specifically on the
COE integration part, contributing that integration focus to Magnum via
plug-ins, without having to actually know much about Magnum, but instead
contribute to the COE plug-in using DevOps tools of choice.   Pegging
Magnum to one-and-only one COE means there will be a Magnum2, Magnum3,
etc. project for every COE of interest, all with different ways of kicking
off COE management.  Magnum could unify that experience for users and
operators, without picking a winner in the COE space ‹ this is just like
Nova not picking a winner between VM flavors or OS types.  It just
facilitates instantiation and management of thins.  Opinion here:  The
value of Magnum is in being a light-weight/thin API, providing modular
choice and plug-ability to COE provisioning and management, thereby
providing operators and users choice of COE instantiation and management
(via the bay concept), where each COE can be as tightly or loosely
integrated as desired by different plug-ins contributed to perform the COE
setup and configurations.  So, Magnum could have two or more swarm plug-in
options contributed to the community.. One overlays generic swarm on VMs.
The other swarm plug-in could instantiate swarm tightly integrated to
neutron, keystone, etc on to bare metal.  Magnum just facilities a plug-in
model with thin API to offer choice of CEO instantiation and management.
The plug-in does the heavy lifting using whatever methods desired by the
curator.

That¹s my $0.2.

-Keith

On 4/20/16, 4:49 PM, "Joshua Harlow" 
<harlo...@fastmail.com<mailto:harlo...@fastmail.com>> wrote:

>Thierry Carrez wrote:
>> Adrian Otto wrote:
>>> This pursuit is a trap. Magnum should focus on making native container
>>> APIs available. We should not wrap APIs with leaky abstractions. The
>>> lowest common denominator of all COEs is an remarkably low value API
>>> that adds considerable complexity to Magnum that will not
>>> strategically advance OpenStack. If we instead focus our effort on
>>> making the COEs work better on OpenStack, that would be a winning
>>> strategy. Support and compliment our various COE ecosystems.
>
>So I'm all for avoiding 'wrap APIs with leaky abstractions' and 'making
>COEs work better on OpenStack' but I do dislike the part about COEs
>(plural) because it is once again the old non-opinionated problem that
>we (as a community) suffer from.
>
>Just my 2 cents, but I'd almost rather we pick one COE and integrate
>that deeply/tightly with openstack, and yes if this causes some part of
>the openstack community to be annoyed, meh, to bad. Sadly I have a
>feeling we are hurting ourselves by continuing to try to be everything
>and not picking anything (it's a general thing we, as a group, seem to
>be good at, lol). I mean I get the reason to just support all the
>things, but it feels like we as a community could just pick something,
>work together on figuring out how to pick one, using all these bright
&g

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Flavio Percoco]

On 21/04/16 23:34 +, Fox, Kevin M wrote:

Amrith,

Very well thought out. Thanks. :)

I agree a nova driver that let you treat containers the same way as vm's, bare 
metal, and lxc containers would be a great thing, and if it could plug into 
magnum managed clusters well, would be awesome.

I think a bit of the conversation around it gets muddy when you start talking 
about the philosophy between lxc and docker containers. They are very 
different. lxc containers typically are heavy weight. You think of them more as 
a vm without the kernel. Multiple daemons run in them, you have a regular init 
system, etc. This isn't bad. It has some benefits. But it also has some 
drawbacks.

Docker's philosophy of software deployment has typically been much different 
then that, and doesn't lend itself to launching that way with nova. With 
docker, each individual services gets its own container, and are co'scheduled. 
Not at the ip level but even lower at the unix/filesystem level.

For example, with Trove, architected with the docker philosophy, you might have 
two containers, one for mysql which exports its unix socket to a second 
container for the guest agent, which talks to mysql over the shared socket. The 
benefit with this is, you only need one guest agent container for all of your 
different types of databases (mysql, postgres,mongodb,etc). Your db and your 
guest agent can even be different distro's and still will work. Its then also 
very easy to upgrade just the guest agent container without affecting the db 
container at all. You just delete/recreate that container, leaving the other 
container alone.


There are ways to make the agent and the database run under the same docker
container. In my local tests, I've tried both ways and I certainly prefer the
one that provides separate containers for the agent and the database instance.
As you mentioned below, this can't be architected under the same nova API but it
could likely be architected under the same containers API as this philosophy is
shared by other COEs.


So, when you architect docker containers using this phylosophy, you can't 
really use nova as is, as an abstraction. You can't share unix sockets between 
container instances... But, this kind of functionality is very common in all 
the COE's and should be able to be easily made into an abstraction that all 
current COE's can easily launch. Hence thinking it might be best put in Magnum. 
A nova extension may work too... not sure. But seems more natural in Magnum to 
me.


I'm on the boat of folks that think it'd be nice to have a single API to manage
*containers lifecycle*. TBH, I'd hate to see yet another service/project being
created for this BUT I could see why some folks would prefer that over adding
these APIs to Magnum.

For a long time I pitched what Amrith said below. Most users shouldn't care
whether their compute resource is a container, a bare metal node or a VM.
Unfortunately, the current APIs don't allow for abstracting compute resources
well enough. For those users that do care, then access to the native API must be
provided (YAY, Magnum does this).

As far as the Trove use case goes, I believe a common API would do most of the
job but there are things that access to the native API would do better. For 
example:

- Managing One Agent: Many Instances deployments.
- Managing containers upgrades (whether it's a db instance upgrade or an agent 
upgrade)

Flavio


Thanks,
Kevin


From: Amrith Kumar [amr...@tesora.com]
Sent: Thursday, April 21, 2016 2:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
abstraction for all COEs

As I was preparing some thoughts for the Board/TC meeting on Sunday that will 
discuss this topic, I made the notes below and was going to post them on a 
topic specific etherpad but I didn't find one.

I want to represent the view point of a consumer of compute services in 
OpenStack. Trove is a consumer of many OpenStack services, and one of the 
things I sometimes (infrequently) get asked is whether Trove supports 
containers. I have wondered about the utility of running databases in 
containers and after quizzing people who asked for container support, I was 
able to put them into three buckets and ranked them roughly by frequency.

2. containers are a very useful packaging construct; unionfs for VM's would be 
a great thing
3. containers launch faster than VM's
4. container performance is in some cases better than VM's

That's weird, what is #1, you may ask. Well, that was

1. containers are cool, it is currently the highest grossing buzzword

OK, so I ignored #1 and focused on #2-#4 and these are very relevant for Trove, 
I think.

While I realize that containers offer many capabilities, from the perspective 
of Trove, I have not found a compelling reason to treat it differently from any 
other compute capability. As a matter

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Fox, Kevin M]

Thanks for the invite. I'll try my best to be there. :)

As for the rest of the comments below, I think they are spot on, and I very 
much appreciate those features in Trove. It makes for a very nice way of 
dealing with databases. Thanks to the trove team for all the hard work put in 
to make it work. :)

Kevin

From: Amrith Kumar [amr...@tesora.com]
Sent: Friday, April 22, 2016 4:40 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
abstraction for all COEs

For those interested in one aspect of this discussion (a common compute API for 
bare-metal, VM's and containers), there's a review of a spec in Trove [1], and 
a session at the summit [2].

Please join [2] if you are able

 Trove Container Support
 Thursday, April 28, 9:50am-10:30am
 Hilton Austin - MR 406

Keith, more detailed answer to one of your questions is below.

Thanks,

-amrith


[1] https://review.openstack.org/#/c/307883/4
[2] https://www.openstack.org/summit/austin-2016/summit-schedule/events/9150

> -Original Message-
> From: Keith Bray [mailto:keith.b...@rackspace.com]
> Sent: Thursday, April 21, 2016 5:11 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> abstraction for all COEs
>
> 100% agreed on all your points… with the addition that the level of
> functionality you are asking for doesn’t need to be baked into an API
> service such as Magnum.  I.e., Magnum doesn’t have to be the thing
> providing the easy-button app deployment — Magnum isn’t and shouldn’t be a
> Docker Hub alternative, a Tutum alternative, etc.  A Horizon UI, App
> Catalog UI, or OpenStack CLI on top of Heat, Murano, Solum, Magnum, etc.
> etc. can all provide this by pulling together the underlying API
> services/technologies to give users the easy app deployment buttons.   I
> don’t think Magnum should do everything (or next thing we know we’ll be
> trying to make Magnum a PaaS, or make it a CircleCI, or … Ok, I’ve gotten
> carried away).  Hopefully my position is understood, and no problem if
> folks disagree with me.  I’d just rather compartmentalize domain concerns
> and scope Magnum to something focused, achievable, agnostic, and easy for
> operators to adopt first. User traction will not be helped by increasing
> service/operator complexity.  I’ll have to go look at the latest Trove and
> Sahara APIs to see how LCD is incorporated, and would love feedback from

[amrith] Trove provides a common, database agnostic set of API's for a number 
of common database workflows including provisioning and lifecycle management. 
It also provides abstractions for common database topologies like replication 
and clustering, and management actions that will manipulate those topologies 
(grow, shrink, failover, ...). It provides abstractions for some common 
database administration activities like user management, database management, 
and ACL's. It allows you to take backups of databases and to launch new 
instances from backups. It provides a simple way in which a user can manage the 
configuration of databases (a subset of the configuration parameters that the 
database supports, the choice the subset being up to the operator) in a 
consistent way. Further it allows users to make configuration changes across a 
group of databases through the process of associating a 'configuration group' 
to database instances.

The important thing about this is that there is a desire to provide all of the 
above capabilities through the Trove API and make these capabilities database 
agnostic. The actual database specific implementations are within Trove and 
largely contained in a database specific guest agent that performs the database 
specific actions to achieve the end result that the user requested via the 
Trove API.

The user interacts directly with the database as well; the application speaks 
native database API's to the database and unlike (for example, DynamoDB) Trove 
does not get into the data path between the application and the database 
itself. Users and administrators are able to interact with the database through 
its native management interfaces as well (some restrictions may apply, 
depending on the level of access that the operator allows).

In short, the value provided is that databases are long lived things and 
provisioning and initial configuration are very important, but ongoing 
maintenance and management are as well. The mantra for dba's is always to 
automate and standardize all the repeated workflows. Trove does that for you 
through a single set of API's because todays datacenters have a wide diversity 
of databases. Hope that helps.

> Trove and Sahara operators on the value vs. customer con

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Amrith Kumar]

Keith, I was with you all the way till your last sentence ...

> -Original Message-
> From: Keith Bray [mailto:keith.b...@rackspace.com]
> Sent: Friday, April 22, 2016 11:53 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> abstraction for all COEs
> 
> Thanks Amirth… I’m glad to see it hasn’t changed much since I was involved
> with Trove in its early days.  What you are describing makes sense, and I
> view it as an LCD for managing common things across the database types,
> not an LCD for the database interaction performed by the user/client
> interacting with the application database.  This parallels where I think
> Magnum should sit, which is general management of the COEs (reinitialize
> bay, backup bay, maybe even common configuration of bays, etc. etc.), and
> not an LCD for user/application interaction with the COEs.  It’s a grey
> area for sure, as should “list containers” on a bay be a common
> abstraction?  I think it’s too early to tell… and, to be clear for all
> folks, I’m not opposed to the LCD existing.  I just don’t want it to be
> required for the operator to run it at this time as part of Magnum given
> how quickly the COE technology landscape is evolving.  So, optional
> support, or separate API/Project make the most sense to me, and can always
> be merged in as part of the Magnum project at a future date once the
> technology landscape settles.  RDBMS has been fairly standard for awhile.
> 

[amrith] Yes, but these pesky things called NoSQL have not, and Trove tries to 
handle both. Fun fact, there are more NoSQL databases than there are Ben & 
Jerry's flavors.

There is some of the same kind of challenges that you describe and while we 
currently have an API that tries to give you the LCD, I can certainly see the 
value in the approach you propose for Magnum. If there are going to be 
conversations about this in the magnum sessions, I would certainly like to 
attend as I think they will help to instruct us on how you are handling a 
similar class of challenges to ones that we face in Trove.

> Thanks for all the input.  The context helps.
> 
> -Keith
> 
> 
> 
> On 4/22/16, 6:40 AM, "Amrith Kumar" <amr...@tesora.com> wrote:
> 
> >For those interested in one aspect of this discussion (a common compute
> >API for bare-metal, VM's and containers), there's a review of a spec in
> >Trove [1], and a session at the summit [2].
> >
> >Please join [2] if you are able
> >
> > Trove Container Support
> > Thursday, April 28, 9:50am-10:30am
> > Hilton Austin - MR 406
> >
> >Keith, more detailed answer to one of your questions is below.
> >
> >Thanks,
> >
> >-amrith
> >
> >
> >[1] https://review.openstack.org/#/c/307883/4
> >[2]
> >https://www.openstack.org/summit/austin-2016/summit-schedule/events/915
> >0
> >
> >> -----Original Message-
> >> From: Keith Bray [mailto:keith.b...@rackspace.com]
> >> Sent: Thursday, April 21, 2016 5:11 PM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> <openstack-dev@lists.openstack.org>
> >> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> >> abstraction for all COEs
> >>
> >> 100% agreed on all your points… with the addition that the level of
> >>functionality you are asking for doesn’t need to be baked into an API
> >>service such as Magnum.  I.e., Magnum doesn’t have to be the thing
> >>providing the easy-button app deployment — Magnum isn’t and shouldn’t
> >>be a  Docker Hub alternative, a Tutum alternative, etc.  A Horizon UI,
> >>App  Catalog UI, or OpenStack CLI on top of Heat, Murano, Solum,
> >>Magnum, etc.
> >> etc. can all provide this by pulling together the underlying API
> >> services/technologies to give users the easy app deployment buttons.
> I
> >> don’t think Magnum should do everything (or next thing we know we’ll
> >>be  trying to make Magnum a PaaS, or make it a CircleCI, or … Ok, I’ve
> >>gotten  carried away).  Hopefully my position is understood, and no
> >>problem if  folks disagree with me.  I’d just rather compartmentalize
> >>domain concerns  and scope Magnum to something focused, achievable,
> >>agnostic, and easy for  operators to adopt first. User traction will
> >>not be helped by increasing  service/operator complexity.  I’ll have
> >>to go look at the latest Trove and  Sahara APIs to see how LCD is
> >>incorporated, and would lov

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Keith Bray]

Thanks Amirth… I’m glad to see it hasn’t changed much since I was involved
with Trove in its early days.  What you are describing makes sense, and I
view it as an LCD for managing common things across the database types,
not an LCD for the database interaction performed by the user/client
interacting with the application database.  This parallels where I think
Magnum should sit, which is general management of the COEs (reinitialize
bay, backup bay, maybe even common configuration of bays, etc. etc.), and
not an LCD for user/application interaction with the COEs.  It’s a grey
area for sure, as should “list containers” on a bay be a common
abstraction?  I think it’s too early to tell… and, to be clear for all
folks, I’m not opposed to the LCD existing.  I just don’t want it to be
required for the operator to run it at this time as part of Magnum given
how quickly the COE technology landscape is evolving.  So, optional
support, or separate API/Project make the most sense to me, and can always
be merged in as part of the Magnum project at a future date once the
technology landscape settles.  RDBMS has been fairly standard for awhile.

Thanks for all the input.  The context helps.

-Keith



On 4/22/16, 6:40 AM, "Amrith Kumar" <amr...@tesora.com> wrote:

>For those interested in one aspect of this discussion (a common compute
>API for bare-metal, VM's and containers), there's a review of a spec in
>Trove [1], and a session at the summit [2].
>
>Please join [2] if you are able
>
> Trove Container Support
> Thursday, April 28, 9:50am-10:30am
> Hilton Austin - MR 406
>
>Keith, more detailed answer to one of your questions is below.
>
>Thanks,
>
>-amrith
>
>
>[1] https://review.openstack.org/#/c/307883/4
>[2] 
>https://www.openstack.org/summit/austin-2016/summit-schedule/events/9150
>
>> -Original Message-
>> From: Keith Bray [mailto:keith.b...@rackspace.com]
>> Sent: Thursday, April 21, 2016 5:11 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> <openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
>> abstraction for all COEs
>> 
>> 100% agreed on all your points… with the addition that the level of
>> functionality you are asking for doesn’t need to be baked into an API
>> service such as Magnum.  I.e., Magnum doesn’t have to be the thing
>> providing the easy-button app deployment — Magnum isn’t and shouldn’t
>>be a
>> Docker Hub alternative, a Tutum alternative, etc.  A Horizon UI, App
>> Catalog UI, or OpenStack CLI on top of Heat, Murano, Solum, Magnum, etc.
>> etc. can all provide this by pulling together the underlying API
>> services/technologies to give users the easy app deployment buttons.   I
>> don’t think Magnum should do everything (or next thing we know we’ll be
>> trying to make Magnum a PaaS, or make it a CircleCI, or … Ok, I’ve
>>gotten
>> carried away).  Hopefully my position is understood, and no problem if
>> folks disagree with me.  I’d just rather compartmentalize domain
>>concerns
>> and scope Magnum to something focused, achievable, agnostic, and easy
>>for
>> operators to adopt first. User traction will not be helped by increasing
>> service/operator complexity.  I’ll have to go look at the latest Trove
>>and
>> Sahara APIs to see how LCD is incorporated, and would love feedback from
>
>[amrith] Trove provides a common, database agnostic set of API's for a
>number of common database workflows including provisioning and lifecycle
>management. It also provides abstractions for common database topologies
>like replication and clustering, and management actions that will
>manipulate those topologies (grow, shrink, failover, ...). It provides
>abstractions for some common database administration activities like user
>management, database management, and ACL's. It allows you to take backups
>of databases and to launch new instances from backups. It provides a
>simple way in which a user can manage the configuration of databases (a
>subset of the configuration parameters that the database supports, the
>choice the subset being up to the operator) in a consistent way. Further
>it allows users to make configuration changes across a group of databases
>through the process of associating a 'configuration group' to database
>instances.
>
>The important thing about this is that there is a desire to provide all
>of the above capabilities through the Trove API and make these
>capabilities database agnostic. The actual database specific
>implementations are within Trove and largely contained in a database
>specific guest agent that performs the database specific actions to
>achieve t

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Antoni Segura Puimedon]

On Thu, Apr 21, 2016 at 9:30 PM, Fox, Kevin M <kevin@pnnl.gov> wrote:
> +1.
> 
> From: Hongbin Lu [hongbin...@huawei.com]
> Sent: Thursday, April 21, 2016 7:50 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
> abstraction for all COEs
>
>> -Original Message-
>> From: Steve Gordon [mailto:sgor...@redhat.com]
>> Sent: April-21-16 9:39 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
>> abstraction for all COEs
>>
>> - Original Message -
>> > From: "Hongbin Lu" <hongbin...@huawei.com>
>> > To: "OpenStack Development Mailing List (not for usage questions)"
>> > <openstack-dev@lists.openstack.org>
>> > > -Original Message-
>> > > From: Keith Bray [mailto:keith.b...@rackspace.com]
>> > > Sent: April-20-16 6:13 PM
>> > > To: OpenStack Development Mailing List (not for usage questions)
>> > > Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build
>> > > unified abstraction for all COEs
>> > >
>> > > Magnum doesn¹t have to preclude tight integration for single COEs
>> > > you speak of.  The heavy lifting of tight integration of the COE in
>> > > to OpenStack (so that it performs optimally with the infra) can be
>> > > modular (where the work is performed by plug-in models to Magnum,
>> > > not performed by Magnum itself. The tight integration can be done
>> by
>> > > leveraging existing technologies (Heat and/or choose your DevOps
>> tool of choice:
>> > > Chef/Ansible/etc). This allows interested community members to
>> focus
>> > > on tight integration of whatever COE they want, focusing
>> > > specifically on
>> >
>> > I agree that tight integration can be achieved by a plugin, but I
>> > think the key question is who will do the work. If tight integration
>> > needs to be done, I wonder why it is not part of the Magnum efforts.
>>
>> Why does the integration belong in Magnum though? To me it belongs in
>> the COEs themselves (e.g. their in-tree network/storage plugins) such
>> that someone can leverage them regardless of their choices regarding
>> COE deployment tooling (and yes that means Magnum should be able to
>> leverage them too)? I guess the issue is that in the above conversation
>> we are overloading the term "integration" which can be taken to mean
>> different things...
>
> I can clarify. I mean to introduce abstractions to allow tight integration 
> between COEs and OpenStack. For example,
>
> $ magnum container-create --volume= --net= ...
>
> I agree with you that such integration should be supported by the COEs 
> themselves. If it does, Magnum will leverage it (anyone can leverage it as 
> well regardless of they are using Magnum or not). If it doesn't (the 
> reality), Magnum could add support for that via its abstraction layer. For 
> your question about why such integration belongs in Magnum, my answer is that 
> the work needs to be done in one place so that everyone can leverage it 
> instead of re-inventing their own solutions. Magnum is the OpenStack 
> container service so it is nature for Magnum to take it IMHO.

The integration is being done in the COEs themselves.

In Docker with Swarm you can just do:

docker network create -d kuryr \
   --ipam-driver=kuryr \
   --subnet=10. 10.0.0/24 \
   --gateway=10.10.0.1 \
   -o neutron.net.name=mynet mynet_d

You can also refer to them by uuid. People are starting to join to be
able to do the same with storage volumes (we'll talk about it in [1])

For Kubernetes we still do not have it upstream, but we create and use
neutron resources as well. All this in bare-metal, but in the newton
cycle, provided that the vlan-aware-vms spec gets released, we'll
support container-in-vm (we'll discuss it in the summit in work
sessions and in a presentation [2]) and Magnum will be able to use it.

So, the way I look at it, Magnum should probably not be too
opinionated, giving choice to operators, but it should provide as much
access to the core OpenStack resources as possible, as long as those
are available in the COE (and that's where we are trying to help).

[1] https://www.openstack.org/summit/austin-2016/summit-schedule/events/6861
[2] https://www.openstack.org/summit/austin-2016/summit-schedule/events/7633


>
>>
>>

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Amrith Kumar]

For those interested in one aspect of this discussion (a common compute API for 
bare-metal, VM's and containers), there's a review of a spec in Trove [1], and 
a session at the summit [2]. 

Please join [2] if you are able

 Trove Container Support
 Thursday, April 28, 9:50am-10:30am
 Hilton Austin - MR 406

Keith, more detailed answer to one of your questions is below.

Thanks,

-amrith


[1] https://review.openstack.org/#/c/307883/4
[2] https://www.openstack.org/summit/austin-2016/summit-schedule/events/9150

> -Original Message-
> From: Keith Bray [mailto:keith.b...@rackspace.com]
> Sent: Thursday, April 21, 2016 5:11 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> abstraction for all COEs
> 
> 100% agreed on all your points… with the addition that the level of
> functionality you are asking for doesn’t need to be baked into an API
> service such as Magnum.  I.e., Magnum doesn’t have to be the thing
> providing the easy-button app deployment — Magnum isn’t and shouldn’t be a
> Docker Hub alternative, a Tutum alternative, etc.  A Horizon UI, App
> Catalog UI, or OpenStack CLI on top of Heat, Murano, Solum, Magnum, etc.
> etc. can all provide this by pulling together the underlying API
> services/technologies to give users the easy app deployment buttons.   I
> don’t think Magnum should do everything (or next thing we know we’ll be
> trying to make Magnum a PaaS, or make it a CircleCI, or … Ok, I’ve gotten
> carried away).  Hopefully my position is understood, and no problem if
> folks disagree with me.  I’d just rather compartmentalize domain concerns
> and scope Magnum to something focused, achievable, agnostic, and easy for
> operators to adopt first. User traction will not be helped by increasing
> service/operator complexity.  I’ll have to go look at the latest Trove and
> Sahara APIs to see how LCD is incorporated, and would love feedback from

[amrith] Trove provides a common, database agnostic set of API's for a number 
of common database workflows including provisioning and lifecycle management. 
It also provides abstractions for common database topologies like replication 
and clustering, and management actions that will manipulate those topologies 
(grow, shrink, failover, ...). It provides abstractions for some common 
database administration activities like user management, database management, 
and ACL's. It allows you to take backups of databases and to launch new 
instances from backups. It provides a simple way in which a user can manage the 
configuration of databases (a subset of the configuration parameters that the 
database supports, the choice the subset being up to the operator) in a 
consistent way. Further it allows users to make configuration changes across a 
group of databases through the process of associating a 'configuration group' 
to database instances.

The important thing about this is that there is a desire to provide all of the 
above capabilities through the Trove API and make these capabilities database 
agnostic. The actual database specific implementations are within Trove and 
largely contained in a database specific guest agent that performs the database 
specific actions to achieve the end result that the user requested via the 
Trove API.

The user interacts directly with the database as well; the application speaks 
native database API's to the database and unlike (for example, DynamoDB) Trove 
does not get into the data path between the application and the database 
itself. Users and administrators are able to interact with the database through 
its native management interfaces as well (some restrictions may apply, 
depending on the level of access that the operator allows).

In short, the value provided is that databases are long lived things and 
provisioning and initial configuration are very important, but ongoing 
maintenance and management are as well. The mantra for dba's is always to 
automate and standardize all the repeated workflows. Trove does that for you 
through a single set of API's because todays datacenters have a wide diversity 
of databases. Hope that helps.

> Trove and Sahara operators on the value vs. customer confusion or operator
> overhead they get from those LCDs if they are required parts of the
> services.
> 
> Thanks,
> -Keith
> 
> On 4/21/16, 3:31 PM, "Fox, Kevin M" <kevin@pnnl.gov> wrote:
> 
> >There are a few reasons, but the primary one that affects me is Its
> >from the app-catalog use case.
> >
> >To gain user support for a product like OpenStack, you need users. The
> >easier you make it to use, the more users you can potentially get.
> >Traditional Operating Systems learned this a while back. Rather then
&g

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Fox, Kevin M]

Yup, Murano indeed may be part of the solution. The problem is much larger then 
any one single OpenStack project though, so its good to have the discussions 
with the various projects to see where the pieces best fit. If Magnum at the 
end of the day rejects the idea that a COE abstraction is not in Magnum's best 
interest, some other OpenStack project will probably pick it up. But hopefully 
Magnum will commit to at least not having any hurtles that stand in the way of 
the workflow actually being implementable somewhere in the stack.

Thanks,
Kevin

From: Monty Taylor [mord...@inaugust.com]
Sent: Thursday, April 21, 2016 1:43 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
abstraction for all COEs

I believe you just described Murano.

On 04/21/2016 03:31 PM, Fox, Kevin M wrote:
> There are a few reasons, but the primary one that affects me is Its from the 
> app-catalog use case.
>
> To gain user support for a product like OpenStack, you need users. The easier 
> you make it to use, the more users you can potentially get.  Traditional 
> Operating Systems learned this a while back. Rather then make each OS user 
> have to be a developer and custom deploy every app they want to run, they 
> split the effort in such a way that Developers can provide software through 
> channels that Users that are not skilled Developers can consume and deploy. 
> The "App" culture in the mobile space it the epitome of that at the moment. 
> My grandmother fires up the app store on her phone, clicks install on 
> something interesting, and starts using it.
>
> Right now, Thats incredibly difficult in OpenStack. You have to find the 
> software your interested in, figure out which components your going to 
> consume (nova, magnum, which COE, etc) then use those api's to launch some 
> resource. Then after that resource is up, then you have to switch tools and 
> then use those tools to further launch things, ansible or kubectl or 
> whatever, then further deploy things.
>
> What I'm looking for, is a unified enough api, that a user can go into 
> horizon, go to the app catalog, find an interesting app, click install/run, 
> and then get a link to a service they can click on and start consuming the 
> app they want in the first place. The number of users that could use such an 
> interface, and consume OpenStack resources are several orders of magnitude 
> greater then the numbers that can manually deploy something ala the procedure 
> in the previous paragraph. More of that is good for Users, Developers, and 
> Operators.
>
> Does that help?
>
> Thanks,
> Kevin
>
>
> 
> From: Keith Bray [keith.b...@rackspace.com]
> Sent: Thursday, April 21, 2016 1:10 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
> abstraction for all COEs
>
> If you don¹t want a user to have to choose a COE, can¹t we just offer an
> option for the operator to mark a particular COE as the ³Default COE² that
> could be defaulted to if one isn¹t specified in the Bay create call?  If
> the operator didn¹t specify a default one, then the CLI/UI must submit one
> in the bay create call otherwise it would fail.
>
> Kevin, can you clarify Why you have to write scripts to deploy a container
> to the COE?   It can be made easy for the user to extract all the
> runtime/env vars needed for a user to just do ³docker run Š²  and poof,
> container running on Swarm on a Magnum bay.  Can you help me understand
> the script part of it?   I don¹t believe container users want an
> abstraction between them and their COE CLIŠ but, what I believe isn¹t
> important.  What I do think is important is that we not require OpenStack
> operators to run that abstraction layer to be running a ³magnum compliant²
> service.  It should either be an ³optional² API add-on or a separate API
> or separate project.  If some folks want an abstraction layer, then great,
> feel free to build it and even propose it under the OpenStack ecosystem..
> But, that abstraction would be a ³proxy API" over the COEs, and doesn¹t
> need to be part of Magnum¹s offering, as it would be targeted at the COE
> interactions and not the bay interactions (which is where Magnum scope is
> best focused).  I don¹t think Magnum should play in both these distinct
> domains (Bay interaction vs. COE interaction).  The former (bay
> interaction) is an infrastructure cloud thing (fits well with OpenStack),
> the latter (COE interaction) is an obfuscation of emerging technologies,
> which gets in to the Trap that Adrian mentioned.  The abstraction layer
> API will forever an

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Fox, Kevin M]

+1. That's a very good list. Thanks for writing it up. :)

Kevin

From: Hongbin Lu [hongbin...@huawei.com]
Sent: Thursday, April 21, 2016 4:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
abstraction for all COEs

Hi Monty,

I respect your position, but I want to point out that there is not only one 
human wants this. There are a group of people want this. I have been working 
for Magnum in about a year and a half. Along the way, I have been researching 
how to attract users to Magnum. My observation is there are two groups of 
potential users. The first group of users are generally in the domain of 
individual COEs and they want to use the native COE APIs. The second group of 
users are generally out of the domain and they want an OpenStack way to manage 
containers. Below are the specific use cases:
* Some people want to migrate the workload from VM to container
* Some people want to support hybrid deployment (VMs & containers) of their 
application
* Some people want to bring containers (in Magnum bays) to a Heat template, and 
enable connections between containers and other OpenStack resources
* Some people want to bring containers to Horizon
* Some people want to send container metrics to Ceilometer
* Some people want a portable experience across COEs
* Some people just want a container and don't want the complexities of others 
(COEs, bays, baymodels, etc.)

I think we need to research how large the second group of users is. Then, based 
on the data, we can decide if the LCD APIs should be part of Magnum, a Magnum 
plugin, or it should not exist. Thoughts?

Best regards,
Hongbin

> -Original Message-
> From: Monty Taylor [mailto:mord...@inaugust.com]
> Sent: April-21-16 4:42 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> abstraction for all COEs
>
> On 04/21/2016 03:18 PM, Fox, Kevin M wrote:
> > Here's where we disagree.
>
> We may have to agree to disagree.
>
> > Your speaking for everyone in the world now, and all you need is one
> > counter example. I'll be that guy. Me. I want a common abstraction
> for
> > some common LCD stuff.
>
> We also disagree on this. Just because one human wants something does
> not make implementing that feature a good idea. In fact, good design is
> largely about appropriately and selectively saying no.
>
> Now I'm not going to pretend that we're good at design around here...
> we seem to very easily fall into the trap that your assertion presents.
> But in almost every one of those cases, having done so winds up having
> been a mistake.
>
> > Both Sahara and Trove have LCD abstractions for very common things.
> > Magnum should too.
> >
> > You are falsely assuming that if an LCD abstraction is provided, then
> > users cant use the raw api directly. This is false. There is no
> > either/or. You can have both. I would be against it too if they were
> > mutually exclusive. They are not.
>
> I'm not assuming that at all. I'm quite clearly asserting that the
> existence of an OpenStack LCD is a Bad Idea. This is a thing we
> disagree about.
>
> I think it's unfriendly to the upstreams in question. I think it does
> not provide significant enough value to the world to justify that
> unfriendliness. And also, https://xkcd.com/927/
>
> > Thanks, Kevin ________________ From: Monty
> > Taylor [mord...@inaugust.com] Sent: Thursday, April 21, 2016 10:22 AM
> > To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev]
> > [magnum][app-catalog][all] Build unified abstraction for all COEs
> >
> > On 04/21/2016 11:03 AM, Tim Bell wrote:
> >>
> >>
> >> On 21/04/16 17:38, "Hongbin Lu" <hongbin...@huawei.com> wrote:
> >>
> >>>
> >>>
> >>>> -Original Message- From: Adrian Otto
> >>>> [mailto:adrian.o...@rackspace.com] Sent: April-21-16 10:32 AM
> >>>> To: OpenStack Development Mailing List (not for usage
> >>>> questions) Subject: Re: [openstack-dev] [magnum][app-catalog][all]
> >>>> Build unified abstraction for all COEs
> >>>>
> >>>>
> >>>>> On Apr 20, 2016, at 2:49 PM, Joshua Harlow <harlo...@fastmail.com>
> >>>> wrote:
> >>>>>
> >>>>> Thierry Carrez wrote:
> >>>>>> Adrian Otto wrote:
> >>>>>>> This pursuit is a trap. Magnum should focus on making
> >>>>>>> native container APIs available. We should not wrap APIs
> 

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Fox, Kevin M]

Amrith,

Very well thought out. Thanks. :)

I agree a nova driver that let you treat containers the same way as vm's, bare 
metal, and lxc containers would be a great thing, and if it could plug into 
magnum managed clusters well, would be awesome.

I think a bit of the conversation around it gets muddy when you start talking 
about the philosophy between lxc and docker containers. They are very 
different. lxc containers typically are heavy weight. You think of them more as 
a vm without the kernel. Multiple daemons run in them, you have a regular init 
system, etc. This isn't bad. It has some benefits. But it also has some 
drawbacks.

Docker's philosophy of software deployment has typically been much different 
then that, and doesn't lend itself to launching that way with nova. With 
docker, each individual services gets its own container, and are co'scheduled. 
Not at the ip level but even lower at the unix/filesystem level.

For example, with Trove, architected with the docker philosophy, you might have 
two containers, one for mysql which exports its unix socket to a second 
container for the guest agent, which talks to mysql over the shared socket. The 
benefit with this is, you only need one guest agent container for all of your 
different types of databases (mysql, postgres,mongodb,etc). Your db and your 
guest agent can even be different distro's and still will work. Its then also 
very easy to upgrade just the guest agent container without affecting the db 
container at all. You just delete/recreate that container, leaving the other 
container alone.

So, when you architect docker containers using this phylosophy, you can't 
really use nova as is, as an abstraction. You can't share unix sockets between 
container instances... But, this kind of functionality is very common in all 
the COE's and should be able to be easily made into an abstraction that all 
current COE's can easily launch. Hence thinking it might be best put in Magnum. 
A nova extension may work too... not sure. But seems more natural in Magnum to 
me.

Thanks,
Kevin


From: Amrith Kumar [amr...@tesora.com]
Sent: Thursday, April 21, 2016 2:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
abstraction for all COEs

As I was preparing some thoughts for the Board/TC meeting on Sunday that will 
discuss this topic, I made the notes below and was going to post them on a 
topic specific etherpad but I didn't find one.

I want to represent the view point of a consumer of compute services in 
OpenStack. Trove is a consumer of many OpenStack services, and one of the 
things I sometimes (infrequently) get asked is whether Trove supports 
containers. I have wondered about the utility of running databases in 
containers and after quizzing people who asked for container support, I was 
able to put them into three buckets and ranked them roughly by frequency.

2. containers are a very useful packaging construct; unionfs for VM's would be 
a great thing
3. containers launch faster than VM's
4. container performance is in some cases better than VM's

That's weird, what is #1, you may ask. Well, that was

1. containers are cool, it is currently the highest grossing buzzword

OK, so I ignored #1 and focused on #2-#4 and these are very relevant for Trove, 
I think.

While I realize that containers offer many capabilities, from the perspective 
of Trove, I have not found a compelling reason to treat it differently from any 
other compute capability. As a matter of fact, Trove works fine with bare metal 
(using the ironic driver) and with VM's using the various VM drivers. I even 
had all of Trove working with containers using nova-docker. I had to make some 
specific choices on my docker images but I got it all to work as a prototype.

My belief is that there are a group of use-cases where a common compute 
abstraction would be beneficial. In an earlier message on one of these threads, 
Adrian made a very good point[1] that "I suppose you were imagining an LCD 
approach. If that's what you want, just use the existing Nova API, and load 
different compute drivers on different host aggregates. A single Nova client 
can produce VM, BM (Ironic), and Container (lbvirt-lxc) instances all with a 
common API (Nova) if it's configured in this way. That's what we do. Flavors 
determine which compute type you get."

He then went on to say, "If what you meant is that you could tap into the power 
of all the unique characteristics of each of the various compute types (through 
some modular extensibility framework) you'll likely end up with complexity in 
Trove that is comparable to integrating with the native upstream APIs, along 
with the disadvantage of waiting for OpenStack to continually catch up to the 
pace of change of the various upstream systems on which it depends. This is a 
recipe for disappointment.&

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Fox, Kevin M]

Thats cool. Hopefully something great will come of it. :)

Thanks for sharing the link. :)

Kevin

From: Joshua Harlow [harlo...@fastmail.com]
Sent: Thursday, April 21, 2016 2:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
abstraction for all COEs

I thought this was also what the goal of https://cncf.io/ was starting
to be? Maybe to early to tell if that standardization will be an real
outcome vs just an imagined outcome :-P

-Josh

Fox, Kevin M wrote:
> The COE's have a pressure not to standardize their api's between competing 
> COE's. If you can lock a user into your api, then they cant go to your 
> competitor.
>
> The standard api really needs to come from those invested in not being locked 
> in. OpenStack's been largely about that since the beginning. It may not 
> belong in Magnum, but I do believe it belongs in OpenStack.
>
> Thanks,
> Kevin
> 
> From: Steve Gordon [sgor...@redhat.com]
> Sent: Thursday, April 21, 2016 6:39 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
> abstraction for all COEs
>
> - Original Message -
>> From: "Hongbin Lu"<hongbin...@huawei.com>
>> To: "OpenStack Development Mailing List (not for usage 
>> questions)"<openstack-dev@lists.openstack.org>
>>> -Original Message-
>>> From: Keith Bray [mailto:keith.b...@rackspace.com]
>>> Sent: April-20-16 6:13 PM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
>>> abstraction for all COEs
>>>
>>> Magnum doesn¹t have to preclude tight integration for single COEs you
>>> speak of.  The heavy lifting of tight integration of the COE in to
>>> OpenStack (so that it performs optimally with the infra) can be modular
>>> (where the work is performed by plug-in models to Magnum, not performed
>>> by Magnum itself. The tight integration can be done by leveraging
>>> existing technologies (Heat and/or choose your DevOps tool of choice:
>>> Chef/Ansible/etc). This allows interested community members to focus on
>>> tight integration of whatever COE they want, focusing specifically on
>> I agree that tight integration can be achieved by a plugin, but I think the
>> key question is who will do the work. If tight integration needs to be done,
>> I wonder why it is not part of the Magnum efforts.
>
> Why does the integration belong in Magnum though? To me it belongs in the 
> COEs themselves (e.g. their in-tree network/storage plugins) such that 
> someone can leverage them regardless of their choices regarding COE 
> deployment tooling (and yes that means Magnum should be able to leverage them 
> too)? I guess the issue is that in the above conversation we are overloading 
> the term "integration" which can be taken to mean different things...
>
> -Steve
>
>>  From my point of view,
>> pushing the work out doesn't seem to address the original pain, which is
>> some users don't want to explore the complexities of individual COEs.
>
>
> __
> 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

__
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][app-catalog][all] Build unified abstraction for all COEs

[Hongbin Lu]

Hi Monty,

I respect your position, but I want to point out that there is not only one 
human wants this. There are a group of people want this. I have been working 
for Magnum in about a year and a half. Along the way, I have been researching 
how to attract users to Magnum. My observation is there are two groups of 
potential users. The first group of users are generally in the domain of 
individual COEs and they want to use the native COE APIs. The second group of 
users are generally out of the domain and they want an OpenStack way to manage 
containers. Below are the specific use cases:
* Some people want to migrate the workload from VM to container
* Some people want to support hybrid deployment (VMs & containers) of their 
application
* Some people want to bring containers (in Magnum bays) to a Heat template, and 
enable connections between containers and other OpenStack resources
* Some people want to bring containers to Horizon
* Some people want to send container metrics to Ceilometer
* Some people want a portable experience across COEs
* Some people just want a container and don't want the complexities of others 
(COEs, bays, baymodels, etc.)

I think we need to research how large the second group of users is. Then, based 
on the data, we can decide if the LCD APIs should be part of Magnum, a Magnum 
plugin, or it should not exist. Thoughts?

Best regards,
Hongbin 

> -Original Message-
> From: Monty Taylor [mailto:mord...@inaugust.com]
> Sent: April-21-16 4:42 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> abstraction for all COEs
> 
> On 04/21/2016 03:18 PM, Fox, Kevin M wrote:
> > Here's where we disagree.
> 
> We may have to agree to disagree.
> 
> > Your speaking for everyone in the world now, and all you need is one
> > counter example. I'll be that guy. Me. I want a common abstraction
> for
> > some common LCD stuff.
> 
> We also disagree on this. Just because one human wants something does
> not make implementing that feature a good idea. In fact, good design is
> largely about appropriately and selectively saying no.
> 
> Now I'm not going to pretend that we're good at design around here...
> we seem to very easily fall into the trap that your assertion presents.
> But in almost every one of those cases, having done so winds up having
> been a mistake.
> 
> > Both Sahara and Trove have LCD abstractions for very common things.
> > Magnum should too.
> >
> > You are falsely assuming that if an LCD abstraction is provided, then
> > users cant use the raw api directly. This is false. There is no
> > either/or. You can have both. I would be against it too if they were
> > mutually exclusive. They are not.
> 
> I'm not assuming that at all. I'm quite clearly asserting that the
> existence of an OpenStack LCD is a Bad Idea. This is a thing we
> disagree about.
> 
> I think it's unfriendly to the upstreams in question. I think it does
> not provide significant enough value to the world to justify that
> unfriendliness. And also, https://xkcd.com/927/
> 
> > Thanks, Kevin ________________ From: Monty
> > Taylor [mord...@inaugust.com] Sent: Thursday, April 21, 2016 10:22 AM
> > To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev]
> > [magnum][app-catalog][all] Build unified abstraction for all COEs
> >
> > On 04/21/2016 11:03 AM, Tim Bell wrote:
> >>
> >>
> >> On 21/04/16 17:38, "Hongbin Lu" <hongbin...@huawei.com> wrote:
> >>
> >>>
> >>>
> >>>> -Original Message- From: Adrian Otto
> >>>> [mailto:adrian.o...@rackspace.com] Sent: April-21-16 10:32 AM
> >>>> To: OpenStack Development Mailing List (not for usage
> >>>> questions) Subject: Re: [openstack-dev] [magnum][app-catalog][all]
> >>>> Build unified abstraction for all COEs
> >>>>
> >>>>
> >>>>> On Apr 20, 2016, at 2:49 PM, Joshua Harlow <harlo...@fastmail.com>
> >>>> wrote:
> >>>>>
> >>>>> Thierry Carrez wrote:
> >>>>>> Adrian Otto wrote:
> >>>>>>> This pursuit is a trap. Magnum should focus on making
> >>>>>>> native container APIs available. We should not wrap APIs
> >>>>>>> with leaky abstractions. The lowest common denominator of
> >>>>>>> all COEs is an remarkably low value API that adds
> >>>>>>> considerable complexity to
> >>>> Magnum
> >>>>>>> that will not strategically advance 

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Fox, Kevin M]

Yeah. its good to disagree and talk through it. sometimes there just isn't a 
way to see eye to eye on something. thats fine too. I was just objecting to the 
assertion:

"I do not believe anyone in the world wants us to build an
> abstraction layer on top of the _use_ of swarm/k8s/mesos. People who
> want to use those technologies know what they want."

This felt very wrong to me to the conversation. I don't believe I'm alone in 
the desire for basic abstraction too, since multiple people are involved on the 
pro-coe-abstraction side of the conversation. Please don't try and dismiss the 
conversation that way or believe you know the only ways folks will want to use 
technology.

I'm just fine having the conversation that what folks are asking for, might not 
be a good idea for the community to support. Thats a fair thing to talk about. 
Lets continue that conversation.

Thanks,
Kevin


From: Monty Taylor [mord...@inaugust.com]
Sent: Thursday, April 21, 2016 1:41 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
abstraction for all COEs

On 04/21/2016 03:18 PM, Fox, Kevin M wrote:
> Here's where we disagree.

We may have to agree to disagree.

> Your speaking for everyone in the world now, and all you need is one
> counter example. I'll be that guy. Me. I want a common abstraction
> for some common LCD stuff.

We also disagree on this. Just because one human wants something does
not make implementing that feature a good idea. In fact, good design is
largely about appropriately and selectively saying no.

Now I'm not going to pretend that we're good at design around here... we
seem to very easily fall into the trap that your assertion presents. But
in almost every one of those cases, having done so winds up having been
a mistake.

> Both Sahara and Trove have LCD abstractions for very common things.
> Magnum should too.
>
> You are falsely assuming that if an LCD abstraction is provided, then
> users cant use the raw api directly. This is false. There is no
> either/or. You can have both. I would be against it too if they were
> mutually exclusive. They are not.

I'm not assuming that at all. I'm quite clearly asserting that the
existence of an OpenStack LCD is a Bad Idea. This is a thing we disagree
about.

I think it's unfriendly to the upstreams in question. I think it does
not provide significant enough value to the world to justify that
unfriendliness. And also, https://xkcd.com/927/

> Thanks, Kevin  From: Monty
> Taylor [mord...@inaugust.com] Sent: Thursday, April 21, 2016 10:22
> AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev]
> [magnum][app-catalog][all] Build unified abstraction for all COEs
>
> On 04/21/2016 11:03 AM, Tim Bell wrote:
>>
>>
>> On 21/04/16 17:38, "Hongbin Lu" <hongbin...@huawei.com> wrote:
>>
>>>
>>>
>>>> -Original Message- From: Adrian Otto
>>>> [mailto:adrian.o...@rackspace.com] Sent: April-21-16 10:32 AM
>>>> To: OpenStack Development Mailing List (not for usage
>>>> questions) Subject: Re: [openstack-dev]
>>>> [magnum][app-catalog][all] Build unified abstraction for all
>>>> COEs
>>>>
>>>>
>>>>> On Apr 20, 2016, at 2:49 PM, Joshua Harlow
>>>>> <harlo...@fastmail.com>
>>>> wrote:
>>>>>
>>>>> Thierry Carrez wrote:
>>>>>> Adrian Otto wrote:
>>>>>>> This pursuit is a trap. Magnum should focus on making
>>>>>>> native container APIs available. We should not wrap APIs
>>>>>>> with leaky abstractions. The lowest common denominator of
>>>>>>> all COEs is an remarkably low value API that adds
>>>>>>> considerable complexity to
>>>> Magnum
>>>>>>> that will not strategically advance OpenStack. If we
>>>>>>> instead focus our effort on making the COEs work better
>>>>>>> on OpenStack, that would be a winning strategy. Support
>>>>>>> and compliment our various COE
>>>> ecosystems.
>>>>>
>>>>> So I'm all for avoiding 'wrap APIs with leaky abstractions'
>>>>> and 'making COEs work better on OpenStack' but I do dislike
>>>>> the part
>>>> about COEs (plural) because it is once again the old
>>>> non-opinionated problem that we (as a community) suffer from.
>>>>>
>>>>> Just my 2 cents, but I'd almost rather we pick one COE and
>>>>> integrate that deeply/tightly wi

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Amrith Kumar]

As I was preparing some thoughts for the Board/TC meeting on Sunday that will 
discuss this topic, I made the notes below and was going to post them on a 
topic specific etherpad but I didn't find one.

I want to represent the view point of a consumer of compute services in 
OpenStack. Trove is a consumer of many OpenStack services, and one of the 
things I sometimes (infrequently) get asked is whether Trove supports 
containers. I have wondered about the utility of running databases in 
containers and after quizzing people who asked for container support, I was 
able to put them into three buckets and ranked them roughly by frequency.

2. containers are a very useful packaging construct; unionfs for VM's would be 
a great thing
3. containers launch faster than VM's
4. container performance is in some cases better than VM's

That's weird, what is #1, you may ask. Well, that was

1. containers are cool, it is currently the highest grossing buzzword

OK, so I ignored #1 and focused on #2-#4 and these are very relevant for Trove, 
I think.

While I realize that containers offer many capabilities, from the perspective 
of Trove, I have not found a compelling reason to treat it differently from any 
other compute capability. As a matter of fact, Trove works fine with bare metal 
(using the ironic driver) and with VM's using the various VM drivers. I even 
had all of Trove working with containers using nova-docker. I had to make some 
specific choices on my docker images but I got it all to work as a prototype.

My belief is that there are a group of use-cases where a common compute 
abstraction would be beneficial. In an earlier message on one of these threads, 
Adrian made a very good point[1] that "I suppose you were imagining an LCD 
approach. If that's what you want, just use the existing Nova API, and load 
different compute drivers on different host aggregates. A single Nova client 
can produce VM, BM (Ironic), and Container (lbvirt-lxc) instances all with a 
common API (Nova) if it's configured in this way. That's what we do. Flavors 
determine which compute type you get."

He then went on to say, "If what you meant is that you could tap into the power 
of all the unique characteristics of each of the various compute types (through 
some modular extensibility framework) you'll likely end up with complexity in 
Trove that is comparable to integrating with the native upstream APIs, along 
with the disadvantage of waiting for OpenStack to continually catch up to the 
pace of change of the various upstream systems on which it depends. This is a 
recipe for disappointment."

I've pondered this a while and it is still my belief that there are a class of 
use-cases, and I submit to you that I believe that Trove is one of them, where 
the LCD is sufficient in the area of compute. I say this knowing full well that 
in the area of storage this is likely not the case and we are discussing how we 
can better integrate with storage in a manner akin to what Adrian says later in 
his reply [1].

I submit to you that there are likely other situations where an LCD approach is 
sufficient, and there are most definitely situations where an LCD approach is 
not sufficient, and one would benefit from "tap[ping] into the power of all the 
unique characteristics of each of the various compute types".

I'm not proposing that we must have only one or the other.

I believe that OpenStack should provide both. It should equally provide Magnum, 
a mechanism to tap into all the finer aspects of containers, should one want 
it, and also a common compute abstraction through some means whereby a user 
could get a LCD.

I don't believe that Magnum can (or intends to) allow a user to provision VM's 
or bare-metal servers (nor should it). But, I believe that a common compute API 
that provides the LCD and determines whether in some way (potentially through 
flavors) whether the request should be a bare-metal server, a VM, or a 
container, has value too.

Specifically, what I'm wondering is why there isn't interest in a driver/plugin 
for Nova that will provide an LCD container capability from Magnum. I am sure 
there's likely a good reason for this, that's one of the things I was 
definitely looking to learn in the course of the board/TC meeting.

Thanks, and my apologies for writing long emails.

-amrith

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-April/091982.html



> -Original Message-
> From: Monty Taylor [mailto:mord...@inaugust.com]
> Sent: Thursday, April 21, 2016 4:42 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> abstraction for all COEs
> 
> On 04/21/2016 03:18 PM, Fox, Kevin M wrote:
> > Here's where we disagree.
> 
> We may have to agree to disagree.
> 
> > Your speaking for everyone in the world now, and all you need is one
> > counter example. I'll be

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Amrith Kumar]

> -Original Message-
> From: Keith Bray [mailto:keith.b...@rackspace.com]
> Sent: Thursday, April 21, 2016 5:11 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> abstraction for all COEs
> 
> 100% agreed on all your points… with the addition that the level of
> functionality you are asking for doesn’t need to be baked into an API
> service such as Magnum.  I.e., Magnum doesn’t have to be the thing
> providing the easy-button app deployment — Magnum isn’t and shouldn’t be a
> Docker Hub alternative, a Tutum alternative, etc.  A Horizon UI, App
> Catalog UI, or OpenStack CLI on top of Heat, Murano, Solum, Magnum, etc.
> etc. can all provide this by pulling together the underlying API
> services/technologies to give users the easy app deployment buttons.   I
> don’t think Magnum should do everything (or next thing we know we’ll be
> trying to make Magnum a PaaS, or make it a CircleCI, or … Ok, I’ve gotten
> carried away).  Hopefully my position is understood, and no problem if
> folks disagree with me.  I’d just rather compartmentalize domain concerns
> and scope Magnum to something focused, achievable, agnostic, and easy for
> operators to adopt first. User traction will not be helped by increasing
> service/operator complexity.  I’ll have to go look at the latest Trove and
> Sahara APIs to see how LCD is incorporated, and would love feedback from
> Trove and Sahara operators on the value vs. customer confusion or operator
> overhead they get from those LCDs if they are required parts of the
> services.

[amrith] Keith, I'm happy to chat with you about how Trove does all that. I 
work on Trove, not an operator.

> 
> Thanks,
> -Keith
> 
> On 4/21/16, 3:31 PM, "Fox, Kevin M" <kevin@pnnl.gov> wrote:
> 
> >There are a few reasons, but the primary one that affects me is Its
> >from the app-catalog use case.
> >
> >To gain user support for a product like OpenStack, you need users. The
> >easier you make it to use, the more users you can potentially get.
> >Traditional Operating Systems learned this a while back. Rather then
> >make each OS user have to be a developer and custom deploy every app
> >they want to run, they split the effort in such a way that Developers
> >can provide software through channels that Users that are not skilled
> >Developers can consume and deploy. The "App" culture in the mobile
> >space it the epitome of that at the moment. My grandmother fires up the
> >app store on her phone, clicks install on something interesting, and
> starts using it.
> >
> >Right now, Thats incredibly difficult in OpenStack. You have to find
> >the software your interested in, figure out which components your going
> >to consume (nova, magnum, which COE, etc) then use those api's to
> >launch some resource. Then after that resource is up, then you have to
> >switch tools and then use those tools to further launch things, ansible
> >or kubectl or whatever, then further deploy things.
> >
> >What I'm looking for, is a unified enough api, that a user can go into
> >horizon, go to the app catalog, find an interesting app, click
> >install/run, and then get a link to a service they can click on and
> >start consuming the app they want in the first place. The number of
> >users that could use such an interface, and consume OpenStack resources
> >are several orders of magnitude greater then the numbers that can
> >manually deploy something ala the procedure in the previous paragraph.
> >More of that is good for Users, Developers, and Operators.
> >
> >Does that help?
> >
> >Thanks,
> >Kevin
> >
> >
> >
> >From: Keith Bray [keith.b...@rackspace.com]
> >Sent: Thursday, April 21, 2016 1:10 PM
> >To: OpenStack Development Mailing List (not for usage questions)
> >Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> >abstraction for all COEs
> >
> >If you don¹t want a user to have to choose a COE, can¹t we just offer
> >an option for the operator to mark a particular COE as the ³Default
> >COE² that could be defaulted to if one isn¹t specified in the Bay
> >create call?  If the operator didn¹t specify a default one, then the
> >CLI/UI must submit one in the bay create call otherwise it would fail.
> >
> >Kevin, can you clarify Why you have to write scripts to deploy a
> container
> >to the COE?   It can be made easy for the user to extract all the
> >runtime/env vars needed for a

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Keith Bray]

100% agreed on all your points… with the addition that the level of
functionality you are asking for doesn’t need to be baked into an API
service such as Magnum.  I.e., Magnum doesn’t have to be the thing
providing the easy-button app deployment — Magnum isn’t and shouldn’t be a
Docker Hub alternative, a Tutum alternative, etc.  A Horizon UI, App
Catalog UI, or OpenStack CLI on top of Heat, Murano, Solum, Magnum, etc.
etc. can all provide this by pulling together the underlying API
services/technologies to give users the easy app deployment buttons.   I
don’t think Magnum should do everything (or next thing we know we’ll be
trying to make Magnum a PaaS, or make it a CircleCI, or … Ok, I’ve gotten
carried away).  Hopefully my position is understood, and no problem if
folks disagree with me.  I’d just rather compartmentalize domain concerns
and scope Magnum to something focused, achievable, agnostic, and easy for
operators to adopt first. User traction will not be helped by increasing
service/operator complexity.  I’ll have to go look at the latest Trove and
Sahara APIs to see how LCD is incorporated, and would love feedback from
Trove and Sahara operators on the value vs. customer confusion or operator
overhead they get from those LCDs if they are required parts of the
services.

Thanks,
-Keith

On 4/21/16, 3:31 PM, "Fox, Kevin M" <kevin@pnnl.gov> wrote:

>There are a few reasons, but the primary one that affects me is Its from
>the app-catalog use case.
>
>To gain user support for a product like OpenStack, you need users. The
>easier you make it to use, the more users you can potentially get.
>Traditional Operating Systems learned this a while back. Rather then make
>each OS user have to be a developer and custom deploy every app they want
>to run, they split the effort in such a way that Developers can provide
>software through channels that Users that are not skilled Developers can
>consume and deploy. The "App" culture in the mobile space it the epitome
>of that at the moment. My grandmother fires up the app store on her
>phone, clicks install on something interesting, and starts using it.
>
>Right now, Thats incredibly difficult in OpenStack. You have to find the
>software your interested in, figure out which components your going to
>consume (nova, magnum, which COE, etc) then use those api's to launch
>some resource. Then after that resource is up, then you have to switch
>tools and then use those tools to further launch things, ansible or
>kubectl or whatever, then further deploy things.
>
>What I'm looking for, is a unified enough api, that a user can go into
>horizon, go to the app catalog, find an interesting app, click
>install/run, and then get a link to a service they can click on and start
>consuming the app they want in the first place. The number of users that
>could use such an interface, and consume OpenStack resources are several
>orders of magnitude greater then the numbers that can manually deploy
>something ala the procedure in the previous paragraph. More of that is
>good for Users, Developers, and Operators.
>
>Does that help?
>
>Thanks,
>Kevin
>
>
>
>From: Keith Bray [keith.b...@rackspace.com]
>Sent: Thursday, April 21, 2016 1:10 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
>abstraction for all COEs
>
>If you don¹t want a user to have to choose a COE, can¹t we just offer an
>option for the operator to mark a particular COE as the ³Default COE² that
>could be defaulted to if one isn¹t specified in the Bay create call?  If
>the operator didn¹t specify a default one, then the CLI/UI must submit one
>in the bay create call otherwise it would fail.
>
>Kevin, can you clarify Why you have to write scripts to deploy a container
>to the COE?   It can be made easy for the user to extract all the
>runtime/env vars needed for a user to just do ³docker run Š²  and poof,
>container running on Swarm on a Magnum bay.  Can you help me understand
>the script part of it?   I don¹t believe container users want an
>abstraction between them and their COE CLIŠ but, what I believe isn¹t
>important.  What I do think is important is that we not require OpenStack
>operators to run that abstraction layer to be running a ³magnum compliant²
>service.  It should either be an ³optional² API add-on or a separate API
>or separate project.  If some folks want an abstraction layer, then great,
>feel free to build it and even propose it under the OpenStack ecosystem..
>But, that abstraction would be a ³proxy API" over the COEs, and doesn¹t
>need to be part of Magnum¹s offering, as it would be targeted at the COE
>interactions and not the bay interactions (which is 

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Joshua Harlow]

I thought this was also what the goal of https://cncf.io/ was starting 
to be? Maybe to early to tell if that standardization will be an real 
outcome vs just an imagined outcome :-P


-Josh

Fox, Kevin M wrote:

The COE's have a pressure not to standardize their api's between competing 
COE's. If you can lock a user into your api, then they cant go to your 
competitor.

The standard api really needs to come from those invested in not being locked 
in. OpenStack's been largely about that since the beginning. It may not belong 
in Magnum, but I do believe it belongs in OpenStack.

Thanks,
Kevin

From: Steve Gordon [sgor...@redhat.com]
Sent: Thursday, April 21, 2016 6:39 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
abstraction for all COEs

- Original Message -

From: "Hongbin Lu"<hongbin...@huawei.com>
To: "OpenStack Development Mailing List (not for usage 
questions)"<openstack-dev@lists.openstack.org>

-Original Message-
From: Keith Bray [mailto:keith.b...@rackspace.com]
Sent: April-20-16 6:13 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
abstraction for all COEs

Magnum doesn¹t have to preclude tight integration for single COEs you
speak of.  The heavy lifting of tight integration of the COE in to
OpenStack (so that it performs optimally with the infra) can be modular
(where the work is performed by plug-in models to Magnum, not performed
by Magnum itself. The tight integration can be done by leveraging
existing technologies (Heat and/or choose your DevOps tool of choice:
Chef/Ansible/etc). This allows interested community members to focus on
tight integration of whatever COE they want, focusing specifically on

I agree that tight integration can be achieved by a plugin, but I think the
key question is who will do the work. If tight integration needs to be done,
I wonder why it is not part of the Magnum efforts.


Why does the integration belong in Magnum though? To me it belongs in the COEs themselves 
(e.g. their in-tree network/storage plugins) such that someone can leverage them 
regardless of their choices regarding COE deployment tooling (and yes that means Magnum 
should be able to leverage them too)? I guess the issue is that in the above conversation 
we are overloading the term "integration" which can be taken to mean different 
things...

-Steve


 From my point of view,
pushing the work out doesn't seem to address the original pain, which is
some users don't want to explore the complexities of individual COEs.



__
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

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Monty Taylor]

On 04/21/2016 03:18 PM, Fox, Kevin M wrote:

Here's where we disagree.


We may have to agree to disagree.


Your speaking for everyone in the world now, and all you need is one
counter example. I'll be that guy. Me. I want a common abstraction
for some common LCD stuff.


We also disagree on this. Just because one human wants something does 
not make implementing that feature a good idea. In fact, good design is 
largely about appropriately and selectively saying no.


Now I'm not going to pretend that we're good at design around here... we 
seem to very easily fall into the trap that your assertion presents. But 
in almost every one of those cases, having done so winds up having been 
a mistake.



Both Sahara and Trove have LCD abstractions for very common things.
Magnum should too.

You are falsely assuming that if an LCD abstraction is provided, then
users cant use the raw api directly. This is false. There is no
either/or. You can have both. I would be against it too if they were
mutually exclusive. They are not.


I'm not assuming that at all. I'm quite clearly asserting that the 
existence of an OpenStack LCD is a Bad Idea. This is a thing we disagree 
about.


I think it's unfriendly to the upstreams in question. I think it does 
not provide significant enough value to the world to justify that 
unfriendliness. And also, https://xkcd.com/927/



Thanks, Kevin  From: Monty
Taylor [mord...@inaugust.com] Sent: Thursday, April 21, 2016 10:22
AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev]
[magnum][app-catalog][all] Build unified abstraction for all COEs

On 04/21/2016 11:03 AM, Tim Bell wrote:



On 21/04/16 17:38, "Hongbin Lu" <hongbin...@huawei.com> wrote:





-Original Message- From: Adrian Otto
[mailto:adrian.o...@rackspace.com] Sent: April-21-16 10:32 AM
To: OpenStack Development Mailing List (not for usage
questions) Subject: Re: [openstack-dev]
[magnum][app-catalog][all] Build unified abstraction for all
COEs



On Apr 20, 2016, at 2:49 PM, Joshua Harlow
<harlo...@fastmail.com>

wrote:


Thierry Carrez wrote:

Adrian Otto wrote:

This pursuit is a trap. Magnum should focus on making
native container APIs available. We should not wrap APIs
with leaky abstractions. The lowest common denominator of
all COEs is an remarkably low value API that adds
considerable complexity to

Magnum

that will not strategically advance OpenStack. If we
instead focus our effort on making the COEs work better
on OpenStack, that would be a winning strategy. Support
and compliment our various COE

ecosystems.


So I'm all for avoiding 'wrap APIs with leaky abstractions'
and 'making COEs work better on OpenStack' but I do dislike
the part

about COEs (plural) because it is once again the old
non-opinionated problem that we (as a community) suffer from.


Just my 2 cents, but I'd almost rather we pick one COE and
integrate that deeply/tightly with openstack, and yes if this
causes some part of the openstack community to be annoyed,
meh, to bad. Sadly I have a feeling we are hurting ourselves
by continuing to try to be

everything

and not picking anything (it's a general thing we, as a
group, seem

to

be good at, lol). I mean I get the reason to just support all
the things, but it feels like we as a community could just
pick something, work together on figuring out how to pick
one, using all these bright leaders we have to help make that
possible (and yes this might piss some people off, to bad).
Then work toward making that something

great

and move on…


The key issue preventing the selection of only one COE is that
this area is moving very quickly. If we would have decided what
to pick at the time the Magnum idea was created, we would have
selected Docker. If you look at it today, you might pick
something else. A few months down the road, there may be yet
another choice that is more compelling. The fact that a cloud
operator can integrate services with OpenStack, and have the
freedom to offer support for a selection of COE’s is a form of
insurance against the risk of picking the wrong one. Our
compute service offers a choice of hypervisors, our block
storage service offers a choice of storage hardware drivers,
our networking service allows a choice of network drivers.
Magnum is following the same pattern of choice that has made
OpenStack compelling for a very diverse community. That design
consideration was intentional.

Over time, we can focus the majority of our effort on deep
integration with COEs that users select the most. I’m convinced
it’s still too early to bet the farm on just one choice.


If Magnum want to avoid the risk of picking the wrong COE, that
mean the risk is populated to all our users. They might pick a
COE and explore the its complexities. Then they find out another
COE is more compelling and their integration work is wasted. I
wonder if we can do better by taking the risk and provide
insurance for 

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Monty Taylor]

I believe you just described Murano.

On 04/21/2016 03:31 PM, Fox, Kevin M wrote:

There are a few reasons, but the primary one that affects me is Its from the 
app-catalog use case.

To gain user support for a product like OpenStack, you need users. The easier you make it 
to use, the more users you can potentially get.  Traditional Operating Systems learned 
this a while back. Rather then make each OS user have to be a developer and custom deploy 
every app they want to run, they split the effort in such a way that Developers can 
provide software through channels that Users that are not skilled Developers can consume 
and deploy. The "App" culture in the mobile space it the epitome of that at the 
moment. My grandmother fires up the app store on her phone, clicks install on something 
interesting, and starts using it.

Right now, Thats incredibly difficult in OpenStack. You have to find the 
software your interested in, figure out which components your going to consume 
(nova, magnum, which COE, etc) then use those api's to launch some resource. 
Then after that resource is up, then you have to switch tools and then use 
those tools to further launch things, ansible or kubectl or whatever, then 
further deploy things.

What I'm looking for, is a unified enough api, that a user can go into horizon, 
go to the app catalog, find an interesting app, click install/run, and then get 
a link to a service they can click on and start consuming the app they want in 
the first place. The number of users that could use such an interface, and 
consume OpenStack resources are several orders of magnitude greater then the 
numbers that can manually deploy something ala the procedure in the previous 
paragraph. More of that is good for Users, Developers, and Operators.

Does that help?

Thanks,
Kevin



From: Keith Bray [keith.b...@rackspace.com]
Sent: Thursday, April 21, 2016 1:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
abstraction for all COEs

If you don¹t want a user to have to choose a COE, can¹t we just offer an
option for the operator to mark a particular COE as the ³Default COE² that
could be defaulted to if one isn¹t specified in the Bay create call?  If
the operator didn¹t specify a default one, then the CLI/UI must submit one
in the bay create call otherwise it would fail.

Kevin, can you clarify Why you have to write scripts to deploy a container
to the COE?   It can be made easy for the user to extract all the
runtime/env vars needed for a user to just do ³docker run Š²  and poof,
container running on Swarm on a Magnum bay.  Can you help me understand
the script part of it?   I don¹t believe container users want an
abstraction between them and their COE CLIŠ but, what I believe isn¹t
important.  What I do think is important is that we not require OpenStack
operators to run that abstraction layer to be running a ³magnum compliant²
service.  It should either be an ³optional² API add-on or a separate API
or separate project.  If some folks want an abstraction layer, then great,
feel free to build it and even propose it under the OpenStack ecosystem..
But, that abstraction would be a ³proxy API" over the COEs, and doesn¹t
need to be part of Magnum¹s offering, as it would be targeted at the COE
interactions and not the bay interactions (which is where Magnum scope is
best focused).  I don¹t think Magnum should play in both these distinct
domains (Bay interaction vs. COE interaction).  The former (bay
interaction) is an infrastructure cloud thing (fits well with OpenStack),
the latter (COE interaction) is an obfuscation of emerging technologies,
which gets in to the Trap that Adrian mentioned.  The abstraction layer
API will forever and always be drastically behind in trying to keep up
with the COE innovation.

In summary, an abstraction over the COEs would be best served as a
different effort.  Magnum would be best focused on bay interactions and
should not try to pick a COE winner or require an operator to run a
lowest-common-demonitor API abstraction.

Thanks for listening to my soap-box.
-Keith



On 4/21/16, 2:36 PM, "Fox, Kevin M" <kevin@pnnl.gov> wrote:


I agree with that, and thats why providing some bare minimum abstraction
will help the users not have to choose a COE themselves. If we can't
decide, why can they? If all they want to do is launch a container, they
should be able to script up "magnum launch-container foo/bar:latest" and
get one. That script can then be relied upon.

Today, they have to write scripts to deploy to the specific COE they have
chosen. If they chose Docker, and something better comes out, they have
to go rewrite a bunch of stuff to target the new, better thing. This puts
a lot of work on others.

Do I think we can provide an abstraction that prevents them from ever
having to rewrite scripts? N

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Fox, Kevin M]

There are a few reasons, but the primary one that affects me is Its from the 
app-catalog use case.

To gain user support for a product like OpenStack, you need users. The easier 
you make it to use, the more users you can potentially get.  Traditional 
Operating Systems learned this a while back. Rather then make each OS user have 
to be a developer and custom deploy every app they want to run, they split the 
effort in such a way that Developers can provide software through channels that 
Users that are not skilled Developers can consume and deploy. The "App" culture 
in the mobile space it the epitome of that at the moment. My grandmother fires 
up the app store on her phone, clicks install on something interesting, and 
starts using it.

Right now, Thats incredibly difficult in OpenStack. You have to find the 
software your interested in, figure out which components your going to consume 
(nova, magnum, which COE, etc) then use those api's to launch some resource. 
Then after that resource is up, then you have to switch tools and then use 
those tools to further launch things, ansible or kubectl or whatever, then 
further deploy things.

What I'm looking for, is a unified enough api, that a user can go into horizon, 
go to the app catalog, find an interesting app, click install/run, and then get 
a link to a service they can click on and start consuming the app they want in 
the first place. The number of users that could use such an interface, and 
consume OpenStack resources are several orders of magnitude greater then the 
numbers that can manually deploy something ala the procedure in the previous 
paragraph. More of that is good for Users, Developers, and Operators.

Does that help?

Thanks,
Kevin



From: Keith Bray [keith.b...@rackspace.com]
Sent: Thursday, April 21, 2016 1:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
abstraction for all COEs

If you don¹t want a user to have to choose a COE, can¹t we just offer an
option for the operator to mark a particular COE as the ³Default COE² that
could be defaulted to if one isn¹t specified in the Bay create call?  If
the operator didn¹t specify a default one, then the CLI/UI must submit one
in the bay create call otherwise it would fail.

Kevin, can you clarify Why you have to write scripts to deploy a container
to the COE?   It can be made easy for the user to extract all the
runtime/env vars needed for a user to just do ³docker run Š²  and poof,
container running on Swarm on a Magnum bay.  Can you help me understand
the script part of it?   I don¹t believe container users want an
abstraction between them and their COE CLIŠ but, what I believe isn¹t
important.  What I do think is important is that we not require OpenStack
operators to run that abstraction layer to be running a ³magnum compliant²
service.  It should either be an ³optional² API add-on or a separate API
or separate project.  If some folks want an abstraction layer, then great,
feel free to build it and even propose it under the OpenStack ecosystem..
But, that abstraction would be a ³proxy API" over the COEs, and doesn¹t
need to be part of Magnum¹s offering, as it would be targeted at the COE
interactions and not the bay interactions (which is where Magnum scope is
best focused).  I don¹t think Magnum should play in both these distinct
domains (Bay interaction vs. COE interaction).  The former (bay
interaction) is an infrastructure cloud thing (fits well with OpenStack),
the latter (COE interaction) is an obfuscation of emerging technologies,
which gets in to the Trap that Adrian mentioned.  The abstraction layer
API will forever and always be drastically behind in trying to keep up
with the COE innovation.

In summary, an abstraction over the COEs would be best served as a
different effort.  Magnum would be best focused on bay interactions and
should not try to pick a COE winner or require an operator to run a
lowest-common-demonitor API abstraction.

Thanks for listening to my soap-box.
-Keith



On 4/21/16, 2:36 PM, "Fox, Kevin M" <kevin@pnnl.gov> wrote:

>I agree with that, and thats why providing some bare minimum abstraction
>will help the users not have to choose a COE themselves. If we can't
>decide, why can they? If all they want to do is launch a container, they
>should be able to script up "magnum launch-container foo/bar:latest" and
>get one. That script can then be relied upon.
>
>Today, they have to write scripts to deploy to the specific COE they have
>chosen. If they chose Docker, and something better comes out, they have
>to go rewrite a bunch of stuff to target the new, better thing. This puts
>a lot of work on others.
>
>Do I think we can provide an abstraction that prevents them from ever
>having to rewrite scripts? No. There are a lot of features 

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Fox, Kevin M]

Here's where we disagree.

Your speaking for everyone in the world now, and all you need is one counter 
example. I'll be that guy. Me. I want a common abstraction for some common LCD 
stuff.

Both Sahara and Trove have LCD abstractions for very common things. Magnum 
should too.

You are falsely assuming that if an LCD abstraction is provided, then users 
cant use the raw api directly. This is false. There is no either/or. You can 
have both. I would be against it too if they were mutually exclusive. They are 
not.

Thanks,
Kevin

From: Monty Taylor [mord...@inaugust.com]
Sent: Thursday, April 21, 2016 10:22 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
abstraction for all COEs

On 04/21/2016 11:03 AM, Tim Bell wrote:
>
>
> On 21/04/16 17:38, "Hongbin Lu" <hongbin...@huawei.com> wrote:
>
>>
>>
>>> -Original Message-
>>> From: Adrian Otto [mailto:adrian.o...@rackspace.com]
>>> Sent: April-21-16 10:32 AM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
>>> abstraction for all COEs
>>>
>>>
>>>> On Apr 20, 2016, at 2:49 PM, Joshua Harlow <harlo...@fastmail.com>
>>> wrote:
>>>>
>>>> Thierry Carrez wrote:
>>>>> Adrian Otto wrote:
>>>>>> This pursuit is a trap. Magnum should focus on making native
>>>>>> container APIs available. We should not wrap APIs with leaky
>>>>>> abstractions. The lowest common denominator of all COEs is an
>>>>>> remarkably low value API that adds considerable complexity to
>>> Magnum
>>>>>> that will not strategically advance OpenStack. If we instead focus
>>>>>> our effort on making the COEs work better on OpenStack, that would
>>>>>> be a winning strategy. Support and compliment our various COE
>>> ecosystems.
>>>>
>>>> So I'm all for avoiding 'wrap APIs with leaky abstractions' and
>>>> 'making COEs work better on OpenStack' but I do dislike the part
>>> about COEs (plural) because it is once again the old non-opinionated
>>> problem that we (as a community) suffer from.
>>>>
>>>> Just my 2 cents, but I'd almost rather we pick one COE and integrate
>>>> that deeply/tightly with openstack, and yes if this causes some part
>>>> of the openstack community to be annoyed, meh, to bad. Sadly I have a
>>>> feeling we are hurting ourselves by continuing to try to be
>>> everything
>>>> and not picking anything (it's a general thing we, as a group, seem
>>> to
>>>> be good at, lol). I mean I get the reason to just support all the
>>>> things, but it feels like we as a community could just pick something,
>>>> work together on figuring out how to pick one, using all these bright
>>>> leaders we have to help make that possible (and yes this might piss
>>>> some people off, to bad). Then work toward making that something
>>> great
>>>> and move on…
>>>
>>> The key issue preventing the selection of only one COE is that this
>>> area is moving very quickly. If we would have decided what to pick at
>>> the time the Magnum idea was created, we would have selected Docker. If
>>> you look at it today, you might pick something else. A few months down
>>> the road, there may be yet another choice that is more compelling. The
>>> fact that a cloud operator can integrate services with OpenStack, and
>>> have the freedom to offer support for a selection of COE’s is a form of
>>> insurance against the risk of picking the wrong one. Our compute
>>> service offers a choice of hypervisors, our block storage service
>>> offers a choice of storage hardware drivers, our networking service
>>> allows a choice of network drivers. Magnum is following the same
>>> pattern of choice that has made OpenStack compelling for a very diverse
>>> community. That design consideration was intentional.
>>>
>>> Over time, we can focus the majority of our effort on deep integration
>>> with COEs that users select the most. I’m convinced it’s still too
>>> early to bet the farm on just one choice.
>>
>> If Magnum want to avoid the risk of picking the wrong COE, that mean the 
>> risk is populated to all our users. They might pick a COE and explore the 
>> its complexities. Then they find out another 

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Keith Bray]

If you don¹t want a user to have to choose a COE, can¹t we just offer an
option for the operator to mark a particular COE as the ³Default COE² that
could be defaulted to if one isn¹t specified in the Bay create call?  If
the operator didn¹t specify a default one, then the CLI/UI must submit one
in the bay create call otherwise it would fail.

Kevin, can you clarify Why you have to write scripts to deploy a container
to the COE?   It can be made easy for the user to extract all the
runtime/env vars needed for a user to just do ³docker run Š²  and poof,
container running on Swarm on a Magnum bay.  Can you help me understand
the script part of it?   I don¹t believe container users want an
abstraction between them and their COE CLIŠ but, what I believe isn¹t
important.  What I do think is important is that we not require OpenStack
operators to run that abstraction layer to be running a ³magnum compliant²
service.  It should either be an ³optional² API add-on or a separate API
or separate project.  If some folks want an abstraction layer, then great,
feel free to build it and even propose it under the OpenStack ecosystem..
But, that abstraction would be a ³proxy API" over the COEs, and doesn¹t
need to be part of Magnum¹s offering, as it would be targeted at the COE
interactions and not the bay interactions (which is where Magnum scope is
best focused).  I don¹t think Magnum should play in both these distinct
domains (Bay interaction vs. COE interaction).  The former (bay
interaction) is an infrastructure cloud thing (fits well with OpenStack),
the latter (COE interaction) is an obfuscation of emerging technologies,
which gets in to the Trap that Adrian mentioned.  The abstraction layer
API will forever and always be drastically behind in trying to keep up
with the COE innovation.

In summary, an abstraction over the COEs would be best served as a
different effort.  Magnum would be best focused on bay interactions and
should not try to pick a COE winner or require an operator to run a
lowest-common-demonitor API abstraction.

Thanks for listening to my soap-box.
-Keith



On 4/21/16, 2:36 PM, "Fox, Kevin M" <kevin@pnnl.gov> wrote:

>I agree with that, and thats why providing some bare minimum abstraction
>will help the users not have to choose a COE themselves. If we can't
>decide, why can they? If all they want to do is launch a container, they
>should be able to script up "magnum launch-container foo/bar:latest" and
>get one. That script can then be relied upon.
>
>Today, they have to write scripts to deploy to the specific COE they have
>chosen. If they chose Docker, and something better comes out, they have
>to go rewrite a bunch of stuff to target the new, better thing. This puts
>a lot of work on others.
>
>Do I think we can provide an abstraction that prevents them from ever
>having to rewrite scripts? No. There are a lot of features in the COE
>world in flight right now and we dont want to solidify an api around them
>yet. We shouldn't even try that. But can we cover a few common things
>now? Yeah.
>
>Thanks,
>Kevin
>
>From: Adrian Otto [adrian.o...@rackspace.com]
>Sent: Thursday, April 21, 2016 7:32 AM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
>abstraction for all COEs
>
>> On Apr 20, 2016, at 2:49 PM, Joshua Harlow <harlo...@fastmail.com>
>>wrote:
>>
>> Thierry Carrez wrote:
>>> Adrian Otto wrote:
>>>> This pursuit is a trap. Magnum should focus on making native container
>>>> APIs available. We should not wrap APIs with leaky abstractions. The
>>>> lowest common denominator of all COEs is an remarkably low value API
>>>> that adds considerable complexity to Magnum that will not
>>>> strategically advance OpenStack. If we instead focus our effort on
>>>> making the COEs work better on OpenStack, that would be a winning
>>>> strategy. Support and compliment our various COE ecosystems.
>>
>> So I'm all for avoiding 'wrap APIs with leaky abstractions' and 'making
>> COEs work better on OpenStack' but I do dislike the part about COEs
>>(plural) because it is once again the old non-opinionated problem that
>>we (as a community) suffer from.
>>
>> Just my 2 cents, but I'd almost rather we pick one COE and integrate
>>that deeply/tightly with openstack, and yes if this causes some part of
>>the openstack community to be annoyed, meh, to bad. Sadly I have a
>>feeling we are hurting ourselves by continuing to try to be everything
>>and not picking anything (it's a general thing we, as a group, seem to
>>be good at, lol). I mean I get the reason to just support all th

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Fox, Kevin M]

I agree with that, and thats why providing some bare minimum abstraction will 
help the users not have to choose a COE themselves. If we can't decide, why can 
they? If all they want to do is launch a container, they should be able to 
script up "magnum launch-container foo/bar:latest" and get one. That script can 
then be relied upon.

Today, they have to write scripts to deploy to the specific COE they have 
chosen. If they chose Docker, and something better comes out, they have to go 
rewrite a bunch of stuff to target the new, better thing. This puts a lot of 
work on others.

Do I think we can provide an abstraction that prevents them from ever having to 
rewrite scripts? No. There are a lot of features in the COE world in flight 
right now and we dont want to solidify an api around them yet. We shouldn't 
even try that. But can we cover a few common things now? Yeah.

Thanks,
Kevin

From: Adrian Otto [adrian.o...@rackspace.com]
Sent: Thursday, April 21, 2016 7:32 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
abstraction for all COEs

> On Apr 20, 2016, at 2:49 PM, Joshua Harlow <harlo...@fastmail.com> wrote:
>
> Thierry Carrez wrote:
>> Adrian Otto wrote:
>>> This pursuit is a trap. Magnum should focus on making native container
>>> APIs available. We should not wrap APIs with leaky abstractions. The
>>> lowest common denominator of all COEs is an remarkably low value API
>>> that adds considerable complexity to Magnum that will not
>>> strategically advance OpenStack. If we instead focus our effort on
>>> making the COEs work better on OpenStack, that would be a winning
>>> strategy. Support and compliment our various COE ecosystems.
>
> So I'm all for avoiding 'wrap APIs with leaky abstractions' and 'making
> COEs work better on OpenStack' but I do dislike the part about COEs (plural) 
> because it is once again the old non-opinionated problem that we (as a 
> community) suffer from.
>
> Just my 2 cents, but I'd almost rather we pick one COE and integrate that 
> deeply/tightly with openstack, and yes if this causes some part of the 
> openstack community to be annoyed, meh, to bad. Sadly I have a feeling we are 
> hurting ourselves by continuing to try to be everything and not picking 
> anything (it's a general thing we, as a group, seem to be good at, lol). I 
> mean I get the reason to just support all the things, but it feels like we as 
> a community could just pick something, work together on figuring out how to 
> pick one, using all these bright leaders we have to help make that possible 
> (and yes this might piss some people off, to bad). Then work toward making 
> that something great and move on…

The key issue preventing the selection of only one COE is that this area is 
moving very quickly. If we would have decided what to pick at the time the 
Magnum idea was created, we would have selected Docker. If you look at it 
today, you might pick something else. A few months down the road, there may be 
yet another choice that is more compelling. The fact that a cloud operator can 
integrate services with OpenStack, and have the freedom to offer support for a 
selection of COE’s is a form of insurance against the risk of picking the wrong 
one. Our compute service offers a choice of hypervisors, our block storage 
service offers a choice of storage hardware drivers, our networking service 
allows a choice of network drivers. Magnum is following the same pattern of 
choice that has made OpenStack compelling for a very diverse community. That 
design consideration was intentional.

Over time, we can focus the majority of our effort on deep integration with 
COEs that users select the most. I’m convinced it’s still too early to bet the 
farm on just one choice.

Adrian

>> I'm with Adrian on that one. I've attended a lot of container-oriented
>> conferences over the past year and my main takeaway is that this new
>> crowd of potential users is not interested (at all) in an
>> OpenStack-specific lowest common denominator API for COEs. They want to
>> take advantage of the cool features in Kubernetes API or the versatility
>> of Mesos. They want to avoid caring about the infrastructure provider
>> bit (and not deploy Mesos or Kubernetes themselves).
>>
>> Let's focus on the infrastructure provider bit -- that is what we do and
>> what the ecosystem wants us to provide.
>>
>
> __
> 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/op

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Fox, Kevin M]

The COE's have a pressure not to standardize their api's between competing 
COE's. If you can lock a user into your api, then they cant go to your 
competitor.

The standard api really needs to come from those invested in not being locked 
in. OpenStack's been largely about that since the beginning. It may not belong 
in Magnum, but I do believe it belongs in OpenStack.

Thanks,
Kevin

From: Steve Gordon [sgor...@redhat.com]
Sent: Thursday, April 21, 2016 6:39 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
abstraction for all COEs

- Original Message -
> From: "Hongbin Lu" <hongbin...@huawei.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org>
> > -Original Message-
> > From: Keith Bray [mailto:keith.b...@rackspace.com]
> > Sent: April-20-16 6:13 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> > abstraction for all COEs
> >
> > Magnum doesn¹t have to preclude tight integration for single COEs you
> > speak of.  The heavy lifting of tight integration of the COE in to
> > OpenStack (so that it performs optimally with the infra) can be modular
> > (where the work is performed by plug-in models to Magnum, not performed
> > by Magnum itself. The tight integration can be done by leveraging
> > existing technologies (Heat and/or choose your DevOps tool of choice:
> > Chef/Ansible/etc). This allows interested community members to focus on
> > tight integration of whatever COE they want, focusing specifically on
>
> I agree that tight integration can be achieved by a plugin, but I think the
> key question is who will do the work. If tight integration needs to be done,
> I wonder why it is not part of the Magnum efforts.

Why does the integration belong in Magnum though? To me it belongs in the COEs 
themselves (e.g. their in-tree network/storage plugins) such that someone can 
leverage them regardless of their choices regarding COE deployment tooling (and 
yes that means Magnum should be able to leverage them too)? I guess the issue 
is that in the above conversation we are overloading the term "integration" 
which can be taken to mean different things...

-Steve

> From my point of view,
> pushing the work out doesn't seem to address the original pain, which is
> some users don't want to explore the complexities of individual COEs.


__
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

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Fox, Kevin M]

+1.

From: Hongbin Lu [hongbin...@huawei.com]
Sent: Thursday, April 21, 2016 7:50 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
abstraction for all COEs

> -Original Message-
> From: Steve Gordon [mailto:sgor...@redhat.com]
> Sent: April-21-16 9:39 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> abstraction for all COEs
>
> - Original Message -
> > From: "Hongbin Lu" <hongbin...@huawei.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev@lists.openstack.org>
> > > -Original Message-
> > > From: Keith Bray [mailto:keith.b...@rackspace.com]
> > > Sent: April-20-16 6:13 PM
> > > To: OpenStack Development Mailing List (not for usage questions)
> > > Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build
> > > unified abstraction for all COEs
> > >
> > > Magnum doesn¹t have to preclude tight integration for single COEs
> > > you speak of.  The heavy lifting of tight integration of the COE in
> > > to OpenStack (so that it performs optimally with the infra) can be
> > > modular (where the work is performed by plug-in models to Magnum,
> > > not performed by Magnum itself. The tight integration can be done
> by
> > > leveraging existing technologies (Heat and/or choose your DevOps
> tool of choice:
> > > Chef/Ansible/etc). This allows interested community members to
> focus
> > > on tight integration of whatever COE they want, focusing
> > > specifically on
> >
> > I agree that tight integration can be achieved by a plugin, but I
> > think the key question is who will do the work. If tight integration
> > needs to be done, I wonder why it is not part of the Magnum efforts.
>
> Why does the integration belong in Magnum though? To me it belongs in
> the COEs themselves (e.g. their in-tree network/storage plugins) such
> that someone can leverage them regardless of their choices regarding
> COE deployment tooling (and yes that means Magnum should be able to
> leverage them too)? I guess the issue is that in the above conversation
> we are overloading the term "integration" which can be taken to mean
> different things...

I can clarify. I mean to introduce abstractions to allow tight integration 
between COEs and OpenStack. For example,

$ magnum container-create --volume= --net= ...

I agree with you that such integration should be supported by the COEs 
themselves. If it does, Magnum will leverage it (anyone can leverage it as well 
regardless of they are using Magnum or not). If it doesn't (the reality), 
Magnum could add support for that via its abstraction layer. For your question 
about why such integration belongs in Magnum, my answer is that the work needs 
to be done in one place so that everyone can leverage it instead of 
re-inventing their own solutions. Magnum is the OpenStack container service so 
it is nature for Magnum to take it IMHO.

>
> -Steve
>
> > From my point of view,
> > pushing the work out doesn't seem to address the original pain, which
> > is some users don't want to explore the complexities of individual
> COEs.
>
>
> ___
> ___
> 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

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Monty Taylor]

On 04/21/2016 11:03 AM, Tim Bell wrote:



On 21/04/16 17:38, "Hongbin Lu" <hongbin...@huawei.com> wrote:





-Original Message-
From: Adrian Otto [mailto:adrian.o...@rackspace.com]
Sent: April-21-16 10:32 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
abstraction for all COEs



On Apr 20, 2016, at 2:49 PM, Joshua Harlow <harlo...@fastmail.com>

wrote:


Thierry Carrez wrote:

Adrian Otto wrote:

This pursuit is a trap. Magnum should focus on making native
container APIs available. We should not wrap APIs with leaky
abstractions. The lowest common denominator of all COEs is an
remarkably low value API that adds considerable complexity to

Magnum

that will not strategically advance OpenStack. If we instead focus
our effort on making the COEs work better on OpenStack, that would
be a winning strategy. Support and compliment our various COE

ecosystems.


So I'm all for avoiding 'wrap APIs with leaky abstractions' and
'making COEs work better on OpenStack' but I do dislike the part

about COEs (plural) because it is once again the old non-opinionated
problem that we (as a community) suffer from.


Just my 2 cents, but I'd almost rather we pick one COE and integrate
that deeply/tightly with openstack, and yes if this causes some part
of the openstack community to be annoyed, meh, to bad. Sadly I have a
feeling we are hurting ourselves by continuing to try to be

everything

and not picking anything (it's a general thing we, as a group, seem

to

be good at, lol). I mean I get the reason to just support all the
things, but it feels like we as a community could just pick something,
work together on figuring out how to pick one, using all these bright
leaders we have to help make that possible (and yes this might piss
some people off, to bad). Then work toward making that something

great

and move on…


The key issue preventing the selection of only one COE is that this
area is moving very quickly. If we would have decided what to pick at
the time the Magnum idea was created, we would have selected Docker. If
you look at it today, you might pick something else. A few months down
the road, there may be yet another choice that is more compelling. The
fact that a cloud operator can integrate services with OpenStack, and
have the freedom to offer support for a selection of COE’s is a form of
insurance against the risk of picking the wrong one. Our compute
service offers a choice of hypervisors, our block storage service
offers a choice of storage hardware drivers, our networking service
allows a choice of network drivers. Magnum is following the same
pattern of choice that has made OpenStack compelling for a very diverse
community. That design consideration was intentional.

Over time, we can focus the majority of our effort on deep integration
with COEs that users select the most. I’m convinced it’s still too
early to bet the farm on just one choice.


If Magnum want to avoid the risk of picking the wrong COE, that mean the risk is 
populated to all our users. They might pick a COE and explore the its complexities. Then 
they find out another COE is more compelling and their integration work is wasted. I 
wonder if we can do better by taking the risk and provide insurance for our users? I am 
trying to understand the rationales that prevents us to improve the integration between 
COEs and OpenStack. Personally, I don't like to end up with a situation that "this 
is the pain from our users, but we cannot do anything".


We’re running Magnum and have requests from our user communities for 
Kubernetes, Docker Swarm and Mesos. The use cases are significantly different 
and can justify the selection of different technologies. We’re offering 
Kubernetes and Docker Swarm now and adding Mesos. If I was only to offer one, 
they’d build their own at considerable cost to them and the IT department.

Magnum allows me to make them all available under the single umbrella of quota, 
capacity planning, identity and resource lifecycle. As experience is gained, we 
may make a recommendation for those who do not have a strong need but I am 
pleased to be able to offer all of them under the single framework.

Since we’re building on the native APIs for the COEs, the effect from the 
operator side to add new engines is really very small (compared to trying to 
explain to the user that they’re wrong in choosing something different from the 
IT department).

BTW, our users also really appreciate using the native APIs.

Some more details at 
http://superuser.openstack.org/articles/openstack-magnum-on-the-cern-production-cloud
 and we’ll give more under the hood details in a further blog.



Yes!!!

This is 100% where the value of magnum comes from to me. It's about 
end-user choice, and about a sane way for operators to enable that 
end-user choice.


I do not believe anyone in the world wants us to bu

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Monty Taylor]

On 04/21/2016 11:01 AM, Flavio Percoco wrote:

On 21/04/16 12:26 +0200, Thierry Carrez wrote:

Joshua Harlow wrote:

Thierry Carrez wrote:

Adrian Otto wrote:

This pursuit is a trap. Magnum should focus on making native container
APIs available. We should not wrap APIs with leaky abstractions. The
lowest common denominator of all COEs is an remarkably low value API
that adds considerable complexity to Magnum that will not
strategically advance OpenStack. If we instead focus our effort on
making the COEs work better on OpenStack, that would be a winning
strategy. Support and compliment our various COE ecosystems.


So I'm all for avoiding 'wrap APIs with leaky abstractions' and 'making
COEs work better on OpenStack' but I do dislike the part about COEs
(plural) because it is once again the old non-opinionated problem that
we (as a community) suffer from.

Just my 2 cents, but I'd almost rather we pick one COE and integrate
that deeply/tightly with openstack, and yes if this causes some part of
the openstack community to be annoyed, meh, to bad. Sadly I have a
feeling we are hurting ourselves by continuing to try to be everything
and not picking anything (it's a general thing we, as a group, seem to
be good at, lol). I mean I get the reason to just support all the
things, but it feels like we as a community could just pick something,
work together on figuring out how to pick one, using all these bright
leaders we have to help make that possible (and yes this might piss some
people off, to bad). Then work toward making that something great and
move on...


I see where you come from, but I think this is a bit different from,
say, our choice to support multiple DLMs through Tooz instead of just
picking ZooKeeper.

I like to say that OpenStack solves the infrastructure provider
problem: what should I install over my datacenter to serve the needs
of all my end users. Some want VMs, some want bare metal, some want a
Docker host, some want a Kubernetes cluster, some want a Mesos
cluster. If we explicitly choose to, say, not support Mesos to only
support Kubernetes users, we are no longer a universal solution for
that infrastructure provider. He may deploy OpenStack but then will
have to tell his end users that they can do everything but Mesos,
and/or deploy a Mesos cluster manually on the side if his users end up
deciding they want one.

So while I agree we should get more opinionated on the
implementation/deployer-side options (weeding out less supported
options/drivers and driving more interoperability), I think we need to
support as many infrastructure use cases as we can.

Happy to talk about that with you next week :)



+1 to the above! Magnum's goal (as also mentioned by Kevin in another
email) is
similar to what Trove and Sahara do. I do not believe it should be
opinionated.
It solves a different set of issues and it sits in the provisioning
plane next
to other services akin.


Totally agree.


__
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][app-catalog][all] Build unified abstraction for all COEs

[Flavio Percoco]

On 21/04/16 12:26 +0200, Thierry Carrez wrote:

Joshua Harlow wrote:

Thierry Carrez wrote:

Adrian Otto wrote:

This pursuit is a trap. Magnum should focus on making native container
APIs available. We should not wrap APIs with leaky abstractions. The
lowest common denominator of all COEs is an remarkably low value API
that adds considerable complexity to Magnum that will not
strategically advance OpenStack. If we instead focus our effort on
making the COEs work better on OpenStack, that would be a winning
strategy. Support and compliment our various COE ecosystems.


So I'm all for avoiding 'wrap APIs with leaky abstractions' and 'making
COEs work better on OpenStack' but I do dislike the part about COEs
(plural) because it is once again the old non-opinionated problem that
we (as a community) suffer from.

Just my 2 cents, but I'd almost rather we pick one COE and integrate
that deeply/tightly with openstack, and yes if this causes some part of
the openstack community to be annoyed, meh, to bad. Sadly I have a
feeling we are hurting ourselves by continuing to try to be everything
and not picking anything (it's a general thing we, as a group, seem to
be good at, lol). I mean I get the reason to just support all the
things, but it feels like we as a community could just pick something,
work together on figuring out how to pick one, using all these bright
leaders we have to help make that possible (and yes this might piss some
people off, to bad). Then work toward making that something great and
move on...


I see where you come from, but I think this is a bit different from, 
say, our choice to support multiple DLMs through Tooz instead of just 
picking ZooKeeper.


I like to say that OpenStack solves the infrastructure provider 
problem: what should I install over my datacenter to serve the needs 
of all my end users. Some want VMs, some want bare metal, some want a 
Docker host, some want a Kubernetes cluster, some want a Mesos 
cluster. If we explicitly choose to, say, not support Mesos to only 
support Kubernetes users, we are no longer a universal solution for 
that infrastructure provider. He may deploy OpenStack but then will 
have to tell his end users that they can do everything but Mesos, 
and/or deploy a Mesos cluster manually on the side if his users end up 
deciding they want one.


So while I agree we should get more opinionated on the 
implementation/deployer-side options (weeding out less supported 
options/drivers and driving more interoperability), I think we need to 
support as many infrastructure use cases as we can.


Happy to talk about that with you next week :)



+1 to the above! Magnum's goal (as also mentioned by Kevin in another email) is
similar to what Trove and Sahara do. I do not believe it should be opinionated.
It solves a different set of issues and it sits in the provisioning plane next
to other services akin.

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][app-catalog][all] Build unified abstraction for all COEs

[Raj Patel]

There¹s one more issue with lowest common denominator API. Every time a
new version of native client is released, magnum will be responsible for
making those sure the common denominator API works with that version of
native client. Since the native client will always have more
functions/features than the common denominator API, it means the end users
will have to use native client for some operations and magnum API for
others.

-Raj

Raj Patel
raj.pa...@rackspace.com <mailto:raj.pa...@rackspace.com>



On 4/21/16, 11:03 AM, "Tim Bell" <tim.b...@cern.ch> wrote:

>
>
>On 21/04/16 17:38, "Hongbin Lu" <hongbin...@huawei.com> wrote:
>
>>
>>
>>> -Original Message-
>>> From: Adrian Otto [mailto:adrian.o...@rackspace.com]
>>> Sent: April-21-16 10:32 AM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
>>> abstraction for all COEs
>>> 
>>> 
>>> > On Apr 20, 2016, at 2:49 PM, Joshua Harlow <harlo...@fastmail.com>
>>> wrote:
>>> >
>>> > Thierry Carrez wrote:
>>> >> Adrian Otto wrote:
>>> >>> This pursuit is a trap. Magnum should focus on making native
>>> >>> container APIs available. We should not wrap APIs with leaky
>>> >>> abstractions. The lowest common denominator of all COEs is an
>>> >>> remarkably low value API that adds considerable complexity to
>>> Magnum
>>> >>> that will not strategically advance OpenStack. If we instead focus
>>> >>> our effort on making the COEs work better on OpenStack, that would
>>> >>> be a winning strategy. Support and compliment our various COE
>>> ecosystems.
>>> >
>>> > So I'm all for avoiding 'wrap APIs with leaky abstractions' and
>>> > 'making COEs work better on OpenStack' but I do dislike the part
>>> about COEs (plural) because it is once again the old non-opinionated
>>> problem that we (as a community) suffer from.
>>> >
>>> > Just my 2 cents, but I'd almost rather we pick one COE and integrate
>>> > that deeply/tightly with openstack, and yes if this causes some part
>>> > of the openstack community to be annoyed, meh, to bad. Sadly I have a
>>> > feeling we are hurting ourselves by continuing to try to be
>>> everything
>>> > and not picking anything (it's a general thing we, as a group, seem
>>> to
>>> > be good at, lol). I mean I get the reason to just support all the
>>> > things, but it feels like we as a community could just pick
>>>something,
>>> > work together on figuring out how to pick one, using all these bright
>>> > leaders we have to help make that possible (and yes this might piss
>>> > some people off, to bad). Then work toward making that something
>>> great
>>> > and move onŠ
>>> 
>>> The key issue preventing the selection of only one COE is that this
>>> area is moving very quickly. If we would have decided what to pick at
>>> the time the Magnum idea was created, we would have selected Docker. If
>>> you look at it today, you might pick something else. A few months down
>>> the road, there may be yet another choice that is more compelling. The
>>> fact that a cloud operator can integrate services with OpenStack, and
>>> have the freedom to offer support for a selection of COE¹s is a form of
>>> insurance against the risk of picking the wrong one. Our compute
>>> service offers a choice of hypervisors, our block storage service
>>> offers a choice of storage hardware drivers, our networking service
>>> allows a choice of network drivers. Magnum is following the same
>>> pattern of choice that has made OpenStack compelling for a very diverse
>>> community. That design consideration was intentional.
>>> 
>>> Over time, we can focus the majority of our effort on deep integration
>>> with COEs that users select the most. I¹m convinced it¹s still too
>>> early to bet the farm on just one choice.
>>
>>If Magnum want to avoid the risk of picking the wrong COE, that mean the
>>risk is populated to all our users. They might pick a COE and explore
>>the its complexities. Then they find out another COE is more compelling
>>and their integration work is wasted. I wonder if we can do better by
>>taking the risk and provide insurance for our users? I am trying to
>>understand the rationales th

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Tim Bell]

On 21/04/16 17:38, "Hongbin Lu" <hongbin...@huawei.com> wrote:

>
>
>> -Original Message-
>> From: Adrian Otto [mailto:adrian.o...@rackspace.com]
>> Sent: April-21-16 10:32 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
>> abstraction for all COEs
>> 
>> 
>> > On Apr 20, 2016, at 2:49 PM, Joshua Harlow <harlo...@fastmail.com>
>> wrote:
>> >
>> > Thierry Carrez wrote:
>> >> Adrian Otto wrote:
>> >>> This pursuit is a trap. Magnum should focus on making native
>> >>> container APIs available. We should not wrap APIs with leaky
>> >>> abstractions. The lowest common denominator of all COEs is an
>> >>> remarkably low value API that adds considerable complexity to
>> Magnum
>> >>> that will not strategically advance OpenStack. If we instead focus
>> >>> our effort on making the COEs work better on OpenStack, that would
>> >>> be a winning strategy. Support and compliment our various COE
>> ecosystems.
>> >
>> > So I'm all for avoiding 'wrap APIs with leaky abstractions' and
>> > 'making COEs work better on OpenStack' but I do dislike the part
>> about COEs (plural) because it is once again the old non-opinionated
>> problem that we (as a community) suffer from.
>> >
>> > Just my 2 cents, but I'd almost rather we pick one COE and integrate
>> > that deeply/tightly with openstack, and yes if this causes some part
>> > of the openstack community to be annoyed, meh, to bad. Sadly I have a
>> > feeling we are hurting ourselves by continuing to try to be
>> everything
>> > and not picking anything (it's a general thing we, as a group, seem
>> to
>> > be good at, lol). I mean I get the reason to just support all the
>> > things, but it feels like we as a community could just pick something,
>> > work together on figuring out how to pick one, using all these bright
>> > leaders we have to help make that possible (and yes this might piss
>> > some people off, to bad). Then work toward making that something
>> great
>> > and move on…
>> 
>> The key issue preventing the selection of only one COE is that this
>> area is moving very quickly. If we would have decided what to pick at
>> the time the Magnum idea was created, we would have selected Docker. If
>> you look at it today, you might pick something else. A few months down
>> the road, there may be yet another choice that is more compelling. The
>> fact that a cloud operator can integrate services with OpenStack, and
>> have the freedom to offer support for a selection of COE’s is a form of
>> insurance against the risk of picking the wrong one. Our compute
>> service offers a choice of hypervisors, our block storage service
>> offers a choice of storage hardware drivers, our networking service
>> allows a choice of network drivers. Magnum is following the same
>> pattern of choice that has made OpenStack compelling for a very diverse
>> community. That design consideration was intentional.
>> 
>> Over time, we can focus the majority of our effort on deep integration
>> with COEs that users select the most. I’m convinced it’s still too
>> early to bet the farm on just one choice.
>
>If Magnum want to avoid the risk of picking the wrong COE, that mean the risk 
>is populated to all our users. They might pick a COE and explore the its 
>complexities. Then they find out another COE is more compelling and their 
>integration work is wasted. I wonder if we can do better by taking the risk 
>and provide insurance for our users? I am trying to understand the rationales 
>that prevents us to improve the integration between COEs and OpenStack. 
>Personally, I don't like to end up with a situation that "this is the pain 
>from our users, but we cannot do anything".

We’re running Magnum and have requests from our user communities for 
Kubernetes, Docker Swarm and Mesos. The use cases are significantly different 
and can justify the selection of different technologies. We’re offering 
Kubernetes and Docker Swarm now and adding Mesos. If I was only to offer one, 
they’d build their own at considerable cost to them and the IT department.

Magnum allows me to make them all available under the single umbrella of quota, 
capacity planning, identity and resource lifecycle. As experience is gained, we 
may make a recommendation for those who do not have a strong need but I am 
pleased to be able to offer all of them under the single framewo

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Hongbin Lu]

> -Original Message-
> From: Adrian Otto [mailto:adrian.o...@rackspace.com]
> Sent: April-21-16 10:32 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> abstraction for all COEs
> 
> 
> > On Apr 20, 2016, at 2:49 PM, Joshua Harlow <harlo...@fastmail.com>
> wrote:
> >
> > Thierry Carrez wrote:
> >> Adrian Otto wrote:
> >>> This pursuit is a trap. Magnum should focus on making native
> >>> container APIs available. We should not wrap APIs with leaky
> >>> abstractions. The lowest common denominator of all COEs is an
> >>> remarkably low value API that adds considerable complexity to
> Magnum
> >>> that will not strategically advance OpenStack. If we instead focus
> >>> our effort on making the COEs work better on OpenStack, that would
> >>> be a winning strategy. Support and compliment our various COE
> ecosystems.
> >
> > So I'm all for avoiding 'wrap APIs with leaky abstractions' and
> > 'making COEs work better on OpenStack' but I do dislike the part
> about COEs (plural) because it is once again the old non-opinionated
> problem that we (as a community) suffer from.
> >
> > Just my 2 cents, but I'd almost rather we pick one COE and integrate
> > that deeply/tightly with openstack, and yes if this causes some part
> > of the openstack community to be annoyed, meh, to bad. Sadly I have a
> > feeling we are hurting ourselves by continuing to try to be
> everything
> > and not picking anything (it's a general thing we, as a group, seem
> to
> > be good at, lol). I mean I get the reason to just support all the
> > things, but it feels like we as a community could just pick something,
> > work together on figuring out how to pick one, using all these bright
> > leaders we have to help make that possible (and yes this might piss
> > some people off, to bad). Then work toward making that something
> great
> > and move on…
> 
> The key issue preventing the selection of only one COE is that this
> area is moving very quickly. If we would have decided what to pick at
> the time the Magnum idea was created, we would have selected Docker. If
> you look at it today, you might pick something else. A few months down
> the road, there may be yet another choice that is more compelling. The
> fact that a cloud operator can integrate services with OpenStack, and
> have the freedom to offer support for a selection of COE’s is a form of
> insurance against the risk of picking the wrong one. Our compute
> service offers a choice of hypervisors, our block storage service
> offers a choice of storage hardware drivers, our networking service
> allows a choice of network drivers. Magnum is following the same
> pattern of choice that has made OpenStack compelling for a very diverse
> community. That design consideration was intentional.
> 
> Over time, we can focus the majority of our effort on deep integration
> with COEs that users select the most. I’m convinced it’s still too
> early to bet the farm on just one choice.

If Magnum want to avoid the risk of picking the wrong COE, that mean the risk 
is populated to all our users. They might pick a COE and explore the its 
complexities. Then they find out another COE is more compelling and their 
integration work is wasted. I wonder if we can do better by taking the risk and 
provide insurance for our users? I am trying to understand the rationales that 
prevents us to improve the integration between COEs and OpenStack. Personally, 
I don't like to end up with a situation that "this is the pain from our users, 
but we cannot do anything".

> 
> Adrian
> 
> >> I'm with Adrian on that one. I've attended a lot of
> >> container-oriented conferences over the past year and my main
> >> takeaway is that this new crowd of potential users is not interested
> >> (at all) in an OpenStack-specific lowest common denominator API for
> >> COEs. They want to take advantage of the cool features in Kubernetes
> >> API or the versatility of Mesos. They want to avoid caring about the
> >> infrastructure provider bit (and not deploy Mesos or Kubernetes
> themselves).
> >>
> >> Let's focus on the infrastructure provider bit -- that is what we do
> >> and what the ecosystem wants us to provide.
> >>
> >
> >
> __
> >  OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > 

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Keith Bray]

The work on the plug-ins can still be done by Magnum core contributors (or
anyone). My point is that the work doesn’t have to be code-coupled to
Magnum except via the plug-in interface, which, like heat resources,
should be relatively straight forward. Creating the plug-in framework in
this way allows for leverage of work by non-Magnum contributors and re-use
of Chef/Ansible/Heat/PickYourFavoriteHere tool for infra configuration and
orchestration.  

-Keith

On 4/20/16, 6:03 PM, "Hongbin Lu" <hongbin...@huawei.com> wrote:

>
>
>> -Original Message-
>> From: Keith Bray [mailto:keith.b...@rackspace.com]
>> Sent: April-20-16 6:13 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
>> abstraction for all COEs
>> 
>> Magnum doesn¹t have to preclude tight integration for single COEs you
>> speak of.  The heavy lifting of tight integration of the COE in to
>> OpenStack (so that it performs optimally with the infra) can be modular
>> (where the work is performed by plug-in models to Magnum, not performed
>> by Magnum itself. The tight integration can be done by leveraging
>> existing technologies (Heat and/or choose your DevOps tool of choice:
>> Chef/Ansible/etc). This allows interested community members to focus on
>> tight integration of whatever COE they want, focusing specifically on
>
>I agree that tight integration can be achieved by a plugin, but I think
>the key question is who will do the work. If tight integration needs to
>be done, I wonder why it is not part of the Magnum efforts. From my point
>of view, pushing the work out doesn't seem to address the original pain,
>which is some users don't want to explore the complexities of individual
>COEs.
>
>> the COE integration part, contributing that integration focus to Magnum
>> via plug-ins, without having to actually know much about Magnum, but
>> instead
>> contribute to the COE plug-in using DevOps tools of choice.   Pegging
>> Magnum to one-and-only one COE means there will be a Magnum2, Magnum3,
>> etc. project for every COE of interest, all with different ways of
>> kicking off COE management.  Magnum could unify that experience for
>> users and operators, without picking a winner in the COE space < this
>> is just like Nova not picking a winner between VM flavors or OS types.
>> It just facilitates instantiation and management of thins.  Opinion
>> here:  The value of Magnum is in being a light-weight/thin API,
>> providing modular choice and plug-ability to COE provisioning and
>> management, thereby providing operators and users choice of COE
>> instantiation and management (via the bay concept), where each COE can
>> be as tightly or loosely integrated as desired by different plug-ins
>> contributed to perform the COE setup and configurations.  So, Magnum
>> could have two or more swarm plug-in options contributed to the
>> community.. One overlays generic swarm on VMs.
>> The other swarm plug-in could instantiate swarm tightly integrated to
>> neutron, keystone, etc on to bare metal.  Magnum just facilities a
>> plug-in model with thin API to offer choice of CEO instantiation and
>> management.
>> The plug-in does the heavy lifting using whatever methods desired by
>> the curator.
>> 
>> That¹s my $0.2.
>> 
>> -Keith
>> 
>> On 4/20/16, 4:49 PM, "Joshua Harlow" <harlo...@fastmail.com> wrote:
>> 
>> >Thierry Carrez wrote:
>> >> Adrian Otto wrote:
>> >>> This pursuit is a trap. Magnum should focus on making native
>> >>> container APIs available. We should not wrap APIs with leaky
>> >>> abstractions. The lowest common denominator of all COEs is an
>> >>> remarkably low value API that adds considerable complexity to
>> Magnum
>> >>> that will not strategically advance OpenStack. If we instead focus
>> >>> our effort on making the COEs work better on OpenStack, that would
>> >>> be a winning strategy. Support and compliment our various COE
>> ecosystems.
>> >
>> >So I'm all for avoiding 'wrap APIs with leaky abstractions' and
>> 'making
>> >COEs work better on OpenStack' but I do dislike the part about COEs
>> >(plural) because it is once again the old non-opinionated problem that
>> >we (as a community) suffer from.
>> >
>> >Just my 2 cents, but I'd almost rather we pick one COE and integrate
>> >that deeply/tightly with openstack, and yes if this causes some part
>> of
>> >the openst

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Keith Bray]

+1

From: "Fox, Kevin M" <kevin@pnnl.gov<mailto:kevin@pnnl.gov>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, April 20, 2016 at 6:14 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
abstraction for all COEs

I think Magnum much is much closer to Sahara or Trove in its workings. Heat's 
orchestration. Thats what the COE does.

Sahara is and has plugins to deploy various Hadoopy like clusters, get them 
assembled into something useful, and has a few abstraction api's like "submit a 
job to the deployed hadoop cluster queue."

Trove is and has plugins to deploy various Databasey things. Both SQL and 
noSQL. It has a few abstractions over all the things for cluster maintenance, 
backups, db and user creation.

If all Magnum did was deploy a COE, you could potentially just use Heat to do 
that.

What I want to do is have Heat hooked in closely enough through Magnum that 
Heat templates can deploy COE templates through Magnum Resources. Heat tried to 
do that with a docker resource driver directly, and its messy, racy, and 
doesn't work very well. Magnum's in a better position to establish a 
communication channel between Heat and the COE due to its back channel into the 
vms, bypassing Neutron network stuff.

Thanks,
Kevin

From: Georgy Okrokvertskhov 
[gokrokvertsk...@mirantis.com<mailto:gokrokvertsk...@mirantis.com>]
Sent: Wednesday, April 20, 2016 3:51 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
abstraction for all COEs

If Magnum will be focused on installation and management for COE it will be 
unclear how much it is different from Heat and other generic orchestrations.  
It looks like most of the current Magnum functionality is provided by Heat. 
Magnum focus on deployment will potentially lead to another Heat-like  API.
Unless Magnum is really focused on containers its value will be minimal for 
OpenStack users who already use Heat/Orchestration.


On Wed, Apr 20, 2016 at 3:12 PM, Keith Bray 
<keith.b...@rackspace.com<mailto:keith.b...@rackspace.com>> wrote:
Magnum doesn¹t have to preclude tight integration for single COEs you
speak of.  The heavy lifting of tight integration of the COE in to
OpenStack (so that it performs optimally with the infra) can be modular
(where the work is performed by plug-in models to Magnum, not performed by
Magnum itself. The tight integration can be done by leveraging existing
technologies (Heat and/or choose your DevOps tool of choice:
Chef/Ansible/etc). This allows interested community members to focus on
tight integration of whatever COE they want, focusing specifically on the
COE integration part, contributing that integration focus to Magnum via
plug-ins, without having to actually know much about Magnum, but instead
contribute to the COE plug-in using DevOps tools of choice.   Pegging
Magnum to one-and-only one COE means there will be a Magnum2, Magnum3,
etc. project for every COE of interest, all with different ways of kicking
off COE management.  Magnum could unify that experience for users and
operators, without picking a winner in the COE space ‹ this is just like
Nova not picking a winner between VM flavors or OS types.  It just
facilitates instantiation and management of thins.  Opinion here:  The
value of Magnum is in being a light-weight/thin API, providing modular
choice and plug-ability to COE provisioning and management, thereby
providing operators and users choice of COE instantiation and management
(via the bay concept), where each COE can be as tightly or loosely
integrated as desired by different plug-ins contributed to perform the COE
setup and configurations.  So, Magnum could have two or more swarm plug-in
options contributed to the community.. One overlays generic swarm on VMs.
The other swarm plug-in could instantiate swarm tightly integrated to
neutron, keystone, etc on to bare metal.  Magnum just facilities a plug-in
model with thin API to offer choice of CEO instantiation and management.
The plug-in does the heavy lifting using whatever methods desired by the
curator.

That¹s my $0.2.

-Keith

On 4/20/16, 4:49 PM, "Joshua Harlow" 
<harlo...@fastmail.com<mailto:harlo...@fastmail.com>> wrote:

>Thierry Carrez wrote:
>> Adrian Otto wrote:
>>> This pursuit is a trap. Magnum should focus on making native container
>>> APIs available. We should not wrap APIs with leaky abstractions. The
>>> lowest common denominator of all COEs is an remarkably low value API
>>>

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Hongbin Lu]

> -Original Message-
> From: Steve Gordon [mailto:sgor...@redhat.com]
> Sent: April-21-16 9:39 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> abstraction for all COEs
> 
> - Original Message -
> > From: "Hongbin Lu" <hongbin...@huawei.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev@lists.openstack.org>
> > > -Original Message-
> > > From: Keith Bray [mailto:keith.b...@rackspace.com]
> > > Sent: April-20-16 6:13 PM
> > > To: OpenStack Development Mailing List (not for usage questions)
> > > Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build
> > > unified abstraction for all COEs
> > >
> > > Magnum doesn¹t have to preclude tight integration for single COEs
> > > you speak of.  The heavy lifting of tight integration of the COE in
> > > to OpenStack (so that it performs optimally with the infra) can be
> > > modular (where the work is performed by plug-in models to Magnum,
> > > not performed by Magnum itself. The tight integration can be done
> by
> > > leveraging existing technologies (Heat and/or choose your DevOps
> tool of choice:
> > > Chef/Ansible/etc). This allows interested community members to
> focus
> > > on tight integration of whatever COE they want, focusing
> > > specifically on
> >
> > I agree that tight integration can be achieved by a plugin, but I
> > think the key question is who will do the work. If tight integration
> > needs to be done, I wonder why it is not part of the Magnum efforts.
> 
> Why does the integration belong in Magnum though? To me it belongs in
> the COEs themselves (e.g. their in-tree network/storage plugins) such
> that someone can leverage them regardless of their choices regarding
> COE deployment tooling (and yes that means Magnum should be able to
> leverage them too)? I guess the issue is that in the above conversation
> we are overloading the term "integration" which can be taken to mean
> different things...

I can clarify. I mean to introduce abstractions to allow tight integration 
between COEs and OpenStack. For example,

$ magnum container-create --volume= --net= ...

I agree with you that such integration should be supported by the COEs 
themselves. If it does, Magnum will leverage it (anyone can leverage it as well 
regardless of they are using Magnum or not). If it doesn't (the reality), 
Magnum could add support for that via its abstraction layer. For your question 
about why such integration belongs in Magnum, my answer is that the work needs 
to be done in one place so that everyone can leverage it instead of 
re-inventing their own solutions. Magnum is the OpenStack container service so 
it is nature for Magnum to take it IMHO.

> 
> -Steve
> 
> > From my point of view,
> > pushing the work out doesn't seem to address the original pain, which
> > is some users don't want to explore the complexities of individual
> COEs.
> 
> 
> ___
> ___
> 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

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Adrian Otto]

> On Apr 20, 2016, at 2:49 PM, Joshua Harlow  wrote:
> 
> Thierry Carrez wrote:
>> Adrian Otto wrote:
>>> This pursuit is a trap. Magnum should focus on making native container
>>> APIs available. We should not wrap APIs with leaky abstractions. The
>>> lowest common denominator of all COEs is an remarkably low value API
>>> that adds considerable complexity to Magnum that will not
>>> strategically advance OpenStack. If we instead focus our effort on
>>> making the COEs work better on OpenStack, that would be a winning
>>> strategy. Support and compliment our various COE ecosystems.
> 
> So I'm all for avoiding 'wrap APIs with leaky abstractions' and 'making
> COEs work better on OpenStack' but I do dislike the part about COEs (plural) 
> because it is once again the old non-opinionated problem that we (as a 
> community) suffer from.
> 
> Just my 2 cents, but I'd almost rather we pick one COE and integrate that 
> deeply/tightly with openstack, and yes if this causes some part of the 
> openstack community to be annoyed, meh, to bad. Sadly I have a feeling we are 
> hurting ourselves by continuing to try to be everything and not picking 
> anything (it's a general thing we, as a group, seem to be good at, lol). I 
> mean I get the reason to just support all the things, but it feels like we as 
> a community could just pick something, work together on figuring out how to 
> pick one, using all these bright leaders we have to help make that possible 
> (and yes this might piss some people off, to bad). Then work toward making 
> that something great and move on…

The key issue preventing the selection of only one COE is that this area is 
moving very quickly. If we would have decided what to pick at the time the 
Magnum idea was created, we would have selected Docker. If you look at it 
today, you might pick something else. A few months down the road, there may be 
yet another choice that is more compelling. The fact that a cloud operator can 
integrate services with OpenStack, and have the freedom to offer support for a 
selection of COE’s is a form of insurance against the risk of picking the wrong 
one. Our compute service offers a choice of hypervisors, our block storage 
service offers a choice of storage hardware drivers, our networking service 
allows a choice of network drivers. Magnum is following the same pattern of 
choice that has made OpenStack compelling for a very diverse community. That 
design consideration was intentional.

Over time, we can focus the majority of our effort on deep integration with 
COEs that users select the most. I’m convinced it’s still too early to bet the 
farm on just one choice.

Adrian

>> I'm with Adrian on that one. I've attended a lot of container-oriented
>> conferences over the past year and my main takeaway is that this new
>> crowd of potential users is not interested (at all) in an
>> OpenStack-specific lowest common denominator API for COEs. They want to
>> take advantage of the cool features in Kubernetes API or the versatility
>> of Mesos. They want to avoid caring about the infrastructure provider
>> bit (and not deploy Mesos or Kubernetes themselves).
>> 
>> Let's focus on the infrastructure provider bit -- that is what we do and
>> what the ecosystem wants us to provide.
>> 
> 
> __
> 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

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Steve Gordon]

- Original Message -
> From: "Hongbin Lu" <hongbin...@huawei.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org>
> > -Original Message-
> > From: Keith Bray [mailto:keith.b...@rackspace.com]
> > Sent: April-20-16 6:13 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> > abstraction for all COEs
> > 
> > Magnum doesn¹t have to preclude tight integration for single COEs you
> > speak of.  The heavy lifting of tight integration of the COE in to
> > OpenStack (so that it performs optimally with the infra) can be modular
> > (where the work is performed by plug-in models to Magnum, not performed
> > by Magnum itself. The tight integration can be done by leveraging
> > existing technologies (Heat and/or choose your DevOps tool of choice:
> > Chef/Ansible/etc). This allows interested community members to focus on
> > tight integration of whatever COE they want, focusing specifically on
> 
> I agree that tight integration can be achieved by a plugin, but I think the
> key question is who will do the work. If tight integration needs to be done,
> I wonder why it is not part of the Magnum efforts.

Why does the integration belong in Magnum though? To me it belongs in the COEs 
themselves (e.g. their in-tree network/storage plugins) such that someone can 
leverage them regardless of their choices regarding COE deployment tooling (and 
yes that means Magnum should be able to leverage them too)? I guess the issue 
is that in the above conversation we are overloading the term "integration" 
which can be taken to mean different things...

-Steve

> From my point of view,
> pushing the work out doesn't seem to address the original pain, which is
> some users don't want to explore the complexities of individual COEs.


__
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][app-catalog][all] Build unified abstraction for all COEs

[Thierry Carrez]

Joshua Harlow wrote:

Thierry Carrez wrote:

Adrian Otto wrote:

This pursuit is a trap. Magnum should focus on making native container
APIs available. We should not wrap APIs with leaky abstractions. The
lowest common denominator of all COEs is an remarkably low value API
that adds considerable complexity to Magnum that will not
strategically advance OpenStack. If we instead focus our effort on
making the COEs work better on OpenStack, that would be a winning
strategy. Support and compliment our various COE ecosystems.


So I'm all for avoiding 'wrap APIs with leaky abstractions' and 'making
COEs work better on OpenStack' but I do dislike the part about COEs
(plural) because it is once again the old non-opinionated problem that
we (as a community) suffer from.

Just my 2 cents, but I'd almost rather we pick one COE and integrate
that deeply/tightly with openstack, and yes if this causes some part of
the openstack community to be annoyed, meh, to bad. Sadly I have a
feeling we are hurting ourselves by continuing to try to be everything
and not picking anything (it's a general thing we, as a group, seem to
be good at, lol). I mean I get the reason to just support all the
things, but it feels like we as a community could just pick something,
work together on figuring out how to pick one, using all these bright
leaders we have to help make that possible (and yes this might piss some
people off, to bad). Then work toward making that something great and
move on...


I see where you come from, but I think this is a bit different from, 
say, our choice to support multiple DLMs through Tooz instead of just 
picking ZooKeeper.


I like to say that OpenStack solves the infrastructure provider problem: 
what should I install over my datacenter to serve the needs of all my 
end users. Some want VMs, some want bare metal, some want a Docker host, 
some want a Kubernetes cluster, some want a Mesos cluster. If we 
explicitly choose to, say, not support Mesos to only support Kubernetes 
users, we are no longer a universal solution for that infrastructure 
provider. He may deploy OpenStack but then will have to tell his end 
users that they can do everything but Mesos, and/or deploy a Mesos 
cluster manually on the side if his users end up deciding they want one.


So while I agree we should get more opinionated on the 
implementation/deployer-side options (weeding out less supported 
options/drivers and driving more interoperability), I think we need to 
support as many infrastructure use cases as we can.


Happy to talk about that with you next week :)

--
Thierry Carrez (ttx)

__
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][app-catalog][all] Build unified abstraction for all COEs

[Fox, Kevin M]

Its new enough that people haven't thought to ask until recently. The recent 
interest is starting in the topic due to Magnum getting mature enough folks are 
starting to deploy it and finding out it doesn't solve a bunch of issues they 
had thought it would. Its pretty natural. Don't just blow it off because you 
haven't been asked till now.

I know we're going to try and pilot it here soon, and the only reason I know 
some of these things that we will need coming up aren't there now is I've paid 
close attention to the dev mailing list. Others don't pay so close attention.

Thanks,
Kevin

From: Hongbin Lu [hongbin...@huawei.com]
Sent: Wednesday, April 20, 2016 4:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
abstraction for all COEs

> -Original Message-
> From: Keith Bray [mailto:keith.b...@rackspace.com]
> Sent: April-20-16 6:13 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> abstraction for all COEs
>
> Magnum doesn¹t have to preclude tight integration for single COEs you
> speak of.  The heavy lifting of tight integration of the COE in to
> OpenStack (so that it performs optimally with the infra) can be modular
> (where the work is performed by plug-in models to Magnum, not performed
> by Magnum itself. The tight integration can be done by leveraging
> existing technologies (Heat and/or choose your DevOps tool of choice:
> Chef/Ansible/etc). This allows interested community members to focus on
> tight integration of whatever COE they want, focusing specifically on

I agree that tight integration can be achieved by a plugin, but I think the key 
question is who will do the work. If tight integration needs to be done, I 
wonder why it is not part of the Magnum efforts. From my point of view, pushing 
the work out doesn't seem to address the original pain, which is some users 
don't want to explore the complexities of individual COEs.

> the COE integration part, contributing that integration focus to Magnum
> via plug-ins, without having to actually know much about Magnum, but
> instead
> contribute to the COE plug-in using DevOps tools of choice.   Pegging
> Magnum to one-and-only one COE means there will be a Magnum2, Magnum3,
> etc. project for every COE of interest, all with different ways of
> kicking off COE management.  Magnum could unify that experience for
> users and operators, without picking a winner in the COE space < this
> is just like Nova not picking a winner between VM flavors or OS types.
> It just facilitates instantiation and management of thins.  Opinion
> here:  The value of Magnum is in being a light-weight/thin API,
> providing modular choice and plug-ability to COE provisioning and
> management, thereby providing operators and users choice of COE
> instantiation and management (via the bay concept), where each COE can
> be as tightly or loosely integrated as desired by different plug-ins
> contributed to perform the COE setup and configurations.  So, Magnum
> could have two or more swarm plug-in options contributed to the
> community.. One overlays generic swarm on VMs.
> The other swarm plug-in could instantiate swarm tightly integrated to
> neutron, keystone, etc on to bare metal.  Magnum just facilities a
> plug-in model with thin API to offer choice of CEO instantiation and
> management.
> The plug-in does the heavy lifting using whatever methods desired by
> the curator.
>
> That¹s my $0.2.
>
> -Keith
>
> On 4/20/16, 4:49 PM, "Joshua Harlow" <harlo...@fastmail.com> wrote:
>
> >Thierry Carrez wrote:
> >> Adrian Otto wrote:
> >>> This pursuit is a trap. Magnum should focus on making native
> >>> container APIs available. We should not wrap APIs with leaky
> >>> abstractions. The lowest common denominator of all COEs is an
> >>> remarkably low value API that adds considerable complexity to
> Magnum
> >>> that will not strategically advance OpenStack. If we instead focus
> >>> our effort on making the COEs work better on OpenStack, that would
> >>> be a winning strategy. Support and compliment our various COE
> ecosystems.
> >
> >So I'm all for avoiding 'wrap APIs with leaky abstractions' and
> 'making
> >COEs work better on OpenStack' but I do dislike the part about COEs
> >(plural) because it is once again the old non-opinionated problem that
> >we (as a community) suffer from.
> >
> >Just my 2 cents, but I'd almost rather we pick one COE and integrate
> >that deeply/tightly with openstack, and yes if this causes some part
> of

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Fox, Kevin M]

I think Magnum much is much closer to Sahara or Trove in its workings. Heat's 
orchestration. Thats what the COE does.

Sahara is and has plugins to deploy various Hadoopy like clusters, get them 
assembled into something useful, and has a few abstraction api's like "submit a 
job to the deployed hadoop cluster queue."

Trove is and has plugins to deploy various Databasey things. Both SQL and 
noSQL. It has a few abstractions over all the things for cluster maintenance, 
backups, db and user creation.

If all Magnum did was deploy a COE, you could potentially just use Heat to do 
that.

What I want to do is have Heat hooked in closely enough through Magnum that 
Heat templates can deploy COE templates through Magnum Resources. Heat tried to 
do that with a docker resource driver directly, and its messy, racy, and 
doesn't work very well. Magnum's in a better position to establish a 
communication channel between Heat and the COE due to its back channel into the 
vms, bypassing Neutron network stuff.

Thanks,
Kevin

From: Georgy Okrokvertskhov [gokrokvertsk...@mirantis.com]
Sent: Wednesday, April 20, 2016 3:51 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
abstraction for all COEs

If Magnum will be focused on installation and management for COE it will be 
unclear how much it is different from Heat and other generic orchestrations.  
It looks like most of the current Magnum functionality is provided by Heat. 
Magnum focus on deployment will potentially lead to another Heat-like  API.
Unless Magnum is really focused on containers its value will be minimal for 
OpenStack users who already use Heat/Orchestration.


On Wed, Apr 20, 2016 at 3:12 PM, Keith Bray 
<keith.b...@rackspace.com<mailto:keith.b...@rackspace.com>> wrote:
Magnum doesn¹t have to preclude tight integration for single COEs you
speak of.  The heavy lifting of tight integration of the COE in to
OpenStack (so that it performs optimally with the infra) can be modular
(where the work is performed by plug-in models to Magnum, not performed by
Magnum itself. The tight integration can be done by leveraging existing
technologies (Heat and/or choose your DevOps tool of choice:
Chef/Ansible/etc). This allows interested community members to focus on
tight integration of whatever COE they want, focusing specifically on the
COE integration part, contributing that integration focus to Magnum via
plug-ins, without having to actually know much about Magnum, but instead
contribute to the COE plug-in using DevOps tools of choice.   Pegging
Magnum to one-and-only one COE means there will be a Magnum2, Magnum3,
etc. project for every COE of interest, all with different ways of kicking
off COE management.  Magnum could unify that experience for users and
operators, without picking a winner in the COE space ‹ this is just like
Nova not picking a winner between VM flavors or OS types.  It just
facilitates instantiation and management of thins.  Opinion here:  The
value of Magnum is in being a light-weight/thin API, providing modular
choice and plug-ability to COE provisioning and management, thereby
providing operators and users choice of COE instantiation and management
(via the bay concept), where each COE can be as tightly or loosely
integrated as desired by different plug-ins contributed to perform the COE
setup and configurations.  So, Magnum could have two or more swarm plug-in
options contributed to the community.. One overlays generic swarm on VMs.
The other swarm plug-in could instantiate swarm tightly integrated to
neutron, keystone, etc on to bare metal.  Magnum just facilities a plug-in
model with thin API to offer choice of CEO instantiation and management.
The plug-in does the heavy lifting using whatever methods desired by the
curator.

That¹s my $0.2.

-Keith

On 4/20/16, 4:49 PM, "Joshua Harlow" 
<harlo...@fastmail.com<mailto:harlo...@fastmail.com>> wrote:

>Thierry Carrez wrote:
>> Adrian Otto wrote:
>>> This pursuit is a trap. Magnum should focus on making native container
>>> APIs available. We should not wrap APIs with leaky abstractions. The
>>> lowest common denominator of all COEs is an remarkably low value API
>>> that adds considerable complexity to Magnum that will not
>>> strategically advance OpenStack. If we instead focus our effort on
>>> making the COEs work better on OpenStack, that would be a winning
>>> strategy. Support and compliment our various COE ecosystems.
>
>So I'm all for avoiding 'wrap APIs with leaky abstractions' and 'making
>COEs work better on OpenStack' but I do dislike the part about COEs
>(plural) because it is once again the old non-opinionated problem that
>we (as a community) suffer from.
>
>Just my 2 cents, but I'd almost rather we pick one COE and inte

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Hongbin Lu]

> -Original Message-
> From: Keith Bray [mailto:keith.b...@rackspace.com]
> Sent: April-20-16 6:13 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> abstraction for all COEs
> 
> Magnum doesn¹t have to preclude tight integration for single COEs you
> speak of.  The heavy lifting of tight integration of the COE in to
> OpenStack (so that it performs optimally with the infra) can be modular
> (where the work is performed by plug-in models to Magnum, not performed
> by Magnum itself. The tight integration can be done by leveraging
> existing technologies (Heat and/or choose your DevOps tool of choice:
> Chef/Ansible/etc). This allows interested community members to focus on
> tight integration of whatever COE they want, focusing specifically on

I agree that tight integration can be achieved by a plugin, but I think the key 
question is who will do the work. If tight integration needs to be done, I 
wonder why it is not part of the Magnum efforts. From my point of view, pushing 
the work out doesn't seem to address the original pain, which is some users 
don't want to explore the complexities of individual COEs.

> the COE integration part, contributing that integration focus to Magnum
> via plug-ins, without having to actually know much about Magnum, but
> instead
> contribute to the COE plug-in using DevOps tools of choice.   Pegging
> Magnum to one-and-only one COE means there will be a Magnum2, Magnum3,
> etc. project for every COE of interest, all with different ways of
> kicking off COE management.  Magnum could unify that experience for
> users and operators, without picking a winner in the COE space < this
> is just like Nova not picking a winner between VM flavors or OS types.
> It just facilitates instantiation and management of thins.  Opinion
> here:  The value of Magnum is in being a light-weight/thin API,
> providing modular choice and plug-ability to COE provisioning and
> management, thereby providing operators and users choice of COE
> instantiation and management (via the bay concept), where each COE can
> be as tightly or loosely integrated as desired by different plug-ins
> contributed to perform the COE setup and configurations.  So, Magnum
> could have two or more swarm plug-in options contributed to the
> community.. One overlays generic swarm on VMs.
> The other swarm plug-in could instantiate swarm tightly integrated to
> neutron, keystone, etc on to bare metal.  Magnum just facilities a
> plug-in model with thin API to offer choice of CEO instantiation and
> management.
> The plug-in does the heavy lifting using whatever methods desired by
> the curator.
> 
> That¹s my $0.2.
> 
> -Keith
> 
> On 4/20/16, 4:49 PM, "Joshua Harlow" <harlo...@fastmail.com> wrote:
> 
> >Thierry Carrez wrote:
> >> Adrian Otto wrote:
> >>> This pursuit is a trap. Magnum should focus on making native
> >>> container APIs available. We should not wrap APIs with leaky
> >>> abstractions. The lowest common denominator of all COEs is an
> >>> remarkably low value API that adds considerable complexity to
> Magnum
> >>> that will not strategically advance OpenStack. If we instead focus
> >>> our effort on making the COEs work better on OpenStack, that would
> >>> be a winning strategy. Support and compliment our various COE
> ecosystems.
> >
> >So I'm all for avoiding 'wrap APIs with leaky abstractions' and
> 'making
> >COEs work better on OpenStack' but I do dislike the part about COEs
> >(plural) because it is once again the old non-opinionated problem that
> >we (as a community) suffer from.
> >
> >Just my 2 cents, but I'd almost rather we pick one COE and integrate
> >that deeply/tightly with openstack, and yes if this causes some part
> of
> >the openstack community to be annoyed, meh, to bad. Sadly I have a
> >feeling we are hurting ourselves by continuing to try to be everything
> >and not picking anything (it's a general thing we, as a group, seem to
> >be good at, lol). I mean I get the reason to just support all the
> >things, but it feels like we as a community could just pick something,
> >work together on figuring out how to pick one, using all these bright
> >leaders we have to help make that possible (and yes this might piss
> >some people off, to bad). Then work toward making that something great
> >and move on...
> >
> >>
> >> I'm with Adrian on that one. I've attended a lot of
> >> container-oriented conferences over the past year and my main
> >> takeaway is that this new crowd of poten

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Georgy Okrokvertskhov]

If Magnum will be focused on installation and management for COE it will be
unclear how much it is different from Heat and other generic
orchestrations.  It looks like most of the current Magnum functionality is
provided by Heat. Magnum focus on deployment will potentially lead to
another Heat-like  API.
Unless Magnum is really focused on containers its value will be minimal for
OpenStack users who already use Heat/Orchestration.


On Wed, Apr 20, 2016 at 3:12 PM, Keith Bray 
wrote:

> Magnum doesn¹t have to preclude tight integration for single COEs you
> speak of.  The heavy lifting of tight integration of the COE in to
> OpenStack (so that it performs optimally with the infra) can be modular
> (where the work is performed by plug-in models to Magnum, not performed by
> Magnum itself. The tight integration can be done by leveraging existing
> technologies (Heat and/or choose your DevOps tool of choice:
> Chef/Ansible/etc). This allows interested community members to focus on
> tight integration of whatever COE they want, focusing specifically on the
> COE integration part, contributing that integration focus to Magnum via
> plug-ins, without having to actually know much about Magnum, but instead
> contribute to the COE plug-in using DevOps tools of choice.   Pegging
> Magnum to one-and-only one COE means there will be a Magnum2, Magnum3,
> etc. project for every COE of interest, all with different ways of kicking
> off COE management.  Magnum could unify that experience for users and
> operators, without picking a winner in the COE space ‹ this is just like
> Nova not picking a winner between VM flavors or OS types.  It just
> facilitates instantiation and management of thins.  Opinion here:  The
> value of Magnum is in being a light-weight/thin API, providing modular
> choice and plug-ability to COE provisioning and management, thereby
> providing operators and users choice of COE instantiation and management
> (via the bay concept), where each COE can be as tightly or loosely
> integrated as desired by different plug-ins contributed to perform the COE
> setup and configurations.  So, Magnum could have two or more swarm plug-in
> options contributed to the community.. One overlays generic swarm on VMs.
> The other swarm plug-in could instantiate swarm tightly integrated to
> neutron, keystone, etc on to bare metal.  Magnum just facilities a plug-in
> model with thin API to offer choice of CEO instantiation and management.
> The plug-in does the heavy lifting using whatever methods desired by the
> curator.
>
> That¹s my $0.2.
>
> -Keith
>
> On 4/20/16, 4:49 PM, "Joshua Harlow"  wrote:
>
> >Thierry Carrez wrote:
> >> Adrian Otto wrote:
> >>> This pursuit is a trap. Magnum should focus on making native container
> >>> APIs available. We should not wrap APIs with leaky abstractions. The
> >>> lowest common denominator of all COEs is an remarkably low value API
> >>> that adds considerable complexity to Magnum that will not
> >>> strategically advance OpenStack. If we instead focus our effort on
> >>> making the COEs work better on OpenStack, that would be a winning
> >>> strategy. Support and compliment our various COE ecosystems.
> >
> >So I'm all for avoiding 'wrap APIs with leaky abstractions' and 'making
> >COEs work better on OpenStack' but I do dislike the part about COEs
> >(plural) because it is once again the old non-opinionated problem that
> >we (as a community) suffer from.
> >
> >Just my 2 cents, but I'd almost rather we pick one COE and integrate
> >that deeply/tightly with openstack, and yes if this causes some part of
> >the openstack community to be annoyed, meh, to bad. Sadly I have a
> >feeling we are hurting ourselves by continuing to try to be everything
> >and not picking anything (it's a general thing we, as a group, seem to
> >be good at, lol). I mean I get the reason to just support all the
> >things, but it feels like we as a community could just pick something,
> >work together on figuring out how to pick one, using all these bright
> >leaders we have to help make that possible (and yes this might piss some
> >people off, to bad). Then work toward making that something great and
> >move on...
> >
> >>
> >> I'm with Adrian on that one. I've attended a lot of container-oriented
> >> conferences over the past year and my main takeaway is that this new
> >> crowd of potential users is not interested (at all) in an
> >> OpenStack-specific lowest common denominator API for COEs. They want to
> >> take advantage of the cool features in Kubernetes API or the versatility
> >> of Mesos. They want to avoid caring about the infrastructure provider
> >> bit (and not deploy Mesos or Kubernetes themselves).
> >>
> >> Let's focus on the infrastructure provider bit -- that is what we do and
> >> what the ecosystem wants us to provide.
> >>
> >
> >__
> >OpenStack Development 

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Fox, Kevin M]

+1 to plugins. it has suited nova/trove/sahara/etc well.

Thanks,
Kevin

From: Keith Bray [keith.b...@rackspace.com]
Sent: Wednesday, April 20, 2016 3:12 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
abstraction for all COEs

Magnum doesn¹t have to preclude tight integration for single COEs you
speak of.  The heavy lifting of tight integration of the COE in to
OpenStack (so that it performs optimally with the infra) can be modular
(where the work is performed by plug-in models to Magnum, not performed by
Magnum itself. The tight integration can be done by leveraging existing
technologies (Heat and/or choose your DevOps tool of choice:
Chef/Ansible/etc). This allows interested community members to focus on
tight integration of whatever COE they want, focusing specifically on the
COE integration part, contributing that integration focus to Magnum via
plug-ins, without having to actually know much about Magnum, but instead
contribute to the COE plug-in using DevOps tools of choice.   Pegging
Magnum to one-and-only one COE means there will be a Magnum2, Magnum3,
etc. project for every COE of interest, all with different ways of kicking
off COE management.  Magnum could unify that experience for users and
operators, without picking a winner in the COE space ‹ this is just like
Nova not picking a winner between VM flavors or OS types.  It just
facilitates instantiation and management of thins.  Opinion here:  The
value of Magnum is in being a light-weight/thin API, providing modular
choice and plug-ability to COE provisioning and management, thereby
providing operators and users choice of COE instantiation and management
(via the bay concept), where each COE can be as tightly or loosely
integrated as desired by different plug-ins contributed to perform the COE
setup and configurations.  So, Magnum could have two or more swarm plug-in
options contributed to the community.. One overlays generic swarm on VMs.
The other swarm plug-in could instantiate swarm tightly integrated to
neutron, keystone, etc on to bare metal.  Magnum just facilities a plug-in
model with thin API to offer choice of CEO instantiation and management.
The plug-in does the heavy lifting using whatever methods desired by the
curator.

That¹s my $0.2.

-Keith

On 4/20/16, 4:49 PM, "Joshua Harlow" <harlo...@fastmail.com> wrote:

>Thierry Carrez wrote:
>> Adrian Otto wrote:
>>> This pursuit is a trap. Magnum should focus on making native container
>>> APIs available. We should not wrap APIs with leaky abstractions. The
>>> lowest common denominator of all COEs is an remarkably low value API
>>> that adds considerable complexity to Magnum that will not
>>> strategically advance OpenStack. If we instead focus our effort on
>>> making the COEs work better on OpenStack, that would be a winning
>>> strategy. Support and compliment our various COE ecosystems.
>
>So I'm all for avoiding 'wrap APIs with leaky abstractions' and 'making
>COEs work better on OpenStack' but I do dislike the part about COEs
>(plural) because it is once again the old non-opinionated problem that
>we (as a community) suffer from.
>
>Just my 2 cents, but I'd almost rather we pick one COE and integrate
>that deeply/tightly with openstack, and yes if this causes some part of
>the openstack community to be annoyed, meh, to bad. Sadly I have a
>feeling we are hurting ourselves by continuing to try to be everything
>and not picking anything (it's a general thing we, as a group, seem to
>be good at, lol). I mean I get the reason to just support all the
>things, but it feels like we as a community could just pick something,
>work together on figuring out how to pick one, using all these bright
>leaders we have to help make that possible (and yes this might piss some
>people off, to bad). Then work toward making that something great and
>move on...
>
>>
>> I'm with Adrian on that one. I've attended a lot of container-oriented
>> conferences over the past year and my main takeaway is that this new
>> crowd of potential users is not interested (at all) in an
>> OpenStack-specific lowest common denominator API for COEs. They want to
>> take advantage of the cool features in Kubernetes API or the versatility
>> of Mesos. They want to avoid caring about the infrastructure provider
>> bit (and not deploy Mesos or Kubernetes themselves).
>>
>> Let's focus on the infrastructure provider bit -- that is what we do and
>> what the ecosystem wants us to provide.
>>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.o

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Keith Bray]

Magnum doesn¹t have to preclude tight integration for single COEs you
speak of.  The heavy lifting of tight integration of the COE in to
OpenStack (so that it performs optimally with the infra) can be modular
(where the work is performed by plug-in models to Magnum, not performed by
Magnum itself. The tight integration can be done by leveraging existing
technologies (Heat and/or choose your DevOps tool of choice:
Chef/Ansible/etc). This allows interested community members to focus on
tight integration of whatever COE they want, focusing specifically on the
COE integration part, contributing that integration focus to Magnum via
plug-ins, without having to actually know much about Magnum, but instead
contribute to the COE plug-in using DevOps tools of choice.   Pegging
Magnum to one-and-only one COE means there will be a Magnum2, Magnum3,
etc. project for every COE of interest, all with different ways of kicking
off COE management.  Magnum could unify that experience for users and
operators, without picking a winner in the COE space ‹ this is just like
Nova not picking a winner between VM flavors or OS types.  It just
facilitates instantiation and management of thins.  Opinion here:  The
value of Magnum is in being a light-weight/thin API, providing modular
choice and plug-ability to COE provisioning and management, thereby
providing operators and users choice of COE instantiation and management
(via the bay concept), where each COE can be as tightly or loosely
integrated as desired by different plug-ins contributed to perform the COE
setup and configurations.  So, Magnum could have two or more swarm plug-in
options contributed to the community.. One overlays generic swarm on VMs.
The other swarm plug-in could instantiate swarm tightly integrated to
neutron, keystone, etc on to bare metal.  Magnum just facilities a plug-in
model with thin API to offer choice of CEO instantiation and management.
The plug-in does the heavy lifting using whatever methods desired by the
curator.

That¹s my $0.2.

-Keith

On 4/20/16, 4:49 PM, "Joshua Harlow"  wrote:

>Thierry Carrez wrote:
>> Adrian Otto wrote:
>>> This pursuit is a trap. Magnum should focus on making native container
>>> APIs available. We should not wrap APIs with leaky abstractions. The
>>> lowest common denominator of all COEs is an remarkably low value API
>>> that adds considerable complexity to Magnum that will not
>>> strategically advance OpenStack. If we instead focus our effort on
>>> making the COEs work better on OpenStack, that would be a winning
>>> strategy. Support and compliment our various COE ecosystems.
>
>So I'm all for avoiding 'wrap APIs with leaky abstractions' and 'making
>COEs work better on OpenStack' but I do dislike the part about COEs
>(plural) because it is once again the old non-opinionated problem that
>we (as a community) suffer from.
>
>Just my 2 cents, but I'd almost rather we pick one COE and integrate
>that deeply/tightly with openstack, and yes if this causes some part of
>the openstack community to be annoyed, meh, to bad. Sadly I have a
>feeling we are hurting ourselves by continuing to try to be everything
>and not picking anything (it's a general thing we, as a group, seem to
>be good at, lol). I mean I get the reason to just support all the
>things, but it feels like we as a community could just pick something,
>work together on figuring out how to pick one, using all these bright
>leaders we have to help make that possible (and yes this might piss some
>people off, to bad). Then work toward making that something great and
>move on...
>
>>
>> I'm with Adrian on that one. I've attended a lot of container-oriented
>> conferences over the past year and my main takeaway is that this new
>> crowd of potential users is not interested (at all) in an
>> OpenStack-specific lowest common denominator API for COEs. They want to
>> take advantage of the cool features in Kubernetes API or the versatility
>> of Mesos. They want to avoid caring about the infrastructure provider
>> bit (and not deploy Mesos or Kubernetes themselves).
>>
>> Let's focus on the infrastructure provider bit -- that is what we do and
>> what the ecosystem wants us to provide.
>>
>
>__
>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

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Joshua Harlow]

Thierry Carrez wrote:

Adrian Otto wrote:

This pursuit is a trap. Magnum should focus on making native container
APIs available. We should not wrap APIs with leaky abstractions. The
lowest common denominator of all COEs is an remarkably low value API
that adds considerable complexity to Magnum that will not
strategically advance OpenStack. If we instead focus our effort on
making the COEs work better on OpenStack, that would be a winning
strategy. Support and compliment our various COE ecosystems.


So I'm all for avoiding 'wrap APIs with leaky abstractions' and 'making
COEs work better on OpenStack' but I do dislike the part about COEs 
(plural) because it is once again the old non-opinionated problem that 
we (as a community) suffer from.


Just my 2 cents, but I'd almost rather we pick one COE and integrate 
that deeply/tightly with openstack, and yes if this causes some part of 
the openstack community to be annoyed, meh, to bad. Sadly I have a 
feeling we are hurting ourselves by continuing to try to be everything 
and not picking anything (it's a general thing we, as a group, seem to 
be good at, lol). I mean I get the reason to just support all the 
things, but it feels like we as a community could just pick something, 
work together on figuring out how to pick one, using all these bright 
leaders we have to help make that possible (and yes this might piss some 
people off, to bad). Then work toward making that something great and 
move on...




I'm with Adrian on that one. I've attended a lot of container-oriented
conferences over the past year and my main takeaway is that this new
crowd of potential users is not interested (at all) in an
OpenStack-specific lowest common denominator API for COEs. They want to
take advantage of the cool features in Kubernetes API or the versatility
of Mesos. They want to avoid caring about the infrastructure provider
bit (and not deploy Mesos or Kubernetes themselves).

Let's focus on the infrastructure provider bit -- that is what we do and
what the ecosystem wants us to provide.



__
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][app-catalog][all] Build unified abstraction for all COEs

[Hongbin Lu]

> -Original Message-
> From: Ian Cordasco [mailto:sigmaviru...@gmail.com]
> Sent: April-20-16 1:56 PM
> To: Adrian Otto; OpenStack Development Mailing List (not for usage
> questions)
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> abstraction for all COEs
> 
> -Original Message-
> From: Adrian Otto <adrian.o...@rackspace.com>
> Reply: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Date: April 19, 2016 at 19:11:07
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject:  Re: [openstack-dev] [magnum][app-catalog][all] Build unified
>   abstraction for all COEs
> 
> > This pursuit is a trap. Magnum should focus on making native
> container APIs available.
> > We should not wrap APIs with leaky abstractions. The lowest common
> > denominator of all COEs is an remarkably low value API that adds
> > considerable complexity to Magnum that will not strategically advance
> > OpenStack. If we instead focus our effort on making the COEs work
> > better on OpenStack, that would be a winning strategy. Support and
> compliment our various COE ecosystems.
> 
> I'm not nearly as familiar with each COE's API as I'm sure some of you
> are, but knowing the present quality of Magnum's documentation, the
> fact that it's API is not being documented well, and how thinly
> stretched most of Magnum's developers already seem to be, I think that
> not doing this now (or in the near term is a better option). First, all
> of the COEs magnum supports have excellent documentation around their
> API and clients. Magnum does not have that at present and would need to
> work on that for this effort to be worthwhile to Magnum's users. Second
> of all, what little I do know about each COE's API reinforces (in my
> opinion) what Adrian has stated above. Finally, it seems like there are
> too many focuses for development at the moment (between trying to
> improve gating to allow for multiple supported distributions by default,
> eliminating the hard reliance on barbican, creating a versioned and
> stable API, and other efforts) for the API design to be done well and
> documented well. Frankly, I think the magnum team should be focusing on
> 1 thing as their top priority right now and have a secondary priority.
> What those priorities are, is up to the community, but I don't think
> this should be one of those priorities as someone watching the
> community to evaluate it's direction and the potential future of Magnum
> inside a product.

I think we are debating the long-term direction of the project (not the 
short-term priorities of individual tasks). The decision will have an impact on 
the scope of Magnum (to be a COE deployment tool or a container lifecycle 
management service). Maybe your suggestion is not to make such decision in 
short term? If yes, could you elaborate?

> 
> --
> Ian Cordasco
> 
> 
> ___
> ___
> 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

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Ian Cordasco]

-Original Message-
From: Adrian Otto <adrian.o...@rackspace.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: April 19, 2016 at 19:11:07
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [magnum][app-catalog][all] Build unified  
abstraction for all COEs

> This pursuit is a trap. Magnum should focus on making native container APIs 
> available.  
> We should not wrap APIs with leaky abstractions. The lowest common 
> denominator of all  
> COEs is an remarkably low value API that adds considerable complexity to 
> Magnum that  
> will not strategically advance OpenStack. If we instead focus our effort on 
> making the  
> COEs work better on OpenStack, that would be a winning strategy. Support and 
> compliment  
> our various COE ecosystems.

I'm not nearly as familiar with each COE's API as I'm sure some of you are, but 
knowing the present quality of Magnum's documentation, the fact that it's API 
is not being documented well, and how thinly stretched most of Magnum's 
developers already seem to be, I think that not doing this now (or in the near 
term is a better option). First, all of the COEs magnum supports have excellent 
documentation around their API and clients. Magnum does not have that at 
present and would need to work on that for this effort to be worthwhile to 
Magnum's users. Second of all, what little I do know about each COE's API 
reinforces (in my opinion) what Adrian has stated above. Finally, it seems like 
there are too many focuses for development at the moment (between trying to 
improve gating to allow for multiple supported distributions by default, 
eliminating the hard reliance on barbican, creating a versioned and stable API, 
and other efforts) for the API design to be done well and documented well. 
Frankly, I think the magnum team should be focusing on 1 thing as their top 
priority right now and have a secondary priority. What those priorities are, is 
up to the community, but I don't think this should be one of those priorities 
as someone watching the community to evaluate it's direction and the potential 
future of Magnum inside a product.

--  
Ian Cordasco


__
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][app-catalog][all] Build unified abstraction for all COEs

[Fox, Kevin M]

So, location of unified api is an interesting topic... Can things be arranged 
in such a way that the abstraction largely exists only on the client in its own 
project?

So, what about a change of ideas

The three pain points in the abstraction are:
 * Authentication
 * Connectivity
 * Differences in COE features/api that need abstracting.

Authentication issues: All OpenStack services use the same creds. Its painful 
if you ever have to use another set. How does a client ask Magnum for creds for 
a COE if it doesn't have some. Its painful if doesn't use keystone tokens. 
Three ways to solve this... 1, add keystone auth support to the COEs and have 
Magnum always configure it. 2, Proxy the COE api through Magnum's api, and deal 
with authentication on the Magnum side using Keystone. 3, Have some kind of way 
to provision users/creds in each of the COE's and have a way to fetch the creds 
easily via Magnum's api.

Connectivity issues: The cloud ops ensure Magnum/Keystone/etc's apis are 
available. The COE's api is potentially in a tenant or private network, where 
it can be difficult to know how to get to properly. If you have two COE's in 
two different tenants both using 10.0.0.0/24 you may run into issues keeping 
them apart. So I can see two potential ways forward here. Again, proxying the 
native COE api requests through Magnum could solve the issue. The other would 
be mandating every COE have a floating ip, though I think there still are 
issues there with clouds with multiple external networks and connectivity (I 
have a cloud with multiple external networks, so I know they are real :)

So, what do folks think about a proxy? I think all three COE API's are rest 
based? If so, they could be grafted into magum api, something like 
/v1/coeproxy//.

A unified client could then use keystone auth and the magnum api to talk to the 
COE, and then all the rest of the Abstraction nasties are all Features/API 
differences and totally on the client to figure out. This can be a non Magnum 
project if its too distasteful.

Thanks,
Kevin




From: Keith Bray [keith.b...@rackspace.com]
Sent: Tuesday, April 19, 2016 10:12 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified 
abstraction for all COEs

Sure… I can clarify with a few additional thoughts:

.1) I wouldn’t recommend that it be required for the operator to offer
this API. Representing a view of both providing managed services for
private cloud customer-on-premise installations of upstream OpenStack and
as a business owner with responsibility to operate Magnum for internal
usage within my own employer, I would prefer not to have to operate and
service a unified abstraction API that obfuscates all the benefit of
choice of the native COEs, which is the choice being provided to the end
user who is specifically selecting one COE over another when they
instantiate a bay (unless they pick the “Default” operator choice).  Maybe
a unified abstraction API is a separate project?  OpenStack services get
complicated very quickly and try to do too much.  At a minimum, I would
recommend it be an optional API, not required, and any overhead of
database or other necessary service components should be minimized to not
impact operators who do not want to offer it because it negates the point
of COE choice.  My ideal state is it would be a separate project entirely.

.2) I’d like for folks who want the lowest common denominator API to chime
in with why they want it, and whether they need it to be part of Magnum or
not. I don’t intend to argue with folks who want it… I assume their
reasons are justified, but I would want to find out why it needs to be
part of the Magnum API. Offering choice in COEs and then getting out of
the way (which I believe Magnum should do) is at odds with abstracting the
differentiation of the CEO choice via a unified API.  If there aren’t good
arguments for the "why a unified API needs to be integrated in Magnum",
then have it be separate from a code perspective and not required for
running the Magnum service.  When we talk about APIs and whether a service
is supported by one vendor or another, it is generally easiest to think
about the entire API; The API is either supported in its entirety or the
service isn’t compatible with OpenStack.  If some folks believe a lowest
common denominator API should exist, but there aren’t compelling arguments
for why it must be a required part of the Magnum API then we should
probably consider them as separate projects.  At this point, I am not
compelled to be in favor of integrating a unified API in Magnum when doing
so is a fundamentally different direction than the route Magnum has been
headed down which.  By offering choice of COE, and trying not to get in
the way of that, Magnum provides relevant choice of platform to a very
rapidly changing technology landscape.

Thank you 

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Thierry Carrez]

Adrian Otto wrote:

This pursuit is a trap. Magnum should focus on making native container APIs 
available. We should not wrap APIs with leaky abstractions. The lowest common 
denominator of all COEs is an remarkably low value API that adds considerable 
complexity to Magnum that will not strategically advance OpenStack. If we 
instead focus our effort on making the COEs work better on OpenStack, that 
would be a winning strategy. Support and compliment our various COE ecosystems.


I'm with Adrian on that one. I've attended a lot of container-oriented 
conferences over the past year and my main takeaway is that this new 
crowd of potential users is not interested (at all) in an 
OpenStack-specific lowest common denominator API for COEs. They want to 
take advantage of the cool features in Kubernetes API or the versatility 
of Mesos. They want to avoid caring about the infrastructure provider 
bit (and not deploy Mesos or Kubernetes themselves).


Let's focus on the infrastructure provider bit -- that is what we do and 
what the ecosystem wants us to provide.


--
Thierry Carrez (ttx)

__
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][app-catalog][all] Build unified abstraction for all COEs

[Keith Bray]

Sure… I can clarify with a few additional thoughts:

.1) I wouldn’t recommend that it be required for the operator to offer
this API. Representing a view of both providing managed services for
private cloud customer-on-premise installations of upstream OpenStack and
as a business owner with responsibility to operate Magnum for internal
usage within my own employer, I would prefer not to have to operate and
service a unified abstraction API that obfuscates all the benefit of
choice of the native COEs, which is the choice being provided to the end
user who is specifically selecting one COE over another when they
instantiate a bay (unless they pick the “Default” operator choice).  Maybe
a unified abstraction API is a separate project?  OpenStack services get
complicated very quickly and try to do too much.  At a minimum, I would
recommend it be an optional API, not required, and any overhead of
database or other necessary service components should be minimized to not
impact operators who do not want to offer it because it negates the point
of COE choice.  My ideal state is it would be a separate project entirely.

.2) I’d like for folks who want the lowest common denominator API to chime
in with why they want it, and whether they need it to be part of Magnum or
not. I don’t intend to argue with folks who want it… I assume their
reasons are justified, but I would want to find out why it needs to be
part of the Magnum API. Offering choice in COEs and then getting out of
the way (which I believe Magnum should do) is at odds with abstracting the
differentiation of the CEO choice via a unified API.  If there aren’t good
arguments for the "why a unified API needs to be integrated in Magnum",
then have it be separate from a code perspective and not required for
running the Magnum service.  When we talk about APIs and whether a service
is supported by one vendor or another, it is generally easiest to think
about the entire API; The API is either supported in its entirety or the
service isn’t compatible with OpenStack.  If some folks believe a lowest
common denominator API should exist, but there aren’t compelling arguments
for why it must be a required part of the Magnum API then we should
probably consider them as separate projects.  At this point, I am not
compelled to be in favor of integrating a unified API in Magnum when doing
so is a fundamentally different direction than the route Magnum has been
headed down which.  By offering choice of COE, and trying not to get in
the way of that, Magnum provides relevant choice of platform to a very
rapidly changing technology landscape.

Thank you for asking for clarification.  I’d really like to hear thoughts
from anyone who wants the unified API as to why it would need to be part
of Magnum, especially when doing so means chasing rapidly changing
technologies (hard to keep up with continued abstraction) and not offering
the deep value of their differentiation.

Kind regards,
-Keith



On 4/19/16, 8:58 PM, "Hongbin Lu" <hongbin...@huawei.com> wrote:

>I am going to clarify one thing. Users will always have access to native
>APIs provided by individual COEs, regardless of the existence of the
>common abstraction. In other words, the proposed common abstraction layer
>is an addition, not a replacement.
>
>Best regards,
>Hongbin
>
>> -Original Message-
>> From: Keith Bray [mailto:keith.b...@rackspace.com]
>> Sent: April-19-16 7:17 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
>> abstraction for all COEs
>> 
>> I would recommend against implementing a lowest common denominator API
>> for
>> the COEs ³right now.²   It¹s too early to tell if the COEs are going to
>> be
>> seen as a commodity (where in the long run they may all perform
>> relatively equal for the majority of workloads < in which case why do
>> you care to have choice in COE?), or continue to be
>> specialized/differentiated.  If you assume having choice to provision
>> more than one COE using the same system is valuable, then it is logical
>> that users value the differentiation in the COEs in some way. If they
>> are differentiated, and you value that, then you likely want to avoid
>> the lowest-common-demonitator API because that abstracts you from the
>> differentiation that you value.
>> 
>> Kind regards,
>> -Keith
>> 
>> 
>> 
>> On 4/19/16, 10:18 AM, "Hongbin Lu" <hongbin...@huawei.com> wrote:
>> 
>> >Sorry, it is too late to adjust the schedule now, but I don't mind to
>> >have a pre-discussion here. If you have opinions/ideas on this topic
>> >but cannot attend the session [1], we'd like to have you inputs in
>> this
&g

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Hongbin Lu]

I am going to clarify one thing. Users will always have access to native APIs 
provided by individual COEs, regardless of the existence of the common 
abstraction. In other words, the proposed common abstraction layer is an 
addition, not a replacement.

Best regards,
Hongbin

> -Original Message-
> From: Keith Bray [mailto:keith.b...@rackspace.com]
> Sent: April-19-16 7:17 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> abstraction for all COEs
> 
> I would recommend against implementing a lowest common denominator API
> for
> the COEs ³right now.²   It¹s too early to tell if the COEs are going to
> be
> seen as a commodity (where in the long run they may all perform
> relatively equal for the majority of workloads < in which case why do
> you care to have choice in COE?), or continue to be
> specialized/differentiated.  If you assume having choice to provision
> more than one COE using the same system is valuable, then it is logical
> that users value the differentiation in the COEs in some way. If they
> are differentiated, and you value that, then you likely want to avoid
> the lowest-common-demonitator API because that abstracts you from the
> differentiation that you value.
> 
> Kind regards,
> -Keith
> 
> 
> 
> On 4/19/16, 10:18 AM, "Hongbin Lu" <hongbin...@huawei.com> wrote:
> 
> >Sorry, it is too late to adjust the schedule now, but I don't mind to
> >have a pre-discussion here. If you have opinions/ideas on this topic
> >but cannot attend the session [1], we'd like to have you inputs in
> this
> >ML or in the etherpad [2]. This will help to set the stage for the
> session.
> >
> >For background, Magnum supports provisioning Container Orchestration
> >Engines (COEs), including Kubernetes, Docker Swarm and Apache Mesos,
> on
> >top of Nova instances. After the provisioning, users need to use the
> >native COE APIs to manage containers (and/or other COE resources). In
> >the Austin summit, we will have a session to discuss if it makes sense
> >to build a common abstraction layer for the supported COEs. If you
> >think it is a good idea, it would be great to elaborate the details.
> >For example, answering the following questions could be useful:
> >* Which abstraction(s) you are looking for (i.e. container, pod)?
> >* What are your use cases for the abstraction(s)?
> >* How the native APIs provided by individual COEs doesn't satisfy your
> >requirements?
> >
> >If you think it is a bad idea, I would love to hear your inputs as
> well:
> >* Why it is bad?
> >* If there is no common abstraction, how to address the pain of
> >leveraging native COE APIs as reported below?
> >
> >[1]
> >https://www.openstack.org/summit/austin-2016/summit-
> schedule/events/910
> >2 [2]
> >https://etherpad.openstack.org/p/newton-magnum-unified-abstraction
> >
> >Best regards,
> >Hongbin
> >
> >> -Original Message-
> >> From: Fox, Kevin M [mailto:kevin@pnnl.gov]
> >> Sent: April-18-16 6:13 PM
> >> To: OpenStack Development Mailing List (not for usage questions);
> >> Flavio Percoco
> >> Cc: foundat...@lists.openstack.org
> >> Subject: Re: [openstack-dev] [OpenStack Foundation] [board][tc][all]
> >> One Platform - Containers/Bare Metal? (Re: Board of Directors
> >> Meeting)
> >>
> >> I'd love to attend, but this is right on top of the app catalog
> meeting.
> >> I think the app catalog might be one of the primary users of a cross
> >> COE api.
> >>
> >> At minimum we'd like to be able to be able to store url's for
> >> Kubernetes/Swarm/Mesos templates and have an api to kick off a
> >> workflow in Horizon to have Magnum start up a new instance of of the
> >> template the user selected.
> >>
> >> Thanks,
> >> Kevin
> >> 
> >> From: Hongbin Lu [hongbin...@huawei.com]
> >> Sent: Monday, April 18, 2016 2:09 PM
> >> To: Flavio Percoco; OpenStack Development Mailing List (not for
> usage
> >> questions)
> >> Cc: foundat...@lists.openstack.org
> >> Subject: Re: [openstack-dev] [OpenStack Foundation] [board][tc][all]
> >> One Platform - Containers/Bare Metal? (Re: Board of Directors
> >> Meeting)
> >>
> >> Hi all,
> >>
> >> Magnum will have a fishbowl session to discuss if it makes sense to
> >> build a common abstraction layer for all COEs (kubernetes, docker
&

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Adrian Otto]

This pursuit is a trap. Magnum should focus on making native container APIs 
available. We should not wrap APIs with leaky abstractions. The lowest common 
denominator of all COEs is an remarkably low value API that adds considerable 
complexity to Magnum that will not strategically advance OpenStack. If we 
instead focus our effort on making the COEs work better on OpenStack, that 
would be a winning strategy. Support and compliment our various COE ecosystems.

Thanks,

Adrian

> On Apr 19, 2016, at 8:26 AM, Hongbin Lu  wrote:
> 
> Sorry, it is too late to adjust the schedule now, but I don't mind to have a 
> pre-discussion here. If you have opinions/ideas on this topic but cannot 
> attend the session [1], we'd like to have you inputs in this ML or in the 
> etherpad [2]. This will help to set the stage for the session.
> 
> For background, Magnum supports provisioning Container Orchestration Engines 
> (COEs), including Kubernetes, Docker Swarm and Apache Mesos, on top of Nova 
> instances. After the provisioning, users need to use the native COE APIs to 
> manage containers (and/or other COE resources). In the Austin summit, we will 
> have a session to discuss if it makes sense to build a common abstraction 
> layer for the supported COEs. If you think it is a good idea, it would be 
> great to elaborate the details. For example, answering the following 
> questions could be useful:
> * Which abstraction(s) you are looking for (i.e. container, pod)?
> * What are your use cases for the abstraction(s)?
> * How the native APIs provided by individual COEs doesn't satisfy your 
> requirements?
> 
> If you think it is a bad idea, I would love to hear your inputs as well:
> * Why it is bad?
> * If there is no common abstraction, how to address the pain of leveraging 
> native COE APIs as reported below?
> 
> [1] https://www.openstack.org/summit/austin-2016/summit-schedule/events/9102 
> [2] https://etherpad.openstack.org/p/newton-magnum-unified-abstraction
> 
> Best regards,
> Hongbin
> 
>> -Original Message-
>> From: Fox, Kevin M [mailto:kevin@pnnl.gov]
>> Sent: April-18-16 6:13 PM
>> To: OpenStack Development Mailing List (not for usage questions);
>> Flavio Percoco
>> Cc: foundat...@lists.openstack.org
>> Subject: Re: [openstack-dev] [OpenStack Foundation] [board][tc][all]
>> One Platform - Containers/Bare Metal? (Re: Board of Directors Meeting)
>> 
>> I'd love to attend, but this is right on top of the app catalog meeting.
>> I think the app catalog might be one of the primary users of a cross
>> COE api.
>> 
>> At minimum we'd like to be able to be able to store url's for
>> Kubernetes/Swarm/Mesos templates and have an api to kick off a workflow
>> in Horizon to have Magnum start up a new instance of of the template
>> the user selected.
>> 
>> Thanks,
>> Kevin
>> 
>> From: Hongbin Lu [hongbin...@huawei.com]
>> Sent: Monday, April 18, 2016 2:09 PM
>> To: Flavio Percoco; OpenStack Development Mailing List (not for usage
>> questions)
>> Cc: foundat...@lists.openstack.org
>> Subject: Re: [openstack-dev] [OpenStack Foundation] [board][tc][all]
>> One Platform - Containers/Bare Metal? (Re: Board of Directors Meeting)
>> 
>> Hi all,
>> 
>> Magnum will have a fishbowl session to discuss if it makes sense to
>> build a common abstraction layer for all COEs (kubernetes, docker swarm
>> and mesos):
>> 
>> https://www.openstack.org/summit/austin-2016/summit-
>> schedule/events/9102
>> 
>> Frankly, this is a controversial topic since I heard agreements and
>> disagreements from different people. It would be great if all of you
>> can join the session and share your opinions and use cases. I wish we
>> will have a productive discussion.
>> 
>> Best regards,
>> Hongbin
>> 
>>> -Original Message-
>>> From: Flavio Percoco [mailto:fla...@redhat.com]
>>> Sent: April-12-16 8:40 AM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Cc: foundat...@lists.openstack.org
>>> Subject: Re: [openstack-dev] [OpenStack Foundation] [board][tc][all]
>>> One Platform - Containers/Bare Metal? (Re: Board of Directors Meeting)
>>> 
 On 11/04/16 16:53 +, Adrian Otto wrote:
 Amrith,
 
 I respect your point of view, and agree that the idea of a common
 compute API is attractive... until you think a bit deeper about what
>>> that
 would mean. We seriously considered a "global" compute API at the
 time we were first contemplating Magnum. However, what we came to
 learn through the journey of understanding the details of how such a
 thing would be implemented, that such an API would either be (1) the
 lowest common denominator (LCD) of all compute types, or (2) an
 exceedingly
>>> complex interface.
 
 You expressed a sentiment below that trying to offer choices for VM,
 Bare Metal (BM), and Containers for Trove instances "adds
 considerable
>>> complexity".
 Roughly the 

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

[Keith Bray]

I would recommend against implementing a lowest common denominator API for
the COEs ³right now.²   It¹s too early to tell if the COEs are going to be
seen as a commodity (where in the long run they may all perform relatively
equal for the majority of workloads ‹ in which case why do you care to
have choice in COE?), or continue to be specialized/differentiated.  If
you assume having choice to provision more than one COE using the same
system is valuable, then it is logical that users value the
differentiation in the COEs in some way. If they are differentiated, and
you value that, then you likely want to avoid the
lowest-common-demonitator API because that abstracts you from the
differentiation that you value.

Kind regards,
-Keith



On 4/19/16, 10:18 AM, "Hongbin Lu"  wrote:

>Sorry, it is too late to adjust the schedule now, but I don't mind to
>have a pre-discussion here. If you have opinions/ideas on this topic but
>cannot attend the session [1], we'd like to have you inputs in this ML or
>in the etherpad [2]. This will help to set the stage for the session.
>
>For background, Magnum supports provisioning Container Orchestration
>Engines (COEs), including Kubernetes, Docker Swarm and Apache Mesos, on
>top of Nova instances. After the provisioning, users need to use the
>native COE APIs to manage containers (and/or other COE resources). In the
>Austin summit, we will have a session to discuss if it makes sense to
>build a common abstraction layer for the supported COEs. If you think it
>is a good idea, it would be great to elaborate the details. For example,
>answering the following questions could be useful:
>* Which abstraction(s) you are looking for (i.e. container, pod)?
>* What are your use cases for the abstraction(s)?
>* How the native APIs provided by individual COEs doesn't satisfy your
>requirements?
>
>If you think it is a bad idea, I would love to hear your inputs as well:
>* Why it is bad?
>* If there is no common abstraction, how to address the pain of
>leveraging native COE APIs as reported below?
>
>[1] 
>https://www.openstack.org/summit/austin-2016/summit-schedule/events/9102
>[2] https://etherpad.openstack.org/p/newton-magnum-unified-abstraction
>
>Best regards,
>Hongbin
>
>> -Original Message-
>> From: Fox, Kevin M [mailto:kevin@pnnl.gov]
>> Sent: April-18-16 6:13 PM
>> To: OpenStack Development Mailing List (not for usage questions);
>> Flavio Percoco
>> Cc: foundat...@lists.openstack.org
>> Subject: Re: [openstack-dev] [OpenStack Foundation] [board][tc][all]
>> One Platform - Containers/Bare Metal? (Re: Board of Directors Meeting)
>> 
>> I'd love to attend, but this is right on top of the app catalog meeting.
>> I think the app catalog might be one of the primary users of a cross
>> COE api.
>> 
>> At minimum we'd like to be able to be able to store url's for
>> Kubernetes/Swarm/Mesos templates and have an api to kick off a workflow
>> in Horizon to have Magnum start up a new instance of of the template
>> the user selected.
>> 
>> Thanks,
>> Kevin
>> 
>> From: Hongbin Lu [hongbin...@huawei.com]
>> Sent: Monday, April 18, 2016 2:09 PM
>> To: Flavio Percoco; OpenStack Development Mailing List (not for usage
>> questions)
>> Cc: foundat...@lists.openstack.org
>> Subject: Re: [openstack-dev] [OpenStack Foundation] [board][tc][all]
>> One Platform - Containers/Bare Metal? (Re: Board of Directors Meeting)
>> 
>> Hi all,
>> 
>> Magnum will have a fishbowl session to discuss if it makes sense to
>> build a common abstraction layer for all COEs (kubernetes, docker swarm
>> and mesos):
>> 
>> https://www.openstack.org/summit/austin-2016/summit-
>> schedule/events/9102
>> 
>> Frankly, this is a controversial topic since I heard agreements and
>> disagreements from different people. It would be great if all of you
>> can join the session and share your opinions and use cases. I wish we
>> will have a productive discussion.
>> 
>> Best regards,
>> Hongbin
>> 
>> > -Original Message-
>> > From: Flavio Percoco [mailto:fla...@redhat.com]
>> > Sent: April-12-16 8:40 AM
>> > To: OpenStack Development Mailing List (not for usage questions)
>> > Cc: foundat...@lists.openstack.org
>> > Subject: Re: [openstack-dev] [OpenStack Foundation] [board][tc][all]
>> > One Platform - Containers/Bare Metal? (Re: Board of Directors Meeting)
>> >
>> > On 11/04/16 16:53 +, Adrian Otto wrote:
>> > >Amrith,
>> > >
>> > >I respect your point of view, and agree that the idea of a common
>> > >compute API is attractive... until you think a bit deeper about what
>> > that
>> > >would mean. We seriously considered a "global" compute API at the
>> > >time we were first contemplating Magnum. However, what we came to
>> > >learn through the journey of understanding the details of how such a
>> > >thing would be implemented, that such an API would either be (1) the
>> > >lowest common denominator (LCD) of all compute types, or (2) an
>> >