[openstack-dev] [nova] how to handle vendor-specific API microversions?

Hi, I've recently been playing around a bit with API microversions and I noticed something that may be problematic. The way microversions are handled, there is a monotonically increasing MAX_API_VERSION value in "nova/api/openstack/api_version_request.py". When you want to make a change you

Re: [openstack-dev] [Ironic] ironic-discoverd release plans

Dmitry, Thank you! Great! pshige 2015-03-21 0:18 GMT+09:00 高田唯子 : > Thank you, Dmitry. > I agree! > > > Best Regards, > Yuiko Takada > > 2015-03-20 23:32 GMT+09:00 Imre Farkas : >> >> Hi Dmitry, >> >> Sounds good to me! ;-) >> >> Imre >> >> >> >> On 03/20/2015 01:59 PM, Dmitry Tantsur wrote: >>>

Re: [openstack-dev] [barbican] Barbican : Unable to send PUT request to store the secret

Hello Asha, I missed this later email, sorry. The content type on the PUT call determines the type of the secret (the first POST call only creates the metadata for the secret). This older wiki page might help clarify things: https://github.com/cloudkeep/barbican/wiki/Application-Programming-In

Re: [openstack-dev] [barbican] Barbican : Unable to send PUT request to store the secret

Hello Asha, First, please add '[barbican]' to the subject line to indicate this thread is of Barbican interest only. So for example, the revised subject line would look like: Re: [openstack-dev] [barbican] Unable to send PUT request to store the secret You appear to be doing a two step secret u

Re: [openstack-dev] [cinder] May you reconsider about huawei driver?

It is huawei-volume-ci that is on behalf of huawei 18000 iSCSI and huawei 18000 FC driver, not huawei-ci. I am sorry for these two ci names so similar. And I think the point is: Does the requirement is really "a stable CI", and if one CI is not stable, can it make a exemption like NetApp FC driv

Re: [openstack-dev] [cinder] May you reconsider about huawei driver?

Yes, currently our CI is not stable now, but it is really reporting, and have a look at all the other CI’s report, I think some of them are really not stable too. The server of "review.openstack.org" is located at the United States (U.S.) and the network is really not good between our CI and t

Re: [openstack-dev] [cinder] Request exemption for removal of NetApp FC drivers (no voting CI)

Hi Mike, I think what we are talking is huawei-volume-ci, not huawei-ci. It is huawei-volume-ci that is on behalf of huawei 18000 iSCSI and huawei 18000 FC driver. Regarding to "only report failures when a patch really does break your integration", I think huawei-volume-ci probaly should be mar

[openstack-dev] [TripleO] CI outage

Short version: The RH1 CI region has been down since yesterday afternoon. We have a misbehaving switch and have file a support ticket with the vendor to troubleshoot things further. We hope to know more this weekend, or Monday at the latest. Long version: Yesterday afternoon we started seeing i

Re: [openstack-dev] [Neutron] Neutron extenstions

On 20 March 2015 at 15:49, Salvatore Orlando wrote: > The MTU issue has been a long-standing problem for neutron users. What > this extension is doing is simply, in my opinion, enabling API control over > an aspect users were dealing with previously through custom made scripts. > Actually, versi

Re: [openstack-dev] [puppet] Re-schedule Puppet OpenStack meeting

A couple more responses were submitted but 1500 on Tuesdays is still in first place. Since there was no further discussion, we'll meet next week at 1500 on Tuesday in #openstack-meeting-4 (no Monday meeting). I've edited the meetings wiki to indicate this. If you have topics to discuss at the meeti

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

If we feel a need for specifying the relative position of gateway address and allocation pools when creating a subnet from a pool which will pick a CIDR from its prefixes, then the integer value solution is probably marginally better than the "fake IP" one (eg.: 0.0.0.1 to say the gateway is the fi

[openstack-dev] [Keystone] Liberty Spec Proposals now being accepted

Hi everyone, This is a quick note that Spec proposals are now open for Keystone for the Liberty cycle. By open, this means that specs can be proposed against Liberty with the intention to kick-start the review cycle on specs for the next cycle a bit earlier and help prevent piling all the new feat

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

Great suggestion Kevin. Passing 0.0.0.1 as gateway_ip_template (or whatever you call it) is essentially passing an address index, so when you OR 0.0.0.1 with the CIDR you get your gateway set as the first usable IP in the subnet. The intent of the user is to allocate the first usable IP addres

Re: [openstack-dev] [Neutron] Neutron extenstions

It's good to have trackers for "cleaning up" the implementation of these features. I hope we might be able soon to provide more details concerning what cleaning up activities should happen here. Core vs extension is often incorrectly misunderstood for "essential" vs "optional". I believe this clas

Re: [openstack-dev] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

I did hear of one use case.[1] :-) In all seriousness, it seems like our abstraction over executing processes must be leaking quite a bit if we can't handle a no-namespace deployment. It seems like running a command without "ip netns" in front of it shouldn't be that much harder. Or am I misunders

Re: [openstack-dev] [cinder] Request exemption for removal of NetApp FC drivers (no voting CI)

On 21:53 Fri 20 Mar , Rochelle Grober wrote: > Ditto for Huawei. > > While we are not *reliably* reporting, we are reporting and the necessary > steps have already been taken (and more importantly, approved) to get this > reliably working ASAP. > > We respectfully request the same considera

Re: [openstack-dev] [Congress] [Delegation] Meeting scheduling

(Instead of having a copy of these emails in the gdoc, I resolved the comment in the gdoc and added a link to this email thread in the ML archives.) Inline. On Mar 20, 2015, at 8:34 AM, Yathiraj Udupi (yudupi) mailto:yud...@cisco.com>> wrote: Hi Tim, I think what you are saying is a reasonabl

Re: [openstack-dev] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

- Original Message - > Tempest tests fail when not using namespaces, so I'm not sure how well we're > even testing that codepath anymore. Hrmph, I meant to mention that the code path is basically untested but forgot to do that when I sent the email. > > doug > > > > On Mar 20, 2015,

Re: [openstack-dev] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

They blow up because they assume you can have overlapping IPs, right? On Fri, Mar 20, 2015 at 2:26 PM, Doug Wiegley wrote: > Tempest tests fail when not using namespaces, so I'm not sure how well > we're even testing that codepath anymore. > > doug > > > > On Mar 20, 2015, at 3:19 PM, Brian Hale

[openstack-dev] [oslo][cinder][nova][neutron] going forward to oslo-config-generator ...

All, Let me start with the TLDR; Cinder, Nova and Neutron have lots of configuration options that need to be processed by oslo-config-generator to create the .conf.sample file. There are a couple of different ways this could be done. I have one proposal out, which has raised concerns, ther

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

On Fri, Mar 20, 2015 at 1:48 PM, Jay Pipes wrote: > I actually don't think the API URI structure should acknowledge if there is > or is not a window of time that is involved in some action. Instead, whether > or not the API call returns a 202 Accepted or a 201 Created should be > sufficient for co

Re: [openstack-dev] [cinder] Request exemption for removal of NetApp FC drivers (no voting CI)

Ditto for Huawei. While we are not *reliably* reporting, we are reporting and the necessary steps have already been taken (and more importantly, approved) to get this reliably working ASAP. We respectfully request the same consideration for our cinder drivers. --Rocky (as proxy for Liu Xinqu

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

What if we just call it 'address_index' and make it an integer representing the offset from the network start address? On Fri, Mar 20, 2015 at 12:39 PM, Carl Baldwin wrote: > On Fri, Mar 20, 2015 at 1:34 PM, Jay Pipes wrote: > > How is 0.0.0.1 a host address? That isn't a valid IP address, AFAI

Re: [openstack-dev] [cinder] Request exemption for removal of NetApp FC drivers (no voting CI)

Mike, I request the same consideration being given to the Oracle driver team: > The tag for Kilo in Cinder has already happened, so it's too late to revert. > We > may be able to revisit this in Kilo RC, but I want to see your CI reporting > reliably now to then to Cinder reviews. We are going

Re: [openstack-dev] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

Tempest tests fail when not using namespaces, so I'm not sure how well we're even testing that codepath anymore. doug > On Mar 20, 2015, at 3:19 PM, Brian Haley wrote: > > On 03/20/2015 02:57 PM, Assaf Muller wrote: >> Hello everyone, >> >> The use_namespaces option in the L3 and DHCP Neutro

[openstack-dev] [MagnetoDB] Kilo-3 milestone release

Hello everybody, MagnetoDB team is happy to announce Kilo-3 release [1] Thank you to everyone who made this possible. [1] https://launchpad.net/magnetodb/kilo/kilo-3 -- With best regards Ilya Sviridov __ OpenStack Develop

Re: [openstack-dev] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

On 03/20/2015 02:57 PM, Assaf Muller wrote: > Hello everyone, > > The use_namespaces option in the L3 and DHCP Neutron agents controls if you > can create multiple routers and DHCP networks managed by a single L3/DHCP > agent, > or if the agent manages only a single resource. > > Are the setups

Re: [openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a tenant

To clarify a bit, we obviously divide lots of things by tenant (quotas, network listing, etc). The difference is that we have nothing right now that has to be unique within a tenant. Are there objects that are uniquely scoped to a tenant in Nova/Glance/etc? On Fri, Mar 20, 2015 at 12:50 PM, Jay Pi

[openstack-dev] [Ironic] Announcing Bifrost

At present, the only configuration in which ironic is tested is as part of a complete OpenStack cloud. While this is also the most common usage, there has been significant interest in running Ironic outside of OpenStack contexts as an independent service for provisioning hardware in trusted envir

Re: [openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a tenant

On 2015-03-20 13:37:49 -0600 (-0600), Carl Baldwin wrote: > From what I've heard others say both in this thread and privately to > me, there are already a lot of cases where a tenant will use the same > address range to stamp out identical topologies. It occurred to me > that we might even being d

Re: [openstack-dev] [Nova] Liberty specs are now open

Davanum Srinivas writes: > Neil, > > yes, see example - https://review.openstack.org/#/c/155116/ - you file > against the /approved directory Thanks! Neil __ OpenStack Development Mailing List (not for usage questio

Re: [openstack-dev] [Nova] Liberty specs are now open

Neil, yes, see example - https://review.openstack.org/#/c/155116/ - you file against the /approved directory -- dims On Fri, Mar 20, 2015 at 2:41 PM, Neil Jerram wrote: > Neil Jerram writes: > >> Hi Michael, >> >> Michael Still writes: >> >>> For specs approved in Juno or Kilo, there is a fas

[openstack-dev] [Murano] Feature Freeze Exceptions

Hi, folks! Today we released third milestone of Kilo release - 2015.1.0b3 [1], in this milestone we completed 11 blueprints and fixed 13 bugs. We finally completed a number of big features that we were working whole cycle: Integration with Congress, Environment Templates and so on. Release of kil

Re: [openstack-dev] [Keystone][FFE] - Reseller Implementation

Hi Geoff, I'm very happy to know that companies like Cisco wants to use Reseller. When we start the Hierarchical Multitenancy implementation we had some use cases in mind, there is: - Organize a divisional department of a company. - Reseller - Merge/Acquisition - Contracting parties The first u

Re: [openstack-dev] [Heat] vnic_type in OS::Neutron::Port

On 20/03/15 14:33, Rob Pothier (rpothier) wrote: Hi All, It was brought to my attention that the recent changes with the vnic_type possibly should not include the colon in the property value. In the earlier versions of the review the colon was not in the property, and was appended later. https

Re: [openstack-dev] [heat][congress] Stack lifecycle plugpoint as an enabler for cloud provider's services

On 19/03/15 06:17, VACHNIS, AVI (AVI) wrote: Hi, I'm looking at this interesting blueprint https://blueprints.launchpad.net/heat/+spec/stack-lifecycle-plugpoint and I hope you can easily clarify some things to me. I see the following statements related to this BP: * [in "problem description" s

Re: [openstack-dev] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

Assaf Muller writes: > Hello everyone, Hi Assaf, > The use_namespaces option in the L3 and DHCP Neutron agents controls if you > can create multiple routers and DHCP networks managed by a single L3/DHCP > agent, > or if the agent manages only a single resource. > > Are the setups out there *no

Re: [openstack-dev] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

- Original Message - > Assaf Muller writes: > > > Hello everyone, > > Hi Assaf, > > > The use_namespaces option in the L3 and DHCP Neutron agents controls if you > > can create multiple routers and DHCP networks managed by a single L3/DHCP > > agent, > > or if the agent manages only a

Re: [openstack-dev] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

Assaf Muller writes: > Hello everyone, Hi Assaf, > The use_namespaces option in the L3 and DHCP Neutron agents controls if you > can create multiple routers and DHCP networks managed by a single L3/DHCP > agent, > or if the agent manages only a single resource. > > Are the setups out there *no

Re: [openstack-dev] Barbican : Unable to send PUT request to store the secret

Hi All , Now the command for put request has been successful .the content type for the header needs to be text/plain. I thought that the datatype for the data parameters would determine the content type of the header. For ex : In this case the data is passed in the following format *'{"secret

Re: [openstack-dev] [Ceilometer]Add hardware pollster of memory buffer and cache

this seems reasonable... this might fall into same category ironic generated metrics (and any other source that has their own defined list of metrics beyond ceilometer's list). there was discussion on how to properly handle these cases [1][2] [1] http://eavesdrop.openstack.org/meetings/ceilome

Re: [openstack-dev] [ceilometer] Pipeline for notifications does not seem to work

i can confirm it works for me as well... are there any noticeable errors in the ceilometer-agent-notifications log? the snippet below looks sane to me though. cheers, gord > From: idegtia...@mirantis.com > Date: Fri, 20 Mar 2015 18:35:56 +0200 > To: openstack-dev@lists.openstack.org > Subject:

Re: [openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a tenant

On 03/20/2015 03:37 PM, Carl Baldwin wrote: On Fri, Mar 20, 2015 at 12:31 PM, Jay Pipes wrote: This is a question purely out of curiousity. Why is Neutron averse to the concept of using tenants as natural ways of dividing up the cloud -- which at its core means "multi-tenant", on-demand computi

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

On 03/20/2015 03:02 PM, Carl Baldwin wrote: On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes wrote: 2) Is the action of creating a subnet from a pool better realized as a different way of creating a subnet, or should there be some sort of "pool action"? Eg.: POST /subnet_pools/my_pool_id/subnet {'p

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

On Fri, Mar 20, 2015 at 1:34 PM, Jay Pipes wrote: > How is 0.0.0.1 a host address? That isn't a valid IP address, AFAIK. It isn't a valid *IP* address without the network part. However, it can be referred to as the "host address on the network" or the host part of the IP address. Carl

Re: [openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a tenant

On Fri, Mar 20, 2015 at 12:31 PM, Jay Pipes wrote: > This is a question purely out of curiousity. Why is Neutron averse to the > concept of using tenants as natural ways of dividing up the cloud -- which > at its core means "multi-tenant", on-demand computing and networking? >From what I've heard

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

On Fri, Mar 20, 2015 at 1:09 PM, Dean Troyer wrote: > Template is totally the wrong word. It is a host address without a network. > The prefix is there for the same purpose, to OR it back into a network > address. > > I just want us to stop inventing things that already exist. You want to > spec

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

On Fri, Mar 20, 2015 at 1:07 PM, Jay Pipes wrote: > On 03/20/2015 02:51 PM, Carl Baldwin wrote: >> >> On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes wrote: >>> >>> What about this instead? >>> >>> POST /v2.0/subnets >>> >>> { >>>'network_id': 'meh', >>>'gateway_ip_template': '*.*.*.1' >>>

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

On 03/20/2015 02:51 PM, Carl Baldwin wrote: On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes wrote: What about this instead? POST /v2.0/subnets { 'network_id': 'meh', 'gateway_ip_template': '*.*.*.1' 'prefix_len': 24, 'pool_id': 'some_pool' } At least that way it's clear the gateway a

Re: [openstack-dev] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

+1 Would like to hear feedback hoping that deprecation is viable. Carl On Fri, Mar 20, 2015 at 12:57 PM, Assaf Muller wrote: > Hello everyone, > > The use_namespaces option in the L3 and DHCP Neutron agents controls if you > can create multiple routers and DHCP networks managed by a single L3/D

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

On Fri, Mar 20, 2015 at 12:58 PM, Dean Troyer wrote: >> I thought about doing *s but in the world of Classless Inter-Domain >> Routing where not all networks are /24, /16, or /8 it seemed a bit >> imprecise. But, maybe that doesn't matter. > > > So do a CIDR host address: 0.0.0.1/24 can be merge

[openstack-dev] Barbican : Unable to send PUT request to store the secret

Hi All , I am unable to send the PUT request using the CURL command for storing the secret . root@barbican:~# curl -X POST -H 'content-type:application/json' -H 'X-Project-Id: 12345' -d '{"secret": {"name": "secretname", "algorithm": "aes", "bit_length" : 256, "m

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes wrote: >> 2) Is the action of creating a subnet from a pool better realized as a >> different way of creating a subnet, or should there be some sort of >> "pool action"? Eg.: >> >> POST /subnet_pools/my_pool_id/subnet >> {'prefix_len': 24} >> >> which wo

Re: [openstack-dev] [cinder] May you reconsider about huawei driver?

On 03/20/2015 04:48 PM, Walter A. Boring IV wrote: > [...] >> >> >> *https://review.openstack.org/#/c/152401/ >> >> Post time: 3-18 23:08:45 >> > This patch also has NO Huawei Volume CI check results. It has results on patches 5, 6, 7, 25, 26, 28, and 45. 45 was the only successfull one. To see

[openstack-dev] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

Hello everyone, The use_namespaces option in the L3 and DHCP Neutron agents controls if you can create multiple routers and DHCP networks managed by a single L3/DHCP agent, or if the agent manages only a single resource. Are the setups out there *not* using the use_namespaces option? I'm curious

Re: [openstack-dev] [Neutron] Neutron extenstions

In order to track this, and for Kyle's sanity, I have created these two RC1 bugs: - https://bugs.launchpad.net/neutron/+bug/1434667 - https://bugs.launchpad.net/neutron/+bug/1434671 Please, let's make sure that whatever approach we decide on, the resulting code fix targets those two bugs. Thanks

Re: [openstack-dev] [cinder] Request exemption for removal of NetApp FC drivers (no voting CI)

On 12:33 Fri 20 Mar , ClaytonLuce, Timothy wrote: > I'd like to point out that for NetApp FC drivers NetApp has been in > discussions and updating progress on these drivers since their submission. > > I will point out a discussion in the Nov Core meeting where I brought up the > challenge arou

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes wrote: > What about this instead? > > POST /v2.0/subnets > > { > 'network_id': 'meh', > 'gateway_ip_template': '*.*.*.1' > 'prefix_len': 24, > 'pool_id': 'some_pool' > } > > At least that way it's clear the gateway attribute is not an IP, but a >

Re: [openstack-dev] [OpenStack-Infra] [cinder] Could you please re-consider Oracle ZFS/SA Cinder drivers (iSCSI and NFS)

On 3/20/15 2:19 PM, Mike Perez wrote: On 12:37 Fri 20 Mar , Alka Deshpande wrote: Hi MIke, My team and I would like to respectfully request a revert for the change at:https://review.openstack.org/#/c/165939/ to bring back the ZFSSA drivers to Kilo. Oracle has the CI working internally and

Re: [openstack-dev] [Keystone][FFE] - Reseller Implementation

Glad to see this FFE. The Cisco Cloud Services team is very interested in the Reseller use case, and in a couple of possible extensions of the work. http://specs.openstack.org/openstack/keystone-specs/specs/kilo/reseller.html

Re: [openstack-dev] [Nova] Liberty specs are now open

Neil Jerram writes: > Hi Michael, > > Michael Still writes: > >> For specs approved in Juno or Kilo, there is a fast track approval >> process for Liberty. The steps to get your spec re-approved are: >> >> - Copy your spec from the specs//approved directory to >> the specs/liberty/approved dire

[openstack-dev] [Heat] vnic_type in OS::Neutron::Port

Hi All, It was brought to my attention that the recent changes with the vnic_type possibly should not include the colon in the property value. In the earlier versions of the review the colon was not in the property, and was appended later. https://review.openstack.org/#/c/129353/4..5/heat/engine

Re: [openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a tenant

On 03/11/2015 06:48 PM, John Belamaric wrote: This has been settled and we're not moving forward with it for Kilo. I agree tenants are an administrative concept, not a networking one so using them for uniqueness doesn't really make sense. In Liberty we are proposing a new grouping mechanism, as

Re: [openstack-dev] [cinder] May you reconsider about huawei driver?

On 09:41 Fri 20 Mar , Jay S. Bryant wrote: > Mike, > > Looks like this removal may have been a mistake. We should readdress. This was not a mistake. As Walt has mentioned that CI run failed anyways. Also if you take a look at Huawei's CI reporting history, it's not that often AND not reliabl

Re: [openstack-dev] [Nova] Liberty specs are now open

Hi Michael, Michael Still writes: > For specs approved in Juno or Kilo, there is a fast track approval > process for Liberty. The steps to get your spec re-approved are: > > - Copy your spec from the specs//approved directory to > the specs/liberty/approved directory. [...] Perhaps I'm misunde

Re: [openstack-dev] [OpenStack-Infra] [cinder] Could you please re-consider Oracle ZFS/SA Cinder drivers (iSCSI and NFS)

On 12:37 Fri 20 Mar , Alka Deshpande wrote: > Hi MIke, > > My team and I would like to respectfully request a revert for the > change at:https://review.openstack.org/#/c/165939/ to bring back the > ZFSSA drivers to Kilo. Oracle has the CI working internally and we > are in the process of going

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

On 03/09/2015 09:05 AM, Salvatore Orlando wrote: POST /v2.0/subnets {'network_id': 'meh', 'gateway_ip': '0.0.0.1', 'prefix_len': 24, 'pool_id': 'some_pool'} would indicate that the user wishes to use the first address in the range as the gateway IP, and the API would return something like

[openstack-dev] [neutron][lbaas] Invalid import in tempest v2 api tests

Hi: The LBaaS API tests are failing to run because test_pools.py(and other tests as well) are importing data_utils from tempest.common.utils. Looks like data_utils is moved to tempest_lib now and the API tests need to change to import from tempest_lib. Is someone tracking this? We are blocke

[openstack-dev] [Horizon] FFE request for Firewall Router insertion BP

Dear Horizon community, I would like to request an FFE for the review we have out currently for the firewall feature in the project dashboard. The review is at - https://review.openstack.org/#/c/162552/ This feature is very important for the neutron FWaaS community to move the firewall feature

[openstack-dev] [Manila] Nominate Igor Malinovskiy for core team

+1 from me. On 03/18/2015 03:04 PM, Ben Swartzlander wrote: > >> Igor (u_glide on IRC) joined the Manila team back in December and has >> done a consistent amount of reviews and contributed significant new core >> features in the last 2-3 months. I would like to nominate him to join the >> Manila

Re: [openstack-dev] [Neutron] Neutron extenstions

On 19 March 2015 at 23:59, Akihiro Motoki wrote: > Forwarding my reply to the other thread too... > > Multiple threads on the same topic is confusing. > Can we use this thread if we continue the discussion? > (The title of this thread looks approapriate) > > > API extension is the only way t

Re: [openstack-dev] [oslo.utils] allow strutils.mask_password to mask keys dynamically

Excerpts from Matthew Van Dijk's message of 2015-03-20 15:06:08 +: > I’ve come across a use case for allowing dynamic keys to be made > secret. The hardcoded list is good for common keys, but there will be > cases where masking a custom value is useful without having to add it > to the hardcode

[openstack-dev] [OpenStack-Infra] [cinder] Could you please re-consider Oracle ZFS/SA Cinder drivers (iSCSI and NFS)

Hi MIke, My team and I would like to respectfully request a revert for the change at:https://review.openstack.org/#/c/165939/ to bring back the ZFSSA drivers to Kilo. Oracle has the CI working internally and we are in the process of going through internal security review, which is expected to

Re: [openstack-dev] [ceilometer] Pipeline for notifications does not seem to work

Hi Tim I've check your case on my devstack. And I've received new hs06 meter in my meter list. So something wrong with your local env. Cheers, Igor D. Igor Degtiarov Software Engineer Mirantis Inc www.mirantis.com On Fri, Mar 20, 2015 at 5:40 PM, Tim Bell wrote: > > > I’m running Juno with c

Re: [openstack-dev] About Sahara EDP New Ideas for Liberty

Hi Weiting, >1. Add a schedule feature to run the jobs on time: >This request comes from the customer, they usually run the job in a specific time every day. So it should be great if there > is a scheduler to help arrange the regular job to run. Looks like a great feature. And should be quite easy

Re: [openstack-dev] [cinder] May you reconsider about huawei driver?

On 03/19/2015 07:13 PM, liuxinguo wrote: Hi Mike, I have seen the patch at https://review.openstack.org/#/c/165990/ saying that huawei driver will be removed because “the maintainer does not have a CI reporting to ensure their driver integration is successful”. Looking at this patch, ther

Re: [openstack-dev] [neutron][lbaas] canceling meeting

That is correct. On Fri, 2015-03-20 at 15:11 +, Vijay Venkatachalam wrote: > > > +1 For on demand meeting. > > > On demand lbaas meetings will happen in neutron meeting and not in > Octavia meetings, right? > > > Sent from Surface > > > From: Susanne Balle > Sent: ‎Friday‎, ‎20‎ ‎March

[openstack-dev] [ceilometer] Pipeline for notifications does not seem to work

I'm running Juno with ceilometer and trying to produce a new meter which is based on vcpus * F (where F is a constant that is different for each hypervisor). When I create a VM, I get a new sample for vcpus. However, it does not appear to fire the transformer. The same approach using "cpu" wo

Re: [openstack-dev] [Congress] [Delegation] Meeting scheduling

Hi Tim, I think what you are saying is a reasonable goal in terms of high-level Congress policies not having to depend on the domain-specific solver / policy engines. As long as there are Congress adapters to transform the user’s policies to something that domain-specific solver understands it

[openstack-dev] [third-party]Properly format the status message with gerrit trigger

Hi guys, I am in charge of a third party CI (for Cinder). My setup is based on Jenkins + gerrit trigger plugin. As you may know, it"s hard to customize the message in the "Gerrit Verified Commands" config. In particular, it"s not possible to add "white/empty line". And you need white lines if you h

[openstack-dev] [magnum] updated Fedora Atomic image available - needs testing

Hey folks, I have manually updated the Fedora 21 Atomic image via rpm-ostree upgrade. This image includes kubernetes 0.11 which some people have said is required to use kubectl with current Magnum master. I don’t have time for the next week to heavily test, but if someone could run this image

Re: [openstack-dev] [Ironic] ironic-discoverd release plans

Thank you, Dmitry. I agree! Best Regards, Yuiko Takada 2015-03-20 23:32 GMT+09:00 Imre Farkas : > Hi Dmitry, > > Sounds good to me! ;-) > > Imre > > > > On 03/20/2015 01:59 PM, Dmitry Tantsur wrote: > >> This is an informational email about upcoming ironic-discoverd-1.1.0 >> [1]. If you're not

Re: [openstack-dev] [neutron][lbaas] canceling meeting

+1 For on demand meeting. On demand lbaas meetings will happen in neutron meeting and not in Octavia meetings, right? Sent from Surface From: Susanne Balle Sent: ‎Friday‎, ‎20‎ ‎March‎ ‎2015 ‎20‎:‎20 To: OpenStack Development Mailing List (not for usage questions

[openstack-dev] [oslo.utils] allow strutils.mask_password to mask keys dynamically

I’ve come across a use case for allowing dynamic keys to be made secret. The hardcoded list is good for common keys, but there will be cases where masking a custom value is useful without having to add it to the hardcoded list. I propose we add an optional parameter that is a list of secret_keys wh

Re: [openstack-dev] openstack storage configaration file(cinder-service)

You can follow the basic instructions here in FAQ: https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers Ramy From: Kamsali, RaghavendraChari (Artesyn) [mailto:raghavendrachari.kams...@artesyn.com] Sent: Friday, March 20, 2015 4:20 AM To: openstack-dev@lists.openstack.org Subject: [ope

[openstack-dev] [Cinder] Bug Triage - Call for Participation

Hi OpenStack Developers! I want to remind you that bug triage [1] is important part of contribution to any project[2]. We've got a lot of not triaged bugs in Cinder [3]. Please, do not hesitate to triage bugs in Cinder [4] to make upcoming Kilo release better. You can ask any questions via opens

Re: [openstack-dev] [neutron][lbaas] canceling meeting

Make sense to me. Susanne On Thu, Mar 19, 2015 at 5:49 PM, Doug Wiegley wrote: > Hi lbaas'ers, > > Now that lbaasv2 has "shipped", the need for a regular weekly meeting is > greatly reduced. I propose that we cancel the regular meeting, and discuss > neutron-y things during the neutron on-demand

Re: [openstack-dev] [cinder] May you reconsider about huawei driver?

Mike, Looks like this removal may have been a mistake. We should readdress. Jay On 03/20/2015 05:59 AM, Erlon Cruz wrote: I agree with John (comment on the mentioned patchset). Also, I expected one change removing all drivers that does not report on CI. There's one of us (HUSDriver) that is

Re: [openstack-dev] [Ironic] ironic-discoverd release plans

Hi Dmitry, Sounds good to me! ;-) Imre On 03/20/2015 01:59 PM, Dmitry Tantsur wrote: This is an informational email about upcoming ironic-discoverd-1.1.0 [1]. If you're not interested in discoverd, you may safely skip it. Hi all! Do you know what time is coming? Release time! I'm hoping to

Re: [openstack-dev] [TripleO][Tuskar] Common library for shared code

On Fri, Mar 20, 2015 at 7:20 AM, Jan Provazník wrote: > On 03/18/2015 04:22 PM, Ben Nemec wrote: >> So is this eventually going to live in Tuskar? If so, I would point out >> that it's going to be awkward to move it there if it starts out as a >> separate thing. There's no good way I know of to

[openstack-dev] [Fuel] FFE backport IBP-reconnect to 6.0

Hello Fuelers, I'm kindly insisting on merging the following 2 patches into 6.0 [1] https://review.openstack.org/#/c/161721/ [2] https://review.openstack.org/#/c/161722/ These patches are going to implement IBP-reconnect [3]. Additionally, it closes one of customer-found bug [4] related to that.

Re: [openstack-dev] Stable/icehouse: oslo.messaging RPCClient segmentation fault core dumped

Hello, For information, I solved my problem by uninstalling the package "librabbitmq" which is not installed in the stable icehouse release of Openstack RDO. This library causes my problem. Best regards, Romain Ziba. De : ZIBA Romain Envoyé : jeudi 19 mars 2015 18:11 À : 'openstack-dev@lists.ope

Re: [openstack-dev] [Neutron] Neutron extenstions

I agree with a lot of your desires, but not your reasoning as to why the changes are problematic. Also, your statements about API changes are pretty reasonable and probably want writing down somewhere so that future specs are evaluated against them. Firstly, if we add to the core Neutron interfac

Re: [openstack-dev] [Neutron] Neutron extenstions

The MTU values are derived from the config values only. If the tenant tries to set the MTU directly, that is rejected. Rob From: Gary Kotton mailto:gkot...@vmware.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Thur

[openstack-dev] [Ironic] ironic-discoverd release plans

This is an informational email about upcoming ironic-discoverd-1.1.0 [1]. If you're not interested in discoverd, you may safely skip it. Hi all! Do you know what time is coming? Release time! I'm hoping to align this ironic-discoverd release with the OpenStack one. Here's proposed plan, whic

Re: [openstack-dev] [infra][horizon] Need help at debugging requirements issue

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/20/2015 09:01 AM, Matthias Runge wrote: > On 19/03/15 15:52, Ihar Hrachyshka wrote: > >>> [1] https://review.openstack.org/#/c/155353/ >> >> >> Hi, >> >> it all comes to the fact that DEVSTACK_GATE_INSTALL_TESTONLY=1 is >> not specified in th

[openstack-dev] [cinder] Request exemption for removal of NetApp FC drivers (no voting CI)

I'd like to point out that for NetApp FC drivers NetApp has been in discussions and updating progress on these drivers since their submission. I will point out a discussion in the Nov Core meeting where I brought up the challenge around FC environments and the response I received: 16:10:44

Re: [openstack-dev] [Neutron] IPAM reference driver status and other stuff

As pointed out by Pavel in yesterday's meeting, the refactor [1] cannot assume that the DB transaction for IPAM operations will occur in a scope different from the one for performing the API operation. This is because most plugins, including ML2, use inheritance to perform further operations on dat

Re: [openstack-dev] [cinder] All Cinder Volume Drivers Must Have A Third Party CI by March 19, 2014

Mike, for HDS and Hitachi, the contact person is the same: openstackdevelopm...@hds.com. Also, we have 5 drivers: - HDS HNAS NFS - HDS HNAS iSCSI - HBSD FC - HBSD iSCSI - HDS HUS This last one, HDS HUS, is deprecated by HBSD drivers and won't be maintained, so you can add it in the removal list.

Re: [openstack-dev] [TripleO][Tuskar] Common library for shared code

On 03/18/2015 04:22 PM, Ben Nemec wrote: On 03/17/2015 09:13 AM, Zane Bitter wrote: On 16/03/15 16:38, Ben Nemec wrote: On 03/13/2015 05:53 AM, Jan Provaznik wrote: On 03/10/2015 05:53 PM, James Slagle wrote: On Mon, Mar 9, 2015 at 4:35 PM, Jan Provazník wrote: Hi, it would make sense to ha

  1   2   >