Re: [openstack-dev] [magnum] Seek advices for a licence issue

forward to your contribution. [1] https://blueprints.launchpad.net/magnum/+spec/mesos-dcos Best regards, Hongbin From: Jay Lau [mailto:jay.lau@gmail.com] Sent: April-24-16 6:47 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Seek advices

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

Hi Eli, Copy that, I will consider that. Thanks. Regards Mike Date: Thu, 28 Apr 2016 17:05:44 +0800 From: Eli Qiao <liyong.q...@intel.com<mailto:liyong.q...@intel.com>> To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org> Subject: Re: [open

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

To: "OpenStack Development Mailing List \(not for usage questions\)" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes Message-ID: <201604271004.u3ra49v4008...@d23av04.au.ibm.com> Con

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

List \(not for usage questions\)" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes Message-ID: <201604271004.u3ra49v4008...@d23av04.au.ibm.com> Content-Type: text/plain;

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

gt; Date: 27/04/2016 03:10 pm Subject:Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes Hi Hong bin, Thanks very much. It’s good suggestion, I think it is a good way by using labels for extra flavors. But I notice that there is not

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

rg> > Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to > provision minion nodes > > Hi Hongbin, Ricardo > This is mike, I am working with Gary now. > Thanks for Ricardo's good suggestion. I have tried the "map/index" > method , we can

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

> -Original Message- > From: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) [mailto:wentao...@hpe.com] > Sent: April-26-16 3:01 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to > provision minion nodes >

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

Gary, HPServers-Core-OE-PSC) > Sent: Monday, April 25, 2016 3:37 PM > To: OpenStack Development Mailing List (not for usage questions) > lists.openstack.org<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>> > Cc: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) hpe.com

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

ervers-Core-OE-PSC) Sent: Monday, April 25, 2016 3:37 PM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Cc: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) <wentao...@hpe.com> Subject: RE: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

Core-OE-PSC) Sent: Monday, April 25, 2016 3:37 PM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Cc: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) <wentao...@hpe.com> Subject: RE: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to prov

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

ent: Monday, April 25, 2016 3:37 PM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Cc: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) <wentao...@hpe.com> Subject: RE: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to prov

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes Hi Hongbin. On Wed, Apr 20, 2016 at 8:13 PM, Hongbin Lu <hongbin...@huawei.com> wrote: > > >

Re: [openstack-dev] [magnum] Seek advices for a licence issue

interest to > contribute? > > > > [1] https://blueprints.launchpad.net/magnum/+spec/mesos-dcos > > > > Best regards, > > Hongbin > > > > *From:* Jay Lau [mailto:jay.lau@gmail.com] > *Sent:* April-22-16 12:12 AM > *To:* OpenStack Development Mail

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

: [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

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

> -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 >

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

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

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

Re: [openstack-dev] [magnum] Seek advices for a licence issue

: April-22-16 12:12 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Seek advices for a licence issue I got confirmation from Mesosphere that we can use the open source DC/OS in Magnum now, it is a good time to enhance the Mesos Bay to Open

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

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

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

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

/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 f

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

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

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

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

Re: [openstack-dev] [magnum] Seek advices for a licence issue

I got confirmation from Mesosphere that we can use the open source DC/OS in Magnum now, it is a good time to enhance the Mesos Bay to Open Source DCOS. From Mesosphere DC/OS software is licensed under the Apache License, so you should feel free to use it within the

Re: [openstack-dev] [magnum] Link to the latest atomic image

@hongbin, FYI, there is a patch from yolanda to using fedora atomic images built in our mirros https://review.openstack.org/#/c/306283/ On 2016年04月22日 10:41, Hongbin Lu wrote: Hi team, Based on a request, I created a link to the latest atomic image that Magnum is using:

[openstack-dev] [magnum] Link to the latest atomic image

Hi team, Based on a request, I created a link to the latest atomic image that Magnum is using: https://fedorapeople.org/groups/magnum/fedora-atomic-latest.qcow2 . We plan to keep this link pointing to the newest atomic image so that we can avoid updating the name of the image for every image

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

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

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

+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

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

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

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

: [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

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

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

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

. 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

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

> 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

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

> -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]

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

__ >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

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

, 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

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

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

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

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

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

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

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

[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" <

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

: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

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

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

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

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

+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

Re: [openstack-dev] [magnum] High Availability

gt; Subject: Re: [openstack-dev] [magnum] High Availability > > Hi. > > The thread is a month old, but I sent a shorter version of this to > Daneyon before with some info on the things we dealt with to get Magnum > deployed successfully. We wrapped it up in a post (there's a vid

Re: [openstack-dev] [magnum] High Availability

; Barbican is best at, secure storage for our certificates that will allow >>>> multi-conductor operation. >>>> >>>> I am opposed to the idea that Magnum should re-implement Barbican for >>>> certificate storage just because operators are reluctant to ado

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

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

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.

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

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

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

> > >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

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

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

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

> -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

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

; 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 >> >>

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

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 &

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

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

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

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

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

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

it. Regards, Gary Duan From: Hongbin Lu [mailto:hongbin...@huawei.com] Sent: Thursday, April 21, 2016 2:13 AM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to pro

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

C)" <li-gong.d...@hpe.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 21/04/2016 02:31 pm Subject: Re: [openstack-dev] [Magnum] Magn

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

t for usage questions)" <openstack-dev@lists.openstack.org> Date: 21/04/2016 02:31 pm Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes Hi Eli, This is exactly what I want. If you guys think this requirement is reasonable, I’d

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

@lists.openstack.org Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes Kannan, I think Duan Li is talking about using both 2 kinds of (secure-booted and non-secure-booted) node deploy *minion* node. The scenario may like this: let say 2 flavors

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

driver as Nova hypervisor to implement it. Regards, Gary From: Kai Qiang Wu [mailto:wk...@cn.ibm.com] Sent: Wednesday, April 20, 2016 4:37 PM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Magnum] Magnum sup

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

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

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

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

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 &

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

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

+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

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.

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

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

[openstack-dev] [magnum] Seek advices for a licence issue

Hi Mark, I have went though the announcement in details, From my point of view, it seems to resolve the license issue that was blocking us in before. I have included the Magnum team in ML to see if our team members have any comment. Thanks for the support from foundation. Best regards,

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

estions) > Subject: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision > minion nodes > > > > Hi Folks, > > > > We are considering whether Magnum can supports 2 Nova flavors to provision > Kubernetes and other COE minion nodes. > > This requir

Re: [openstack-dev] [Magnum]Cache docker images

_e...@yahoo.com] > Sent: Tuesday, April 19, 2016 7:20 PM > To: OpenStack Development Mailing List (not for usage questions) > Cc: Fox, Kevin M > Subject: Re: [openstack-dev] [Magnum]Cache docker images > > Kevin, > > I agree this is not ideal solution, but it's probably t

Re: [openstack-dev] [Magnum]Cache docker images

From: Adrian Otto [mailto:adrian.o...@rackspace.com] Sent: April-20-16 9:39 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Magnum]Cache docker images Hongbin, Both of approaches you suggested may only work for one binary format. If you try

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

> -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

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

. Thanks, Kevin From: Hongbin Lu [hongbin...@huawei.com] Sent: Wednesday, April 20, 2016 11:13 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes From: Duan

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) [mailto:li-gong.d...@hpe.com] Sent: April-20-16 3:39 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes Hi Folks, We are considering

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

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

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

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

Re: [openstack-dev] [Magnum]Cache docker images

To: OpenStack Development Mailing List (not for usage questions) Cc: Fox, Kevin M Subject: Re: [openstack-dev] [Magnum]Cache docker images Kevin, I agree this is not ideal solution, but it's probably the best option to deal with public cloud "stability" (e.g. we switched to the same mo

Re: [openstack-dev] [Magnum]Cache docker images

ct: Re: [openstack-dev] [Magnum]Cache docker images hi hello again I believe you are talking about this bp https://blueprints.launchpad.net/magnum/+spec/cache-docker-images then ignore my previous reply, that may another topic to solve network limited problem. I think you are on the right w

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

Kannan, I think Duan Li is talking about using both 2 kinds of (secure-booted and non-secure-booted) node deploy *minion* node. The scenario may like this: let say 2 flavors: * flavor_secure * flavor_none_secure For now, flavor-id in baymodel can only be set as one value, Duan Li's

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

<li-gong.d...@hpe.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 20/04/2016 03:46 pm Subject:[openstack-dev] [Magnum] Magnum supports 2 Nova flavor to pro

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

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

[openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

Hi Folks, We are considering whether Magnum can supports 2 Nova flavors to provision Kubernetes and other COE minion nodes. This requirement comes from the below use cases: - There are 2 kind of baremetal machines in customer site: one is legacy machines which doesn't support UEFI

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

>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

Re: [openstack-dev] [Magnum]Cache docker images

guarantee "fresh" image, it uses  force pull option in Marathon. --- Egor From: "Fox, Kevin M" <kevin@pnnl.gov> To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Sent: Tuesday, April 19, 2016 1:04 PM

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

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

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

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

Re: [openstack-dev] [Magnum]Cache docker images

To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Magnum]Cache docker images Eli, The approach of pre-pulling docker images has a problem. It only works for specific docker storage driver. In comparison, the tar file approach is portable across different

Re: [openstack-dev] [Magnum]Cache docker images

: Hongbin Lu [hongbin...@huawei.com] Sent: Tuesday, April 19, 2016 11:50 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Magnum]Cache docker images Yes, that is an alternative. The complication is how to secure the communication between Magnum bays

Re: [openstack-dev] [Magnum]Cache docker images

To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Magnum]Cache docker images hi hello again I believe you are talking about this bp https://blueprints.launchpad.net/magnum/+spec/cache-docker-images then ignore my previous reply, that may another topic to solve network limited problem

Re: [openstack-dev] [Magnum]Cache docker images

] Sent: April-19-16 1:12 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Magnum]Cache docker images why not just allow a prefix to be added to the container name? you can then have a container named: foo/mycontainer and the prefix could be set

Re: [openstack-dev] [magnum][kuryr] Shared session in design summit

rch-30-16 10:36 AM > > *To:* OpenStack Development Mailing List (not for usage questions); > > Antoni Segura Puimedon; Fawad Khaliq; Mohammad Banikazemi; Taku Fukushima; > > Irena Berezovsky; Mike Spreitzer > > *Subject:* Re: [openstack-dev] [magnum][kuryr] Shared session in d

Re: [openstack-dev] [Magnum]Cache docker images

: [openstack-dev] [Magnum]Cache docker images Hi all, We want to eliminate pulling docker images over the Internet on bay provisioning. There are two problems of this approach: 1. Pulling docker images over the Internet is slow and fragile. 2. Some clouds don't have external Internet access

Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay

Sent: Friday, March 25, 2016 7:01 PM Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay Yes, that's exactly what I want to do, adding dcos cli and also add Chronos to Mesos Bay to make it can handle both long running services and batch jobs. Thanks, On Fri, Mar 25, 2016 at 5:2

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

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

Re: [openstack-dev] [Magnum] duplicate scripts in different coes

I made a first attempt to factor out the configuration of different storage drivers in this change [1]. Spyros [1] https://review.openstack.org/#/c/284720/ On 19 April 2016 at 05:45, Eli Qiao wrote: > Sure that is the things I want to cleanup long time before. > I

Re: [openstack-dev] [Magnum]Cache docker images

hi hello again I believe you are talking about this bp https://blueprints.launchpad.net/magnum/+spec/cache-docker-images then ignore my previous reply, that may another topic to solve network limited problem. I think you are on the right way to build docker images but this image could only

<    1   2   3   4   5   6   7   8   9   10   >