: [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
> -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
>
...@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
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
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
ists.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 a
hat 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 int
stions)
> 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 q
eith.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
>
&g
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
nty 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
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
ment 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 L
ent: 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 dis
.
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, Fo
> 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
t 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
&g
__
>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
,
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
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 M
ors.
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
a
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
[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" <
: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:
>>
>> T
h.
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
> -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
> > abstr
+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
ons)
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 API
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.
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
>
>
>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 Mailin
)
>> 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:
>&
> -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 COE
; 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
>>
>>
, 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 Mag
> -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
&
> 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
ith.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
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
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
> -Origi
nt 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
> -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
&
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
][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
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.
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
> -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
> abs
t;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 c
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
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
>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)
>> Subj
nal 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 recomm
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
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
54 matches
Mail list logo