Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

From: Adrian Otto [mailto:adrian.o...@rackspace.com] Sent: March-01-16 9:54 AM To: Guz Egor Cc: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro This issue involves what I refer to as &qu

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

space.com<mailto:adrian.o...@rackspace.com>> To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Sent: Monday, February 29, 2016 10:36 AM Subject: Re: [openstack-dev] [magnum] Discussion of s

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

<sgor...@redhat.com> > To: Guz Egor <guz_e...@yahoo.com>, "OpenStack Development Mailing > List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Cc: Josh Berkus <jber...@redhat.com> > Date: 01/03/2016 08:19 pm > Subject:

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

e questions)" <openstack-dev@lists.openstack.org> Cc: Martin Andre <maan...@redhat.com>, Josh Berkus <jber...@redhat.com> Date: 01/03/2016 08:25 pm Subject: Re: [openstack-dev] [magnum]Discussion of supporting single/multiple O

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

om> Date: 01/03/2016 08:19 pm Subject: Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro - Original Message - > From: "Guz Egor" <guz_e...@yahoo.com> > To: "OpenStack Development Mailing List (not for usa

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

penStack deployments) and CoreOS (is > > highly adopted/tested in Kub community and Mesosphere DCOS uses it as > > well). > > We can implement CoreOS support as driver and users can use it as > > reference > > implementation. > > > > --- Egor >

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

es it as well). >  We can implement CoreOS support as driver and users can use it as reference > implementation. > --- Egor > From: Adrian Otto <adrian.o...@rackspace.com> > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lis

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

Subject: Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro Consider this: Which OS runs on the bay nodes is not important to end users. What matters to users is the environments their containers execute in, which has only one thing in common with the bay node OS

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

g List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 02/29/2016 06:30 PM Subject:Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro I think users need the support for multiple OS choices. Users may w

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

I think users need the support for multiple OS choices. Users may want to modify the OS by themselves to meet the requirement of their business. If Magnum only supports a single OS distro, we should have a convenient way to change one OS distro to another. But the OSes are so different, the work

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

From: Adrian Otto [mailto:adrian.o...@rackspace.com] Sent: February-29-16 1:36 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro Consider this: Which OS runs on the bay nodes

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

From: Adrian Otto Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Monday 29 February 2016 at 19:36 To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [magnum] Discussion of supporting single

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

Consider this: Which OS runs on the bay nodes is not important to end users. What matters to users is the environments their containers execute in, which has only one thing in common with the bay node OS: the kernel. The linux syscall interface is stable enough that the various linux

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro Hi team, This is a continued discussion from a revi

[openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

Hi team, This is a continued discussion from a review [1]. Corey O'Brien suggested to have Magnum support a single OS distro (Atomic). I disagreed. I think we should bring the discussion to here to get broader set of inputs. Corey O'Brien >From the midcycle, we decided we weren't going to

Re: [openstack-dev] [Magnum][Kuryr] Kuryr-Magnum integration (nested containers)

Folks, A friendly reminder to review the updated spec [1] https://review.openstack.org/#/c/269039/ Thank you, Fawad Khaliq On Wed, Feb 24, 2016 at 8:50 PM, Fawad Khaliq wrote: > Folks, > > Thanks for the reviews. The spec [1] has been updated after the latest > feedback.

Re: [openstack-dev] [Magnum] API service won't work if conductor down?

an atomic unit. >>>> >>>> >>>> >>>> I think we should make our own decision here. If we can pair magnum-api >>>> with magnum-conductor as a unit, we can remove the indirection API and >>>> allow both binaries to access DB. This

Re: [openstack-dev] [Magnum] API service won't work if conductor down?

unit, we can remove the indirection API and >>> allow both binaries to access DB. This could mitigate the potential >>> performance bottleneck of message queue. On the other hand, if we stay with >>> the current design, we would allow magnum-api and magnum-conductor to scale

Re: [openstack-dev] [Magnum] API service won't work if conductor down?

[openstack-dev] [Magnum] API service won't work if >> conductor down? >> >> >> >> Corey the one you are talking about has changed to coe-service-*. >> >> >> >> Eli, IMO we should display proper error message. M-api service should >&g

Re: [openstack-dev] [magnum] Failed to create trustee %(username) in domain $(domain_id)

regards, Hongbin From: Kai Qiang Wu [mailto:wk...@cn.ibm.com] Sent: February-25-16 8:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Failed to create trustee %(username) in domain $(domain_id) Thanks Hongbin for your info. I really

Re: [openstack-dev] [magnum] Failed to create trustee %(username) in domain $(domain_id)

hi, I am not sure Magnum need to introduce reno, which will help user/developer to understand what new feature magnum has recently. I see HouMing Wang already registered a blueprint to add reno(I just registered a new one, after that I found it's registered already, great) I think it's good to

Re: [openstack-dev] [magnum] Failed to create trustee %(username) in domain $(domain_id)

..@huawei.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 26/02/2016 08:02 am Subject:[openstack-dev] [magnum] Failed to create trustee %(username) in domain $(domain_id) Hi team, FYI, y

[openstack-dev] [magnum] Failed to create trustee %(username) in domain $(domain_id)

Hi team, FYI, you might encounter the following error if you pull from master recently: magnum bay-create --name swarmbay --baymodel swarmbaymodel --node-count 1 Create for bay swarmbay failed: Failed to create trustee %(username) in domain $(domain_id) (HTTP 500)" This is due to a recent

Re: [openstack-dev] [Magnum][Kuryr] Kuryr-Magnum integration (nested containers)

Folks, Thanks for the reviews. The spec [1] has been updated after the latest feedback. [1] https://review.openstack.org/#/c/269039/ Thanks, Fawad Khaliq On Mon, Feb 22, 2016 at 11:58 PM, Fawad Khaliq wrote: > Hi folks, > > The spec [1] for Mangum-Kuryr integration is

Re: [openstack-dev] [magnum] containers across availability zones

Ricardo, The blueprint is approved, thanks! Adrian > On Feb 24, 2016, at 2:53 PM, Ricardo Rocha wrote: > > Thanks, done. > > https://blueprints.launchpad.net/magnum/+spec/magnum-availability-zones > > We might have something already to expose the labels in the docker

Re: [openstack-dev] [magnum] containers across availability zones

Thanks, done. https://blueprints.launchpad.net/magnum/+spec/magnum-availability-zones We might have something already to expose the labels in the docker daemon config. On Wed, Feb 24, 2016 at 6:01 PM, Vilobh Meshram wrote: > +1 from me too for the idea.

Re: [openstack-dev] [magnum] containers across availability zones

+1 from me too for the idea. Please file a blueprint. Seems feasible and useful. -Vilobh On Tue, Feb 23, 2016 at 7:25 PM, Adrian Otto wrote: > Ricardo, > > Yes, that approach would work. I don’t see any harm in automatically > adding tags to the docker daemon on the

Re: [openstack-dev] [magnum] containers across availability zones

Ricardo, Yes, that approach would work. I don’t see any harm in automatically adding tags to the docker daemon on the bay nodes as part of the swarm heat template. That would allow the filter selection you described. Adrian > On Feb 23, 2016, at 4:11 PM, Ricardo Rocha

Re: [openstack-dev] [magnum] containers across availability zones

Hi Ricardo, +1 from me. I like this feature. Best regards, Hongbin -Original Message- From: Ricardo Rocha [mailto:rocha.po...@gmail.com] Sent: February-23-16 5:11 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [magnum] containers across

[openstack-dev] [magnum] containers across availability zones

Hi. Has anyone looked into having magnum bay nodes deployed in different availability zones? The goal would be to have multiple instances of a container running on nodes across multiple AZs. Looking at docker swarm this could be achieved using (for example) affinity filters based on labels.

[openstack-dev] [Magnum][Kuryr] Kuryr-Magnum integration (nested containers)

Hi folks, The spec [1] for Mangum-Kuryr integration is out and has already gone through good discussion and updates. Please take out some time to review, we would like to converge on the design soon. [1] https://review.openstack.org/#/c/269039/5 Thanks, Fawad Khaliq

Re: [openstack-dev] [magnum]swarm + compose = k8s?

se cases. Maybe magnum could support multiple modes? > > > > Best regards, > > Hongbin > > > > *From:* Corey O'Brien [mailto:coreypobr...@gmail.com] > *Sent:* February-15-16 8:43 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subjec

Re: [openstack-dev] [magnum]swarm + compose = k8s?

) Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s? Hi all, A few thoughts to add: I like the idea of isolating the masters so that they are not tenant-controllable, but I don't think the Magnum control plane is the right place for them. They still need to be running on tenant-owned

Re: [openstack-dev] [magnum] Re: Assistance with Magnum Setup

te one and give it a high priority. Best regards, Hongbin From: Steven Dake (stdake) [mailto:std...@cisco.com] Sent: February-14-16 10:54 AM To: Shiva Ramdeen Cc: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [magnum] Re: Assistance with Magnum Setup

Re: [openstack-dev] [magnum]swarm + compose = k8s?

-- > Hyper - Make VM run like Container > > > > On Mon, Feb 15, 2016 at 9:53 AM, Hongbin Lu <hongbin...@huawei.com> wrote: > >> My replies are inline. >> >> >> >> *From:* Kai Qiang Wu [mailto:wk...@cn.ibm.com] >

Re: [openstack-dev] [magnum]swarm + compose = k8s?

inline. From: Kai Qiang Wu [mailto: wk...@cn.ibm.com ] Sent: February-14-16 7:17 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s? HongBin, See my replies and questions in line. >> Thanks

Re: [openstack-dev] [magnum]swarm + compose = k8s?

uawei.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 15/02/2016 01:26 am Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s? Kai Qiang, A major benefit is to have Magnum manage the COEs for

Re: [openstack-dev] [magnum]swarm + compose = k8s?

(not for usage questions) Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s? Hi HongBin and Egor, I went through what you talked about, and thinking what's the great benefits for utilisation here. For user cases, looks like following: user A want to have a COE provision. user B want

[openstack-dev] [magnum] Re: Assistance with Magnum Setup

Shiva, First off, welcome to OpenStack :) Feel free to call me Steve. Ccing openstack-dev which is typically about development questions not usage questions, but you might have found some kind of bug. I am not sure what the state of Magnum and Keystone is with OpenStack. I recall at our

Re: [openstack-dev] [magnum] Re: Assistance with Magnum Setup

(not for usage questions) Subject: [openstack-dev] [magnum] Re: Assistance with Magnum Setup Shiva, First off, welcome to OpenStack :) Feel free to call me Steve. Ccing openstack-dev which is typically about development questions not usage questions, but you might have found some kind of bug. I am

Re: [openstack-dev] [magnum]swarm + compose = k8s?

lists.openstack.org> Date: 13/02/2016 11:02 am Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s? Egor, Thanks for sharing your insights. I gave it more thoughts. Maybe the goal can be achieved without implementing a shared COE. We could move all the master nodes out of use

Re: [openstack-dev] [Magnum] gate issues

* OpenStack Development Mailing List (not for usage questions) > > *Subject:* [openstack-dev] [Magnum] gate issues > > > > So as we're all aware, the gate is a mess right now. I wanted to sum up > some of the issues so we can figure out solutions. > > > > 1. The f

Re: [openstack-dev] [magnum]swarm + compose = k8s?

bin...@huawei.com> To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Sent: Thursday, February 11, 2016 8:50 PM Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s? Hi team,   Sorry for bringing up this old thread, but a recent

Re: [openstack-dev] [magnum]swarm + compose = k8s?

Best regards, Hongbin From: Guz Egor [mailto:guz_e...@yahoo.com] Sent: February-12-16 2:34 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Hongbin Lu Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s? Hongbin, I am not sure that it's good idea, it looks you

Re: [openstack-dev] [magnum][heat] Bug 1544227

On Thu, Feb 11, 2016 at 5:23 PM, Hongbin Lu wrote: > Rabi, > > As you observed, I have uploaded two testing patches [1][2] that depends on > your fix patch [3] and the reverted patch [4] respectively. An observation is > that the test "gate-functional-dsvm-magnum-mesos"

Re: [openstack-dev] [magnum][heat] Bug 1544227

[3] https://review.openstack.org/#/c/278576/ [4] https://review.openstack.org/#/c/278575/ Best regards, Hongbin -Original Message- From: Rabi Mishra [mailto:ramis...@redhat.com] Sent: February-11-16 12:46 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [ope

[openstack-dev] [magnum][heat] Bug 1544227

Hi Heat team, As mentioned in IRC, magnum gate broke with bug 1544227 . Rabi submitted on a fix (https://review.openstack.org/#/c/278576/), but it doesn't seem to be enough to unlock the broken gate. In particular, it seems templates with SoftwareDeploymentGroup resource failed to complete (I

Re: [openstack-dev] [magnum][heat] Bug 1544227

Hi, We did some analysis of the issue you are facing. One of the issues from heat side is, we convert None(singleton) resource references to 'None'(string) and the translation logic is not ignoring them. Though we don't apply translation rules to resource references[1].We don't see this issue

Re: [openstack-dev] [Magnum] gate issues

, since it is hard to work with a gate that takes several hours to complete. Thanks. Best regards, Hongbin From: Corey O'Brien [mailto:coreypobr...@gmail.com] Sent: February-05-16 12:04 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Magnum] gate issues

Re: [openstack-dev] [Magnum] Bug 1541105 options

Sorry for 1 day delay in response - busy prepping for Kolla midcycle next week. Responses inline. On 2/5/16, 12:14 PM, "Steve Gordon" wrote: >- Original Message - >> From: "Steven Dake (stdake)" >> To: "OpenStack Development Mailing List (not for

Re: [openstack-dev] [Magnum] gate issues

2:44 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Magnum] gate issues Corey, I think we should do more investigation before applying any "hot" patches. E.g. I look at several failures today and honestly there is no way to find out

Re: [openstack-dev] [Magnum] Bug 1541105 options

- Original Message - > From: "Steven Dake (stdake)" > To: "OpenStack Development Mailing List (not for usage questions)" > > > Steve, > > Comments inline > > On 2/3/16, 3:08 PM, "Steve Gordon" wrote: > >

Re: [openstack-dev] [Magnum] gate issues

t (not for usage questions) <openstack-dev@lists.openstack.org> Sent: Thursday, February 4, 2016 9:03 PM Subject: [openstack-dev] [Magnum] gate issues So as we're all aware, the gate is a mess right now. I wanted to sum up some of the issues so we can figure out solutions. 1.

[openstack-dev] [Magnum] gate issues

So as we're all aware, the gate is a mess right now. I wanted to sum up some of the issues so we can figure out solutions. 1. The functional-api job sometimes fails because bays timeout building after 1 hour. The logs look something like this:

Re: [openstack-dev] [Magnum] New Core Reviewers

e questions)" <openstack-dev@lists.openstack.org> Date: 02/02/2016 08:28 PM Subject: Re: [openstack-dev] [Magnum] New Core Reviewers Welcome Ton and Egor!! On Wed, Feb 3, 2016 at 12:04 AM, Adrian Otto <adrian.o...@rackspace.com> wrote: Thanks everyone

Re: [openstack-dev] [Magnum] API service won't work if conductor down?

The service-* commands aren't related to the magnum services (e.g. magnum-conductor). The service-* commands are for services on the bay that the user creates and deletes. Corey On Wed, Feb 3, 2016 at 2:25 AM Eli Qiao wrote: > hi > Whey I try to run magnum service-list

Re: [openstack-dev] [Magnum] API service won't work if conductor down?

(not for usage questions) Subject: Re: [openstack-dev] [Magnum] API service won't work if conductor down? Corey the one you are talking about has changed to coe-service-*. Eli, IMO we should display proper error message. M-api service should only have read permission. Regards, Madhuri From: Corey

Re: [openstack-dev] [Magnum] Bug 1541105 options

eve [1] https://git.fedorahosted.org/git/spin-kickstarts.git [2] https://git.fedorahosted.org/git/fedora-atomic.git > From: Corey O'Brien [mailto:coreypobr...@gmail.com] > Sent: February-03-16 2:53 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [opensta

Re: [openstack-dev] [Magnum] Bug 1541105 options

. Best regards, Hongbin From: Corey O'Brien [mailto:coreypobr...@gmail.com] Sent: February-03-16 2:53 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Magnum] Bug 1541105 options As long as configurations for 2.2 and 2.0 are compatible we shouldn't have

Re: [openstack-dev] [Magnum] Bug 1541105 options

n-kickstarts.git >[2] https://git.fedorahosted.org/git/fedora-atomic.git > > >> From: Corey O'Brien [mailto:coreypobr...@gmail.com] >> Sent: February-03-16 2:53 PM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [Magnum] B

[openstack-dev] [Magnum] Bug 1541105 options

Hey team, I've been looking into https://bugs.launchpad.net/magnum/+bug/1541105 which covers a bug with etcdctl, and I wanted opinions on how best to fix it. Should we update the image to include the latest version of etcd? Or, should we temporarily install the latest version as a part of

Re: [openstack-dev] [Magnum] Remove time costing case from gate-functional-dsvm-magnum-api

6 at 10:03 PM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: [openstack-dev] [Magnum] Remove time costing case from > gate-functional-dsvm-magnum-api > > hello > all, as you s

[openstack-dev] [Magnum] Remove time costing case from gate-functional-dsvm-magnum-api

hello all, as you see that[1], gate failed to merge patch though gate since gate-functional-dsvm-magnum-api will cause timeout error and make job failed. by investigate cases in gate-functional-dsvm-magnum-api, these 2 are time costing. 2016-02-03 22:25:42.834

Re: [openstack-dev] [Magnum] Remove time costing case from gate-functional-dsvm-magnum-api

sday, February 3, 2016 at 10:03 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [Magnum] Remove time costing case from gate-functional-dsvm-magnum-api hello al

Re: [openstack-dev] [Magnum] API service won't work if conductor down?

gt; *Sent:* February-03-16 10:57 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Magnum] API service won't work if > conductor down? > > > > Corey the one you are talking about has changed to coe-service-*. > > > &

Re: [openstack-dev] [Magnum] API service won't work if conductor down?

Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Magnum] API service won't work if conductor down? The service-* commands aren't related to the magnum services (e.g. magnum-conductor). The service-* commands are for services on t

Re: [openstack-dev] [Magnum] Bug 1541105 options

Hi Corey, This is slowing down our merge rate and needs to be fixed IMHO. What risk are you talking about when using newer version of etcd ? Is it documented somewhere for the team to have a look ? -Vilobh On Wed, Feb 3, 2016 at 8:11 AM, Corey O'Brien wrote: > Hey

Re: [openstack-dev] [Magnum] Bug 1541105 options

As long as configurations for 2.2 and 2.0 are compatible we shouldn't have an issue I wouldn't think. I just don't know enough about etcd deployment to be sure about that. If we want to quickly improve the gate, I can patch the problematic areas in the templates and then we can make a blueprint

Re: [openstack-dev] [Magnum] New Core Reviewers

Welcome Ton and Egor!! On Wed, Feb 3, 2016 at 12:04 AM, Adrian Otto wrote: > Thanks everyone for your votes. Welcome Ton and Egor to the core team! > > Regards, > > Adrian > > > On Feb 1, 2016, at 7:58 AM, Adrian Otto > wrote: > > > >

Re: [openstack-dev] [Magnum] New Core Reviewers

Thanks everyone for your votes. Welcome Ton and Egor to the core team! Regards, Adrian > On Feb 1, 2016, at 7:58 AM, Adrian Otto wrote: > > Magnum Core Team, > > I propose Ton Ngo (Tango) and Egor Guz (eghobo) as new Magnum Core Reviewers. > Please respond with

[openstack-dev] [Magnum] API service won't work if conductor down?

hi Whey I try to run magnum service-list to list all services (seems now we only have m-cond service), it m-cond is down(which means no conductor at all), API won't response and will return a timeout error. taget@taget-ThinkStation-P300:~/devstack$ magnum service-list ERROR: Timed out waiting

Re: [openstack-dev] [Magnum] New Core Reviewers

+1 from me for both. On Mon, Feb 1, 2016 at 10:00 AM, Gal Sagie wrote: > Not part of Magnum team, but Egor is a great help for Kuryr as well and is > a great addition in my eyes > > On Mon, Feb 1, 2016 at 7:00 PM, Davanum Srinivas > wrote: > >> +1 from

[openstack-dev] [Magnum] Kuryr-Magnm integration spec

Hi Magnum team, FYI, you might interest to review the Magnum integration spec from Kuryr team: https://review.openstack.org/#/c/269039/ Best regards, Hongbin From: Gal Sagie [mailto:gal.sa...@gmail.com] Sent: January-31-16 2:57 AM To: OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [Magnum] New Core Reviewers

<adrian.o...@rackspace.com> To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org> Date: 02/02/2016 12:01 am Subject: [openstack-dev] [Magnum] New Core Reviewers Magnum Core Team, I propose Ton Ngo (Tango) and Egor Guz (eghobo) as new

Re: [openstack-dev] [Magnum] New Core Reviewers

+1 +1 thanks for both harding reviewing. On 2016年02月01日 23:58, Adrian Otto wrote: Magnum Core Team, I propose Ton Ngo (Tango) and Egor Guz (eghobo) as new Magnum Core Reviewers. Please respond with your votes. Thanks, Adrian Otto

Re: [openstack-dev] [Magnum]Remove node object from Magnum

I think this is an excellent idea. I noticed this endpoint last week for the first time and was really confused about it. Since Heat is managing all the nodes, I agree Magnum shouldn't be tracking them. Corey On Mon, Feb 1, 2016 at 1:48 AM 王华 wrote: > Hi all, > > I

Re: [openstack-dev] [Magnum] New Core Reviewers

+1 from me! On Mon, Feb 1, 2016 at 9:58 AM, Adrian Otto wrote: > Magnum Core Team, > > I propose Ton Ngo (Tango) and Egor Guz (eghobo) as new Magnum Core Reviewers. > Please respond with your votes. > > Thanks, > > Adrian Otto >

Re: [openstack-dev] [Magnum] New Core Reviewers

+1+1 Well deserved! On 01/02/2016, 15:58, "Adrian Otto" wrote: >Magnum Core Team, > >I propose Ton Ngo (Tango) and Egor Guz (eghobo) as new Magnum Core Reviewers. >Please respond with your votes. > >Thanks, > >Adrian Otto

Re: [openstack-dev] [Magnum]Remove node object from Magnum

Agreed. > On Jan 31, 2016, at 10:46 PM, 王华 wrote: > > Hi all, > > I want to remove node object from Magnum. The node object represents either a > bare metal or virtual machine node that is provisioned with an OS to run the > containers, or alternatively, > run

Re: [openstack-dev] [Magnum] New Core Reviewers

+1 for both. Welcome! From: 大塚元央 [mailto:yuany...@oeilvert.org] Sent: Tuesday, February 2, 2016 9:39 AM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Magnum] New Core Reviewers +1 welcome!! 2016年2月2日(火)

Re: [openstack-dev] [Magnum] New Core Reviewers

+1 welcome!! 2016年2月2日(火) 10:14 Eli Qiao : > +1 +1 thanks for both harding reviewing. > > On 2016年02月01日 23:58, Adrian Otto wrote: > > Magnum Core Team, > > > > I propose Ton Ngo (Tango) and Egor Guz (eghobo) as new Magnum Core > Reviewers. Please respond with your votes.

Re: [openstack-dev] [Magnum] New Core Reviewers

st (not for usage questions) < > openstack-dev@lists.openstack.org> > *Subject:* Re: [openstack-dev] [Magnum] New Core Reviewers > > > > +1 welcome!! > > > > 2016年2月2日(火) 10:14 Eli Qiao <liyong.q...@intel.com>: > > +1 +1 thanks for both harding r

[openstack-dev] [Magnum] New Core Reviewers

Magnum Core Team, I propose Ton Ngo (Tango) and Egor Guz (eghobo) as new Magnum Core Reviewers. Please respond with your votes. Thanks, Adrian Otto __ OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [Magnum] New Core Reviewers

+1 -Original Message- From: Adrian Otto [mailto:adrian.o...@rackspace.com] Sent: February-01-16 10:59 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Magnum] New Core Reviewers Magnum Core Team, I propose Ton Ngo (Tango) and Egor Guz (eghobo) as new Magnum Core

[openstack-dev] [Magnum]Remove node object from Magnum

Hi all, I want to remove node object from Magnum. The node object represents either a bare metal or virtual machine node that is provisioned with an OS to run the containers, or alternatively, run kubernetes. Magnum use Heat to deploy the nodes, so it is unnecessary to maintain node object in

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

g List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays I don't see why the existent of /containers endpoint blocks your workflow. However, with /containers gone, the alternate workflows are blocked. As a counterexample, some users want to

Re: [openstack-dev] [Magnum] Use Liberty Magnum bits with Kilo/ Icehouse Openstack ?

quot; <openstack-dev@lists.openstack.org> Date: 28/01/2016 04:10 pm Subject:[openstack-dev] [Magnum] Use Liberty Magnum bits with Kilo/ Icehouse Openstack ? A newbie question … Is it described somewhere what exactly is the set of Liberty dependencies for

[openstack-dev] [Magnum] Use Liberty Magnum bits with Kilo/ Icehouse Openstack ?

A newbie question ... Is it described somewhere what exactly is the set of Liberty dependencies for Magnum ? Since a significant fraction of it is orchestration templates, one would expect it should be possible to run Liberty Magnum bits along with an Icehouse or Kilo version of Openstack.

Re: [openstack-dev] [Magnum] Use Liberty Magnum bits with Kilo/ Icehouse Openstack ?

/ Best regards, Hongbin From: Kai Qiang Wu [mailto:wk...@cn.ibm.com] Sent: January-28-16 3:41 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Magnum] Use Liberty Magnum bits with Kilo/ Icehouse Openstack ? HI, For Magnum, The community keep

Re: [openstack-dev] [magnum] Planning Magnum Midcycle

Team, We have selected Feb 18-19 for the Midcycle, and will be hosted by HPE. Please save the date. The exact location is forthcoming, and is expected to be Sunnyvale. Thanks, Adrian > On Jan 11, 2016, at 11:29 AM, Adrian Otto wrote: > > Team, > > We are

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

-To: OpenStack List Date: Saturday, 16 January 2016 02:24 To: OpenStack List Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays The requirements that running a fully containerized application optimally & effectively requires the usage of a dedicated COE tool such as S

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

ssage- > From: Kyle Kelley [mailto:kyle.kel...@rackspace.com] > Sent: January-19-16 2:37 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays > > With /containers gone

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

. From: Hongbin Lu <hongbin...@huawei.com> Sent: Tuesday, January 19, 2016 9:43 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays Assume your logic is applied. Shoul

Re: [openstack-dev] [magnum] Temporarily remove swarm func test from gate

.com>>, OpenStack Development Mailing List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: 01/18/2016 12:29 PM Subject: Re: [openstack-dev] [magnum] Temporarily remove swarm func test from gate Hi Egor, Than

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

bin...@huawei.com> Sent: Tuesday, January 19, 2016 9:43 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays Assume your logic is applied. Should Nova remove the endpoint of managing VMs? Should

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

] Sent: January-19-16 5:19 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays +1 Doing this, and doing this well, provides critical functionality to OpenStack while keeping said functionality reasonably

Re: [openstack-dev] [magnum] Temporarily remove swarm func test from gate

penstack.org<mailto:openstack-dev@lists.openstack.org> Cc: Hongbin Lu Subject: Re: [openstack-dev] [magnum] Temporarily remove swarm func test from gate Hongbin, I belive most failures are related to containers tests. Maybe we should comment only them out and keep Swarm cluster provisioning. Thoughts?

Re: [openstack-dev] [magnum] Temporarily remove swarm func test from gate

ment Mailing List <openstack-dev@lists.openstack.org> Date: 01/18/2016 12:29 PM Subject: Re: [openstack-dev] [magnum] Temporarily remove swarm func test from gate Hi Egor, Thanks for investigating on the issue. I will review the patch. Agreed. We can

Re: [openstack-dev] [magnum] Temporarily remove swarm func test from gate

Development Mailing List Cc: Hongbin Lu Subject: Re: [openstack-dev] [magnum] Temporarily remove swarm func test from gate Hongbin, I did some digging and found that docker storage driver wasn’t configured correctly at agent nodes. Also it looks like Atomic folks recommend use deicated volumes

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

02 PM To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays A reason is the container abstraction brings containers to OpenStack: Keystone for authentication, Heat for orchestration, Horizon f

<    3   4   5   6   7   8   9   10   11   12   >