Re: [openstack-dev] [oslo] pymysql change in error formatting has broken exception handing in oslo.db

+1 to 4.13.1 I'll get a release review up once https://review.openstack.org/#/c/363828/ merges (seems to be on its way to merging). https://review.openstack.org/#/c/364063/ Enjoy! -Josh __ OpenStack Development

Re: [openstack-dev] [oslo] pymysql change in error formatting has broken exception handing in oslo.db

We need to decide how to handle this: https://review.openstack.org/#/c/362991/ Basically, PyMySQL normally raises an error message like this: (pymysql.err.IntegrityError) (1452, u'Cannot add or update a child row: a foreign key constraint fails (`vaceciqnzs`.`resource_entity`, CONSTRAINT

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

joehuang wrote: I just pointed out the issues for RPC which is used between API cell and child cell if we deploy child cells in edge clouds. For this thread is about massively distributed cloud, so the RPC issues inside current Nova/Cinder/Neutron are not the main focus(it could be another

[openstack-dev] what permission is required to create a Keystone trust

Hi, I am experimenting the Keystone Trusts feature with a script which creates a trust between two users. import keystoneclient.v3 as keystoneclient #import swiftclient.client as swiftclient auth_url_v3 = 'http:/xxxt.com:5000/v3/' demo = keystoneclient.Client(auth_url=auth_url_v3,

[openstack-dev] Upstream - Barcelona

I seemed to have missed the thread where upstream opps we're being announced and/or opened. Who do I contact to get in on this? I had table duty last year and couldn't do it. //adam __ OpenStack Development Mailing List (not

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

Some evaluation aspect were added to the etherpad https://etherpad.openstack.org/p/massively-distributed_WG_description for massively distributed edge clouds, so we can evaluate each proposals. Your comments for these consideration are welcome : - Security management over the WAN: how manage

Re: [openstack-dev] [kolla] important instructions or Newton Milestone #3 Release today 8/31/2015 @ ~23:30 UTC

Great work kolla and kolla-kubernetes communities! Big thanks to the openstyack-infra team as well :) Regards, Vikram Hosakote IRC: vhosakot From: "Steven Dake (stdake)" > Reply-To: "OpenStack Development Mailing List (not for usage questions)"

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

Hi, Ifat, The static configuration contains definitions of `entities` and *their* `relationships while the scenario templates contains a definition section which includes `entities` and `relationships` *between them*. An outline of these two format are as below. static configuration - entities

Re: [openstack-dev] [nova] Next steps for resource providers work

On Aug 31, 2016, at 12:30 PM, Chris Dent wrote: > So to summarize Jay's to do list (please and thank you very much): > > * Look at https://review.openstack.org/#/c/363209/ and decide if it > is good enough to get rolling or needs to be completely altered. > * If the

Re: [openstack-dev] [neutron][networking-sfc] Unable to create openstack SFC

Hi Neutrons, I met this situation once in the release Liberty. Here is the thing. When the create_port_chain() is called, (@networking-sfc/networking_sfc/services/sfc/drivers/ovs/driver.py) it goes the following code path -> _thread_update_path_nodes() ->_update_path_node_flowrules()

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

I just pointed out the issues for RPC which is used between API cell and child cell if we deploy child cells in edge clouds. For this thread is about massively distributed cloud, so the RPC issues inside current Nova/Cinder/Neutron are not the main focus(it could be another important and

Re: [openstack-dev] [heat] Support for an "undo" operation for migrating back resource_properties_data

On 01/09/16 12:57, Crag Wolfe wrote: I'm working on a migrate utility for https://review.openstack.org/#/c/363415 . Quick summary: that means moving resource.properties_data and event.properties_data to a new table, resource_properties_data. Migrating to the new model is easy. The questions come

Re: [openstack-dev] [nova][keystone] auth for new metadata plugins

On 08/31/2016 07:56 AM, Michael Still wrote: There is a quick sketch of what a service account might look like at https://review.openstack.org/#/c/363606/ -- I need to do some more fiddling to get the new option group working, but I could do that if we wanted to try and get this into Newton.

Re: [openstack-dev] [nova][keystone] auth for new metadata plugins

On 08/30/2016 05:36 PM, Michael Still wrote: Sorry for being slow on this one, I've been pulled into some internal things at work. So... Talking to Matt Riedemann just now, it seems like we should continue to pass through the user authentication details when we have them to the plugin. The

Re: [openstack-dev] [nova] cells v2 next steps

On 8/31/2016 1:44 PM, Matt Riedemann wrote: Just to recap a call with Laski, Sean and Dan, the goal for the next 24 hours with cells v2 is to get this nova change landed: https://review.openstack.org/#/c/356138/ That depends on a set of grenade changes:

Re: [openstack-dev] [Neutron][networking-sfc] need help on requesting release for networking-sfc

On 31 August 2016 at 17:31, Cathy Zhang wrote: > CC OpenStack alias. > > > > *From:* Cathy Zhang > *Sent:* Wednesday, August 31, 2016 5:19 PM > *To:* Armando Migliaccio; Ihar Hrachyshka; Cathy Zhang > *Subject:* need help on requesting release for networking-sfc > > > >

Re: [openstack-dev] [tricircle]How to address TCs concerns in Tricircle big-tent application

Hello, Monty, Thank you very much for your guide and encouragement, then let's move on this direction. Best regards Chaoyi Huang (joehuang) From: Monty Taylor [mord...@inaugust.com] Sent: 01 September 2016 0:37 To: joehuang; openstack-dev Subject: Re:

[openstack-dev] [heat] Support for an "undo" operation for migrating back resource_properties_data

I'm working on a migrate utility for https://review.openstack.org/#/c/363415 . Quick summary: that means moving resource.properties_data and event.properties_data to a new table, resource_properties_data. Migrating to the new model is easy. The questions come up with the inverse operation. 1)

[openstack-dev] [Neutron][networking-sfc] need help on requesting release for networking-sfc

CC OpenStack alias. From: Cathy Zhang Sent: Wednesday, August 31, 2016 5:19 PM To: Armando Migliaccio; Ihar Hrachyshka; Cathy Zhang Subject: need help on requesting release for networking-sfc Hi Armando/Ihar, I would like to submit a request for a networking-sfc release. I did this for

Re: [openstack-dev] [tripleo] FFE request for Ceph RGW integration

On 08/30/2016 10:50 PM, Steven Hardy wrote: On Tue, Aug 30, 2016 at 03:25:30PM -0400, Emilien Macchi wrote: Here's my 2 cents: The patch in puppet-ceph has been here for long time now and it still doesn't work (recent update of today, puppet-ceph is not idempotent when deploying RGW service.

Re: [openstack-dev] [infra] Reliable way to filter CI in gerrit spam?

On 2016-08-31 18:58:31 + (+), Jeremy Stanley wrote: > On 2016-08-31 17:59:43 +0100 (+0100), Matthew Booth wrote: > > On Wed, Aug 31, 2016 at 5:31 PM, Jeremy Stanley wrote: > [...] > > > Also we have naming conventions for third-party CI accounts that > > > suggest they

Re: [openstack-dev] [release] don't wait to the last minute

Excerpts from Doug Hellmann's message of 2016-08-31 16:07:13 -0400: > Folks, we've had more than the usual number of validation errors > and -1s for version number choice on patches in openstack/releases > this week. Please don't wait to the last minute to submit your > milestone 3 tag request,

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

On Tue, 2016-08-30 at 03:08 +, joehuang wrote: > Hello, Jay, > > Sorry, I don't know why my mail-agent(Microsoft Outlook Web App) did > not carry the thread message-id information in the reply. I'll check > and avoid to create a new thread for reply in existing thread. It's a common

[openstack-dev] [kolla] important instructions or Newton Milestone #3 Release today 8/31/2015 @ ~23:30 UTC

Hey folks, Milestone 3 will be submitted for tagging to the release team today around my end of work day. All milestone 3 blueprints and bugs will be moved to rc1 in the case they don't make the August 31st(today) deadline. We require fernet in rc1, so if there is anything that can be done to

[openstack-dev] Deprecated fields in upgrade.

Hi, What is the typical protocol/guideline followed in the community to handle deprecated fields during upgrade procedure? Should the fields be removed by the user/admin before upgrade is initiated or would the -manage db_sync, or migrate_flavor_data etc... or any other command take care of

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

On 08/25/2016 04:14 PM, Sean Dague wrote: > On 08/25/2016 01:13 PM, Steve Martinelli wrote: >> The keystone team is pursuing a trigger-based approach to support >> rolling, zero-downtime upgrades. The proposed operator experience is >> documented here: >> >>

[openstack-dev] [Congress] python-client push bug?

Hi all, As I was sanity checking the latest python-client, which we need to release by tomorrow, I may have found a bug that we should fix before releasing. If it's a bug in the server, that can be fixed later, but if it's a bug in the client, we should get that fixed now.

Re: [openstack-dev] [infra] Reliable way to filter CI in gerrit spam?

On Wed, Aug 31, 2016 at 11:58 AM, Jeremy Stanley wrote: > No, as I understand it, since we set capability.emailReviewers="deny > group Third-Party CI" in the global Gerrit configuration it should > avoid sending E-mail for any of their comments. >

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

Excerpts from Ian Wells's message of 2016-08-31 12:30:45 -0700: > On 31 August 2016 at 10:12, Clint Byrum wrote: > > > Excerpts from Duncan Thomas's message of 2016-08-31 12:42:23 +0300: > > > On 31 August 2016 at 11:57, Bogdan Dobrelya > > wrote: > > >

Re: [openstack-dev] migrate_flavor_data doesn't flavor migrate meta data of VMs spawned during upgrade.

On 8/31/2016 4:17 PM, Dan Smith wrote: Thanks Dan for your response. While I do run that before I start my move to liberty, what I see is that it doesn't seem to flavor migrate meta data for the VMs that are spawned after controller upgrade from juno to kilo and before all computes upgraded from

Re: [openstack-dev] [nova] Next steps for resource providers work

On 8/31/2016 12:30 PM, Chris Dent wrote: On 08/29/2016 12:40 PM, Matt Riedemann wrote: I've been out for a week and not very involved in the resource providers work, but after talking about the various changes up in the air at the moment a bunch of us thought it would be helpful to lay out

Re: [openstack-dev] migrate_flavor_data doesn't flavor migrate meta data of VMs spawned during upgrade.

Sure, will file a bug with my observations. On Wed, Aug 31, 2016 at 2:17 PM, Dan Smith wrote: > > Thanks Dan for your response. While I do run that before I start my > > move to liberty, what I see is that it doesn't seem to flavor migrate > > meta data for the VMs that are

[openstack-dev] [sahara] FF is active now

Dear team, So, N3 release is almost done, so from now feature can't be merged without feature freeze exception. Feature Freeze status can be found at [0], along with several features that already has FFE. FFE can be requested by the question at openstack-dev mailing list. [0]

Re: [openstack-dev] migrate_flavor_data doesn't flavor migrate meta data of VMs spawned during upgrade.

>> While migrate_flavor_data seem to flavor migrate meta data of the VMs >> that were spawned before upgrade procedure, it doesn't seem to flavor >> migrate for the VMs that were spawned during the upgrade procedure more >> specifically after openstack controller upgrade and before compute >>

Re: [openstack-dev] migrate_flavor_data doesn't flavor migrate meta data of VMs spawned during upgrade.

> Thanks Dan for your response. While I do run that before I start my > move to liberty, what I see is that it doesn't seem to flavor migrate > meta data for the VMs that are spawned after controller upgrade from > juno to kilo and before all computes upgraded from juno to kilo. The > current work

[openstack-dev] [glance] Reviews in queue for newton-3

Hi all, I've proposed a release patch up [1] where I am collecting all the reviews that are in queue and you'd like them in Newton 3. Please leave a comment up there and I will try to get to reviewing it soon. Based on the progress, time available, freeze, etc. a determination about the

Re: [openstack-dev] [TripleO] FFE request for ec2-api integration

On Wed, Aug 31, 2016 at 4:31 PM, Sven Anderson wrote: > Hi, > > I'm working on the integration of the puppet-ec2api module. It is a > (probably) very straight forward task. The only thing that is a current > impediment is that puppet CI is currently not deploying and running >

[openstack-dev] [horizon] Summit planning etherpad

Hi all, Etherpad for planning summit sessions: https://etherpad.openstack.org/p/horizon-ocata-summit Please note the sessions have been requested, not scheduled, so the actual number we get may not be the same. Rob __

[openstack-dev] [TripleO] FFE request for ec2-api integration

Hi, I'm working on the integration of the puppet-ec2api module. It is a (probably) very straight forward task. The only thing that is a current impediment is that puppet CI is currently not deploying and running tempest on puppet-ec2api. I'm currently working on getting the ec2 credentials

[openstack-dev] [release] don't wait to the last minute

Folks, we've had more than the usual number of validation errors and -1s for version number choice on patches in openstack/releases this week. Please don't wait to the last minute to submit your milestone 3 tag request, and keep an eye on responses in case you need to rework it. Being present in

[openstack-dev] [Fuel] Deprecating old CLI in python-fuelclient

Fuelers, We are proud to announce that we finally managed to reach the point when the old CLI in python-fuelclient (aka the old Fuel Client) can be deprecated and replaced with fuel2 — a cliff based CLI. Support of the full set of commands that are required to operate Fuel was already

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

On 31 August 2016 at 10:12, Clint Byrum wrote: > Excerpts from Duncan Thomas's message of 2016-08-31 12:42:23 +0300: > > On 31 August 2016 at 11:57, Bogdan Dobrelya > wrote: > > > > > I agree that RPC design pattern, as it is implemented now, is a major

Re: [openstack-dev] migrate_flavor_data doesn't flavor migrate meta data of VMs spawned during upgrade.

> While migrate_flavor_data seem to flavor migrate meta data of the VMs > that were spawned before upgrade procedure, it doesn't seem to flavor > migrate for the VMs that were spawned during the upgrade procedure more > specifically after openstack controller upgrade and before compute > upgrade.

Re: [openstack-dev] [cinder] The State of the NFS Driver ...

Hi Jay, Thanks for the update. I can give a look in the NFS job, it will need some care, like configuring the slave to be a Ubuntu Xenial and setting apparmor, so when you finish the cloning support we have an operational job. Erlon On Wed, Aug 31, 2016 at 11:50 AM, Jay S. Bryant <

[openstack-dev] migrate_flavor_data doesn't flavor migrate meta data of VMs spawned during upgrade.

Hi, I am upgrading from Juno to Kilo and from that to Liberty. I understand I need to nova-manage db migrate_flavor_data before upgrading from Kilo to Liberty to let VMs that were spawned while the system was in Juno to flavor migrate to Kilo. Depending on the number of computes, complete

Re: [openstack-dev] [infra] Reliable way to filter CI in gerrit spam?

On 2016-08-31 17:59:43 +0100 (+0100), Matthew Booth wrote: > On Wed, Aug 31, 2016 at 5:31 PM, Jeremy Stanley wrote: [...] > > Also we have naming conventions for third-party CI accounts that > > suggest they should end in " CI" so you could match on that. > > Yeah, all except

[openstack-dev] [nova] cells v2 next steps

Just to recap a call with Laski, Sean and Dan, the goal for the next 24 hours with cells v2 is to get this nova change landed: https://review.openstack.org/#/c/356138/ That depends on a set of grenade changes: https://review.openstack.org/#/q/topic:setup_cell0_before_migrations There are

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

On 31 August 2016 at 18:54, Joshua Harlow wrote: > Duncan Thomas wrote: > >> On 31 August 2016 at 11:57, Bogdan Dobrelya > > wrote: >> >> I agree that RPC design pattern, as it is implemented now, is a major >>

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

As promised, I just wrote a first draft at https://etherpad.openstack.org/p/massively-distributed_WG_description I will try to add more content tomorrow in particular pointers towards articles/ETSI specifications/use-cases. Comments/remarks welcome. Ad_rien_ PS: Chaoyi, your proposal for f2f

Re: [openstack-dev] [nova] Next steps for resource providers work

On 08/29/2016 12:40 PM, Matt Riedemann wrote: I've been out for a week and not very involved in the resource providers work, but after talking about the various changes up in the air at the moment a bunch of us thought it would be helpful to lay out next steps for the work we want to get done

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

Excerpts from Duncan Thomas's message of 2016-08-31 12:42:23 +0300: > On 31 August 2016 at 11:57, Bogdan Dobrelya wrote: > > > I agree that RPC design pattern, as it is implemented now, is a major > > blocker for OpenStack in general. It requires a major redesign, > >

Re: [openstack-dev] [oslo] pymysql change in error formatting has broken exception handing in oslo.db

On Wed, Aug 31, 2016 at 12:09 PM, Doug Hellmann wrote: > Excerpts from Ihar Hrachyshka's message of 2016-08-31 16:48:09 +0200: >> Mike Bayer wrote: >> >> > We need to decide how to handle this: >> > >> > https://review.openstack.org/#/c/362991/ >> > >> >

Re: [openstack-dev] [Horizon] [FFE] Horizon Profiler feature (and openstack/osprofiler integration)

David, I understand your concerns. Early Ocata instead of late Newton makes sense to me. Thank you for a quick response. On Wed, Aug 31, 2016 at 5:54 PM David Lyle wrote: > As a developer feature, I would vote for merging in early Ocata rather > than as a FFE. Since the

Re: [openstack-dev] [infra] Reliable way to filter CI in gerrit spam?

On Wed, Aug 31, 2016 at 5:31 PM, Jeremy Stanley wrote: > On 2016-08-31 16:13:16 +0200 (+0200), Jordan Pittier wrote: > > Most(all?) messages from CI have the lines: > > > > "Patch Set X: > > Build (succeeded|failed)." > > > > Not super robust, but that's a start. > > Also we

Re: [openstack-dev] [tricircle]How to address TCs concerns in Tricircle big-tent application

On 08/31/2016 02:16 AM, joehuang wrote: > Hello, team, > > During last weekly meeting, we discussed how to address TCs concerns in > Tricircle big-tent application. After the weekly meeting, the proposal > was co-prepared by our > contributors: >

Re: [openstack-dev] [infra] Reliable way to filter CI in gerrit spam?

On 2016-08-31 16:13:16 +0200 (+0200), Jordan Pittier wrote: > Most(all?) messages from CI have the lines: > > "Patch Set X: > Build (succeeded|failed)." > > Not super robust, but that's a start. Also we have naming conventions for third-party CI accounts that suggest they should end in " CI" so

Re: [openstack-dev] [Horizon][FFE]Support a param to specify subnet or fixed IP when creating port

I agree this seems reasonable and a good addition for users with minimal risk. David On Tue, Aug 30, 2016 at 10:29 AM, Rob Cresswell (rcresswe) wrote: > I’m happy to allow this personally, but wanted to get others input and give > people the chance to object. > > My

Re: [openstack-dev] [oslo] pymysql change in error formatting has broken exception handing in oslo.db

Excerpts from Ihar Hrachyshka's message of 2016-08-31 16:48:09 +0200: > Mike Bayer wrote: > > > We need to decide how to handle this: > > > > https://review.openstack.org/#/c/362991/ > > > > > > Basically, PyMySQL normally raises an error message like this: > > > >

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

Duncan Thomas wrote: On 31 August 2016 at 11:57, Bogdan Dobrelya > wrote: I agree that RPC design pattern, as it is implemented now, is a major blocker for OpenStack in general. It requires a major redesign, including handling

Re: [openstack-dev] [oslo] pymysql change in error formatting has broken exception handing in oslo.db

On Wed, Aug 31 2016, Ihar Hrachyshka wrote: > I suggest we: > - block 0.7.7 to unblock upper-constraints updates; > - land oslo.db fix to cope with pymysql 0.7.7+, in master as well as all > stable > branches; > - release new oslo.db releases for L-N; > - at least for N, bump minimal version of

Re: [openstack-dev] [oslo] pymysql change in error formatting has broken exception handing in oslo.db

On 08/31/2016 10:48 AM, Ihar Hrachyshka wrote: Unless we fix the bug in next pymysql, it’s not either/or but both will be needed, and also minimal oslo.db version bump. upstream issue: https://github.com/PyMySQL/PyMySQL/issues/507 PyMySQL tends to be very responsive to issues (plus I

Re: [openstack-dev] [cinder] The State of the NFS Driver ...

On 08/30/2016 08:50 PM, Matt Riedemann wrote: On 8/30/2016 10:50 AM, Jay S. Bryant wrote: All, I wanted to follow up on the e-mail thread [1] on Cloning support in the NFS driver. The purpose of this e-mail is to provide the plan for the NFS driver going forward as I see it. First, I am

[openstack-dev] [new][ironic] bifrost 2.0.0 release (newton)

We are chuffed to announce the release of: bifrost 2.0.0: Deployment of physical machines using OpenStack Ironic and Ansible This release is part of the newton release series. For more details, please see below. 2.0.0 ^ New Features * Allows to create VMs with custom names

Re: [openstack-dev] [Horizon] [FFE] Horizon Profiler feature (and openstack/osprofiler integration)

As a developer feature, I would vote for merging in early Ocata rather than as a FFE. Since the potential risk is to users and operators and they won't generally benefit from the feature, I don't see the upside outweighing the potential risk. It's not a localized change either. That said, I

Re: [openstack-dev] [oslo] pymysql change in error formatting has broken exception handing in oslo.db

Mike Bayer wrote: We need to decide how to handle this: https://review.openstack.org/#/c/362991/ Basically, PyMySQL normally raises an error message like this: (pymysql.err.IntegrityError) (1452, u'Cannot add or update a child row: a foreign key constraint fails

[openstack-dev] [oslo] pymysql change in error formatting has broken exception handing in oslo.db

We need to decide how to handle this: https://review.openstack.org/#/c/362991/ Basically, PyMySQL normally raises an error message like this: (pymysql.err.IntegrityError) (1452, u'Cannot add or update a child row: a foreign key constraint fails (`vaceciqnzs`.`resource_entity`, CONSTRAINT

[openstack-dev] [neutron][devstack][all] Deprecation of external_network_bridge and CI impact

Hi, This probably should have been advertised more widely, before the merge happened. I would like to apologize for an after-the-fact e-mail explaining what may be going on for some jobs that are broken. I recently merged a change to DevStack - https://review.openstack.org/346282 It's a little

Re: [openstack-dev] [neutron] Is this a bug in metadata proxy...

Hi, Are you sure metadata_proxy_user==neutron? neutron-metadata-proxy must be able to connect to the metadata-agent socket and watchs its log files and neutron user should be able to do both with usual file permissions. Otherwise the metadata proxy is generally no more able to: - watch log[1]

Re: [openstack-dev] [Cinder] The State of the NFS Driver ...

Thanks for the write up Jay. This is useful. Added [Cinder] tag to subject line... On Tue, Aug 30, 2016 at 10:50:38AM -0500, Jay S. Bryant wrote: > All, > > I wanted to follow up on the e-mail thread [1] on Cloning support in > the NFS driver. The purpose of this e-mail is to provide the plan

Re: [openstack-dev] [infra] Reliable way to filter CI in gerrit spam?

On Wed, Aug 31, 2016 at 3:44 PM, Matthew Booth wrote: > > Is there anything I missed? Or is it possible to unsubscribe from gerrit > mail from bots? Or is there any other good way to achieve what I'm looking > for which doesn't involve maintaining my own bot list? If not, would

[openstack-dev] [infra] Reliable way to filter CI in gerrit spam?

I've just (re-)written an email filter which splits gerrit emails into those from CI and those from real people. In general I'm almost never interested in botmail, but they comprise about 80% of gerrit email. Having looked carefully through some gerrit emails from real people and CIs, I

Re: [openstack-dev] [manila] [security] [tc] Add the vulnerability:managed tag to Manila

On 2016-08-31 10:18:57 +0100 (+0100), John Spray wrote: [...] > Given that all the drivers live in the Manila repo, will this > requirement for security audits is going to apply to them? Given the > variety of technologies and network protocols involved in talking to > external storage systems,

Re: [openstack-dev] [nova][keystone] auth for new metadata plugins

There is a quick sketch of what a service account might look like at https://review.openstack.org/#/c/363606/ -- I need to do some more fiddling to get the new option group working, but I could do that if we wanted to try and get this into Newton. Michael On Wed, Aug 31, 2016 at 7:54 AM, Matt

[openstack-dev] [neutron] Is this a bug in metadata proxy...

Hi, I had seen something and was not sure if this was a subtle bug or not. I have a Liberty based openstack setup. The account that is setting up processes was user=neutron, group=neutron, however the metadata_agent.ini config file was set up for a different group. So there was a

[openstack-dev] [Horizon] [FFE] Horizon Profiler feature (and openstack/osprofiler integration)

Hello, folks! I'd like to ask for a feature-freeze exception for a Horizon Profiler feature [1], that has been demoed long ago (during Portland midcycle Feb 2016) and is finally ready. The actual request applies to the 3 patches [2] that provide the bulk of Profiler functionality. It is a quite

Re: [openstack-dev] [nova] Next steps for resource providers work

On 08/31/2016 05:07 AM, Jay Pipes wrote: > On 08/29/2016 12:40 PM, Matt Riedemann wrote: >> I've been out for a week and not very involved in the resource providers >> work, but after talking about the various changes up in the air at the >> moment a bunch of us thought it would be helpful to lay

Re: [openstack-dev] [nova] Next steps for resource providers work

Le 31/08/2016 13:08, Jay Pipes a écrit : On 08/29/2016 12:40 PM, Matt Riedemann wrote: I've been out for a week and not very involved in the resource providers work, but after talking about the various changes up in the air at the moment a bunch of us thought it would be helpful to lay out

Re: [openstack-dev] [neutron][ipam] max_fixed_ips_per_port

I posted https://review.openstack.org/363602 . The deprecation of a mitaka release note was silly. So please let me know what you guys think. I think that keeping the configuration variable is the sanest option. Implementing a callback in each and every plugin that wants to enforce this is a

[openstack-dev] [neutron][ipam] max_fixed_ips_per_port

Hi, In commit 37277cf4168260d5fa97f20e0b64a2efe2d989ad [i] and commit fc661571765054ff09e41aa6c7fc32f80fd0a98d [ii] this variable was marked as deprecated. A number of neutron plugins make use of this to ensure that only one IP address can be configured per port per subnet. There are cases

Re: [openstack-dev] [nova] Next steps for resource providers work

On 08/29/2016 12:40 PM, Matt Riedemann wrote: I've been out for a week and not very involved in the resource providers work, but after talking about the various changes up in the air at the moment a bunch of us thought it would be helpful to lay out next steps for the work we want to get done

[openstack-dev] [Neutron] Missing functional job in check queue

Hi all, you might have noticed there was a time period where we run our gate without functional job. It was my goof that I appended ubuntu-trusty suffix to functional job [1] while the suffix by default make the job run on stable branches only. It should be fixed by now [2]. Sorry for

[openstack-dev] [new][senlin] python-senlinclient 1.0.0 release (newton)

We are tickled pink to announce the release of: python-senlinclient 1.0.0: OpenStack Clustering API Client Library This release is part of the newton release series. For more details, please see below. 1.0.0 ^ New Features * A new command 'senlin cluster-collect' and its

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

On 08/25/2016 07:52 PM, Andrew Laski wrote: > On Thu, Aug 25, 2016, at 12:22 PM, Everett Toews wrote: >> Top posting with general comment... >> >> It sounds like there's some consensus in Nova-land around these >> traits (née "capabilities"). The API Working Group [4] is >> also aware of similar

[openstack-dev] [new][senlin] senlin-dashboard 0.4.0 release (newton)

We are ecstatic to announce the release of: senlin-dashboard 0.4.0: Senlin Dashboard This release is part of the newton release series. Please report issues through launchpad: https://bugs.launchpad.net/senlin-dashboard For more details, please see below. 0.4.0 ^ New Features

[openstack-dev] [neutron]Should segments become a default service plugin?

Hi all. Before routed network, functions in [1] are used to manage network segment. Routed network introduces a plugin [2] to manage network segment. So, now there are 2 code paths to do the same job. Except in ml2, the segments plugin will be used to manage network segments. Patch [3] [4]

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

On 31 August 2016 at 11:57, Bogdan Dobrelya wrote: > I agree that RPC design pattern, as it is implemented now, is a major > blocker for OpenStack in general. It requires a major redesign, > including handling of corner cases, on both sides, *especially* RPC call >

[openstack-dev] [new][nova] python-novaclient 6.0.0 release (newton)

We are content to announce the release of: python-novaclient 6.0.0: Client library for OpenStack Compute API This release is part of the newton release series. With source available at: https://git.openstack.org/cgit/openstack/python-novaclient With package available at:

Re: [openstack-dev] [tricircle]How to address TCs concerns in Tricircle big-tent application

Hello, Duncan, You got the idea! We have planned to use admin-API (one of the service added in the Tricircle) to manage the routing from the master region to other regions. For these global objects, will make sure the routing(or say mapping) is correct and objects have same attributes, for

Re: [openstack-dev] [manila] [security] [tc] Add the vulnerability:managed tag to Manila

On Tue, Aug 30, 2016 at 6:07 PM, Jeremy Stanley wrote: > Ben has proposed[1] adding manila, manila-ui and python-manilaclient > to the list of deliverables whose vulnerability reports and > advisories are overseen by the OpenStack Vulnerability Management > Team. This proposal

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

On 08/31/2016 01:57 AM, Bogdan Dobrelya wrote: I agree that RPC design pattern, as it is implemented now, is a major blocker for OpenStack in general. It requires a major redesign, including handling of corner cases, on both sides, *especially* RPC call clients. Or may be it just have to be

Re: [openstack-dev] [tricircle]How to address TCs concerns in Tricircle big-tent application

If you're going with the approach of having a master region (which seems sensible), you're going to want an admin API that checks all of the regions setup matches in terms of these objects existing in all regions, for validation. On 31 August 2016 at 10:16, joehuang wrote:

Re: [openstack-dev] [nova] Next steps for resource providers work

On 08/29/2016 12:40 PM, Matt Riedemann wrote: I've been out for a week and not very involved in the resource providers work, but after talking about the various changes up in the air at the moment a bunch of us thought it would be helpful to lay out next steps for the work we want to get done

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

On 31.08.2016 03:52, joehuang wrote: > Cells is a good enhancement for Nova scalability, but there are some issues > in deployment Cells for massively distributed edge clouds: > > 1) using RPC for inter-data center communication will bring the difficulty in > inter-dc troubleshooting and

Re: [openstack-dev] tacker vnf-create is not bringing upalltheinterfaces

Both OpenWRT or Cirros images just brings up their first interface (eth0) to automatically do DHCP (client). Either case, please reach out to us in the #tacker IRC channel to get some help resolving this issue. On Mon, Aug 29, 2016 at 5:27 AM, Abhilash Goyal wrote: >

Re: [openstack-dev] [kuryr] Python 3 usage and kuryr-kubernetes

On Wed, Aug 31, 2016 at 9:23 AM, Jaume Devesa wrote: > Hi Toni, > > > I am +1 on a). Kuryr-kubernetes is an asynchronous service. We are not > talking about some binary/unicode mismatch or list/generators return type > that can be solved with 'six' library or some 'utils'

Re: [openstack-dev] [kuryr] Python 3 usage and kuryr-kubernetes

Hi Toni, I am +1 on a). Kuryr-kubernetes is an asynchronous service. We are not talking about some binary/unicode mismatch or list/generators return type that can be solved with 'six' library or some 'utils' module. If we go to python2 that will force us to re-do all the core part of the

[openstack-dev] [tricircle]agenda of weekly meeting Aug.31

Hello, team, Agenda of Aug.31 weekly meeting, let's continue the topics: # progress review and concerns on the features like micro versions, policy control, dynamic pod binding, cross pod L2 networking # How to address TCs concerns in Tricircle big-tent application:

[openstack-dev] [tricircle]How to address TCs concerns in Tricircle big-tent application

Hello, team, During last weekly meeting, we discussed how to address TCs concerns in Tricircle big-tent application. After the weekly meeting, the proposal was co-prepared by our contributors: https://docs.google.com/presentation/d/1kpVo5rsL6p_rq9TvkuczjommJSsisDiKJiurbhaQg7E The more doable

[openstack-dev] OpenStack Kuryr IRC meetings change

Hi Kuryrs! Infra merged the change that was agreed in this week's IRC meeting [1] Starting immediately, all subsequent OpenStack Kuryr IRC meetings will be held Mondays at 14:00 UTC at #openstack-meeting-4 We'll also try to publish an agenda the latest every Friday at the wiki [2]. Everybody is

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

Hello, Joshua, According to Peter's message, "However that still leaves us with the need to manage a stack of servers in thousands of telephone exchanges, central offices or even cell-sites, running multiple work loads in a distributed fault tolerant manner", the number of edge clouds may even

  1   2   >