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

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

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: openstack-in...@lists.openstack.org > Date: 11/12/2015 09:27 PM > Subject: Re:

[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

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

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

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

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

Le 19/11/2015 18:37, Markus Zoeller a écrit : 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

[openstack-dev] [Cinder] Mitaka Midcycle Sprint

Cinder Mitaka Midcycle Sprint Dates: January 26-29 (29th will be optional hack day) Location: NetApp Office 7301 Kit Creek Road, Research Triangle Park, NC 27709 https://www.openstreetmap.org/search?query=35.8578%2C-78.8839#map=16/35.8569/-78.8851 Contact: Tom Barron (tbarron) Nearest airport:

[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

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 > wrote: Hi, At

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

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

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

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

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"

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:

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

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

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

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

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

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

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

Great, I'll be around next Tuesday. -Lin On Thu, Nov 19, 2015 at 12:53 PM, Rob Cresswell (rcresswe) < rcres...@cisco.com> wrote: > As requested, > https://etherpad.openstack.org/p/horizon-bug-day > > Rob > > From: Richard Jones > Reply-To: "OpenStack Development Mailing

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

++ > -Original Message- > From: Thierry Carrez [mailto:thie...@openstack.org] > Sent: Thursday, November 19, 2015 1:52 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [openstack][openstack-operators] IRC > meeting(s) > > JJ Asghar wrote: > > I've been seeing

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

It's great that we come to some agreement on unifying the client call ;-) As i proposed in previous thread, I think that "magnum app-create" may be better than "magnum create", I want to use "magnum app-create" to distinguish with "magnum container-create". The "app-create" may also not a good

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

Hello, Vladyslav Drok said on Thu, Nov 19, 2015 at 03:59:41PM +0200: 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

Re: [openstack-dev] [nova] Versioned notifications... who cares about the version?

ceilometer cares. we listen to all notifications and build Measurement and Event data from (some of) them. to be honest, i don't know if changes in nova notifications have/are broken in ceilometer because quite frankly there are far too many notifications to test and track. as a consumer of

Re: [openstack-dev] [all]Can we get some sanity in the Neutron logs please?

Thanks both Armando and Matt! I am cross posting this to the operators' list (as the main post -- operators, simple reply and no spam to dev). The logging tag should be a tag in all projects. I'm glad it's already there in Neutron. And, this sort of feedback is exactly what we need operators

Re: [openstack-dev] [nova] Versioned notifications... who cares about the version?

On 11/19/2015 5:52 PM, gord chung wrote: ceilometer cares. we listen to all notifications and build Measurement and Event data from (some of) them. to be honest, i don't know if changes in nova notifications have/are broken in ceilometer because quite frankly there are far too many

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

On 11/19/2015 09:32 AM, Kevin Carter wrote: > 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

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

Thanks Rob, next Tuesday is fine with me. -Zhenguo Sent from my iPhone > On Nov 19, 2015, at 19: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

[openstack-dev] [release][stable] OpenStack 2014.2.4 (juno)

Again, my plea to leave the Juno repository on git.openstack.org, but locked down to enable at least grenade testing for Juno->Kilo upgrades. For upgrade testing purposes, python2.6 is not needed as any cloud would have to upgrade python before upgrading to kilo. The testing could/should be

[openstack-dev] [security][sahara] creating a threat analysis to aid operators

hello all, during the security midcycle meetup we had a session about creating threat analysis for openstack projects. the folks at HPE were kind enough to offer their documentation and examples as an aid to creating these analysis. after talking with the sahara team, i am confident that we

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

On 11/19/2015 03:59 PM, Vladimir Kozhukalov wrote: > Anyway, the idea is to get > rid of Docker containers on the master node and switch to plane package > based approach that we used before. +1 __ OpenStack Development

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

When I originally wanted to create the naming for glance_store to be consistent across platforms, we already had the library glance_store out (actually it first called glance.store but due to the anxiety of namespace conflicts it was quickly renamed to glance_store in git/gerrit etc.). Creating a

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

+1, I found that 'kubectl create -f FILENAME’ (https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_create.md) works very well for different type of objects and I think we should try to use it. but I think we should support two use-cases - 'magnum

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

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,

[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

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

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

Yes, that is why I have suggested you either update the mapping so it is correct or you use glance which is what the mapping currently says you want to use. On Thu, Nov 19, 2015, at 12:08 PM, Nikhil Komawar wrote: > When I originally wanted to create the naming for glance_store to be > consistent

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

Let's do it. I'd like to suggest we use an etherpad to keep track of what people have done. If it's not created when I start my day, I'll make one. Richard On 19 November 2015 at 22:19, Rob Cresswell (rcresswe) wrote: > Hey folks, > > Our bug list is… rather large.

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

As requested, https://etherpad.openstack.org/p/horizon-bug-day Rob From: Richard Jones > Reply-To: "OpenStack Development Mailing List (not for usage questions)" >

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

On Thu, 19 Nov 2015, Julien Danjou wrote: It would be good to support that as being *normal*, not "potentially incorrect and random"! Yes. The underlying issue in this thread is the dominance of the six month cycle and the way this is perceived to be (any may actually be) a benefit for

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

On 11/19/2015 11:38 AM, Clark Boylan wrote: 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

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

Le 19/11/2015 20:46, Sylvain Bauza a écrit : Le 19/11/2015 18:37, Markus Zoeller a écrit : 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]

Re: [openstack-dev] [ironic] weekly subteam status report

On 17 November 2015 at 01:34, Naohiro Tamura wrote: > Ruby, > > Thanks for taking care of our weekly status report. > I'd like to just let you know that the iRMC part is somehow consolidated > with old statuses which I reported two and three weeks ago. > If this

[openstack-dev] [nova] Versioned notifications... who cares about the version?

Reading through [1] I started getting worries in the back of my head about versioning these notifications. The main concern being how can the consumer know about the versions and what's different between them? Because these versioned notification payloads hold live nova objects, there can be a

Re: [openstack-dev] [Fuel] Number of IP addresses in a public network

The high value of the bug here reflects that the error message is wrong. >From a UX side we could maybe even justify this as Critical. The error message must reflect the correct quantity of addresses required. On Tue, Nov 17, 2015 at 1:31 PM Roman Prykhodchenko wrote: > Folks,

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

On 19 November 2015 at 09:25, Brad P. Crochet wrote: > 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

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

On Tue, Nov 17, 2015 at 12:35 AM, Jim Rollenhagen wrote: > > > My preference is 4) no mid-cycle -- and try to work more effectively with > > people in different locations and time zones. > > ++ that was part of my thought process when I proposed not having an > official

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

> > Another idea I floated last week was to do a virtual midcycle of sorts. > > Treat it like a normal midcycle in that everyone tells their management > > "I'm out for 3-4 days for the midcycle", but they don't travel anywhere. > > We come up with an agenda, see if there's any planning/syncing

Re: [openstack-dev] [puppet] weekly meeting #59

Clayton O'Neill wrote: > On Tue, Nov 17, 2015 at 4:38 PM, Cody Herriges > wrote: > > Now that the standard is $::os_service_default does it mean that current > changes up for review with parameters set to the string ' DEFAULT>' should

Re: [openstack-dev] [nova] Versioned notifications... who cares about the version?

On 11/19/2015 4:05 PM, Ryan Rossiter wrote: Reading through [1] I started getting worries in the back of my head about versioning these notifications. The main concern being how can the consumer know about the versions and what's different between them? Because these versioned notification

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

On 11/18/2015 8:00 PM, Gareth wrote: Hi stacker, We could use some 3rd tools like topy: pip install topy topy -a git commit & git review Here is an example: https://review.openstack.org/#/c/247261/ Could we have a periodic job like Jenkins users updating our requirement.txt?

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

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

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

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

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

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

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

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

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

> -Original Message- > From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] > 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

[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

[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

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

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

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

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 < > lucasago...@gmail.com> wrote: > >> Hi, >> >> > I sent a new idea to

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

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

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

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

On 19 November 2015 at 18:26, Assaf Muller wrote: > On Wed, Nov 18, 2015 at 9: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

[openstack-dev] [tacker] Automatic flavor creation

Hi tackers, I am working on automatic flavor creation RFE[1]. I have written my thoughts on implementing on it. I would like to see your comments on it. Due to time differences, I was not able to directly ping core members in IRC. [1]https://bugs.launchpad.net/tacker/+bug/1516193 RegardsBharath

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

On Fri, Nov 20, 2015 at 2:27 AM, Fawad Khaliq wrote: > 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]

[openstack-dev] What's Up, Doc? 20 Nov 2015

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi everyone, This week I've been working on catching up with some reviews and bug triage, I've been speaking to O'Reilly about the future of the Ops Guide, and also been working on a range of other things including docs-specs core team review,

Re: [openstack-dev] [Ceilometer]:Subscribe and Publish Notification frame work in Ceilometer !

On 19/11/15 10:26 PM, Srikanth Vavilapalli wrote: Hi Gord On your second point, Yes, Ceilometer does provide a framework to capture a notification and republish to multiple “publish targets” in addition to the collector service using udp/kafka/notification as the transport mechanisms… We

[openstack-dev] What's Up Doc, 20 Nov 2015

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi everyone, This week I've been working on catching up with some reviews and bug triage, I've been speaking to O'Reilly about the future of the Ops Guide, and also been working on a range of other things including docs-specs core team review,

Re: [openstack-dev] [Neutron] Mid-cycle meetup for Mitaka

Guys, Is there a conclusion now? What's the schedule of Neutron Mid-cycle? On Thu, Nov 5, 2015 at 9:31 PM, Gary Kotton wrote: > Hi, > In Nova the new black is the os-vif-lib > (https://etherpad.openstack.org/p/mitaka-nova-os-vif-lib). It may be > worthwhile seeing if we can

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

On Wed, Nov 18, 2015 at 9: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

Re: [openstack-dev] [Ceilometer]:Subscribe and Publish Notification frame work in Ceilometer !

Hi Gord On your second point, Yes, Ceilometer does provide a framework to capture a notification and republish to multiple "publish targets" in addition to the collector service using udp/kafka/notification as the transport mechanisms... We believe this is how "Event Alarm Evaluator" module in

[openstack-dev] OpenStack-Announce List

Hi all, I'd like to get your thoughts about the OpenStack-Announce list. We describe the list as: """ Subscribe to this list to receive important announcements from the OpenStack Release Team and OpenStack Security Team. This is a low-traffic, read-only list. """ Up until July 2015, it was

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

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

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:mrie...@linux.vnet.ibm.com] > Sent: Wednesday, November 18, 2015 2:54 PM > To: openstack-dev@lists.openstack.org > Subject: Re:

[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

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

Re: [openstack-dev] [release][stable] OpenStack 2014.2.4 (juno)

fyi https://review.openstack.org/#/c/247677/ On Thu, Nov 19, 2015 at 8:56 PM, Rochelle Grober wrote: > Again, my plea to leave the Juno repository on git.openstack.org, but locked > down to enable at least grenade testing for Juno->Kilo upgrades. For upgrade >

[openstack-dev] [Senlin]Support more complicated scaling scenario

Hi, guys, Xu Jun is a contributor from CMCC. He asked a very interesting question about cluster scaling support in Senlin. To make the discussion more thorough, I just post the question and my answer here. The question from Jun is as following: For an action, senlin will check all according

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

Just talking about the idea of auto-spelling-fix. My example patch https://review.openstack.org/#/c/247261/ doesn't work. Topy fixes something and break others. So it is just okay to do auto-spelling-check now, not fix :( On Fri, Nov 20, 2015 at 6:31 AM, Matt Riedemann

[openstack-dev] [cinder][nova]Move encryptors to os-brick

Hi all, To fix bug [1][2] in Cinder, Cinder needs to use nova/volume/encryptors[3] to attach/detach encrypted volumes. To decrease the code duplication, I raised a BP[4] to move encryptors to os-brick[5]. Once it is done, Nova needs to update to use the common library. This is BP raised.

Re: [openstack-dev] [nova] Versioned notifications... who cares about the version?

On 19/11/15 08:53 PM, Matt Riedemann wrote: On 11/19/2015 5:52 PM, gord chung wrote: ceilometer cares. we listen to all notifications and build Measurement and Event data from (some of) them. to be honest, i don't know if changes in nova notifications have/are broken in ceilometer because

Re: [openstack-dev] OpenStack-Announce List

On 2015-11-19 11:00 PM, Tom Fifield wrote: > > Personally, I no longer consider this volume "low traffic" :) > > In addition, I have been recently receiving feedback that users have > been unsubscribing from or deleting without reading the list's posts. > > That isn't good news, given this is

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

Dmitry, I mean whole feature. Btw, why do you want to grant capabilities via puppet? It should be done by post-install package section, I believe. Also I doesn't know if supervisord can bound process capabilities like systemd can - we could use this opportunity too. On Thu, Nov 19, 2015 at 7:44

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

+1 to remove containers On Fri, Nov 20, 2015 at 12:29 AM, Thomas Goirand wrote: > On 11/19/2015 03:59 PM, Vladimir Kozhukalov wrote: > > Anyway, the idea is to get > > rid of Docker containers on the master node and switch to plane package > > based approach that we used

[openstack-dev] [Neutron] Bug update

Hi, There are a ton of old and ancient bugs that have not been trained. If you guys have some time then please go over them. In most cases some are not even bugs and are just questions. I have spent the last few days going over and training a few. Over the last two days a number of bugs related

  1   2   >