[openstack-dev] [nova] [neutron] Re: [Openstack-operators] How do your end users use networking?

Adding -dev because of the reference to the Neutron "Get me a network spec". Also adding [nova] and [neutron] subject markers. Comments inline, Kris. On 05/22/2015 09:28 PM, Kris G. Lindgren wrote: During the Openstack summit this week I got to talk to a number of other operators of large Open

Re: [openstack-dev] [kolla] Proposal for new core-reviewer Harm Waites

On Jun 15, 2015, at 02:48, Steven Dake (stdake) mailto:std...@cisco.com>> wrote: I am proposing Harm Waites for the Kolla core team. +1 Harm did excellent work on the designate container and does very thorough reviews, the cinder container review being just one example among many. Martin

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

On 06/16/2015 03:47 PM, Jim Rollenhagen wrote: On Tue, Jun 16, 2015 at 08:56:37AM +0200, Dmitry Tantsur wrote: On 06/04/2015 08:58 AM, Xu, Hejie wrote: Hi, guys, I’m working on adding Microversion into the API-WG’s guideline which make sure we have consistent Microversion behavior in the API fo

Re: [openstack-dev] [Openstack-operators] Device {UUID}c not defined on plugin

Hi, I forgot to attach some relevant config files: /etc/neutron/plugins/ml2/ml2_conf.ini : [ml2] type_drivers = gre tenant_network_types = gre mechanism_drivers = openvswitch [ml2_type_flat] [ml2_type_vlan] [ml2_type_gre] tunnel_id_ranges = 1:1000 [ml2_type_vxlan] [securitygroup] firewall_driver

Re: [openstack-dev] Device {UUID}c not defined on plugin

Hi, I forgot to attach some relevant config files: /etc/neutron/plugins/ml2/ml2_conf.ini : [ml2] type_drivers = gre tenant_network_types = gre mechanism_drivers = openvswitch [ml2_type_flat] [ml2_type_vlan] [ml2_type_gre] tunnel_id_ranges = 1:1000 [ml2_type_vxlan] [securitygroup] firewall_driver

Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack

+1 Sean. -- dims On Tue, Jun 16, 2015 at 9:22 AM, Sean Dague wrote: > FYI, > > One of the things that came out of the summit for Devstack plans going > forward is to trim it back to something more opinionated and remove a > bunch of low use optionality in the process. > > One of those branches t

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

On 06/16/2015 08:56 AM, Dmitry Tantsur wrote: On 06/04/2015 08:58 AM, Xu, Hejie wrote: Hi, guys, I’m working on adding Microversion into the API-WG’s guideline which make sure we have consistent Microversion behavior in the API for user. The Nova and Ironic already have Microversion implementati

Re: [openstack-dev] [murano] python versions

Stan, +100500 On Fri, Jun 12, 2015 at 3:13 PM, Stan Lagun wrote: > > I'd rather go with Heat approach (job first) because it makes easier to track > what is left to port to Py34 and track progress in this area > > Sincerely yours, > Stan Lagun > Principal Software Engineer @ Mirantis > > > On Mo

Re: [openstack-dev] [QA] [openstack-qa] [tempest] UUIDs and names in tempest.conf file

So I need to point out that the openstack-qa list isn't used anymore. We only keep it around so we have a place to send for periodic test results. In the future you should just send things to the openstack-dev ML with a [QA] tag in the subject. On Tue, Jun 16, 2015 at 05:25:30AM +, Tikkanen, V

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

On Tue, Jun 16, 2015 at 08:56:37AM +0200, Dmitry Tantsur wrote: > On 06/04/2015 08:58 AM, Xu, Hejie wrote: > >Hi, guys, > >I’m working on adding Microversion into the API-WG’s guideline which > >make sure we have consistent Microversion behavior in the API for user. > >The Nova and Ironic already h

Re: [openstack-dev] [all][requirements] Proposing a slight change in requirements.txt syncing output.

Excerpts from Robert Collins's message of 2015-06-16 11:18:55 +1200: > At the moment we copy the global-requirements lines verbatim. > > So if we have two lines in global-requirements.txt: > oslotest>=1.5.1 # Apache-2.0 > PyECLib>=1.0.7 # BSD > with very different layouts

Re: [openstack-dev] [Magnum] TLS Support in Magnum

Out of the box, vms usually can contact the controllers though the routers nat, but not visa versa. So its preferable for guest agents to make the connection, not the controller connect to the guest agents. No floating ips, security group rules or special networks are needed then. Thanks, Kevin

Re: [openstack-dev] [Nova] [Cinder] [Tempest] Regarding deleting snapshot when instance is OFF

On Thu, Apr 9, 2015 at 6:10 PM, Eric Blake wrote: > On 04/08/2015 11:22 PM, Deepak Shetty wrote: > > + [Cinder] and [Tempest] in the $subject since this affects them too > > > > On Thu, Apr 9, 2015 at 4:22 AM, Eric Blake wrote: > > > >> On 04/08/2015 12:01 PM, Deepak Shetty wrote: > >>> > >>> Qu

[openstack-dev] Device {UUID}c not defined on plugin

Hi after a migration of Havana to IceHouse (using controller and network services/agents on the same physical node, and using OVS/GRE) we started facing some network-related problems (the internal tag of the element shown by ovs-vsctl show was set to 4095, which is wrong AFAIK). At the beginni

Re: [openstack-dev] [all][release] summit session summary: Release Versioning for Server Applications

Excerpts from Timur Nurlygayanov's message of 2015-06-16 12:49:02 +0300: > Hi Doug, > > I suggest to use some version for neutron-*aas plugins, probably, 1.0.0 > just to have one pattern for all components. If we will not use numbers for > the first releases (or release candidates) it will be hard

[openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack

FYI, One of the things that came out of the summit for Devstack plans going forward is to trim it back to something more opinionated and remove a bunch of low use optionality in the process. One of those branches to be trimmed is all the support for things beyond RabbitMQ in the rpc layer. Rabbit

Re: [openstack-dev] [all][release] summit session summary: Release Versioning for Server Applications

Excerpts from Thierry Carrez's message of 2015-06-16 11:45:51 +0200: > Doug Hellmann wrote: > > [...] > > I put together a little script [1] to try to count the previous > > releases for projects, to use that as the basis for their first > > SemVer-based version number. I pasted the output into an

Re: [openstack-dev] [nova] Online Migrations.

On 6/15/15 8:34 PM, Philip Schwartz wrote: I discussed this a bit earlier with John and we came up with a thought that I was going to present after getting a little bit more documentation and spec around. With out going into too much detail, here is the basics of the idea. Add a new column t

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

On 16 June 2015 at 14:38, Lucas Alvares Gomes wrote: > Hi > > >> So if our min_version is 2.1 and the max_version is 2.50. That means > >> alternative implementations need implement all the 50 versions > >> api...that sounds pain... > > > > > > Yes, it's pain, but it's no different than someone w

[openstack-dev] [release] Release announcements convergence

Hi everyone, Release announcements in OpenStack come in various forms and shapes. So far we had: - Integrated release "service" components being announced on openstack-announce and openstack general lists. - Other "service" components sometimes being announced on openstack-dev - Oslo libraries

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

On 06/16/2015 08:38 AM, Lucas Alvares Gomes wrote: > Hi > >>> So if our min_version is 2.1 and the max_version is 2.50. That means >>> alternative implementations need implement all the 50 versions >>> api...that sounds pain... >> >> >> Yes, it's pain, but it's no different than someone who is fol

Re: [openstack-dev] [puppet] drop monolithic plugins in neutron module

The patch has been merged: https://review.openstack.org/#/c/190395 These plugins are now deleted from puppet-neutron: * monolithic OVS (replaced in favor of ML2 with openvswitch mechanism driver) * monolithic Linux Bridge (replaced in favor of ML2 with linuxbridge mechanism driver) On 06/12/2015

[openstack-dev] [ceilometer] When do we import aodh?

Hi there, The alarm code split blueprint¹ has been approved, and I finished the split of the code base. It's available online at: https://github.com/jd/aodh tox -e pep8,py27,docs passes. To me the next step is to: 1. Someone cares and review what I've done in the repository 2. import the code

Re: [openstack-dev] [fuel] Fuel API settings reference

Andrew, I've also noticed that incompatible changes are being introduced in JSON schemas for different objects in almost every release. I hope that explicit reference that lists and explains all parameters will discourage such modifications, or at least will increase their visibility and allow to

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

Hi >> So if our min_version is 2.1 and the max_version is 2.50. That means >> alternative implementations need implement all the 50 versions >> api...that sounds pain... > > > Yes, it's pain, but it's no different than someone who is following the > Amazon EC2 API, which cuts releases at a regular

Re: [openstack-dev] [Horizon] [tests] [dsvm] Tests failed because of timeout during the images upload

Timur, If old jQuery code (not AngularJS) is still used for processing 'Create Image' form, then the spinner is shown just before submitting the form contents [1] and hidden right after the request completes [2] in case the form is being redrawn or the whole page is redrawn in case of redirect - w

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

On 06/16/2015 08:00 AM, Dmitry Tantsur wrote: 16 июня 2015 г. 13:52 пользователь "Jay Pipes" mailto:jaypi...@gmail.com>> написал: > > On 06/16/2015 04:36 AM, Alex Xu wrote: >> >> So if our min_version is 2.1 and the max_version is 2.50. That means >> alternative implementations need impleme

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

On 06/16/2015 07:38 AM, Alex Xu wrote: > > > 2015-06-16 18:57 GMT+08:00 Sean Dague >: > > On 06/15/2015 03:45 PM, Kevin L. Mitchell wrote: > > On Mon, 2015-06-15 at 13:07 -0400, Jay Pipes wrote: > >> The original spec said that the HTTP header should contain t

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

16 июня 2015 г. 13:52 пользователь "Jay Pipes" написал: > > On 06/16/2015 04:36 AM, Alex Xu wrote: >> >> So if our min_version is 2.1 and the max_version is 2.50. That means >> alternative implementations need implement all the 50 versions >> api...that sounds pain... > > > Yes, it's pain, but it'

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

On 06/16/2015 04:12 AM, Ken'ichi Ohmichi wrote: 2015-06-16 2:07 GMT+09:00 Jay Pipes : It has come to my attention in [1] that the microversion spec for Nova [2] and Ironic [3] have used the project name -- i.e. Nova and Ironic -- instead of the name of the API -- i.e. "OpenStack Compute" and "Op

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

On 06/16/2015 04:36 AM, Alex Xu wrote: So if our min_version is 2.1 and the max_version is 2.50. That means alternative implementations need implement all the 50 versions api...that sounds pain... Yes, it's pain, but it's no different than someone who is following the Amazon EC2 API, which cut

Re: [openstack-dev] stackforge projects are not second class citizens

You may also find my explanation about the Big Tent helpful in this interview with Niki Acosta and Jeff Dickey: http://blogs.cisco.com/cloud/ospod-29-jay-pipes Best, -jay On 06/16/2015 06:09 AM, Flavio Percoco wrote: On 16/06/15 04:39 -0400, gordon chung wrote: i won't speak to whether this

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

2015-06-16 18:57 GMT+08:00 Sean Dague : > On 06/15/2015 03:45 PM, Kevin L. Mitchell wrote: > > On Mon, 2015-06-15 at 13:07 -0400, Jay Pipes wrote: > >> The original spec said that the HTTP header should contain the name of > >> the service type returned by the Keystone service catalog (which is al

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

On 06/15/2015 03:45 PM, Kevin L. Mitchell wrote: > On Mon, 2015-06-15 at 13:07 -0400, Jay Pipes wrote: >> The original spec said that the HTTP header should contain the name of >> the service type returned by the Keystone service catalog (which is also >> the official name of the REST API). I don

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Thomas On 15/06/15 19:48, Thomas Goirand wrote: [...] > During our discussions at the Summit, you seemed to be > enthusiastic about pushing our packaging to Stackforge. Then others > told me to "push it to the /openstack namespace" to make it "mo

Re: [openstack-dev] stackforge projects are not second class citizens

On 16/06/15 04:39 -0400, gordon chung wrote: i won't speak to whether this confirms/refutes the usefulness of the big tent. that said, probably as a by-product of being in non-stop meetings with sales/ marketing/managers for last few days, i think there needs to be better definitions (or better p

[openstack-dev] [Murano] Cloud Foundry Service Broker Api in Murano

Hi all, I've started a work on bp: https://blueprints.launchpad.net/murano/+spec/cloudfoundry-api-support I plan to publish a spec in a day or two. If anyone interesting to cooperate please drop me a message here or in IRC: Nikolay_St Nikolay Starodubtsev Software Engineer Mirantis Inc. Skyp

[openstack-dev] [Ceilometer][Gnocchi] question on integration with time-series databases

Hi, Originally, I posted this question on the review [0] that adds InfluxDB support to Gnocchi but Julien felt that it wasn't relevant in the scope of the review. Still I think that it deserves some discussion... The current implementation of the InfluxDB driver for Gnocchi doesn't follow the rec

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

Thomas Goirand wrote: > On 06/10/2015 03:46 PM, Thierry Carrez wrote: >> So we could do what you're asking (option B) for Kilo stable releases, >> but I think it's not really a viable option for stable/liberty onward. > > I fail to understand how version numbers are related to doing > synchronized

Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support

That's fine with me. - Graham On 16 Jun 2015 6:06 am, Doug Wiegley wrote: Hi all, We don’t have a rough draft API doc yet, so I’m suggesting that we postpone tomorrow morning’s meeting until next week. Does anyone have any other agenda items, or want the meeting tomorrow? Thanks, doug > On

Re: [openstack-dev] [all][release] summit session summary: Release Versioning for Server Applications

Agree with Thierry, IMO it sounds more consistent On Tue, Jun 16, 2015 at 12:45 PM, Thierry Carrez wrote: > Doug Hellmann wrote: > > [...] > > I put together a little script [1] to try to count the previous > > releases for projects, to use that as the basis for their first > > SemVer-based vers

Re: [openstack-dev] [all][release] summit session summary: Release Versioning for Server Applications

Hi Doug, I suggest to use some version for neutron-*aas plugins, probably, 1.0.0 just to have one pattern for all components. If we will not use numbers for the first releases (or release candidates) it will be hard to understand what the version it is. What do you think about it? Thank you! On

Re: [openstack-dev] [puppet] [zaqar] Adding puppet-zaqar Module to Puppet Modules Project

On 15/06/15 12:48 -0700, Richard Raseley wrote: Here are the two changes I submitted for review to get puppet-zaqar added to the project: https://review.openstack.org/#/c/191942/ https://review.openstack.org/#/c/191946/ I am not sure these are 100% correct, but I followed the guide[0] as well

Re: [openstack-dev] [all][release] summit session summary: Release Versioning for Server Applications

Doug Hellmann wrote: > [...] > I put together a little script [1] to try to count the previous > releases for projects, to use that as the basis for their first > SemVer-based version number. I pasted the output into an etherpad > [2] and started making notes about proposed release numbers at the >

Re: [openstack-dev] [all][release] summit session summary: Release Versioning for Server Applications

I have a question regarding proposed release versions - are we starting to count releases from zero? And 2015.1 (Kilo) missed in all projects in etherpad. So, it means if we're starting from 0.0.0 then the proposed versions are correct, but if we want to start from 1.0.0 (IMO it's better), we shoul

Re: [openstack-dev] [Horizon] [tests] [dsvm] Tests failed because of timeout during the images upload

On 16/06/15 11:20, Timur Nurlygayanov wrote: In this method integration tests try to upload image by the following link [4]: http://download.cirros-cloud.net/0.3.1/cirros-0.3.1-x86_64-uec.tar.gz Imho it would be better to host this somewhere internal in infra rather than getting it from the

[openstack-dev] [Security] Nominating Travis McPeak for Security CoreSec

I'd like to nominate Travis for a CoreSec position as part of the Security project. - CoreSec team members support the VMT with extended consultation on externally reported vulnerabilities. Travis has been an active member of the Security project for a couple of years he's a part of the bandit

[openstack-dev] [Horizon] [tests] [dsvm] Tests failed because of timeout during the images upload

Hi team, I investigated the latest failed Horizon integration dsvm jobs [1] and found that many of them failed because of timeouts during the upload of image (in function 'create_image' [2]), on step '_wait_till_spinner_disappears' [3], where we wait while 'div.*modal-backdrop*' will disappear. In

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

Hi, >> Actually that makes an alternative implementation more valuable. Without >> microversions those alternative implementations would have to wait a long >> time to implement fixes to the API, but now can implement and publish >> the fix as soon as the microversion lands. This means that altern

Re: [openstack-dev] [all][release] summit session summary: Release Versioning for Server Applications

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/16/2015 09:44 AM, Thierry Carrez wrote: > Doug Hellmann wrote: >> [...] I still need to chat with Kyle about some of the neutron >> spin-out projects, since their repositories have the old neutron >> tags but I don't think it's appropriate to u

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/15/2015 11:24 PM, Thomas Goirand wrote: > On 06/15/2015 05:19 PM, Ian Cordasco wrote: >> On 6/15/15, 09:24, "Thomas Goirand" wrote: >> >>> On 06/08/2015 01:55 PM, Kuvaja, Erno wrote: One thing I like about plan D is that it would give al

Re: [openstack-dev] stackforge projects are not second class citizens

i won't speak to whether this confirms/refutes the usefulness of the big tent. that said, probably as a by-product of being in non-stop meetings with sales/marketing/managers for last few days, i think there needs to be better definitions (or better publicised definitions) of what the goals of

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

2015-06-16 5:24 GMT+08:00 Clint Byrum : > Excerpts from Sean Dague's message of 2015-06-15 14:00:43 -0700: > > On 06/15/2015 04:50 PM, Jim Rollenhagen wrote: > > > On Mon, Jun 15, 2015 at 01:07:39PM -0400, Jay Pipes wrote: > > >> It has come to my attention in [1] that the microversion spec for >

Re: [openstack-dev] [Openstack-operators] [ops][tags][packaging] ops:packaging tag - a little common sense, please

Thanks Jay for this. I basically agree with all you wrote. On 06/10/2015 07:51 PM, Jay Pipes wrote: > I don't believe the Ops Tags team should be curating the packaging tags > -- the packaging community should do that, and do that under the main > openstack/governance repository. > > Packagers,

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

2015-06-16 2:07 GMT+09:00 Jay Pipes : > It has come to my attention in [1] that the microversion spec for Nova [2] > and Ironic [3] have used the project name -- i.e. Nova and Ironic -- instead > of the name of the API -- i.e. "OpenStack Compute" and "OpenStack Bare > Metal" -- in the HTTP header t

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

2015-06-16 5:58 GMT+08:00 Ed Leafe : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 06/15/2015 04:30 PM, Michael Davies wrote: > > > On Tue, Jun 16, 2015 at 5:15 AM, Kevin L. Mitchell > > > > wrote: > > > > Given the disagreement evinced by the res

Re: [openstack-dev] [OpenStack-Infra] Nominating Joshua Hesketh for infra-root

Le 11/06/2015 18:54, James E. Blair a écrit : > The Infrastructure program has a unique three-tier team structure: > contributors (that's all of us!), core members (people with +2 ability > on infra projects in Gerrit) and root members (people with > administrative access). Read all about it here:

[openstack-dev] Cross-Project meeting, Tue Jun 16th, 21:00 UTC

Dear PTLs, cross-project liaisons and anyone else interested, We'll have a cross-project meeting today at 21:00 UTC, with the following agenda: * Horizontal teams announcements * Server versioning changes (dhellmann) * Clarification on the return code when a server has a hard coded length limit [

Re: [openstack-dev] [Magnum] Add periodic task threading for conductor server

Hi, folks. At the last summit, we decided to support pluggable conductor for multi backend [1]. So, if we choose #3, new service (instance of periodic task) also should support plugin. I think this will be a little complicated to implement a plugin. [1]: https://etherpad.openstack.org/p/liberty-w

Re: [openstack-dev] [all][release] summit session summary: Release Versioning for Server Applications

Doug Hellmann wrote: > [...] > I still need to chat with Kyle about some of the neutron spin-out > projects, since their repositories have the old neutron tags but I don't > think it's appropriate to use the same version number as neutron for > newer projects. > [...] > neutron 8.0.0 > neutron-fwaa

Re: [openstack-dev] [javascript] [horizon] [merlin] [refstack] Javascript Linting

So my view here is that I don’t particularly mind which plugin/ set of plugins Horizon uses, but the biggest deterrent is the workload. We’re already cleaning everything up quite productively, so I’m reluctant to swap. That said, the cleanup from JSCS/ JSHint should be largely relevant to ESLint

Re: [openstack-dev] [Ironic] Adopting ironic-lib in Ironic

On 06/16/2015 08:58 AM, Ramakrishnan G wrote: Hi All, Some time back we created a new repository[1] to move all the reusable code components of Ironic to a separate library. The branched out code has changed and there has been a review out to sync it [2]. But unfortunately, it has got stale a

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

On 06/15/2015 10:31 PM, Jay Pipes wrote: On 06/15/2015 02:09 PM, Dmitry Tantsur wrote: 2015-06-15 19:50 GMT+02:00 Clint Byrum mailto:cl...@fewbar.com>>: Excerpts from Jay Pipes's message of 2015-06-15 10:07:39 -0700: > It has come to my attention in [1] that the microversion spec fo

[openstack-dev] [Ironic] Adopting ironic-lib in Ironic

Hi All, Some time back we created a new repository[1] to move all the reusable code components of Ironic to a separate library. The branched out code has changed and there has been a review out to sync it [2]. But unfortunately, it has got stale again as some more changes have gone in to the bra

<    1   2