[openstack-dev] [fuel] Fuel is now an OpenStack project: what's next?

Fuel team, You've heard the good news. After 4 months of hard work on expanding our collaboration with other OpenStack projects and aligning our development and governance processes with the OpenStack project requirements, our proposal to add Fuel to OpenStack projects [0] was approved by the Tech

Re: [openstack-dev] [ironic] [inspector] Auto discovery extension for Ironic Inspector

Hi, Using fake driver means we need a manual step to set it to something > non-fake :) and the current introspection process already has 1 manual step > (enrolling nodes), so I'd like autodiscovery to require 0 of them (at least > for the majority of users). Exactly. I recognize that our purpose

Re: [openstack-dev] [magnum] Issue on history of renamed file/folder

This is a defect with Github and should not affect our ability to fix defects and correct/refactor our code. git is a CLI tool not a GUI tool and should be treated as such. We should not be imposing restrictions on our developers because a 3rd party GUI does not fit our workflows. Tom On 18/1

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

Thomas Morin wrote: > The starting point for this post is a specific Neutron sub-project > (networking-bgpvpn) but I believe the issues raised are shared with > other neutron stadium project and possibly relevant beyond Neutron, to > projects tagged release-independent in general. > > In the conte

Re: [openstack-dev] [openstack][openstack-operators] IRC meeting(s)

JJ Asghar wrote: > I've been seeing some interesting regressions in our community > recently. Our IRC meetings, or at least the ones I've been attending, > are extremely variable in quality. I believe this is a disservice to > our community as a whole, so I've offered to help. > > I've written up

Re: [openstack-dev] [neutron][upgrade] new 'all things upgrade' subteam

Artur wrote: Mon 15 UTC works for me too. Was there the first meeting on past Monday? Or are we starting on Monday 23rd November? We start next Monday (Nov 23th). Ihar __ OpenStack Development Mailing List (not for usag

Re: [openstack-dev] [stable][neutron] How we handle Kilo backports

Tony Breeds wrote: On Wed, Nov 18, 2015 at 05:44:38PM +0100, Ihar Hrachyshka wrote: Hi all, as per [1] I imply that all projects under stable-maint-core team supervision must abide the stable policy [2] which limits the types of backports for N-2 branches (now it’s stable/kilo) to "Only criti

Re: [openstack-dev] [OpenStack-Infra] Report from Gerrit User Summit

David Pursehouse wrote on 11/12/2015 09:22:50 PM: > From: David Pursehouse > To: OpenStack Development Mailing List > Cc: [email protected] > Date: 11/12/2015 09:27 PM > Subject: Re: [openstack-dev] [OpenStack-Infra] Report from Gerrit User Summit > > On Mon, Nov 9, 2015 a

Re: [openstack-dev] [ironic] [inspector] Auto discovery extension for Ironic Inspector

What Yuiko has described makes a lot of sense, and from that perspective perhaps instead of us defining what driver a node should and shouldn't be using a config file, we should just provide a guide to using the inspector rules for this and maybe some prewritten rules that can set the driver and

Re: [openstack-dev] [stable][neutron] How we handle Kilo backports

> -Original Message- > From: Ihar Hrachyshka [mailto:[email protected]] > Sent: Thursday, November 19, 2015 10:43 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [stable][neutron] How we handle Kilo > backports > > Tony Breeds wrote:

Re: [openstack-dev] [stable][neutron] How we handle Kilo backports

Erno wrote: Typo fixes are not good idea for stable branches. As it might be bit annoying or amusing for the English user fixing typos in kilo will mean that it breaks translation for all the rest and I haven't seen any translation patches being proposed to older stable branches. Right

[openstack-dev] [Horizon] Bug day! Yeah!

Hey folks, Our bug list is… rather large. We’ve discussed having a bug day, where as a community we all dedicate some time to triaging bugs and discussing in the IRC channel as we go. First off, see the docs about bug triage: https://wiki.openstack.org/wiki/BugTriage Secondly, lets pick a dat

Re: [openstack-dev] [fuel] Fuel is now an OpenStack project: what's next?

Dima, A very huge +1 to the initiatives, especially Diversity, you have listed here and a big congratulations to everyone. Thanks, Dims On Thu, Nov 19, 2015 at 3:04 AM, Dmitry Borodaenko wrote: > Fuel team, > > You've heard the good news. After 4 months of hard work on expanding our > collabora

[openstack-dev] [nova] Today, November 19 is Nova Spec Review Day

Hi all, A (late) reminder that today is Spec Review day: https://wiki.openstack.org/wiki/Nova/Mitaka_Release_Schedule I encourage everyone to help review the specs we still have up for review. Any questions, as normal, chat in #openstack-nova in IRC. If you are busy today, or today as already ha

Re: [openstack-dev] [ironic][security] what is OK to put in DEBUG logs?

Hi, > Also keep in mind that DEBUG logging, while still should have some masking > of data, since it is explicitly called out (or should be) as not safe for > production, can contain some " sensitive" data. Credentials should still be > scrubbed, but I would say the swift temp URL is something tha

Re: [openstack-dev] [Monasca][vitrage] Vitrage project

Hi Roland, Thanks for your feedback. The questions you raised below are helping us in clarifying and enhancing our design. We will also be happy to see your comments on our blueprints. Your input will be very helpful. The integration with Monasca should include two parts: 1. Query information

Re: [openstack-dev] [ironic] [inspector] Auto discovery extension for Ironic Inspector

On 11/19/2015 11:57 AM, Sam Betts (sambetts) wrote: What Yuiko has described makes a lot of sense, and from that perspective perhaps instead of us defining what driver a node should and shouldn’t be using a config file, we should just provide a guide to using the inspector rules for this and mayb

Re: [openstack-dev] [neutron][taas] proposal: dedicated tunnel for carrying mirrored traffic

Regarding tunnel for that. How do you ensure packet timestamps and ordering? Endre Karlson 19. nov. 2015 4.55 a.m. skrev "Li Ma" : > It is suggested that you can issue a RFE request for it. [1] We can > discuss with it and track the progress in the launchpad. > > By the way, I'm very interested i

Re: [openstack-dev] [puppet] review the core-reviewer members

So here is a status: * François Charlier told me he's not working anymore on Puppet OpenStack, and wants to be dropped from core-reviewer list. I would like to personally thank him, he was the guy who showed me what is Puppet and how to write Puppet code. Thanks a lot for your work in our communit

Re: [openstack-dev] [Horizon] Bug day! Yeah!

On 19/11/15 12:19, Rob Cresswell (rcresswe) wrote: > Hey folks, > > Our bug list is… rather large. We’ve discussed having a bug day, where > as a community we all dedicate some time to triaging bugs and discussing > in the IRC channel as we go. > > First off, see the docs about bug > triage: http

Re: [openstack-dev] [stable][neutron] How we handle Kilo backports

+1 for Critical + High. Kevin Benton wrote: +1. Anything that lands in the high category is usually something that will have a big operational impact. On Wed, Nov 18, 2015 at 8:44 AM, Ihar Hrachyshka wrote: Hi all, as per [1] I imply that all projects under stable-maint-core team supervision

[openstack-dev] [infra][devstack][gnocchi] Unable to run devstack-gate with stable/1.3

Hi, The Gnocchi gate is broken for stable/1.3 because of devstack-gate saying¹: ERROR: branch not allowed by features matrix: 1.3 From what I understand, that's because devstack-gate thinks it should try to pull stable/1.3 for devstack & all OpenStack projects, branch that does not exist – and

[openstack-dev] [ironic] specs process for ironic-inspector

Hi folks! I've been dodging subj for some time (mostly due to my laziness), but now it seems like the time has come. We're discussing 2 big features: autodiscovery and HA that I would like us to have a proper consensus on. I'd like to get your opinion on one of the options: 1. Do not have spe

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

UPD: now that we have some understanding what’s needed from l2 agent extension mechanism to cater for interested subprojects (and now that we see that probably the agent in focus right now is OVS only), we may move to RFE step. I reported the following RFE for the feature: https://bugs.laun

Re: [openstack-dev] [ironic] specs process for ironic-inspector

Hi all, +1 for specs in general, big features require a proper review and discussion for which LP is not a good choice. +1 for not requiring a spec for small features, LP BP is enough for just time/release tracking, but of course cores can request a proper spec to be proposed if feeling feature i

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

Thanks to Thomas for continuing this discussion about networking-* projects, and to Thierry for his responses below, and Ihar for his earlier guidance. I have a couple further points that I hope may contribute... On 19/11/15 09:46, Thierry Carrez wrote: > Thomas Morin wrote: >> The starting point

Re: [openstack-dev] [ironic] specs process for ironic-inspector

On 11/19/2015 02:39 PM, Pavlo Shchelokovskyy wrote: Hi all, +1 for specs in general, big features require a proper review and discussion for which LP is not a good choice. +1 for not requiring a spec for small features, LP BP is enough for just time/release tracking, but of course cores can req

[openstack-dev] [ironic] Redfish drivers in ironic

Hi list and Bruno, I’m interested in adding virtual media boot interface for redfish ( https://blueprints.launchpad.net/ironic/+spec/redfish-virtual-media-boot). It depends on https://blueprints.launchpad.net/ironic/+spec/ironic-redfish and a corresponding spec https://review.openstack.org/184653,

Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action

I have pushed up a draft of the spec. Let's move comments there. I tried to incorporate as much as I could from the discussion here. There was a lot of disjointed suggestions and was a bit difficult to follow. So I've taken what I can. It can be refined in the spec itself. https://review.openstac

Re: [openstack-dev] [ironic] specs process for ironic-inspector

Agree, we certainly need specs for discussing big feature, it would more effective than ml; not sure about for best place for it, probably we can start from ironic-specs, and then decide do we need separate repo or not. On Thu, Nov 19, 2015 at 3:39 PM, Pavlo Shchelokovskyy < pshchelokovs...@mirant

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

Hi Thierry, Thanks for you answers, more below. Thierry Carrez : Thomas Morin wrote: The starting point for this post is a specific Neutron sub-project (networking-bgpvpn) but I believe the issues raised are shared with other neutron stadium project and possibly relevant beyond Neutron, to pro

Re: [openstack-dev] [Ironic] Do we need to have a mid-cycle?

On Mon, Nov 16, 2015 at 06:05:54AM -0800, Jim Rollenhagen wrote: > On Wed, Nov 11, 2015 at 12:16:34PM -0500, Ruby Loo wrote: > > On 10 November 2015 at 12:08, Dmitry Tantsur wrote: > > > > > On 11/10/2015 05:45 PM, Lucas Alvares Gomes wrote: > > > > > >> Hi, > > >> > > >> In the last Ironic meeti

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

Thomas Morin wrote: > [...] > But still...one last, very practical, question: until the framework is > adjusted, can we pursue our liberty-targeted work in our master branch, > and our backport work in our backport/kilo and backport/juno branches ? > (of course, we will accept the inconvenience of

[openstack-dev] [ec2-api] EC2API Liberty release

Hello all, We've released new packages of EC2API project on pypi.python.org - [1] 1.0.0 is a release for OpenStack Liberty and 0.2.0 is an update for OpenStack Kilo [1] https://pypi.python.org/pypi/ec2-api -- Kind regards, Andrey Pavlov.

Re: [openstack-dev] [releases] Release countdown for week R-19, Nov 23-27

Excerpts from Matt Riedemann's message of 2015-11-18 18:22:59 -0600: > > On 11/18/2015 4:09 PM, Doug Hellmann wrote: > > Focus > > - > > > > We are currently working towards the Mitaka 1 milestone scheduled > > for Dec 1-3. Teams should be focusing on wrapping up incomplete > > work left over

Re: [openstack-dev] [Ironic] Do we need to have a mid-cycle?

On 11/16/2015 03:05 PM, Jim Rollenhagen wrote: On Wed, Nov 11, 2015 at 12:16:34PM -0500, Ruby Loo wrote: On 10 November 2015 at 12:08, Dmitry Tantsur wrote: On 11/10/2015 05:45 PM, Lucas Alvares Gomes wrote: Hi, In the last Ironic meeting [1] we started a discussion about whether we need t

Re: [openstack-dev] [puppet] review the core-reviewer members

I too would like to thank Dan, Michael, and François for all their hard work. Michael and Dan in particular have helped me personally learn a bunch and been helpful in answering questions. On Thu, Nov 19, 2015 at 5:45 AM, Emilien Macchi wrote: > So here is a status: > > * François Charlier told

[openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

Dear colleagues, As might remember, we introduced Docker containers on the master node a while ago when we implemented first version of Fuel upgrade feature. The motivation behind was to make it possible to rollback upgrade process if something goes wrong. Now we are at the point where we can not

Re: [openstack-dev] [Ironic] Do we need to have a mid-cycle?

Hi, > I sent a new idea to openstack-dev, and nobody has opinions? :P > > I'd like to get consensus on this soon, please do reply if you have > thoughts on this. > Sorry for the delay... Yeah, I've no problem giving this virtual midcycle idea a go, so +1

[openstack-dev] [openstack-dev ] [Heat] how to verify heat resource plugin

Hi team, Currently working on adding heat resource plugin for neutron extension "networking-sfc" , similar to firewall implementation " https://github.com/openstack/heat/blob/master/heat/engine resources/openstack/neutron/firewall.py

Re: [openstack-dev] [Ironic] Do we need to have a mid-cycle?

Me too :) +1 for trying a virtual midcycle On Thu, Nov 19, 2015 at 8:55 AM, Lucas Alvares Gomes wrote: > Hi, > > > I sent a new idea to openstack-dev, and nobody has opinions? :P > > > > I'd like to get consensus on this soon, please do reply if you have > > thoughts on this. > > > > Sorry for

Re: [openstack-dev] [Ironic] Do we need to have a mid-cycle?

Seems good to me too. On Thu, Nov 19, 2015 at 5:07 PM, John Villalovos wrote: > Me too :) > > +1 for trying a virtual midcycle > > On Thu, Nov 19, 2015 at 8:55 AM, Lucas Alvares Gomes < > [email protected]> wrote: > >> Hi, >> >> > I sent a new idea to openstack-dev, and nobody has opinions?

Re: [openstack-dev] [openstack-ansible] Fedora/CentOS/other Support

On 11/18/2015 04:19 AM, Jesse Pretorius wrote: > The current community has done some research into appropriate patterns to use > and has a general idea of how to do it - but in order to actually execute > there need to be enough people who commit to actually maintaining the work > once it's done

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

> On Nov 19, 2015, at 4:43 AM, Thierry Carrez wrote: > > Thomas Morin wrote: >> The starting point for this post is a specific Neutron sub-project >> (networking-bgpvpn) but I believe the issues raised are shared with >> other neutron stadium project and possibly relevant beyond Neutron, to >> p

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

> On Nov 19, 2015, at 9:28 AM, Thomas Morin wrote: > > Hi Thierry, > > Thanks for you answers, more below. > > Thierry Carrez : >> Thomas Morin wrote: >>> The starting point for this post is a specific Neutron sub-project >>> (networking-bgpvpn) but I believe the issues raised are shared with

Re: [openstack-dev] [Openstack-operators] [openstack-ansible] Fedora/CentOS/other Support

I don't believe we should have a class system in the OS's that we choose to support. If we're going to bring in a new OS I think we should first bring it in using non-voting jobs however once all of the bits have been finalized the supported OS should be able to pass the same sets of tests as e

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

On Thu, Nov 19 2015, Doug Hellmann wrote: > In my mind the “independent” release model was originally meant to mean that > the project was completely on their own, doing potentially incorrect and > random > releases. It wasn’t something I anticipated projects *wanting* to use. It > evolved to mea

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

On 19.11.2015 15:59, Vladimir Kozhukalov wrote: > Dear colleagues, > > As might remember, we introduced Docker containers on the master node a > while ago when we implemented first version of Fuel upgrade feature. The > motivation behind was to make it possible to rollback upgrade process if > som

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

Vladimir Although I am a big fan of this idea, I think it is too risky to do this during our latest iteration for 8.0 release. There is a lot of stuff that relies on our containerised approach. For example, it is our Fuel CI master-node tests which will require adjustments. There are pieces of thi

Re: [openstack-dev] [neutron][upgrade] new 'all things upgrade' subteam

UPD: I have added an agenda page for the subteam: https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam Feel free to fill in, and see you all on Mon 15:00 UTC. Ihar Ihar Hrachyshka wrote: Thanks everyone for responses. It seems like Mon 15:00 UTC works for all of us, so I push

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

Vladimir, The old site.pp is long out of date and should just be recreated from the content of all the other $service-only.pp files. My main question is how do we propose to do a rollback from an update (in theory, from 8.0 to 9.0, then back to 8.0)? Should we hardcode persistent data directories

[openstack-dev] [infra][glance] How do we fix the glance_store git > glance-store LP mapping?

Patches in Gerrit aren't syncing status to the glance-store project in launchpad b/c the project in launchpad is called glance-store and in git it's glance_store. Looking at the project creators guide it says to specify a group for the mapping [1] to fix this but glance_store in projects.yaml

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

Hi Neil, Neil Jerram : [snip] I've since realised that my initial statement above wasn't quite right. In fact, because networking-calico uses Neutron interfaces that are pretty stable (ML2 mech driver, DHCP interface driver, etc.) we have found it manageable until now to develop a single (master

Re: [openstack-dev] [tripleo] When to use parameters vs parameter_defaults

On Mon, Nov 16, 2015 at 08:15:48PM +0100, Giulio Fidente wrote: > On 11/16/2015 04:25 PM, Steven Hardy wrote: > >Hi all, > > > >I wanted to start some discussion re $subject, because it's been apparrent > >that we have a lack of clarity on this issue (and have done ever since we > >started using pa

Re: [openstack-dev] [trove] trove unit tests failing on stable/kilo [imm]

Just catching up on this thread, have fixes been submitted for this already? Thanks, -amrith > -Original Message- > From: Matt Riedemann [mailto:[email protected]] > Sent: Wednesday, November 18, 2015 2:54 PM > To: [email protected] > Subject: Re: [openstack-dev]

[openstack-dev] [nova] [Openstack-operators] Profiling nova-conductor and eventlet

Calling all Proflers! I am running into an issue with CPU usage on remote nova-conductor and I am trying to profile it to see where its consuming the most amount of cpu, so that we can investigate further. The etherpad where we have been working on this issue is located at: https://etherpad.o

[openstack-dev] [Infra] Remove .mailmap files from OpenStack repos

Currently we have .mailmap files in the root of almost all OpenStack repos: https://github.com/openstack/glance/blob/master/.mailmap https://github.com/openstack/horizon/blob/master/.mailmap https://github.com/openstack/nova/blob/master/.mailmap https://github.com/openstack/cinder/blob/master/.mail

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

On Thu, Nov 19, 2015 at 04:35:24PM +0100, Julien Danjou wrote: > On Thu, Nov 19 2015, Doug Hellmann wrote: > > > In my mind the “independent” release model was originally meant to mean that > > the project was completely on their own, doing potentially incorrect and > > random > > releases. It wa

Re: [openstack-dev] [magnum] Issue on history of renamed file/folder

As I see this, we need to pick the better of two options, even when neither is perfect. I’d rather have magnum’s source as intuitive and easy to maintain as possible. If it becomes more difficult to follow the commit history for a file in order to achieve that improvement, I’m willing to live wi

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

On Thu, Nov 19 2015, Jim Rollenhagen wrote: > This is actually the idea of the cycle-with-intermediary model. Projects > following this model may release as early and often as they like, and > choose a release near the same time as the coordinated release, to be > the "cycle" release and the base

Re: [openstack-dev] [Infra] Remove .mailmap files from OpenStack repos

On Thu, Nov 19 2015, Mikhail Fedosin wrote: > Currently we have .mailmap files in the root of almost all OpenStack repos: > https://github.com/openstack/glance/blob/master/.mailmap > https://github.com/openstack/horizon/blob/master/.mailmap > https://github.com/openstack/nova/blob/master/.mailmap

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

Hi, On Thu, Nov 19, 2015 at 5:50 PM, Matthew Mosesohn wrote: > Vladimir, > > The old site.pp is long out of date and should just be recreated from the > content of all the other $service-only.pp files. > > My main question is how do we propose to do a rollback from an update (in > theory, from 8

Re: [openstack-dev] [tripleo] When to use parameters vs parameter_defaults

On Thu, Nov 19, 2015 at 6:16 PM, Steven Hardy wrote: > On Mon, Nov 16, 2015 at 08:15:48PM +0100, Giulio Fidente wrote: > > On 11/16/2015 04:25 PM, Steven Hardy wrote: > > >Hi all, > > > > > >I wanted to start some discussion re $subject, because it's been > apparrent > > >that we have a lack of c

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

Doug : [snip] I get your point. This would indeed correctly model intermediate releases. But since no other project in Openstack depends on networking-bgpvpn, what is the value of forcing a release of the project synched at the end of a cycle ? It raises your chances of having your project pack

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

My main concern with using linux capabilities/acls on files is actually puppet support or, actually, the lack of it. ACLs are possible AFAIK, but we'd need to write a custom type/provider for capabilities. I suggest to wait with capabilities support till systemd support. On Tue, Nov 17, 2015 at 9:

Re: [openstack-dev] [Infra] Remove .mailmap files from OpenStack repos

On Thu, Nov 19, 2015 at 07:28:03PM +0300, Mikhail Fedosin wrote: > Currently we have .mailmap files in the root of almost all OpenStack repos: > https://github.com/openstack/glance/blob/master/.mailmap > https://github.com/openstack/horizon/blob/master/.mailmap > https://github.com/openstack/nova/b

Re: [openstack-dev] [tripleo] When to use parameters vs parameter_defaults

On Thu, Nov 19, 2015 at 06:50:35PM +0200, Juan Antonio Osorio wrote: >On Thu, Nov 19, 2015 at 6:16 PM, Steven Hardy wrote: > > On Mon, Nov 16, 2015 at 08:15:48PM +0100, Giulio Fidente wrote: > > On 11/16/2015 04:25 PM, Steven Hardy wrote: > > >Hi all, > > > > > >I wan

Re: [openstack-dev] [nova][infra] Getting a bleeding edge libvirt gate job running

Tony Breeds wrote on 11/18/2015 10:43:30 PM: > From: Tony Breeds > To: "Daniel P. Berrange" , "OpenStack Development > Mailing List (not for usage questions)" > Date: 11/18/2015 10:44 PM > Subject: Re: [openstack-dev] [nova][infra] Getting a bleeding edge > libvirt gate job running > > On We

Re: [openstack-dev] [nova] [Openstack-operators] Profiling nova-conductor and eventlet

Kris and I also experimented with: https://gist.github.com/harlowja/d2b5fc5282c76f10bc3f (which is like the entrypoint to cProfile but instead using the eventlet profiler module instead), that didn't appear to go so well... So any thoughts would be great here (especially around how to profile

Re: [openstack-dev] [infra][glance] How do we fix the glance_store git > glance-store LP mapping?

On 11/19/15, 10:00, "Matt Riedemann" wrote: >Patches in Gerrit aren't syncing status to the glance-store project in >launchpad b/c the project in launchpad is called glance-store and in git >it's glance_store. > >Looking at the project creators guide it says to specify a group for the >mapping

Re: [openstack-dev] [neutron][tap-as-a-service] weekly meeting

Hi Yamamoto, Thanks for resuming work on this effort. TAP-as-a-service is a very important feature, and great to see we are considering use case scenarios and adjusting APIs accordingly. I have some thoughts on the use case scenarios, which are seen as most common ones, when talking to operators.

Re: [openstack-dev] [releases] Release countdown for week R-19, Nov 23-27

On 11/19/2015 8:42 AM, Doug Hellmann wrote: Excerpts from Matt Riedemann's message of 2015-11-18 18:22:59 -0600: On 11/18/2015 4:09 PM, Doug Hellmann wrote: Focus - We are currently working towards the Mitaka 1 milestone scheduled for Dec 1-3. Teams should be focusing on wrapping up inc

Re: [openstack-dev] [trove] trove unit tests failing on stable/kilo [imm]

On 11/19/2015 10:22 AM, Amrith Kumar wrote: Just catching up on this thread, have fixes been submitted for this already? Thanks, -amrith -Original Message- From: Matt Riedemann [mailto:[email protected]] Sent: Wednesday, November 18, 2015 2:54 PM To: [email protected]

[openstack-dev] [Manila] Mitaka deadlines

Based on discussions going back to the Liberty feature freeze, we have decided to add some additional deadlines for Mitaka, to avoid having fire drills at the end of the release, and to focus core reviewer attention on the right things. As always, we will enforce a Feature Freeze on the M-3 mi

Re: [openstack-dev] [trove] trove unit tests failing on stable/kilo [imm]

Thanks Matt, Craig (cp16net) is working on fixing this. -amrith > -Original Message- > From: Matt Riedemann [mailto:[email protected]] > Sent: Thursday, November 19, 2015 12:24 PM > To: [email protected] > Subject: Re: [openstack-dev] [trove] trove unit tests fail

Re: [openstack-dev] [Neutron][ThirdPartyCI] Running third party CI on networking-foo projects

Thanks a lot, Yamamoto. kakuma, I am assuming if you were able to set it up for a ofagent repo, then it should have been the standard procedure documented here [1]. I reach out to infra for any help. [1] http://docs.openstack.org/infra/system-config/third_party.html Fawad Khaliq On Wed, Nov 18

[openstack-dev] [nova] build_instance pre hook cannot set injected_files for new instance

I have some code that uses the build_instance pre hook to set injected_files in the new instance. With the kilo code, the argv[7] was passed as [] - so I could append/extend this value to add more injected_files. With the latest code, this is passed as None, so I can't set it. How can I pass

Re: [openstack-dev] [lbaas] [octavia] Proposing Bertrand Lallau as Octavia Core

All, As I said in a previous e-mail I am really excited about the deep talent in the Octavia sub-project. So it is my pleasure to propose Bertrand Lallau (irc blallau) as a new core for the OpenStack Neutron Octavia sub project. His contributions [1] are in line with other cores and he has be

[openstack-dev] [nova] release notes with reno and which patches need that?

If you ever had a patch which contained "UpgradeImpact" or "DocImpact", this mail is for you. You may have already heard of "reno" and how it will change the handling of the release notes. If not, [1] is the announcement and [2] is an example. I wanted to preemptively ask if we want to add some gui

Re: [openstack-dev] [infra][glance] How do we fix the glance_store git > glance-store LP mapping?

On Thu, Nov 19, 2015, at 08:00 AM, Matt Riedemann wrote: > Patches in Gerrit aren't syncing status to the glance-store project in > launchpad b/c the project in launchpad is called glance-store and in git > it's glance_store. > > Looking at the project creators guide it says to specify a group f

Re: [openstack-dev] [Neutron] Call for review focus

++ On Wed, Nov 18, 2015 at 7:14 PM, Armando M. wrote: > Hi Neutrites, > > We are nearly two weeks away from the end of Mitaka 1. > > I am writing this email to invite you to be mindful to what you review, > especially in the next couple of weeks. Whenever you have the time to review > code, pleas

Re: [openstack-dev] [trove] trove unit tests failing on stable/kilo [imm]

> On Nov 19, 2015, at 11:24 AM, Matt Riedemann > wrote: > > > > On 11/19/2015 10:22 AM, Amrith Kumar wrote: >> Just catching up on this thread, have fixes been submitted for this already? >> >> Thanks, >> >> -amrith >> >>> -Original Message- >>> From: Matt Riedemann [mailto:mrie...

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

On Mon, Nov 9, 2015 at 1:39 PM, Shraddha Pandhe wrote: > Thats great. L3 layer network model is definitely one of our most important > requirements. All our go-forward deployments are going to be L3. So this is > a big deal for us. I think we're on a good path to getting this figured out over the

[openstack-dev] [Manila] Midcycle meetup survey

If you planning to attend the midcycle in any capacity, please vote your preferences here: https://www.surveymonkey.com/r/BXPLDXT -Ben __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-

Re: [openstack-dev] [Manila] Mitaka deadlines

On 11/19/2015 12:24 PM, Ben Swartzlander wrote: Based on discussions going back to the Liberty feature freeze, we have decided to add some additional deadlines for Mitaka, to avoid having fire drills at the end of the release, and to focus core reviewer attention on the right things. As always,

Re: [openstack-dev] [magnum] Mesos Conductor

Hi, At the present scenario, we can have mesos conductor with existing attributes[1]. Or we can add extra options like 'portMappings', 'instances', 'uris'[2]. And the other options is to take json file as input to 'magnum container-create' and dispatch it to corresponding conductor. And the con

Re: [openstack-dev] [openstack-dev ] [Heat] how to verify heat resource plugin

Hi Mohan, well, you should have the service you are developing the resource plugin for installed somewhere and run heat against it, creating the stack with the new resource type your plugin is defining, and checking that the thing it creates is working, can be updated and deleted via heat template

[openstack-dev] [nova] What things do we want to get into a python-novaclient 3.0 release?

We've been talking about doing a 3.0 release for novaclient for awhile so we can make some backward incompatible changes, like: 1. Removing the novaclient.v1_1 module 2. Dropping py26 support (if there is any explicit py26 support in there) What else are people aware of? Monty was talking abou

[openstack-dev] [oslo] Should we make qpid/proton optional dependencies? (please say yes)

I want to fix a thing in oslo.messaging but to my surprise I can't run pep8. This is because python-qpid-proton tries to install qpid-proton and it can't get that because the apache site where it's hosted is down. [1] The apache site for qpid has actually been down a lot lately, I coincidental

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

Folks I guess it should be pretty simple to roll back - install older version and restore the backup with preservation of /var/log directory. On Thu, Nov 19, 2015 at 7:38 PM, Sergii Golovatiuk wrote: > Hi, > > On Thu, Nov 19, 2015 at 5:50 PM, Matthew Mosesohn > wrote: > >> Vladimir, >> >> The

Re: [openstack-dev] [lbaas] [octavia] Proposing Bertrand Lallau as Octavia Core

+1 On Thu, 2015-11-19 at 17:35 +, Eichberger, German wrote: > All, > > > > As I said in a previous e-mail I am really excited about the deep talent in > the Octavia sub-project. So it is my pleasure to propose Bertrand Lallau (irc > blallau) as a new core for the OpenStack Neutron Octavia

Re: [openstack-dev] [magnum] Mesos Conductor

I’m open to allowing magnum to pass a blob of data (such as a lump of JSON or YAML) to the Bay's native API. That approach strikes a balance that’s appropriate. Adrian On Nov 19, 2015, at 10:01 AM, bharath thiruveedula mailto:[email protected]>> wrote: Hi, At the present scenario, we c

Re: [openstack-dev] [lbaas] [octavia] Proposing Bertrand Lallau as Octavia Core

+1 > On Nov 19, 2015, at 11:39 AM, Brandon Logan > wrote: > > +1 > > On Thu, 2015-11-19 at 17:35 +, Eichberger, German wrote: >> All, >> >> >> >> As I said in a previous e-mail I am really excited about the deep talent in >> the Octavia sub-project. So it is my pleasure to propose Bert

Re: [openstack-dev] [Openstack-operators] [logs] Neutron not logging user information on wsgi requests by default

Sorry, I missed this earlier. I was in no way meaning to suggest running devstack for production. I was asking that operators look at their wsgi logs, and see if they are logging a username/tenant for Neutron requests. If not, providing a way to fix that (which I happened to take from DevStack)

Re: [openstack-dev] [lbaas] [octavia] Proposing Bertrand Lallau as Octavia Core

+1 On Thu, Nov 19, 2015 at 9:35 AM, Eichberger, German wrote: > All, > > > > As I said in a previous e-mail I am really excited about the deep talent in > the Octavia sub-project. So it is my pleasure to propose Bertrand Lallau (irc > blallau) as a new core for the OpenStack Neutron Octavia sub

Re: [openstack-dev] [oslo] Should we make qpid/proton optional dependencies? (please say yes)

yes :) On Thu, Nov 19, 2015 at 1:22 PM, Matt Riedemann wrote: > I want to fix a thing in oslo.messaging but to my surprise I can't run pep8. > This is because python-qpid-proton tries to install qpid-proton and it can't > get that because the apache site where it's hosted is down. [1] > > The a

Re: [openstack-dev] [oslo] Should we make qpid/proton optional dependencies? (please say yes)

On 11/19/2015 12:22 PM, Matt Riedemann wrote: I want to fix a thing in oslo.messaging but to my surprise I can't run pep8. This is because python-qpid-proton tries to install qpid-proton and it can't get that because the apache site where it's hosted is down. [1] The apache site for qpid has a

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

Hey guys, Despite the fact I like containers (as deployment unit), we don't use them so. That means I +1 idea to drop containers, just because I believe that would * simplify a lot of things * helps get rid of huge amount of hacks * increase master node deployment * release us from annoying suppo

Re: [openstack-dev] [tripleo] When to use parameters vs parameter_defaults

My personal preference is to say: 1. Any templates which are included in the default environment (e.g overcloud-resource-registry-puppet.yaml), must expose their parameters via overcloud-without-mergepy.yaml 2. Any templates which are included in the default environment, but via a "noop" impleme

Re: [openstack-dev] How to add a periodic check for typos?

So since requirements usually has an 's' on the end, would you make my cheque for $1.00 payable to the Campaign Against Smog Hazard please? Just use our initials. -- MC __ OpenStack Development Mailing List (not for usage qu

  1   2   >