Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

On Mon, Mar 23, 2015 at 9:23 PM, Anita Kuno wrote: > I'm really disappointed that there hasn't been more support for Mike in > this process. I can see how everyone thought I was the problem last year > when I had to endure this kind of treatment in Neutron, but I would > think after seeing the ex

[openstack-dev] [Neutron] Dropped downgrade support from migration scripts

Hello neutrons, I would like to notify all developers that all downgrades was removed from migration scripts [1]. So, if you have a change on review with a migration you have to submit another patch set with updated migration. This work was done according approved cross-project spec [2]. [1] - h

[openstack-dev] [mistral] Mistral kilo-3 dev milestone released

Hi, Mistral Kilo-3 development milestone (tagged as 2015.1.0b3) has been released! In this release we’ve completed mistral engine redesign that allows us to move forward with new exciting requirements (collections, asynchronous processing, policies etc.). A whitepaper describing all the changes

[openstack-dev] [Fuel] Pecan migration status

Hello, I want to summarize work I've done in spare time on migrating our API to Pecan [1]. This is partially based on previous Nicolay's work [2]. One test is still failing there but it's some DB lock and I'm not 100% sure that this is caused because something is yet not done on Pecan side or just

Re: [openstack-dev] [Ironic] 'Chassis' element in Ironic

Chassis alone is a management module too, rather than simply grouping nodes (as enclosure). Some chassis has individual fans, powers, even mini-switches. It normally also act as a supervisor of nodes udner it, to perform discovery, rescue tasks, which are not possible for node itself alone. It i

[openstack-dev] [nova] live migration flow

Hi guys, I would like to get to know about current live migration approach in nova. Maybe some of you could introduce me into basic live migration flow between files/services ? Regards, Bartosz __ OpenStack Development Mailin

Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

On 23 March 2015 at 22:50, Mike Perez wrote: > > I've talked to folks at the OpenStack foundation to get feedback on my > communication, and was told this was good, and even better than previous > communication to controversial changes. > > I expected nevertheless people to be angry with me and b

Re: [openstack-dev] [mistral] Mistral kilo-3 dev milestone released

Awesome! Looking forward to the whitepaper for more details! 2015-03-24 15:34 GMT+08:00 Renat Akhmerov : > Hi, > > Mistral Kilo-3 development milestone (tagged as 2015.1.0b3) has been > released! In this release we’ve completed mistral engine redesign that > allows us to move forward with new exci

Re: [openstack-dev] [Fuel] Pecan migration status

BTW, old urls do not match as yet exactly the new ones. There is a need to write a test that will check all urls.py list and compare with new handlers' urls to make sure nothing was missed. P. On 03/24/2015 08:46 AM, Przemyslaw Kaminski wrote: > Hello, > > I want to summarize work I've done in s

Re: [openstack-dev] [Neutron] Removing udp_port field from 'ml2_vxlan_endpoint' table

Mathieu, now I'm getting curious, is it possible to combine Linuxbridge and OVS VXLAN Nodes in the same cloud? I thought this does not work as Linuxbridge-vxlan uses multicast for instances broad- and multicasts (e.g. an arp request), while ovs-vxlan only does unicast? At least one can specify a

Re: [openstack-dev] [Keystone][FFE] ECP wrapped assertions

Hi, I strongly support this request. On 23.03.2015 22:42, Steve Martinelli wrote: I'd like to request an exemption for the following to go into the Kilo release. This work is crucial for: - Keystone to Keystone communication. An ECP wrapped SAML assertion will make it much easier for consum

[openstack-dev] [Murano] Murano agent development

Hello I would like to test and debug some new features of murano agent like chef recipes. I would like to know how to develop murano agent? How to test and debug new changes in agent code? Creating new image with every change and and test deployment on devstack is time-consuming and not very

Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

On Tue, Mar 24, 2015 at 2:51 AM, Walter A. Boring IV wrote: > On 03/23/2015 01:50 PM, Mike Perez wrote: > >> On 12:59 Mon 23 Mar , Stefano Maffulli wrote: >> >>> On Mon, 2015-03-23 at 11:43 -0700, Mike Perez wrote: >>> We've been talking about CI's for a year. We started talking about CI

[openstack-dev] Skipping Cross-Project meeting today?

Hi! The agenda for the cross-project meeting is currently empty: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting Unless someone has something urgent to discuss (and adds it to the agenda docket), I propose we skip this one and focus on getting our last feature-freeze exception code i

[openstack-dev] [Ceilometer] Meters vs. Metrics

All, I observed various "meters" and "metrics" with almost same meaning in telemetry part of admin-guild-cloud. Just curious about the minor difference. If they are interchangeable, we can pick up one for confusion. Best Rgds, Edwin

Re: [openstack-dev] [Murano] Murano agent development

Hi Filip, Sure, murano-agent is just a python application, you can easily run this application locally (even in IDE like Pycharm with attached debugger). To send execution plan to the agent you need to publish execution plan to specified queue, results also will be published to the queue. murano-

[openstack-dev] EC2 API Sub team weekly meeting

We'll have the weekly EC2 API sub team meeting [1] at 1400UTC in #openstack-meeting today. We'll likely spend the majority of the time going over current status along with critical bugs, as well as covering BPs. Please feel free to add other items in the agenda [2] section. Thanks! Swami [1] ht

Re: [openstack-dev] [oslo.messaging][zeromq] 'Subgroup' for broker-less ZeroMQ driver

On 23/03/15 09:24 -0400, Doug Hellmann wrote: Excerpts from Li Ma's message of 2015-03-23 18:23:39 +0800: Hi all, During previous threads discussing about zeromq driver, a subgroup may be necessary to exchange knowledge and improve efficiency of communication and development. In this subgroup,

Re: [openstack-dev] [all] Do we need release announcements for all the things?

Dean Troyer wrote: > On Mon, Mar 23, 2015 at 9:47 AM, Thierry Carrez > wrote: > > One area where we could work to remove noise would be to move new core > reviewers nomination/suggestion threads out of the ML. They are mostly > useless IMHO (only +1s), an

Re: [openstack-dev] [Murano] Murano agent development

One trick that can be done to simplify agent development is to a) configure it to listen to some specific queue and run it locally or on VM (you can even run it from IDE under debugger) so that you can edit its code in place b) using code from agent.py write sample application that will send execu

Re: [openstack-dev] [oslo.config][kolla] modular backends for oslo.cfg

On 19/03/15 13:31 +0100, Chmouel Boudjnah wrote: Hello, While on a long oversea flight with Sebastien Han we were talking how he had implemented ceph-docker with central configuration over etcd. We quickly came up to the conclusion that if we wanted to have that in Kolla it would be neat if it w

Re: [openstack-dev] [nova] Updating 'scheduled_at' field of nova instances in the database.

On 03/24/2015 12:09 PM, Deepak Shetty wrote: > > > On Tue, Mar 24, 2015 at 11:57 AM, Deepak Shetty > wrote: > > > > On Tue, Mar 24, 2015 at 10:58 AM, Deepthi Dharwar > mailto:[email protected]>> wrote: > > On 03/23/2015 09:00 PM, Jay Pipes

Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

Walter A. Boring IV wrote: > Thanks Mike for all of your efforts on this, +1 I think Mike checked all the possible boxes to give fair warning to driver owners. It's hard to say "no" in the name of quality. It's so much easier to just say "yes" and avoid all the hatemail and the pressure. Mike d

Re: [openstack-dev] [oslo.config][kolla] modular backends for oslo.cfg

On Tue, Mar 24, 2015 at 11:40 AM, Flavio Percoco wrote: > This however won't remove the need of a config file. For instance, > plugins like etcd's will need the host/port options to be set > somewhere - or passed as a cli parameter. > Yes totally! I have been using command line switches in my e

Re: [openstack-dev] [Neutron] Removing udp_port field from 'ml2_vxlan_endpoint' table

On 23 March 2015 at 14:49, Mathieu Rohon wrote: > Hi romil, > > I think the main purpose of this DB field is to maintain the compatibility > in dataplane between OVS and LinuxBridge which, by default, don't use the > same UDP port for VXLAN. > It might be useful for a cloud admin which wants to r

Re: [openstack-dev] [nova] live migration flow

IMHO, code talks everything :) 2015-03-24 16:06 GMT+08:00 Fic, Bartosz : > Hi guys, > > I would like to get to know about current live migration approach in nova. > > Maybe some of you could introduce me into basic live migration flow between > files/services ? > > > > Regards, > > Bartosz > > > _

Re: [openstack-dev] [nova] live migration flow

and FWIW, please refer to https://wiki.openstack.org/wiki/LiveMigrationWorkflows(maybe a little outdated), anyway, hope it will make sense to you. 2015-03-24 16:06 GMT+08:00 Fic, Bartosz : > Hi guys, > > I would like to get to know about current live migration approach in nova. > > Maybe some of y

Re: [openstack-dev] [nova] live migration flow

correct the URL: https://wiki.openstack.org/wiki/LiveMigrationWorkflows 2015-03-24 19:38 GMT+08:00 Lingxian Kong : > and FWIW, please refer to > https://wiki.openstack.org/wiki/LiveMigrationWorkflows(maybe a little > outdated), anyway, hope it will make sense to you. > > 2015-03-24 16:06 GMT+08:00

Re: [openstack-dev] [nova] Revert "objects: introduce numa topology limits objects"

On 03/23/2015 02:06 PM, Dan Smith wrote: >> I am really sorry it got in as I have -1ed it several times for the same >> reason (I _really_ hate using the -2 hammer - we're all adults here >> after all). > > I guess that I should take some blame as a reviewer on that patch, but > only after this ma

Re: [openstack-dev] [Neutron] Removing udp_port field from 'ml2_vxlan_endpoint' table

On Tue, Mar 24, 2015 at 12:15 PM, Salvatore Orlando wrote: > > > On 23 March 2015 at 14:49, Mathieu Rohon wrote: > >> Hi romil, >> >> I think the main purpose of this DB field is to maintain the >> compatibility in dataplane between OVS and LinuxBridge which, by default, >> don't use the same UD

Re: [openstack-dev] [Neutron] Removing udp_port field from 'ml2_vxlan_endpoint' table

Hi Andreas, Linuxbridge is also able to use Unicast, but currently, it is only available when l2pop is activated. AFAIR, I saw the mix of LB agents and ovs agent working, with vxlan, l2pop and and ARP responders turned on everywhere. You also have to tune your vxlan module, or ovs, to make sure th

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

On 2015-03-23 21:31:30 -0400 (-0400), Jay Pipes wrote: > On Mon, Mar 23, 2015 at 09:35:50PM +, Jeremy Stanley wrote: > > On 2015-03-23 15:15:18 -0400 (-0400), Jay Pipes wrote: > > [...] > > > I don't want it suppressed. I want the use of API extensions and the > > > extension framework(s) to be

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

On 2015-03-23 22:34:17 -0600 (-0600), Chris Friesen wrote: > How would that be expected to work for things where it's > fundamentally just a minor extension to an existing nova API? > (Exposing additional information as part of "nova show", for > example.) Conversely, how do you recommend users of

Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

On Tue, Mar 24, 2015 at 4:52 AM, Thierry Carrez wrote: > Walter A. Boring IV wrote: > > Thanks Mike for all of your efforts on this, > > +1 > > I think Mike checked all the possible boxes to give fair warning to > driver owners. > > It's hard to say "no" in the name of quality. It's so much easie

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

On 03/24/2015 09:11 AM, Jeremy Stanley wrote: > On 2015-03-23 22:34:17 -0600 (-0600), Chris Friesen wrote: >> How would that be expected to work for things where it's >> fundamentally just a minor extension to an existing nova API? >> (Exposing additional information as part of "nova show", for >>

Re: [openstack-dev] [Neutron] Removing udp_port field from 'ml2_vxlan_endpoint' table

Thank's Mathieu, I would probably first try out running KVM in mixed environment using OVS and LB as L2 agent with VXLAN underlay. And, try to implement as you suggested on the patchset within kilo or liberty release cycle. On Tue, Mar 24, 2015 at 6:25 PM, Mathieu Rohon wrote: > Hi Andreas, > >

[openstack-dev] Hyper-V meeting

Hi All, We're currently working to resolve CI related issues. We'll need to postpone the meeting for this week as a result. p Peter J. Pouliot CISSP Microsoft Enterprise Cloud Solutions C:\OpenStack New England Research & Development Center 1 Memorial Drive Cambridge, MA 02142 P: 1.(857).4536

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

On Tue, Mar 24, 2015 at 01:04:46PM +, Jeremy Stanley wrote: > On 2015-03-23 21:31:30 -0400 (-0400), Jay Pipes wrote: > > On Mon, Mar 23, 2015 at 09:35:50PM +, Jeremy Stanley wrote: > > > On 2015-03-23 15:15:18 -0400 (-0400), Jay Pipes wrote: > > > [...] > > > > I don't want it suppressed. I

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

On Tue, Mar 24, 2015 at 7:10 AM, Jay Pipes wrote: > On Tue, Mar 24, 2015 at 01:04:46PM +, Jeremy Stanley wrote: > > On 2015-03-23 21:31:30 -0400 (-0400), Jay Pipes wrote: > > > On Mon, Mar 23, 2015 at 09:35:50PM +, Jeremy Stanley wrote: > > > > On 2015-03-23 15:15:18 -0400 (-0400), Jay Pi

Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

> On Mar 24, 2015, at 9:30 AM, John Griffith wrote: > > > > On Tue, Mar 24, 2015 at 4:52 AM, Thierry Carrez > wrote: > Walter A. Boring IV wrote: > > Thanks Mike for all of your efforts on this, > > +1 > > I think Mike checked all the possible boxes to give fai

Re: [openstack-dev] EC2 API Sub team weekly meeting

As we got the conflict with meeting room, moved this meeting to #openstack-meeting-3 room. But, only Rushiagr joined the meeting and so could not discuss the current status and other items and end the meeting. Minutes: http://eavesdrop.openstack.org/meetings/ec2_api/2015/ec2_api.2015-03-24-14.08.

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

On 2015-03-24 10:10:07 -0400 (-0400), Jay Pipes wrote: [...] > I'm really not a fan of the Defcore effort. This should come as no > surprise to anyone. I've been quite blunt about my disdain for the > focus on identifying which API things are mandatory and which are > optional, in order to say some

Re: [openstack-dev] Quota management and enforcement across projects

Hi, Interesting thread. I’ve just started looking at Boson myself to manage quotas across multiple regions. I think one of the cases when having quota management as a separate service is justified, is a multi-region case [1]. 1) Some deployments can share Keystone, so there’s a need to synchron

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

Weiting, Andrew, Agreed, great ideas! As Andrew noted, we have discussed some of these things before and it would be great to discuss them in Vancouver. I think that a Sahara-side workflow manager is the right approach. Oozie has a lot of capability for job coordination, but it won't work for al

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

On 3/23/2015 3:56 AM, Miguel Ángel Ajo wrote: I see you point Van, In the other hand, removing it, cleans up lot of conditional code parts (moving parts at the other side), and also the non-netns case is not tested by upstream CI, AFAIK, so it could be broken anytime and we would not notice it

Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

Excerpts from Mark McClain's message of 2015-03-24 10:25:31 -0400: > > Echoing both Thierry and John. I support Mike’s decision to enforce the > requirement. Maintaining drivers in the tree comes with responsibilities to > the community and 3rd party CI is one of the them. Mike enforcing this

[openstack-dev] [kolla] Announcing k3 release of Kolla

Hello, The Kolla community is pleased to announce the release of Kilo #3 of the Kolla project. It is available for immediate download from: https://github.com/stackforge/kolla/archive/k3.tar.gz This version removes Kubernetes entirely as a development environment. We found we needed super-pr

Re: [openstack-dev] [oslo.messaging][zeromq] 'Subgroup' for broker-less ZeroMQ driver

On Mon, Mar 23, 2015 at 9:24 PM, Doug Hellmann wrote: > The goal we set at the Kilo summit was to have a group of people > interested in zmq start contributing to the driver, and I had hoped to > the library overall. How do we feel that is going? That sounds great. I hope so. > One way to create

Re: [openstack-dev] [kolla] Announcing k3 release of Kolla

sdake, cool! -- pshige 2015/03/25 0:29 "Steven Dake (stdake)" : > Hello, > > The Kolla community is pleased to announce the release of Kilo #3 of the > Kolla project. It is available for immediate download from: > https://github.com/stackforge/kolla/archive/k3.tar.gz > > This version removes

Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

+10 to mike; I have no doubt this is an uneasy and tough task. Thanks mike for pushing this through; given all the challenges and hard work (and likely not fun work) that had to be done. I salute u! :) -Josh Duncan Thomas wrote: On 23 March 2015 at 22:50, Mike Perez mailto:[email protected]

Re: [openstack-dev] [Keystone][FFE] ECP wrapped assertions

++ Same here. From: Marek Denis [mailto:[email protected]] Sent: Tuesday, March 24, 2015 1:51 AM To: [email protected] Subject: Re: [openstack-dev] [Keystone][FFE] ECP wrapped assertions Hi, I strongly support this request. On 23.03.2015 22:42, Steve Martinelli wrote: I'd like

Re: [openstack-dev] [oslo.messaging][zeromq] 'Subgroup' for broker-less ZeroMQ driver

Excerpts from Li Ma's message of 2015-03-24 23:31:22 +0800: > On Mon, Mar 23, 2015 at 9:24 PM, Doug Hellmann wrote: > > The goal we set at the Kilo summit was to have a group of people > > interested in zmq start contributing to the driver, and I had hoped to > > the library overall. How do we fee

Re: [openstack-dev] [oslo.messaging][zeromq] 'Subgroup' for broker-less ZeroMQ driver

On 03/24/2015 10:31 AM, Li Ma wrote: > On Mon, Mar 23, 2015 at 9:24 PM, Doug Hellmann wrote: >> The goal we set at the Kilo summit was to have a group of people >> interested in zmq start contributing to the driver, and I had hoped to >> the library overall. How do we feel that is going? > > That

[openstack-dev] [puppet] Meeting notes 24 March 2015

Our meeting minutes from today are here: http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-03-24-14.59.html We discussed electing a PTL, and will be following up soon to start a deeper discussion on the mailing lists. We'd like to start dedicating time for launc

Re: [openstack-dev] [oslo.messaging][zeromq] 'Subgroup' for broker-less ZeroMQ driver

On 24/03/15 11:03 -0500, Ben Nemec wrote: On 03/24/2015 10:31 AM, Li Ma wrote: On Mon, Mar 23, 2015 at 9:24 PM, Doug Hellmann wrote: The goal we set at the Kilo summit was to have a group of people interested in zmq start contributing to the driver, and I had hoped to the library overall. How

Re: [openstack-dev] [oslo.messaging][zeromq] 'Subgroup' for broker-less ZeroMQ driver

+1 to keep it together. -- dims On Tue, Mar 24, 2015 at 12:17 PM, Flavio Percoco wrote: > On 24/03/15 11:03 -0500, Ben Nemec wrote: >> >> On 03/24/2015 10:31 AM, Li Ma wrote: >>> >>> On Mon, Mar 23, 2015 at 9:24 PM, Doug Hellmann >>> wrote: The goal we set at the Kilo summit was to ha

[openstack-dev] [Neutron] VLAN trunking network for NFV

Hi all: in reference to the following specification about the creation of VLAN trunking network for NFV https://review.openstack.org/#/c/136554/3/specs/kilo/nfv-vlan-trunks.rst I would like to better understand how the tagged traffic will be realized. In order to explain myself, I report the

Re: [openstack-dev] [oslo.messaging][zeromq] 'Subgroup' for broker-less ZeroMQ driver

Hi, +1 for subgroup meeting Does the separate repository mean separate library (python package) with its own release cycles so on? As I can see the separate library makes it easy: 1) To support optional (for oslo.messaging) requirements specific for zmq driver like pyzmq, redis so on 2) Sepa

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

On 03/24/2015 07:42 AM, Sean Dague wrote: On 03/24/2015 09:11 AM, Jeremy Stanley wrote: On 2015-03-23 22:34:17 -0600 (-0600), Chris Friesen wrote: How would that be expected to work for things where it's fundamentally just a minor extension to an existing nova API? (Exposing additional informat

[openstack-dev] [neutron] FF and our march towards the RC

Folks: I've gone through the BPs granted an FFE and I have our RC-1 setup now [1]. Please note that the BPs in there all need to merge by the dates specified in the BP in Launchpad. Most are by next Tuesday, March 31. But the LBaaS drivers need to go in by Friday. If these BPs don't land by then,

Re: [openstack-dev] [oslo.messaging][zeromq] 'Subgroup' for broker-less ZeroMQ driver

>From my experience, making fast moving changes is far easier when code is split out. Changes occur too slowly when integrated. I'd be +1 on splitting the code out. I expect you will get more done this way. Regards, Eric Windisch ___

Re: [openstack-dev] [Ceilometer] Meters vs. Metrics

tbh, i've been using them interchangeably -- i don't know if they are logically different. i believe gnocchi uses 'metric' term while current api uses 'meter' so we don't really have a common usage in api either. if i were to choose one, i'd lean more to using 'metric'. cheers, gord > Date: T

Re: [openstack-dev] [Neutron] VLAN trunking network for NFV

That spec ensures that you can tell what the plugin is doing. You can ask for a VLAN transparent network, but the cloud may tell you it can't make one. The OVS driver in Openstack drops VLAN tagged packets, I'm afraid, and the spec you're referring to doesn't change that. The spec does ensure th

[openstack-dev] [sahara] Sahara + Cinder use cases?

Hi, I am working on a Sahara doc bug: https://bugs.launchpad.net/sahara/+bug/1371360 [DOC] Features overview suggests Cinders to increase reliability I am doing some research for this update. What are the use cases for Sahara + Cinder? 1. Cinder-backed Sahara for persiste

[openstack-dev] [glance] zero downtime conf/kilo

All, The main zero downtime config patch has merged (thanks to everyone, especially Abhishek, for their help). There's a couple of small, follow on corner case patches, that, eg ensure a config change to logging (INFO->DEBUG) can be picked up dynamically. Are we planning/hoping to merge them

Re: [openstack-dev] [Ceilometer] Meters vs. Metrics

Can we keep it consistent ? The APIs have meter in them, so do the CLIs so we should really stick to that convention. If Gnocchi is using metrics, I feel it should change to use meters or a V3 API proposed that changes it all. Projects and Tenants still cause such massive confusion for the end

Re: [openstack-dev] [Neutron] VLAN trunking network for NFV

>From spec [1], I read: - Of the core drivers, the VLAN and OVS drivers will be marked as not supporting VLAN transparent networks and the LB, VXLAN and GRE drivers will be marked as supporting VLAN transparent networks. Other drivers will have legacy behaviour. I can't seem to find

Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

One other item I’d like to bring up. While Nova and Neutron are well distributed around the globe and have Core Reviewers on IRC in the Asia daytime, some other projects are not so well distributed as yet. A problem I noticed a number of times is that an Asia based developer will post to the m

Re: [openstack-dev] [glance] zero downtime conf/kilo

Thanks for your (everyone involved) effort on this! Do we have documented bugs for getting these patches merged? We're in a RC window so better to have explicit indication (possibly using bugs) of what's going; this would help the core reviewers to verify and adhere to the freeze guidelines. P

[openstack-dev] [Congress] Info on Currently Supported Data Drivers

Hi, I have a question about where to find the complete set of currently supported data drivers (with table/row details) for Congress. The info at http://congress.readthedocs.org/en/latest/cloudservices.html#drivers seems to cover only Nova and Neutron. I'm sure that I can pull this info from t

Re: [openstack-dev] [Ceilometer] Meters vs. Metrics

> Can we keep it consistent ? The APIs have meter in them, so do the CLIs so we > should really stick to that convention. agreed, i just wanted to mention the inconsistencies as they exist today. to play devil's advocate, the reason i lean more to using 'metric' is that it's arguably more widely

Re: [openstack-dev] [nova] Updating 'scheduled_at' field of nova instances in the database.

On 03/24/2015 12:27 AM, Deepak Shetty wrote: I am _not_ nova expert, but iiuc, a VM is scheduled once and changing the host as part of migration isn't scheduling, but i could be wrong too. Not sure I agree. Any time that a VM could be placed on a different host the scheduler could be involve

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

Note that https://review.openstack.org/#/c/166888/ has been merged. This means that the option has been deprecated for K and will be removed in L. Anyone using the non-default value of False will be looking at errors in his logs. - Original Message - > > > On 3/23/2015 3:56 AM, Miguel Án

Re: [openstack-dev] [devstack] Overriding settings file for devstack plugin

On 03/24/2015 03:17 PM, Deepak Shetty wrote: > For eg: Look at [1] > [1] > https://github.com/stackforge/devstack-plugin-glusterfs/blob/master/devstack/settings > I would like ability to change these while I use the enable_plugin > apporach to setup devstack w/ GlusterFS per my local glusterfs se

[openstack-dev] Cinder Review Inbox Was RE: Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

Changing the topic. Mike Perez did include a Cinder Review Inbox link on the main Cinder Wiki page. https://wiki.openstack.org/wiki/Cinder#Resources Not sure how many people/cores use that link but that could be a step towards what you’re asking for. The query should probably be proposed to htt

Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers

Hi Bryan, The drive source code is the best documentation that describes the table and row level? detail. The translator description in the source code sums up the tables an drivers in a succinct way. If you need any additional clarification, let me know. - Alex ___

Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers

Hi Bryan, Inline. On Mar 24, 2015, at 12:13 PM, Bryan Sullivan mailto:[email protected]>> wrote: Hi, I have a question about where to find the complete set of currently supported data drivers (with table/row details) for Congress. The info at http://congress.readthedocs.org/en/latest/cloudse

[openstack-dev] [all] creating stable branches for all libraries, Oslo, client, and other

We have a cross-project spec up for review discussing a change in the release process precipitated by the fact that we are now capping library versions in stable branch test configurations. We’ve talked about it a couple of times at the cross-project meetings, but we also want to make sure it is

Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers

Thanks for clarifying, Tim (and Alex for the other response). Since I have to understand the code anyway going to the drivers for current info is reasonable. Can I derive from your statement "One of Congress’s goals is to make any data available via an API call to policy-related" that Congre

Re: [openstack-dev] Cinder Review Inbox Was RE: Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

On 19:38 Tue 24 Mar , Asselin, Ramy wrote: > Changing the topic. > > Mike Perez did include a Cinder Review Inbox link on the main Cinder Wiki > page. > https://wiki.openstack.org/wiki/Cinder#Resources > > Not sure how many people/cores use that link but that could be a step towards > what yo

Re: [openstack-dev] Cinder Review Inbox Was RE: Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

Dell - Internal Use - Confidential The link from cinder page to Cinder review inbox (https://review.openstack.org/#/dashboard/) from https://wiki.openstack.org/wiki/Cinder#Resources is empty. Link to bugs does work. -Original Message- From: Mike Perez [mailto:[email protected]] Sent: T

Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

Dell - Internal Use - Confidential +2 on Mike’s job From: Duncan Thomas [mailto:[email protected]] Sent: Tuesday, March 24, 2015 3:07 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request

Re: [openstack-dev] [all] creating stable branches for all libraries, Oslo, client, and other

On Tue, Mar 24, 2015 at 1:13 PM, Doug Hellmann wrote: > We have a cross-project spec up for review discussing a change in the > release process precipitated by the fact that we are now capping library > versions in stable branch test configurations. We’ve talked about it a > couple of times at th

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

On 18:20 Mon 23 Mar , Diem Tran wrote: > Hello Cinder team, > > Oracle ZFSSA CI has been reporting since March 20th. Below is a link > to the list of results the CI already posted: > > https://review.openstack.org/#/q/reviewer:%22Oracle+ZFSSA+CI%22,n,z > > Our CI system will be running and r

Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

I also absolutely agree that Mike did a great job on the communication with the driver maintainers and a lot more, especially in the hectic days around the K-3 deadline. Removing any driver lacking CI testing was just the right thing to do, even if this affected our SMB3 driver. Hopefully this is

Re: [openstack-dev] Cinder Review Inbox Was RE: Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

On 15:59 Tue 24 Mar , [email protected] wrote: > Dell - Internal Use - Confidential > The link from cinder page to Cinder review inbox > (https://review.openstack.org/#/dashboard/) from > https://wiki.openstack.org/wiki/Cinder#Resources is empty. > > Link to bugs does work. I'm using t

Re: [openstack-dev] [Neutron] VLAN trunking network for NFV

On 24 March 2015 at 11:45, Armando M. wrote: > This may be besides the point, but I really clash with the idea that we > provide a reference implementation on something we don't have CI for... > Aside from the unit testing, it is going to get a test for the case we can test - when using the stan

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

Hi Doug, On Thu, 19 Mar 2015 10:01:54 -0600 Doug Wiegley wrote: > Hi Gary, > > First I’m seeing these, but I don’t see that they’re required on > input, unless I’m mis-reading those reviews. Additional of new > output fields to a json object, or adding optional inputs, is not > generally consi

Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

On Tue, Mar 24, 2015 at 9:56 AM, Doug Hellmann wrote: > Excerpts from Mark McClain's message of 2015-03-24 10:25:31 -0400: > > > > Echoing both Thierry and John. I support Mike’s decision to enforce the > requirement. Maintaining drivers in the tree comes with responsibilities to > the community

Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers

Hi Bryan, I wish we could claim Congress has most of the data from OpenStack APIs already available for policy, but that’s not the case today. If it were me, I’d start with your use cases, figure out which services and API calls you’ll need to support those use cases, and then check if those AP

[openstack-dev] Beyond IRC (was Re: Cinder Third-Party CI: what next?)

On Tue, 2015-03-24 at 19:01 +, Rochelle Grober wrote: > So, how do we get timely first core review of patches in areas of the > world where Core presence in IRC is slim to none? I think that most core reviewers use bouncers, so notifying them in the channel would probably raise a notification

Re: [openstack-dev] [neutron] FF and our march towards the RC

Kyle and cores, There are some fixes [1] I want to get merged in kilo-rc1. (These fixes stay for a long time on gerrit because they have not gained core's review much.) I'd like to set milestone to kilo-rc1 for these fixes but I can't set milestone field of launchpad. I wish cores are interest

Re: [openstack-dev] Beyond IRC (was Re: Cinder Third-Party CI: what next?)

On 15:13 Tue 24 Mar , Stefano Maffulli wrote: > On Tue, 2015-03-24 at 19:01 +, Rochelle Grober wrote: > > ·Somehow queueing requests in the IRC channel so that offline > > developers can easily find review requests when looking at channel > > logs > > Maybe we can hack an IRC bot s

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

Jeremy Stanley on March 24, 2015 07:28 wrote: On 2015-03-24 10:10:07 -0400 (-0400), Jay Pipes wrote: [...] > I'm really not a fan of the Defcore effort. This should come as no > surprise to anyone. I've been quite blunt about my disdain for the > focus on identifying which API things are mandator

Re: [openstack-dev] Beyond IRC (was Re: Cinder Third-Party CI: what next?)

Mike Perez on March 24, 2015 16:39 wrote: On 15:13 Tue 24 Mar , Stefano Maffulli wrote: > On Tue, 2015-03-24 at 19:01 +, Rochelle Grober wrote: > > *Somehow queueing requests in the IRC channel so that offline > > developers can easily find review requests when looking at channel >

Re: [openstack-dev] [Neutron] VLAN trunking network for NFV

I am trying to understand how guest os use trunking network. If guest os use bridge like Linuxbride and OVS, how we launch it and how libvirt to support it? Thanks, -Ruijing From: Ian Wells [mailto:[email protected]] Sent: Wednesday, March 25, 2015 2:18 AM To: OpenStack Development Mailin

Re: [openstack-dev] Beyond IRC (was Re: Cinder Third-Party CI: what next?)

Excerpts from Stefano Maffulli's message of 2015-03-24 15:13:09 -0700: > On Tue, 2015-03-24 at 19:01 +, Rochelle Grober wrote: > > So, how do we get timely first core review of patches in areas of the > > world where Core presence in IRC is slim to none? > > I think that most core reviewers us

Re: [openstack-dev] [all] creating stable branches for all libraries, Oslo, client, and other

Excerpts from Joe Gordon's message of 2015-03-24 14:22:03 -0700: > On Tue, Mar 24, 2015 at 1:13 PM, Doug Hellmann > wrote: > > > We have a cross-project spec up for review discussing a change in the > > release process precipitated by the fact that we are now capping library > > versions in stabl

Re: [openstack-dev] [oslo.messaging][zeromq] 'Subgroup' for broker-less ZeroMQ driver

Excerpts from ozamiatin's message of 2015-03-24 18:57:25 +0200: > Hi, > +1 for subgroup meeting > > Does the separate repository mean separate library (python package) with > its own release cycles so on? Yes, although as an Oslo library it would be subject to our existing policies about version

Re: [openstack-dev] [nova][ThirdPartyCI][PCI] Intel Third party Hardware based CI for PCI

在 2015年03月07日 04:59, Chris Friesen 写道: Hi...it would be good to test a bunch of the hugepages/pinning/multi-numa-node-guests/etc. features with real hardware. The normal testing doesn't cover much of that since it's hardware-agnostic. we had another team build up a Networking CI for this pu

  1   2   >