[openstack-dev] [Nova] Enable policy improvment both v2/v3 API or not

Hi, guys There are some BPs working on improve the usability of API policy. Initially those BP just for v2.1/v3 API. For v2 API, we just want to it keep the same as before. But in Juno design summit, we get some complain about policy is hard to use. (https://etherpad.openstack.org/p/juno-nova-de

[openstack-dev] [Glance][OSSG] - Glance Security Note needs a quick review

Hi Glance Guys, I’ve just added Glance-core to https://review.openstack.org/#/c/96540/ It’s a security note regarding the image publication issues in some versions of Glance. Our policy is that we get at least one core developer from an affected project to +1 an OSSN before it’s released so I’

[openstack-dev] [Ironic] Deploying Ironic with devstack, instance stuck on spawning

Hi, I'm trying to deploy Ironic with devstack. I'm using Ubuntu 14.04 and follow the manual on http://docs.openstack.org/developer/ironic/dev/dev-quickstart.html#deploying-ironic-with-devstack Everything works fine until I want to spawn a new instance. The instance remains in the spawning task. T

Re: [openstack-dev] Selecting more carefully our dependencies

On Thu, May 29, 2014 at 11:25 AM, Thomas Goirand wrote: > So I'm wondering: are we being careful enough when selecting > dependencies? In this case, I think we haven't, and I would recommend > against using wrapt. Not only because it embeds six.py, but because > upstream looks uncooperative, and

Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup

On Fri, May 30, 2014 at 4:57 AM, Zane Bitter wrote: > On 29/05/14 13:33, Mike Spreitzer wrote: > >> Devananda van der Veen wrote on 05/29/2014 >> 01:26:12 PM: >> >> > Hi Jaromir, >> > >> > I agree that the midcycle meetup with TripleO and Ironic was very >> > beneficial last cycle, but this

Re: [openstack-dev] [Neutron] How about deprecate cfg.CONF.allow_overlapping_ips?

Even though the OS supports it now, it's possible that there could still be network backends that don't handle it yet. Specifically certain L3 router implementations that map to a physical router that doesn't support the overlapping spaces. I'm not sure how many deployments are like that, but it's

[openstack-dev] Clone all of OpenStack and Stackforge?

I’m sure there’s a nice way to do this, I want to pull down all the stable code for all the current OpenStack and Stackforge projects to plug into some analytics tooling, whats the best way to do this? -Rob ___ OpenStack-dev mailing list OpenStack-dev

Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup

Excerpt from Zane Bitter's message on 29/05/2014 20:57:10: > From: Zane Bitter > To: openstack-dev@lists.openstack.org > Date: 29/05/2014 20:59 > Subject: Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle > collaborative meetup > BTW one timing option I haven't seen mentioned is to follow

Re: [openstack-dev] [horizon][infra] Plan for the splitting of Horizon into two repositories

On 05/29/2014 08:40 PM, Gabriel Hurley wrote: >> we could have a poll for the name. >> Gabriel, would you like to run that? > > I can run that if you like, though it might be more official coming from the > PTL. ;-) I'm sure that David is reading this and that he will tell us when anything we ar

Re: [openstack-dev] [Neutron] One performance issue about VXLAN pool initiation

It seems that method has some room for optimization, and I suspect the same logic has been used in other type drivers as well. If optimization is possible, it might be the case to open a bug for it. Salvatore On 30 May 2014 04:58, Xurong Yang wrote: > Hi, > Thanks for your response, yes, i get

[openstack-dev] [Blazar] Weekly meeting Blazar (previously Climate) [Climate]

Hi, Due to some important changes with Climate (which is now Blazar) and as the team is quite changing, I want to make sure we run the weekly meeting today at 3pm UTC. Thanks, -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org ht

[openstack-dev] Weekly meeting Blazar (previously Climate)

Hi, Due to some important changes with Climate (which is now Blazar) and as the team is quite changing, I want to make sure we run the weekly meeting today at 3pm UTC. Thanks, -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org ht

Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal

Hello Takashi, thanks for doing this! As we have proposed ExaBgp[1] in the Dynamic Routing blueprint[2], I've added a new column for this speaker in the wiki page. I plan to fill it soon. ExaBgp was our first choice because we thought that run something in library mode would be much more easy to

Re: [openstack-dev] [Murano] Application Actions

Agree. Lets for now assume nothing about events and have separate list of blueprints for actions. As soon as we get back to event design we will decide how they connected with actions and maybe then mark some of event blueprints as obsolete/superseded Sincerely yours, Stan Lagun Principal Software

Re: [openstack-dev] [Neutron] Introducing task oriented workflows

Hi Hirofumi, I reckon this has been immediately recognised as a long term effort. However, I just want to clarify that by "long term" I don't mean pushing it back until we get to the next release cycle and we realize we are in the same place where we are today! It is totally correct that most Neu

Re: [openstack-dev] Designate Incubation Request

Zane Bitter wrote: > I think the problem is that we still have elements of the 'project' > terminology around from the bad old days of the pointless > core/core-but-don't-call-it-core/library/gating/supporting project > taxonomy, where project == repository. The result is that every time a > new pr

[openstack-dev] [Unit-test] Cinder Driver

Hi All, I have developed a cinder driver. Can you please share the steps to create an unit test environment and how to run unit test? *Thanks & Regards*, Yogesh Prasad. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.opens

Re: [openstack-dev] License Management

Tizy Ninan wrote: > Are there are any software license management tools available for > openstack ? For eg. the tool should track the usage of the number of > instances launched using a particular licensed image. > Are there any third party tools also available for this? This is a development-focu

Re: [openstack-dev] [tripleO] Should #tuskar business be conducted in the #tripleo channel?

On 30/05/14 02:08, James Slagle wrote: > On Thu, May 29, 2014 at 12:25 PM, Anita Kuno wrote: >> As I was reviewing this patch today: >> https://review.openstack.org/#/c/96160/ >> >> It occurred to me that the tuskar project is part of the tripleo >> program: >> http://git.openstack.org/cgit/openst

Re: [openstack-dev] [keystone] Redesign of Keystone Federation

Hello, For what it is worth I was toying around with the possibility to extend the federation mapping mechanism to be used with keystone's external auth plugin. I believe this would allow easy, immediate and generic support of other federation protocols through apache mods without the need to w

Re: [openstack-dev] License Management

Thank You. Regards, Tizy On Fri, May 30, 2014 at 2:34 PM, Thierry Carrez wrote: > Tizy Ninan wrote: > > Are there are any software license management tools available for > > openstack ? For eg. the tool should track the usage of the number of > > instances launched using a particular licensed

Re: [openstack-dev] [Blazar] Weekly meeting Blazar (previously Climate) [Climate]

It's still there, yes. I'll be there with 50% activity, I guess, so I'd like to ask Pablo to be chair on this one. On Fri, May 30, 2014 at 12:44 PM, Sylvain Bauza wrote: > Hi, > > Due to some important changes with Climate (which is now Blazar) and as > the team is quite changing, I want to mak

Re: [openstack-dev] License Management

Hi Tizy, May be this is not the right mailing list for that question (what about openstack-operators)? We do have that feature in our StackOps Chargeback product. It can work on any OpenStack Nova solution since Folsom. Regards Diego -- Diego Parrilla *CEO* *www.stack

Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal

Hi, I was about mentionning ExaBGP too! can we also consider using those BGP speakers for BGPVPN implementation [1]. This would be consistent to have the same BGP speaker used for every BGP needs inside Neutron. [1]https://review.openstack.org/#/c/93329/ On Fri, May 30, 2014 at 10:54 AM, Jaume

Re: [openstack-dev] [neutron][L3] VM Scheduling v/s Network as input any consideration ?

Hi. At this moment, Neutron doesn't offer physical network information for now. There is a proposal for it[1] and it was discussed at the summit [2]. Although it is still early design phase[3][4], using routing protocol will surely help to discover physical network topology. [1] https://wiki.ope

Re: [openstack-dev] Selecting more carefully our dependencies

Thomas Goirand wrote: > So I'm wondering: are we being careful enough when selecting > dependencies? In this case, I think we haven't, and I would recommend > against using wrapt. Not only because it embeds six.py, but because > upstream looks uncooperative, and bound to its own use cases. Propose

[openstack-dev] [TripleO] Adding Tuskar to weekly IRC meetings agenda

Hi All, I would like to propose to add Tuskar as a permanent topic to the agenda for our weekly IRC meetings. It is an official TripleO's project, there happening quite a lot around it and we are targeting for Juno to have something solid. So I think that it is important for us to regularly k

[openstack-dev] [Neutron][ML2] Modular agent architecture

Hi all, Modular agent seems to have to choose between two type of architecture [1]. As I understood during the last ML2 meeting [2], Extension driver seems to be the most reasonnable choice. But I think that those two approaches are complementory : Extension drivers will deal with RPC callbacks f

Re: [openstack-dev] [tripleO] Should #tuskar business be conducted in the #tripleo channel?

On 30.5.2014 11:06, Tomas Sedovic wrote: On 30/05/14 02:08, James Slagle wrote: On Thu, May 29, 2014 at 12:25 PM, Anita Kuno wrote: As I was reviewing this patch today: https://review.openstack.org/#/c/96160/ It occurred to me that the tuskar project is part of the tripleo program: http://git

Re: [openstack-dev] [tripleO] Should #tuskar business be conducted in the #tripleo channel?

On 2014/30/05 02:08, James Slagle wrote: On Thu, May 29, 2014 at 12:25 PM, Anita Kuno wrote: As I was reviewing this patch today: https://review.openstack.org/#/c/96160/ It occurred to me that the tuskar project is part of the tripleo program: http://git.openstack.org/cgit/openstack/governanc

[openstack-dev] [UX] Reminder - UX initial meeting starts on Monday

Hi UXers, I just wanted to remind all, that on Monday June 2, 2014 at 1700 UTC we are starting with OpenStack UX meetings (#openstack-meeting-3). More details: https://wiki.openstack.org/wiki/Meetings/UX I'd like to ask all participants if you could write your time zones here: https://etherp

Re: [openstack-dev] [TripleO] [Ironic] [Heat] [Nova] Mid-cycle collaborative meetup

Hi Devananda, it is interesting. I think that we can invite Nova as well and join our efforts at one place. It will be like a tiny (more focused) summit but it sounds that all projects can benefit a lot from it. What do you think? [added Nova tag to the subject] Nova folks, what do you think

Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup

On 2014/29/05 20:57, Zane Bitter wrote: On 29/05/14 13:33, Mike Spreitzer wrote: Devananda van der Veen wrote on 05/29/2014 01:26:12 PM: > Hi Jaromir, > > I agree that the midcycle meetup with TripleO and Ironic was very > beneficial last cycle, but this cycle, Ironic is co-locating its >

Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup

On 2014/30/05 10:00, Thomas Spatzier wrote: Excerpt from Zane Bitter's message on 29/05/2014 20:57:10: From: Zane Bitter To: openstack-dev@lists.openstack.org Date: 29/05/2014 20:59 Subject: Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup BTW one timing option I

Re: [openstack-dev] [Keystone] [Blazar] [Ironic] Py26/27 gates failing because of keystoneclient-0.9.0

Le 30/05/2014 14:00, Sylvain Bauza a écrit : > Hi Keystone developers, > > I just opened a bug [1] because Ironic and Blazar (ex. Climate) patches > are failing due to a new release in Keystone client which seems to > regress on midleware auth. > > Do you have any ideas on if it's quick to fix, or

[openstack-dev] [Keystone] [Blazar] [Ironic] Py26/27 gates failing because of keystoneclient-0.9.0

Hi Keystone developers, I just opened a bug [1] because Ironic and Blazar (ex. Climate) patches are failing due to a new release in Keystone client which seems to regress on midleware auth. Do you have any ideas on if it's quick to fix, or shall I provide a patch to openstack/global-requirements.

[openstack-dev] Mahout-as-a-service [job]

On 05/28/2014 12:37 PM, Dat Tran wrote: >* Hi everyone, *>>* I have a idea for new project: Mahout-as-a-service. *>* Main idea of this project: *>* - Install OpenStack *>* - Deploying OpenStack Sahara source *>* - Deploying Mahout on Sahara OpenStack system. *>* - Construction of the API. *>>* Thro

Re: [openstack-dev] [Keystone] [Blazar] [Ironic] Py26/27 gates failing because of keystoneclient-0.9.0

I did not look close to this concrete issue, but in the ceilometer there is almost the same thing: https://bugs.launchpad.net/ceilometer/+bug/1324885 and fixes were already provided. Will this help Blazar? -- Dina On Fri, May 30, 2014 at 4:00 PM, Sylvain Bauza wrote: > Hi Keystone developers,

Re: [openstack-dev] [Keystone] [Blazar] [Ironic] Py26/27 gates failing because of keystoneclient-0.9.0

Le 30/05/2014 14:07, Dina Belova a écrit : > I did not look close to this concrete issue, but in the ceilometer > there is almost the same > thing: https://bugs.launchpad.net/ceilometer/+bug/1324885 and fixes > were already provided. > > Will this help Blazar? > Got the Ironic patch as well : htt

Re: [openstack-dev] [neutron][L3] VM Scheduling v/s Network as input any consideration ?

Mathieu Rohon wrote: >I'm also very interested in scheduling VMs with Network requirement. This >seems to be in the scope of NFV workgroup >[1]. >For instance, I think that scheduling should take into account bandwith/QoS >requirement for a VM, or specific Nic This falls in my area of interest a

Re: [openstack-dev] [Openstack] Bad perf on swift servers...

Hi Hugo, Thanks for the reply. Sorry for the delay in this reply. A couple of disks in one of the swift servers was accidentally wiped a couple of days back. And swift was trying hard to restore back the data to those disks. It looks like this was definitely contributing to the CPU load. Does swif

Re: [openstack-dev] [climate] Friday Meeting [1]

Thank you! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] [Ironic] [Heat] [Nova] Mid-cycle collaborative meetup

Excerpts from Jaromir Coufal's message of 2014-05-30 17:16:21 +0530: > Hi Devananda, > > it is interesting. I think that we can invite Nova as well and join our > efforts at one place. It will be like a tiny (more focused) summit but > it sounds that all projects can benefit a lot from it. What

[openstack-dev] [Marconi] Kafka support and high throughput

Has anyone given thought to using Kafka to back Marconi? And has there been discussion about adding high throughput APIs to Marconi. We're looking at providing Kafka as a messaging service for our customers, in a scenario where throughput is a priority. We've had good luck using both streamin

Re: [openstack-dev] Monitoring as a Service

Thanks!!! I was actually going to ask this issue :) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] One performance issue about VXLAN pool initiation

I agree with Salvatore, I don't the optimization of that method (and possibly others) requires a BP, but rather a bug. Can you please file one Xurong? Thanks, Kyle On Fri, May 30, 2014 at 3:39 AM, Salvatore Orlando wrote: > It seems that method has some room for optimization, and I suspect the

Re: [openstack-dev] [neutron][L3] VM Scheduling v/s Network as input any consideration ?

Le 30/05/2014 14:44, CARVER, PAUL a écrit : > > Mathieu Rohon wrote: > > > > >I'm also very interested in scheduling VMs with Network requirement. > This seems to be in the scope of NFV workgroup >[1]. > > >For instance, I think that scheduling should take into account > bandwith/QoS requirement

[openstack-dev] Juno mid-cycle sprint in Paris, July 2014

Hi fellow OpenStack developers, I'm glad to announce that we're organizing a mid-cycle hacking sprint in Paris (in eNovance office) from 2nd July to 4th July 2014. This mid-cycle sprint is not tied to any particular OpenStack project, so it can be the occasion to have some cross-project hacking to

Re: [openstack-dev] [tripleO] Should #tuskar business be conducted in the #tripleo channel?

On Thu, May 29, 2014 at 12:25:02PM -0400, Anita Kuno wrote: > As I was reviewing this patch today: > https://review.openstack.org/#/c/96160/ > > It occurred to me that the tuskar project is part of the tripleo > program: > http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.

Re: [openstack-dev] [Unit-test] Cinder Driver

Hi Yogesh, The best way to start writing tests is to get some examples from tests already implemented. Since icehouse release, all tests must be written with mock¹. Most of the tests on the codebase are written with the old framework (mox), please have a look on this implementations: cinder/tests

Re: [openstack-dev] [TripleO] Change of meeting time

- Original Message - > From: "James Polley" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Saturday, 24 May, 2014 1:21:53 AM > Subject: [openstack-dev] [TripleO] Change of meeting time > > Following a lengthy discussion under the subject "Alternating mee

Re: [openstack-dev] [tripleO] Should #tuskar business be conducted in the #tripleo channel?

- Original Message - > From: "Jaromir Coufal" > To: openstack-dev@lists.openstack.org > Sent: Friday, 30 May, 2014 12:04:29 PM > Subject: Re: [openstack-dev] [tripleO] Should #tuskar business be conducted > in the #tripleo channel? > > > I'd say yes. I don't think the additional traffic

Re: [openstack-dev] Clone all of OpenStack and Stackforge?

On Fri, May 30, 2014 at 3:58 AM, Clark, Robert Graham wrote: > I’m sure there’s a nice way to do this, I want to pull down all the stable > code for all the current OpenStack and Stackforge projects to plug into some > analytics tooling, whats the best way to do this? > > -Rob I use a script wi

Re: [openstack-dev] [TripleO] Adding Tuskar to weekly IRC meetings agenda

On Fri 30 May 2014 04:13:31 AM MDT, Jaromir Coufal wrote: > Hi All, > > I would like to propose to add Tuskar as a permanent topic to the > agenda for our weekly IRC meetings. It is an official TripleO's > project, there happening quite a lot around it and we are targeting > for Juno to have someth

Re: [openstack-dev] [oslo][db] oslo.db repository review request

On 4/25/2014 7:46 AM, Doug Hellmann wrote: On Fri, Apr 25, 2014 at 8:33 AM, Matt Riedemann wrote: On 4/18/2014 1:18 PM, Doug Hellmann wrote: Nice work, Victor! I left a few comments on the commits that were made after the original history was exported from the incubator. There were a cou

Re: [openstack-dev] [nova][vmware] Current state of the spawn refactor

On 5/27/2014 4:43 PM, Davanum Srinivas wrote: Hi Michael, * Phase 1 has one review left - https://review.openstack.org/#/c/92691/ * I'll update the phase 2 patch shortly - https://review.openstack.org/#/c/87002/ * Once the 2 reviews above get approved, we will resurrect the oslo.vmware BP/revi

Re: [openstack-dev] [Blazar] Weekly meeting Blazar (previously Climate) [Climate]

I'll be back to weekly meetings from next Friday. Nikolay Starodubtsev Software Engineer Mirantis Inc. Skype: dark_harlequine1 2014-05-30 2:20 GMT-07:00 Dina Belova : > It's still there, yes. > I'll be there with 50% activity, I guess, so I'd like to ask Pablo to be > chair on this one. >

Re: [openstack-dev] [Fuel-dev] [Openstack-dev] New RA for Galera

Bartosz, this looks like a part of our global approach to rewrite pacemaker providers to use crm_diff command instead of cs_shadow/commit approach. ( part of https://blueprints.launchpad.net/fuel/+spec/ha-pacemaker-improvements) If reboot attributes do not help, then we should reconsider this app

Re: [openstack-dev] [FUEL][Design session 5.1] 28/05/2014 meeting minutes

Guys, we gonna have a more extended design FUEL Library design meeting in IRC channel during regular FUEL Meeting on May 5th. So, feel free to add blueprints to meeting agenda and we will consider adding them to 5.1 Roadmap. On Wed, May 28, 2014 at 7:41 PM, Vladimir Kuklin wrote: > Hey, folks

Re: [openstack-dev] [oslo][db] oslo.db repository review request

Hi Matt, We're waiting for a few important fixes to be merged (usage of oslo.config, eventlet tpool support). Once those are merged, we'll cut the initial release. Thanks, Roman On Fri, May 30, 2014 at 5:19 PM, Matt Riedemann wrote: > > > On 4/25/2014 7:46 AM, Doug Hellmann wrote: >> >> On Fri,

Re: [openstack-dev] [oslo][db] oslo.db repository review request

Hey Roman, will it be the alpha version that should not be used by other projects or it'll be ready to use? Thanks. On Fri, May 30, 2014 at 6:36 PM, Roman Podoliaka wrote: > Hi Matt, > > We're waiting for a few important fixes to be merged (usage of > oslo.config, eventlet tpool support). Once

Re: [openstack-dev] [FUEL][Design session 5.1] 28/05/2014 meeting minutes

june 5th? On Fri, May 30, 2014 at 4:33 PM, Vladimir Kuklin wrote: > Guys, we gonna have a more extended design FUEL Library design meeting in > IRC channel during regular FUEL Meeting on May 5th. So, feel free to add > blueprints to meeting agenda and we will consider adding them to 5.1 > Road

[openstack-dev] [sahara] team meeting minutes May 29

Thanks everyone who have joined Sahara meeting. Here are the logs from the meeting: Minutes: http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-05-29-18.01.html Log: http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-05-29-18.01.log.html -- Sincerely yours, Sergey Lu

Re: [openstack-dev] [Neutron][LBaaS] dealing with M:N relashionships for Pools and Listeners

Hi Sam and Stephen, On Thu, 2014-05-29 at 21:10 -0700, Stephen Balukoff wrote: > Hi Sam, > > > Here are my thoughts on this: > > > On Thu, May 29, 2014 at 12:32 PM, Samuel Bercovici > wrote: > Before solving everything, I would like first to itemize the > things we should solv

Re: [openstack-dev] [oslo][db] oslo.db repository review request

On Fri, May 30, 2014 at 11:06 AM, Sergey Lukjanov wrote: > Hey Roman, > > will it be the alpha version that should not be used by other projects > or it'll be ready to use? The current plan is to do alpha releases of oslo libraries during this cycle, with a final official release at the end. We'r

Re: [openstack-dev] [oslo][db] oslo.db repository review request

So, it means that we'll be able to migrate to oslo.db lib in the end of Juno? or early K? On Fri, May 30, 2014 at 7:30 PM, Doug Hellmann wrote: > On Fri, May 30, 2014 at 11:06 AM, Sergey Lukjanov > wrote: >> Hey Roman, >> >> will it be the alpha version that should not be used by other projects

Re: [openstack-dev] [oslo][db] oslo.db repository review request

Hi Sergey, tl;dr I'd like to be a ready to use version, but not 1.0.0. So it's a good question and I'd like to hear more input on this from all. If we start from 1.0.0, this will mean that we'll be very limited in terms of changes to public API we can make without bumping the MAJOR part of the

[openstack-dev] [nova][vmware] iSCSI and managing cluster-wide config

The vmware driver doesn't currently use auth information passed to it by cinder when attaching an iSCSI volume. I'm working on a patch to address this. Adding authentication to the existing code is relatively simple. However, in going over the code I've noticed a problem. The code assumes that th

Re: [openstack-dev] [oslo][db] oslo.db repository review request

Hi guys, +1 to Roman's suggestion. I think we have to use 0.MINOR.PATCH at least during a few cycles. API changes aren't a problem if we use a specific (frozen) version in requirements. Thanks, Igor On Fri, May 30, 2014 at 6:37 PM, Roman Podoliaka wrote: > Hi Sergey, > > tl;dr > > I'd like t

Re: [openstack-dev] [nova] SR-IOV nova-specs

Hey, -2 has been removed, feel free to ping me in IRC if you need quicker turn around, been traveling last few days. Thanks, John On 27 May 2014 19:21, Robert Li (baoli) wrote: > Hi John, > > Now that we have agreement during the summit on how to proceed in order to > get it in to Juno, please

Re: [openstack-dev] [Neutron][LBaaS] dealing with M:N relashionships for Pools and Listeners

Hi y'all! Re-responses inline: On Fri, May 30, 2014 at 8:25 AM, Brandon Logan wrote: > > > § Where can a user check the success of the update? > > > > > > > > > > Depending on the object... either the status of the child object > > itself or all of its affected parent(s). Since we're a

Re: [openstack-dev] [Keystone] [Blazar] [Ironic] Py26/27 gates failing because of keystoneclient-0.9.0

The auth_token middleware changed recently[1] to check if tokens retrieved from the cache are expired based on the expiration time in the token. The unit tests for Blazar, Ceilometer, and Ironic are all using a copy-pasted fake memcache implementation that's supposed to simulate what auth_token sto

Re: [openstack-dev] [Neutron] One performance issue about VXLAN pool initiation

This is very similar to IPAM... There is a space of possible ids or addresses that can grow very large. We need to track the allocation of individual ids or addresses from that space and be able to quickly come up with a new allocations and recycle old ones. I've had this in the back of my mind

Re: [openstack-dev] [keystone][federation] Coordination for Juno

Hello, I have just tried the new "specs" proposal. Hope it is not too bad (maybe the text could be better but english is not my language) :) I have also included some of you involved with federations as reviewers. Cheers, Marco On Tue, May 27, 2014 at 09:15:31AM -0500, Dolph Mathews wrote:

[openstack-dev] [Nova] nova-compute deadlock

Hi all, When I run Icehouse code, I encountered a strange problem. The nova-compute service becomes stuck, when I boot instances. I report this bug in https://bugs.launchpad.net/nova/+bug/1313477. After thinking several days, I feel I know its root cause. This bug should be a deadlock problem cau

Re: [openstack-dev] [All] Disabling Pushes of new Gerrit Draft Patchsets

On Wed, May 21, 2014 at 4:24 PM, Clark Boylan wrote: > Hello everyone, > > Gerrit has long supported "Draft" patchsets, and the infra team has long > recommended against using them as they are a source of bugs and > confusion (see below for specific details if you are curious). The newer > version

[openstack-dev] [Nova] Juno-1 Push and the J-1 (Soft)FeatureProposalFreeze

Hi, Juno-1 release date is now less than two weeks away: https://wiki.openstack.org/wiki/Juno_Release_Schedule In this weeks nova-meeting we decided to apply a kind of FeatureProposalFreeze for Juno-1. And that means... Reviewers (thats everyone!) = 1) Please lets give conc

Re: [openstack-dev] [nova] SR-IOV nova-specs

John, thanks for the review. I¹m going to clarify the things you mentioned in your comments, and upload a new version soon. thanks, Robert On 5/30/14, 12:35 PM, "John Garbutt" wrote: >Hey, > >-2 has been removed, feel free to ping me in IRC if you need quicker >turn around, been traveling last

[openstack-dev] [Glance][TC] Glance Functional API and Cross-project API Consistency

Hello All, I'm writing to notify you of the approach the Glance community has decided to take for doing functional API. Also, I'm writing to solicit your feedback on this approach in the light of cross-project API consistency. At the Atlanta Summit, the Glance team has discussed introducing fun

[openstack-dev] [barbican] Hacking to be enabled in pep8 gate

Hi All, I just wanted to give everyone a quick heads up that we’ve received a lot of contributions in the last couple of days to fix all of the Hacking violations in the Barbican codebase that have been outstanding since before incubation. We’re now ready to include Hacking checks as part of the

Re: [openstack-dev] [Glance] [Heat] Glance Metadata Catalog for Capabilities and Tags

On 29/05/14 18:42, Tripp, Travis S wrote: Hello everyone! At the summit in Atlanta we demonstrated the “Graffiti” project concepts. We received very positive feedback from members of multiple dev projects as well as numerous operators. We were specifically asked multiple times about getting th

Re: [openstack-dev] [Heat] Short term scaling strategies for large Heat stacks

On 29/05/14 19:52, Clint Byrum wrote: Multiple Stacks === We could break the stack up between controllers, and compute nodes. The controller will be less likely to fail because it will probably be 3 nodes for a reasonably sized cloud. The compute nodes would then live in their own st

Re: [openstack-dev] [Glance] [Heat] Glance Metadata Catalog for Capabilities and Tags

I think this is a great feature to have it in Glance. Tagging mechanism for objects which are not owned by Glance is complimentary to artifact catalog\repository in Glance. As soon as we keep tags and artifacts metadata close to each other the end-user will be able to use them seamlessly. Artifacts

Re: [openstack-dev] [Glance] Announcing glance-specs repo

Greetings! The glance-specs repository is now opened! - If you have a blueprint that is targeted for Juno-1 and Approved: you do not need to create a spec. Only two blueprints seem to fall into this category. See [1] for more details. - If you have a blueprint in Launchpad (approved or not,

Re: [openstack-dev] [TripleO] Adding Tuskar to weekly IRC meetings agenda

> On 30 May 2014, at 8:13 pm, Jaromir Coufal wrote: > > Hi All, > > I would like to propose to add Tuskar as a permanent topic to the agenda for > our weekly IRC meetings. It is an official TripleO's project, there happening > quite a lot around it and we are targeting for Juno to have somet

Re: [openstack-dev] [All] Disabling Pushes of new Gerrit Draft Patchsets

Yay! No more weird CR chains. On Fri, May 30, 2014 at 9:32 PM, Clark Boylan wrote: > On Wed, May 21, 2014 at 4:24 PM, Clark Boylan wrote: >> Hello everyone, >> >> Gerrit has long supported "Draft" patchsets, and the infra team has long >> recommended against using them as they are a source of b

Re: [openstack-dev] [Neutron] One performance issue about VXLAN pool initiation

Hi Carl, The idea of in-memory storage was discussed for similar problem, but might not work for multiple server deployment. Some hybrid approach though may be used, I think. Thanks, Eugene. On Fri, May 30, 2014 at 8:53 PM, Carl Baldwin wrote: > This is very similar to IPAM... There is a spa

Re: [openstack-dev] [oslo][db] oslo.db repository review request

No matter what version number we use, we will have to be careful about API changes. We cannot have 2 versions of the same library installed at the same time, so in order for devstack to work (and therefore the gate), we will have to make all changes backwards-compatible and support older APIs until

Re: [openstack-dev] [oslo][db] oslo.db repository review request

On Fri, May 30, 2014 at 11:37 AM, Sergey Lukjanov wrote: > So, it means that we'll be able to migrate to oslo.db lib in the end > of Juno? or early K? Projects will be able to start migrating to the oslo.db during this cycle. We will have a non-alpha release by the end of Juno. Doug > > On Fri

Re: [openstack-dev] [Keystone] [Blazar] [Ironic] Py26/27 gates failing because of keystoneclient-0.9.0

Would it make sense to provide a test fixture in the middleware library for projects who want or need to test with token management? Doug On Fri, May 30, 2014 at 12:49 PM, Brant Knudson wrote: > > The auth_token middleware changed recently[1] to check if tokens retrieved > from the cache are exp

Re: [openstack-dev] [oslo][db] oslo.db repository review request

Doug, thanks for the clarification re migration time. I'm absolutely agree with point about need to keep API backward compat. On Sat, May 31, 2014 at 1:04 AM, Doug Hellmann wrote: > No matter what version number we use, we will have to be careful about > API changes. We cannot have 2 versions of

Re: [openstack-dev] [Keystone] [Blazar] [Ironic] Py26/27 gates failing because of keystoneclient-0.9.0

+1 to a fixture for the middleware if this is a common practice to do unit testing in this manner. The main issue here was mocking out the cache and using a hand-crafted “valid” token. We have a mechanism provided in the keystone client library that allows for creating a valid token (all the re

Re: [openstack-dev] [Mistral] Cleaning up configuration settings

Is there an existing unit test for testing enabling keystone middleware in pecan (setting cfg.CONF.pecan.auth_enable = True)? I don't seem to find one. If there's one, it's not obvious. Can someone kindly point me to it? On Wed, May 28, 2014 at 9:53 AM, W Chan wrote: > Thanks for following u

Re: [openstack-dev] [TripleO] Adding Tuskar to weekly IRC meetings agenda

On Fri 30 May 2014 02:37:49 PM MDT, James Polley wrote: > > >> On 30 May 2014, at 8:13 pm, Jaromir Coufal wrote: >> >> Hi All, >> >> I would like to propose to add Tuskar as a permanent topic to the agenda for >> our weekly IRC meetings. It is an official TripleO's project, there >> happening qu

[openstack-dev] [Heat] Blueprint process (heat-specs repo)

Last week we agreed[1] to follow that other project in setting up a specs repo.[2] (Many thanks to Ying, Monty and Clint for getting this up and running.) I'm still figuring out myself how this is going to work, but the basic idea seems to be this: - All new blueprints should be submitted as

[openstack-dev] [Rally] Tempest + Rally: first success

Hi stackers, I would like to share with you great news. We all know that it's quite hard to use Tempest out of gates, especially when you are going to benchmark different clouds, run just part of tests and would like to store somewhere results. As all this stuff doesn't belong to Tempest, we decid

[openstack-dev] [Nova]Passing flat_injected flag through instance metadata

Hello all, I am new to the openstack community and I am looking for feedback. We would like to implement a feature that allows user to pass flat_injected flag through instance metadata. We would like to enable this feature for images that support config drive. This feature helps us to decrease t

Re: [openstack-dev] [Glance] [Heat] Glance Metadata Catalog for Capabilities and Tags

Thanks, Zane and Georgy! We’ll begin getting all the expected sections for the new Glance spec repo into this document next week and then will upload in RST format for formal review. That is a bit more expedient since there are still several people editing. In the meantime, we’ll take any addit

Re: [openstack-dev] [Neutron] One performance issue about VXLAN pool initiation

Eugene, That was part of the "whole new set of complications" that I dismissively waved my hands at. :) I was thinking it would be a separate process that would communicate over the RPC channel or something. More complications come when you think about making this process HA, etc. It would mea

Re: [openstack-dev] [Neutron] One performance issue about VXLAN pool initiation

> I was thinking it would be a separate process that would communicate over the RPC channel or something. memcached? Eugene. On Sat, May 31, 2014 at 2:27 AM, Carl Baldwin wrote: > Eugene, > > That was part of the "whole new set of complications" that I > dismissively waved my hands at. :) > >

  1   2   >