Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI

Hi Ramy, indeed user zuul could not read the event-stream (permission denied). The question is then how it could start zuul-server and read some events? Anyway, i copied over .ssh from user jenkins, and now user zuul can run that command. I restarted zuul-server and will keep an eye on it. Thanks,

Re: [openstack-dev] [Fuel][Neutron ML2][VMWare]NetworkNotFoundForBridge: Network could not be found for bridge br-int

Hi Xarses, Thanks for your time! I was not able to check my mail yesterday. Sorry for the delay. One of my colleague fixed this issue yesterday. I will understand the issue and update this thread. -- Thanks & Regards E-Mail: thefossg...@gmail.com IRC: neophy Blog : http://lmohanphy.livejournal

Re: [openstack-dev] sos-ci for cinder scst

Hi Nikesh, Not familiar with sos-ci, but in general, for drivers that are not yet in-tree, you’ll want to use the gerrit event patch referenced, then apply (e.g. cherry pick) the patch that contains the out-of-tree driver on top. Ramy From: Nikesh Kumar Mahalka [mailto:nikeshmaha...@vedams.com

Re: [openstack-dev] [Keystone] Nominating Brad Topol for Keystone-Spec core

+1 Steve Morgan Fainberg wrote on 01/18/2015 02:11:02 PM: > From: Morgan Fainberg > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 01/18/2015 02:15 PM > Subject: [openstack-dev] [Keystone] Nominating Brad Topol for > Keystone-Spec core > > Hello all, > > I w

Re: [openstack-dev] [Keystone] Nominating Brad Topol for Keystone-Spec core

+1! > On Jan 18, 2015, at 3:17 PM, Jamie Lennox wrote: > > +1 > > - Original Message - >> From: "Morgan Fainberg" >> To: "OpenStack Development Mailing List (not for usage questions)" >> >> Sent: Monday, 19 January, 2015 5:11:02 AM >> Subject: [openstack-dev] [Keystone] Nominating Br

Re: [openstack-dev] [magnum][nova][ironic] Magnum Milestone #2 blueprints - request for comments

On 01/18/2015 11:02 PM, Steven Dake wrote: On 01/18/2015 07:59 PM, Jay Pipes wrote: On 01/18/2015 11:11 AM, Steven Dake wrote: On 01/18/2015 06:39 AM, Jay Lau wrote: Thanks Steven, just some questions/comments here: 1) For native docker support, do we have some project to handle the network?

Re: [openstack-dev] [all] [api] gabbi: A tool for declarative testing of APIs

On 01/12/2015 02:20 PM, Chris Dent wrote: After some discussion with Sean Dague and a few others it became clear that it would be a good idea to introduce a new tool I've been working on to the list to get a sense of its usefulness generally, work towards getting it into global requirements, and

Re: [openstack-dev] [magnum][nova][ironic] Magnum Milestone #2 blueprints - request for comments

On 01/18/2015 07:59 PM, Jay Pipes wrote: On 01/18/2015 11:11 AM, Steven Dake wrote: On 01/18/2015 06:39 AM, Jay Lau wrote: Thanks Steven, just some questions/comments here: 1) For native docker support, do we have some project to handle the network? The current native docker support did not ha

Re: [openstack-dev] [glance] Replication on image create

(Replace the word "synchronization" to "replication" to reduce misunderstanding) I also recommend approach #2. For, approach #1, 1) You have to maintain a state machine if you want to replicate the image to 3 or more backend. 2) Not always 3 or more backend will be replicated successfully, unl

Re: [openstack-dev] [api] API Definition Formats

On 01/13/2015 07:41 AM, Sean Dague wrote: On 01/09/2015 04:17 PM, Everett Toews wrote: One thing that has come up in the past couple of API WG meetings [1] is just how useful a proper API definition would be for the OpenStack projects. By API definition I mean a format like Swagger, RAML, API B

Re: [openstack-dev] [magnum][nova][ironic] Magnum Milestone #2 blueprints - request for comments

Steven, just filed two bps to trace all the discussions for network and scheduler support for native docker, we can have more discussion there. https://blueprints.launchpad.net/magnum/+spec/native-docker-network https://blueprints.launchpad.net/magnum/+spec/magnum-scheduler-for-docker Another I w

Re: [openstack-dev] [magnum][nova][ironic] Magnum Milestone #2 blueprints - request for comments

On 01/18/2015 11:11 AM, Steven Dake wrote: On 01/18/2015 06:39 AM, Jay Lau wrote: Thanks Steven, just some questions/comments here: 1) For native docker support, do we have some project to handle the network? The current native docker support did not have any logic for network management, are w

Re: [openstack-dev] Notification Schemas ...

On 01/18/2015 04:39 PM, Sandy Walsh wrote: Hey y'all Eddie Sheffield has pulled together a strawman set of notification schemas for Nova and Glance. Looks like a great start for further discussion. He's going to add JSON-Schema validation next as a form of unit test. Then I guess we have to star

Re: [openstack-dev] [heat] Remove deprecation properties

On Fri, Jan 16, 2015 at 11:10 PM, Sergey Kraynev wrote: > Steve, Thanks for the feedback. > > On 16 January 2015 at 15:09, Steven Hardy wrote: > >> On Thu, Dec 25, 2014 at 01:52:43PM +0400, Sergey Kraynev wrote: >> >Hi all. >> >In the last time we got on review several patches, which rem

Re: [openstack-dev] [heat] Remove deprecation properties

On Sat, Jan 17, 2015 at 5:01 AM, Georgy Okrokvertskhov < gokrokvertsk...@mirantis.com> wrote: > Hi, > > Murano uses Heat templates with almost all available resources. Neutron > resources are definitely used. > I think Murano can update our Heat resources handling properly, but there > are at leas

Re: [openstack-dev] [Heat] Support status of Heat resource types

On Sun, Jan 18, 2015 at 10:41 PM, Qiming Teng wrote: > Dear all, > One question we constantly get from Heat users is about the support > status of resource types. Some users are not well informed of this > information so that is something we can improve. > > Though some resource types are already

Re: [openstack-dev] [all] "All rights reserved" V.S. "Apache license"

@Stefano Maffulli Yes, the main point is the conflict of reserved all, and abandon some (actually most). According to the order the last will take effect IIUC Monty Taylor's explaination. I'm thinking that we should remove the "all rights reserved" words if we're using Apache license. Misleading

Re: [openstack-dev] [Keystone] Nominating Brad Topol for Keystone-Spec core

+1 cheers, gord From: morgan.fainb...@gmail.com Date: Sun, 18 Jan 2015 12:11:02 -0700 To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Keystone] Nominating Brad Topol for Keystone-Spec core Hello all, I would like to nominate Brad Topol for Keystone Spec core (core reviewer

Re: [openstack-dev] [Keystone] Nominating Brad Topol for Keystone-Spec core

+1 - Original Message - > From: "Morgan Fainberg" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Monday, 19 January, 2015 5:11:02 AM > Subject: [openstack-dev] [Keystone] Nominating Brad Topol for Keystone-Spec > core > > Hello all, > > I would like

Re: [openstack-dev] [all] "All rights reserved" V.S. "Apache license"

On Sat, 2015-01-17 at 16:07 -0500, Monty Taylor wrote: > It's actually a set of words that is no longer necessary as of the year > 2000. It's not communicating anything about a granted license, which is > what the Apache License does - it's actually just asserting that the > original copyright hold

[openstack-dev] Notification Schemas ...

Hey y'all Eddie Sheffield has pulled together a strawman set of notification schemas for Nova and Glance. Looks like a great start for further discussion. He's going to add JSON-Schema validation next as a form of unit test. Then I guess we have to start thinking about a library to digest these

Re: [openstack-dev] [Keystone] Nominating Brad Topol for Keystone-Spec core

+1 On Sun, Jan 18, 2015 at 2:11 PM, Morgan Fainberg wrote: > Hello all, > > I would like to nominate Brad Topol for Keystone Spec core (core reviewer > for Keystone specifications and API-Specification only: > https://git.openstack.org/cgit/openstack/keystone-specs ). Brad has been > a consisten

Re: [openstack-dev] [Keystone] Nominating Brad Topol for Keystone-Spec core

+1 Em dom, 18 de jan de 2015 16:25, Marek Denis escreveu: > +1 > > > On 18.01.2015 20:11, Morgan Fainberg wrote: > > Hello all, > > I would like to nominate Brad Topol for Keystone Spec core (core > reviewer for Keystone specifications and API-Specification only: > https://git.openstack.org/cg

Re: [openstack-dev] [Keystone] Nominating Brad Topol for Keystone-Spec core

+1 On Jan 18, 2015 1:23 PM, "Marek Denis" wrote: > +1 > > On 18.01.2015 20:11, Morgan Fainberg wrote: > > Hello all, > > I would like to nominate Brad Topol for Keystone Spec core (core > reviewer for Keystone specifications and API-Specification only: > https://git.openstack.org/cgit/openstack

Re: [openstack-dev] [Keystone] Nominating Brad Topol for Keystone-Spec core

+1 On 18.01.2015 20:11, Morgan Fainberg wrote: Hello all, I would like to nominate Brad Topol for Keystone Spec core (core reviewer for Keystone specifications and API-Specification only: https://git.openstack.org/cgit/openstack/keystone-specs ). Brad has been a consistent voice advocating f

[openstack-dev] [Keystone] Nominating Brad Topol for Keystone-Spec core

Hello all, I would like to nominate Brad Topol for Keystone Spec core (core reviewer for Keystone specifications and API-Specification only: https://git.openstack.org/cgit/openstack/keystone-specs ). Brad has been a consistent voice adv

Re: [openstack-dev] [magnum][nova][ironic] Magnum Milestone #2 blueprints - request for comments

On 01/18/2015 09:23 AM, Jay Lau wrote: Thanks Steven, more questions/comments in line. 2015-01-19 0:11 GMT+08:00 Steven Dake >: On 01/18/2015 06:39 AM, Jay Lau wrote: Thanks Steven, just some questions/comments here: 1) For native docker support, do we ha

Re: [openstack-dev] [magnum][nova][ironic] Magnum Milestone #2 blueprints - request for comments

Thanks Steven, more questions/comments in line. 2015-01-19 0:11 GMT+08:00 Steven Dake : > On 01/18/2015 06:39 AM, Jay Lau wrote: > > Thanks Steven, just some questions/comments here: > > 1) For native docker support, do we have some project to handle the > network? The current native docker s

Re: [openstack-dev] [openstack-operators][qa][Rally] Thoughts on removing half of Rally benchmark scenarios

Hi Boris, I understand your concern about keeping the number of different benchmark scenarios in Rally not too big so that users don't get confused. But what I really like now about benchmark scenario names in Rally is that they are highly declarative, i.e. you read them and you have a clear idea

Re: [openstack-dev] [magnum][nova][ironic] Magnum Milestone #2 blueprints - request for comments

On 01/18/2015 06:39 AM, Jay Lau wrote: Thanks Steven, just some questions/comments here: 1) For native docker support, do we have some project to handle the network? The current native docker support did not have any logic for network management, are we going to leverage neutron or nova-networ

Re: [openstack-dev] [openstack-operators][qa][Rally] Thoughts on removing half of Rally benchmark scenarios

On 01/17/2015 12:47 PM, Boris Pavlovic wrote: Hi stackers, I have an idea about removing almost half of rally scenarios and keep all functionality. Currently you can see a lot of similar benchmarks like: NovaServers.boot_server # boot server with passed arguments NovaServe

Re: [openstack-dev] [magnum][nova][ironic] Magnum Milestone #2 blueprints - request for comments

Thanks Steven, just some questions/comments here: 1) For native docker support, do we have some project to handle the network? The current native docker support did not have any logic for network management, are we going to leverage neutron or nova-network just like nova-docker for this? 2) For k8

Re: [openstack-dev] [Neutron] Project Idea: IDS integration.

Hello Mario, IDS surely is an interesting topic for OpenStack integration. I think there might be users out there which could be interested in having this capability in OpenStack networks. As Kevin said, we are moving towards a model where it becomes easier for developers to add such capabilities

[openstack-dev] [Heat] Support status of Heat resource types

Dear all, One question we constantly get from Heat users is about the support status of resource types. Some users are not well informed of this information so that is something we can improve. Though some resource types are already labelled with support status, there are quite some of them not id

Re: [openstack-dev] [Neutron] Project Idea: IDS integration.

Hi Mario, There is currently a large backlog of network-related features that many people want to develop for Neutron. The model of adding them all to the main neutron codebase has failed to keep up. Due to this, all of the advanced services (LBaaS, FWaaS, etc) are being separated into their own r