[openstack-dev] [nova] Adding success message to succeed actions

Hi All, When querying instance actions using API: nova instance-action-list, nova will response with a table show in below:root@controller:~# nova instance-action-list fcbba82f-60a1-4785-84f2-88bcf2da7e7e++-+-+--

Re: [openstack-dev] [packaging] RPM Packaging for OpenStack IRC Meeting

On 12/06/15 13:45 -0400, Russell Bryant wrote: On 06/12/2015 01:31 PM, Dirk Müller wrote: If instead it seems the differences are minor enough that combining efforts is a win for everyone, then that's even better, but I don't see it as the required outcome here personally. Right. We've started

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

Hi, Thanks Adrian for the quick response. Please find my response inline. On Mon, Jun 15, 2015 at 3:09 PM, Adrian Otto wrote: > Madhuri, > > On Jun 14, 2015, at 10:30 PM, Madhuri Rai > wrote: > >Hi All, > > This is to bring the blueprint secure-kubernetes >

Re: [openstack-dev] Getting rid of suds, which is unmaintained, and which we want out of Debian

On 06/14/2015 03:46 PM, Thomas Goirand wrote: > On 06/11/2015 11:31 PM, Nikhil Manchanda wrote: >> Hi Thomas: >> >> I just checked and I don't see suds as a requirement for trove. >> I don't think it should be a requirement for the trove debian package, >> either. >> >> Thanks, >> Nikhil > > Hi, >

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

2015-06-12 7:52 GMT+08:00 Rochelle Grober : > Just want to add that for logging purposes, consistency, as Devananda > explains and Adrian and Sean agree, is really important. The number of > fields in a header response should be consistent. If the field is not > always used, a placeholder should

Re: [openstack-dev] [all][python3] use of six.iteritems()

On 12 June 2015 at 05:39, Dolph Mathews wrote: > > On Thu, Jun 11, 2015 at 12:34 AM, Robert Collins > wrote: >> >> On 11 June 2015 at 17:16, Robert Collins >> wrote: >> >> > This test conflates setup and execution. Better like my example, >> ... >> >> Just had it pointed out to me that I've let

Re: [openstack-dev] [neutron] Missing openvswitch filter rules

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/13/2015 04:38 PM, Jeff Feng wrote: > *I'm using OVSHybridIptablesFirewallDriver in > ovs_neutron_plugin.ini* / [securitygroup] firewall_driver = > neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver > > enable_security_group

Re: [openstack-dev] [Neutron] Proposing Rossella Sblendido for the Control Plane core team

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 No doubt +1. On 06/12/2015 09:44 PM, Kevin Benton wrote: > Hello! > > As the Lieutenant of the built-in control plane[1], I would like > Rossella Sblendido to be a member of the control plane core > reviewer team. > > Her review stats are in line

Re: [openstack-dev] [Neutron] Proposing YAMAMOTO Takashi for the Control Plane core team

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Not on the list either, but I want to +1 what Henry said. Yamamoto's reviews expand to the whole code base and are pretty always *very* usefu l. On 06/12/2015 11:39 PM, Henry Gessau wrote: > Although I am not on your list I would like to add my +1!

Re: [openstack-dev] Getting rid of suds, which is unmaintained, and which we want out of Debian

On Sun, Jun 14, 2015 at 10:46 PM, Thomas Goirand wrote: > On 06/11/2015 11:31 PM, Nikhil Manchanda wrote: > > Hi Thomas: > > > > I just checked and I don't see suds as a requirement for trove. > > I don't think it should be a requirement for the trove debian package, > > either. > > > > Thanks, >

Re: [openstack-dev] [Neutron] Proposing YAMAMOTO Takashi for the Control Plane core team

+1 On Mon, Jun 15, 2015 at 12:16 PM, Ihar Hrachyshka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Not on the list either, but I want to +1 what Henry said. Yamamoto's > reviews expand to the whole code base and are pretty always *very* usefu > l. > > On 06/12/2015 11:39 PM, Hen

Re: [openstack-dev] [Neutron] Proposing Rossella Sblendido for the Control Plane core team

+1 On Mon, Jun 15, 2015 at 12:14 PM, Ihar Hrachyshka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > No doubt +1. > > On 06/12/2015 09:44 PM, Kevin Benton wrote: > > Hello! > > > > As the Lieutenant of the built-in control plane[1], I would like > > Rossella Sblendido to be a memb

[openstack-dev] DB2 CI enablement on Keystone

Hi, Keystone guys, Could we have a talk about DB2 CI enablement on this Monday, 8PM central US time? which is Tuesday 9AM beijeing time? For your questions, here are my answers: 1) Is the team going to be responsive to requests unlike last time there was a problem? (yanfengxi) Yes, problems will

Re: [openstack-dev] [taskflow] Returning information from reverted flow

> -Original Message- > From: Joshua Harlow [mailto:[email protected]] > Sent: Friday, June 12, 2015 5:49 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [taskflow] Returning information from reverted > flow > > Dulko, Michal wrote: >

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

One of the stated problems the 'big tent' is supposed to solve is: 'The binary nature of the integrated release results in projects outside the integrated release failing to get the recognition they deserve. "Non-official" projects are second- or third-class citizens which can't get development re

Re: [openstack-dev] [oslo.vmware] Bump oslo.vmware to 1.0.0

Hi, The email mail below was a little cryptic so here is the general plan to move forwards: 1. Oslo.vmware:- rebase and update the patch https://review.openstack.org/#/c/114503. This will sort out the issues that we have with the exception hierarchy 2. Nova: hopefully manage to get reviews for htt

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

On 06/15/2015 06:20 AM, Joe Gordon wrote: One of the stated problems the 'big tent' is supposed to solve is: 'The binary nature of the integrated release results in projects outside the integrated release failing to get the recognition they deserve. "Non-official" projects are second- or third-c

[openstack-dev] [trove]Put all alternative configurations in default trove.conf

Hi all, I have created the blueprint about the default configuration file. I think we should add the essential configuration like "datastore_manager" in default trove.conf. The blueprint is here https://blueprints.launchpad.net/trove/+spec/default-configuration-items Any suggestion about t

Re: [openstack-dev] [trove]Put all alternative configurations in default trove.conf

Hello! I’ve never had to set datastore_manager in trove.conf and I can launch Trove just fine with either one of three setup methods, devstack, redstack, or following the detailed installation steps provided in the documentation. My suspicion is that the steps you are using to register your gue

Re: [openstack-dev] [all] DevStack switching from MySQL-python to PyMySQL

On 06/11/2015 06:29 AM, Sean Dague wrote: > On 06/09/2015 06:42 PM, Jeremy Stanley wrote: >> As discussed in the Liberty Design Summit "Moving apps to Python 3" >> cross-project workshop, the way forward in the near future is to >> switch to the pure-python PyMySQL library as a default. >> >> h

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

Joe, When looking at stackalytics [2] for each project, we don't see any > noticeably change in number of reviews, contributors, or number of commits > from before and after each project joined OpenStack. I can't agree on this. *) Rally is facing core-reviewers bottleneck currently. We have abo

Re: [openstack-dev] [oslo.vmware] Bump oslo.vmware to 1.0.0

+1 to the plan garyk, vipin et.al -- dims On Mon, Jun 15, 2015 at 7:00 AM, Gary Kotton wrote: > Hi, > The email mail below was a little cryptic so here is the general plan to > move forwards: > > 1. Oslo.vmware:- rebase and update the patch > https://review.openstack.org/#/c/114503. This will so

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

+1 Great job with Cinder. -Ryan - Original Message - From: "Steven Dake (stdake)" To: "OpenStack Development Mailing List (not for usage questions)" Sent: Sunday, June 14, 2015 1:48:48 PM Subject: [openstack-dev] [kolla] Proposal for new core-reviewer Harm Waites Hey folks, I am pro

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

On 06/15/2015 07:30 AM, Boris Pavlovic wrote: Joe, When looking at stackalytics [2] for each project, we don't see any noticeably change in number of reviews, contributors, or number of commits from before and after each project joined OpenStack. I can't agree on this. *) Rally is

Re: [openstack-dev] [puppet] [fuel] more collaboration request

> On 06/12/2015 07:58 AM, Bogdan Dobrelya wrote: > > I'm actually happy to hear from you, since we were discussing together > about that over the last 2 summits, without real plan between both groups. I believe as a first steep, the contribution policy to Fuel library should be clear and *prevent

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

On 15/06/15 19:20 +0900, Joe Gordon wrote: One of the stated problems the 'big tent' is supposed to solve is: 'The binary nature of the integrated release results in projects outside the integrated release failing to get the recognition they deserve. "Non-official" projects are second- or third-

Re: [openstack-dev] [trove]Put all alternative configurations in default trove.conf

I agree with Amrith – we should try to understand what the problem first. The datastore_manager config setting is passed down to the guest in the guest_info.conf file along with a few other config settings that the guest uses. I believe the intention is that trove_guestagent.conf is passed down

Re: [openstack-dev] [Neutron] VLAN-aware VMs meeting

Hi Kyle, > -Original Message- > From: Kyle Mestery [mailto:[email protected]] > Sent: June 15, 2015 04:26 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neutron] VLAN-aware VMs meeting > > On Fri, Jun 12, 2015 at 8:51 AM, Ildikó Váncsa

Re: [openstack-dev] [trove]Put all alternative configurationsin default trove.conf

Thanks for your reply @amrith. The datastore_manager refer to the manager you gonna use, mysql or others. If you don't set it, the default value is None. And if it's None, guest agent will fail to start up. That's why I think it's the necessary configuration we need to focus on. I don't know

[openstack-dev] [Cinder] Volume creation fails in Horizon

Hi All, I am trying to create a Volume for VMFS with a Volume Type (selected Volume Type selected has extra_specs).I am receiving an error Volume creation failed incase if the volume-type has extra-specs. Cinder doesn't support Volume creation if the volume-type has extra-specs? Is this

Re: [openstack-dev] [puppet] [fuel] more collaboration request

On 15.06.2015 13:59, Bogdan Dobrelya wrote: > > I believe as a first steep, the contribution policy to Fuel library Sorry, the step, it is not so steep. > should be clear and *prevent new forks of upstream modules* to be > accepted in future. This will prevent the technical dept and fork > main

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

Good day, fellow fuelers Fuel API is a powerful tool that allow for very fine tuning of deployment settings and parameters, and we all know that UI exposes only a fraction of the full range of attributes client can pass to Fuel installer. However, there are very little documentation that explains

Re: [openstack-dev] Getting rid of suds, which is unmaintained, and which we want out of Debian

On 06/15/2015 11:31 AM, Joe Gordon wrote: > Nova itself doesn't depend on suds anymore. A quick grep still shows references to suds (that's in Kilo, but the master branch shows similar results): etc/nova/logging_sample.conf:qualname = suds nova/tests/unit/test_hacking.py:" def fake_s

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

I think there is some desire to see more documentation around here as there are some odd interactions with parts of the data payload, and perhaps documenting these may improve some of them. I think the gaps in order of most used are: * node object create / update * environment networks ( the fact

Re: [openstack-dev] Online Migrations.

This weekend, I discussed the requested change at length with Mike. I think before moving forward, we need a better understanding of what is trying to be achieved. Request: Add the ability to verify migrations are completed prior to contract. As discussed here previously, I worked out a setup u

Re: [openstack-dev] DB2 CI enablement on Keystone

On Mon, Jun 15, 2015 at 5:00 AM, Feng Xi BJ Yan wrote: > Hi, Keystone guys, > > Could we have a talk about DB2 CI enablement on this Monday, 8PM central > US time? which is Tuesday 9AM beijeing time? > Works for me, I'll make a note to be in the channel at 8 PM central. Thanks for the update. >

Re: [openstack-dev] Getting rid of suds, which is unmaintained, and which we want out of Debian

Thomas, Is anyone willing to the work needed to get the existing Nova vmware driver scenarios with any alternate python library acceptable to Debian? If not, this discussion is moot. -- dims On Mon, Jun 15, 2015 at 9:16 AM, Thomas Goirand wrote: > On 06/15/2015 11:31 AM, Joe Gordon wrote: >> No

Re: [openstack-dev] Getting rid of suds, which is unmaintained, and which we want out of Debian

On Mon, Jun 15, 2015 at 4:16 PM, Thomas Goirand wrote: > On 06/15/2015 11:31 AM, Joe Gordon wrote: > > Nova itself doesn't depend on suds anymore. > > A quick grep still shows references to suds (that's in Kilo, but the > master branch shows similar results): > Your git repo is out of date. ht

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

Well, I suggest continuing https://review.openstack.org/#/c/179051/ It basically requires to update docstrings of handler functions according to [1]. This way the documentation is as close to the code as possible. With some work one could add automatic generation of docs out of JSONSchema probab

Re: [openstack-dev] [Neutron] VLAN-aware VMs meeting

On Mon, Jun 15, 2015 at 7:40 AM, Ildikó Váncsa wrote: > Hi Kyle, > > > -Original Message- > > From: Kyle Mestery [mailto:[email protected]] > > Sent: June 15, 2015 04:26 > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [Neutron] VLAN-

Re: [openstack-dev] [nova] Adding success message to succeed actions

On 15 June 2015 at 08:03, 郑振宇 wrote: > Hi All, > > When querying instance actions using API: nova instance-action-list, nova > will response with a table show in below: > root@controller:~# nova instance-action-list > fcbba82f-60a1-4785-84f2-88bcf2da7e7e > ++---

Re: [openstack-dev] [all] DevStack switching from MySQL-python to PyMySQL

On Mon, Jun 15, 2015 at 6:30 AM, Sean Dague wrote: > On 06/11/2015 06:29 AM, Sean Dague wrote: > > On 06/09/2015 06:42 PM, Jeremy Stanley wrote: > >> As discussed in the Liberty Design Summit "Moving apps to Python 3" > >> cross-project workshop, the way forward in the near future is to > >> swit

[openstack-dev] [release]oslo mox3 release 0.8.0 (liberty)

We are happy to announce the release of: mox3 0.8.0: Mock object framework for Python This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/mox3 For more details, please see the git log history below and: http://launchpad

Re: [openstack-dev] DB2 CI enablement on Keystone

It would be great to see the DB2 CI tests for Keystone. Can we see results of a pass first? Before enabling the CI? Thanks, Steve Martinelli OpenStack Keystone Core From: Feng Xi BJ Yan To: [email protected] Cc: Dan Moravec Date: 06/15/2015 06:01 AM Subject:

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

On 06/10/2015 11:27 AM, Dave Walker wrote: > On 10 June 2015 at 09:53, Thomas Goirand wrote: >> On 06/05/2015 02:46 PM, Thierry Carrez wrote: >>> So.. summarizing the various options again: >>> >>> Plan A >>> Just drop stable point releases. >>> (-) No more release notes >>> (-) Lack of reference

[openstack-dev] [release][openstackclient] python-openstackclient release 1.4.0 (liberty)

We are thrilled to announce the release of: python-openstackclient 1.4.0: OpenStack Command-line Client This release is part of the liberty release series. With source available at: https://git.openstack.org/cgit/openstack/python-openstackclient For more details, please see the git log his

Re: [openstack-dev] [trove]Put all alternative configurationsin default trove.conf

Hi, The value is sent down from Task Manager based on a value that is setup as part of the datastore. It is actually a bad thing if you set a value of the datastore_manager in the taskmanager.conf file on the Trove controller, and attempt to launch some other datastore. The way this works is

Re: [openstack-dev] [Neutron] VLAN-aware VMs meeting

Hi Kyle, Thanks for your support. Let's go for the meeting channel option then, so the final details for the tomorrow's meeting are: Time: Tuesday (06. 16.), 17:00UTC - 18:00UTC Location: #openstack-meeting-4 I will add a pointer to the agenda, when we have it! Best Regards, Ildikó > -Ori

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

On 06/10/2015 03:46 PM, Thierry Carrez wrote: > The main issue with B is that it doesn't work well once server component > versions start to diverge, which will be the case starting with Liberty. Review that policy then. > We already couldn't (with Swift using separate versioning), but we worked

[openstack-dev] [neutron[[vpnaas] Next meeting June 16th at 1600 UTC

Planning on weekly meetings for a while, since this are several things to discuss. See the agenda on the wiki page: https://wiki.openstack.org/wiki/Meetings/VPNaaS There are a bunch of questions to discuss. See you Tuesday! _

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

On 06/08/2015 01:55 PM, Kuvaja, Erno wrote: > One thing I like about plan D > is that it would give also indicator how much the stable branch has moved in > each individual project. The only indication you will get is how many patches it has. I fail to see how this is valuable information. No inf

Re: [openstack-dev] [Solum] Why do app names have to be unique?

Hi Adrian, The new app resource that is being implemented (https://review.openstack.org/#/c/185147/) does not enforce name uniqueness. This issue was discussed here sometime back. Earlier thread: http://lists.openstack.org/pipermail/openstack-dev/2015-March/058858.html The main argument for

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi All On 27/05/15 09:14, Thomas Goirand wrote: > tl;dr: - We'd like to push distribution packaging of OpenStack on > upstream gerrit with reviews. - The intention is to better share > the workload, and improve the overall QA for packaging *and* > u

Re: [openstack-dev] [Solum] Should logs be deleted when we delete an app?

Yes, the log deletion should be optional. The question is what should be the default behavior. Should the default be to delete the logs and provide a flag to keep them, or keep the logs by default and provide a override flag to delete them? Delete-by-default is consistent with the view that whe

Re: [openstack-dev] [Congress] summit events

Tim, > On Jun 9, 2015, at 10:04 AM, Tim Hinrichs wrote: > > Hi Joe, > > The telco slides are powerpoint, but are hosted on google drive ... Thanks very much for the OpEx slides (and corresponding design doc)! Is there a deck link for "Congress: Introduction, Status, and Future Plans" as well

Re: [openstack-dev] [Congress] summit events

Hi Joe, Here's the link to the Intro to Congress slide deck. https://docs.google.com/file/d/0ByDz-eYOtswScTlmamlhLXpmTXc/edit While I'm at it, here are the instructions for the Congress Hands On Lab. https://docs.google.com/document/u/1/d/1lXmMkUhiSZYK45POd5ungPjVR--Fs_wJHeQ6bXWwP44/pub All thes

Re: [openstack-dev] [Congress] summit events

> On Jun 15, 2015, at 11:06 AM, Tim Hinrichs wrote: > > Hi Joe, > > Here's the link to the Intro to Congress slide deck. Thank you! I should have re-checked the wiki. :) jd __ OpenStack Development Mailing List (not for

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

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 also indicator how much the stable branch has >>moved in >> each individual project. > >The only indication you will get is how many patches it has. I

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

Please see https://review.openstack.org/#/c/186617 - Nova Instance Users and review. We're working hard on trying to get heat -> nova -> instance -> barbican secret storage workflow working smoothly. Also related are: https://review.openstack.org/#/c/190404/ - Barbican ACL's and https://review

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

If your asking the cloud provider to go through the effort to install Magnum, its not that much extra effort to install Barbican at the same time. Making it a dependency isn't too bad then IMHO. Thanks, Kevin From: Adrian Otto [[email protected]] Sent: Su

Re: [openstack-dev] Online Migrations.

On 6/15/15 9:21 AM, Philip Schwartz wrote: This weekend, I discussed the requested change at length with Mike. I think before moving forward, we need a better understanding of what is trying to be achieved. Request: Add the ability to verify migrations are completed prior to contract. As

[openstack-dev] [Sahara] Difference between Sahara and CloudBrak

Hi Sahara Team, Just notice that the CloudBreak (https://github.com/sequenceiq/cloudbreak) also support running on top of OpenStack, can anyone show me some difference between Sahara and CloudBreak when both of them using OpenStack as Infrastructure Manager? -- Thanks, Jay Lau (Guangya Liu) ___

[openstack-dev] [Security] Nominating Michael McCune for Security CoreSec

I¹d like to propose Michael McCune for CoreSec membership. I¹ve worked with Michael (elmiko) on numerous security tasks and bugs, and he has a great grasp on security concepts and is very active in the OpenStack security community. I think he would be a natural choice for CoreSec. smime.p7s Des

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

Joe Gordon wrote: > [...] > Below is a list of the first few few projects to join OpenStack after > the big tent, All of which have now been part of OpenStack for at least > two months.[1] > > * Mangum - Tue Mar 24 20:17:36 2015 > * Murano - Tue Mar 24 20:48:25 2015 > * Congress - Tue Mar 31 20:2

Re: [openstack-dev] [Sahara] Difference between Sahara and CloudBrak

Hi Jay, Cloudbreak is a Hadoop installation tool driven by Hortonworks. The main difference with Sahara is a point of control. In Hortonworks world you have Ambari and different planforms (AWS, OpenStack, etc.) to run Hadoop. Sahara point of view - you have OpenStack cluster and want to control ev

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

+1 Regards, Daneyon Hansen Software Engineer Email: [email protected] Phone: 303-718-0400 http://about.me/daneyon_hansen From: "Steven Dake (stdake)" mailto:[email protected]>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:[email protected]>> Da

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

+1 for me as well. Designate looks great On Jun 15, 2015 6:43 AM, "Ryan Hallisey" wrote: > +1 Great job with Cinder. > > -Ryan > > - Original Message - > From: "Steven Dake (stdake)" > To: "OpenStack Development Mailing List (not for usage questions)" < > [email protected]

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

+1 for non-Barbican support first, unfortunately Barbican is not very well adopted in existing installation. Madhuri, also please keep in mind we should come with solution which should work with Swarm and Mesos as well in further. — Egor From: Madhuri Rai mailto:[email protected]>> Reply

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

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 that a client passes to indicate a preferen

[openstack-dev] [Magnum] Make functional tests voting

Hello, I haven't seen any false positives in a few weeks from the functional tests, but I have seen a couple reviewers missing the -1 from the non-voting job when there has been a legitimate failures. I think now would be a good time to turn 'check-functional-dsvm-magnum' to voting. Thanks, T

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

On 06/15/2015 07:07 PM, Jay Pipes wrote: 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 that

Re: [openstack-dev] [Magnum] Make functional tests voting

+1 from me Tom. On Mon, Jun 15, 2015 at 1:15 PM, Tom Cammann wrote: > Hello, > > I haven't seen any false positives in a few weeks from the functional > tests, but I have seen a couple reviewers missing the -1 from the non-voting > job > when there has been a legitimate failures. > > I think now

Re: [openstack-dev] [Networking] Support for multiple gateways in neutron/nova-net subnets for provider networks

Hi Assaf, Kevin, I know we talked about this on IRC, but just want to close this question on the thread, for rest of the community. Yes, Assaf is correct. Either via DHCP or Config Drive, we will make sure that different VMs/baremetal nodes get different gateway addresses. On Fri, Jun 12, 201

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

On 06/15/2015 01:16 PM, Dmitry Tantsur wrote: On 06/15/2015 07:07 PM, Jay Pipes wrote: 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 "O

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

On 06/15/2015 01:07 PM, Jay Pipes wrote: > 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 heade

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

On Sun, Jun 14, 2015 at 05:48:48PM +, Steven Dake (stdake) wrote: I am proposing Harm Waites for the Kolla core team. +1! __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ.

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

Madhuri, On Jun 15, 2015, at 12:47 AM, Madhuri Rai mailto:[email protected]>> wrote: Hi, Thanks Adrian for the quick response. Please find my response inline. On Mon, Jun 15, 2015 at 3:09 PM, Adrian Otto mailto:[email protected]>> wrote: Madhuri, On Jun 14, 2015, at 10:30 PM, M

Re: [openstack-dev] [Magnum] Make functional tests voting

Tom, Yes, let’s make it voting now. I went through the full review queue over the weekend, and I did find a few examples of functional tests timing out after 2 hours. It did not look to me like they actually ran, suggesting a malfunction in the setup of the test nodes. There we only one or two

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

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 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 M

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

My main issue with having the user generate the keys/certs for the kube nodes is that the keys have to be insecurely moved onto the kube nodes. Barbican can talk to heat but heat must still copy them across to the nodes, exposing the keys on the wire. Perhaps there are ways of moving secrets cor

Re: [openstack-dev] [Magnum] Make functional tests voting

Review up for making it voting: https://review.openstack.org/#/c/191921/ It would probably be a good plan to run the functional tests on the python-magnumclient, although I'm not too sure how to set that up. Tom On 15/06/15 18:47, Adrian Otto wrote: Tom, Yes, let’s make it voting now. I wen

Re: [openstack-dev] [puppet] OpenStack Puppet configuration for HA deployment

Cristina Aiftimiei wrote: The puppetlabs-openstack clearly states: "" Limitations * High availability and SSL-enabled endpoints are not provided by this module. """ As Matt touched on, you really should be building your own 'composition layer' for deploying producti

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

2015-06-15 19:50 GMT+02:00 Clint Byrum : > 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 for Nova > > [2] and Ironic [3] have used the project name -- i.e. Nova and Ironic -- > > instead of the name of the API -- i

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

On Mon, 15 Jun 2015, Clint Byrum wrote: I'm a little bit worried that we don't have a guiding principle to point at somewhere. Perhaps the API WG can encode guidance either way ("We use project names", or "we use service types"). I think it's a good idea to encode the principle, whatever it is

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

Tom, > On Jun 15, 2015, at 10:59 AM, Tom Cammann wrote: > > My main issue with having the user generate the keys/certs for the kube nodes > is that the keys have to be insecurely moved onto the kube nodes. Barbican can > talk to heat but heat must still copy them across to the nodes, exposing th

Re: [openstack-dev] Online Migrations.

>> 3. Build the controls into our process with a way of storing the >> current release cycle information to only allow contract’s to >> occur at a set major release and maintain the column in the model >> till it is ready to be removed major release + 1 since the >> migration was a

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

On 15 June 2015 at 13:07, Jay Pipes wrote: > 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 h

Re: [openstack-dev] [oslo.messaging][zeromq] Next step

On 6/12/15, 3:55 PM, "Clint Byrum" wrote: > >> > >I think you missed "it is not tested in the gate" as a root cause for >some of the ambiguity. Anecdotes and bug reports are super important for >knowing where to invest next, but a test suite would at least establish a >base line and prevent t

Re: [openstack-dev] [Magnum] Make functional tests voting

Bug ticket for python-magnumclient gate test: https://bugs.launchpad.net/python-magnumclient/+bug/1465375 On Jun 15, 2015, at 11:07 AM, Tom Cammann mailto:[email protected]>> wrote: Review up for making it voting: https://review.openstack.org/#/c/191921/ It would probably be a good plan to run

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

On 06/15/2015 04:55 PM, James Page wrote: > Hi All > > On 27/05/15 09:14, Thomas Goirand wrote: >> tl;dr: - We'd like to push distribution packaging of OpenStack on >> upstream gerrit with reviews. - The intention is to better share >> the workload, and improve the overall QA for packaging *and* >

[openstack-dev] [Ironic] weekly subteam status report

Hi, Following is the subteam report for Ironic. As usual, this is pulled directly from the Ironic whiteboard[0] and formatted. Bugs (dtantsur) (as of Mon, 15 Jun 15:00 UTC, diff since 1 Jun) Open: 159 (+9) 5 new (0), 51 in progress (+6), 0 critical, 12 high (+2) and 12 incomplete

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

On 06/15/2015 11:48 AM, Thomas Goirand wrote: > On 06/15/2015 04:55 PM, James Page wrote: >> The problem of managing delta and allowing a good level of >> distribution independence is still going to continue to exist and will >> be more difficult to manage due to the tighter coupling of development

Re: [openstack-dev] (re)centralizing library release management

Excerpts from Doug Hellmann's message of 2015-06-09 16:08:16 -0400: > Excerpts from Doug Hellmann's message of 2015-06-09 13:25:26 -0400: > > Until now we have encouraged project teams to prepare their own > > library releases as new versions of projects were needed. We've > > started running into

[openstack-dev] [Swift] slight restructuring of core

We've slightly changed the core group in Swift. Now we have swift-core and also the new swiftclient-core. The swiftclient-core is able to merge patches in python-swiftclient but not in swift. We've made this change so that we can more easily add people who have a dedicated focus on the client C

Re: [openstack-dev] Nominating Serge van Ginderachter to the os-ansible-deployment core team

+1 from me. On May 28, 2015, at 7:01 PM, Kevin Carter wrote: > Hello, > > I would like to nominate Serge (svg on IRC) for the > os-ansible-deployment-core team. Serge has been involved with the greater > Ansible community for some time and has been working with the OSAD project > for the last

Re: [openstack-dev] Online Migrations.

On 6/15/15 2:21 PM, Dan Smith wrote: Tying this to the releases is less desirable from my perspective. It means that landing a thing requires more than six months of developer and reviewer context. We have that right now, and we get along, but it's much harder to plan, execute, and cleanup t

[openstack-dev] [Infra] Meeting Tuesday June 16th at 19:00 UTC

Hi everyone, The OpenStack Infrastructure (Infra) team is having our next weekly meeting on Tuesday June 16th, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is welcome to to add agenda items) Everyone intereste

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

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't understand why the spec was > changed retroactivel

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

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 as I could. Any feedback would be appreciated.

Re: [openstack-dev] [cinder] Will CI failures recently cause the corresponding driver removed from the L?

On 09:26 Jun 12, liuxinguo wrote: > Hi, > Our CI can not connect to port 29418 of review.openstack.org recently, > possibly because the GFW filtered the access. Now we are processing this > problem as soon as we found it. > According to the decision of Cinder Meeting 2015-06-10: > "June 15th propos

  1   2   >