Re: [openstack-dev] [Ironic] When to bump the microversion?

2015-06-04 23:27 GMT+08:00 Lucas Alvares Gomes : > Hi Ruby, > > Thanks for starting this thread, just like you I've been always > confused about when and when not bump the microversioning of the API. > > > Backwards compatible API adds with no user signaling is a fallacy > > because it assumes the

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

On 05/29/2015 07:14 PM, Haïkel wrote: > 2015-05-29 15:41 GMT+02:00 Thierry Carrez : >> Hi everyone, >> >> TL;DR: >> - We propose to stop tagging coordinated point releases (like 2015.1.1) >> - We continue maintaining stable branches as a trusted source of stable >> updates for all projects though >

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

On 05/29/2015 09:23 PM, Ian Cordasco wrote: > Could you explain this as well? Do you mean fragmentation between what > distros are offering? In other words, Ubuntu is packaging Kilo @ SHA1 and > RHEL is at SHA2. I'm not entirely certain that's a bad thing. That seems > to give the packagers more fr

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

On 05/29/2015 09:36 PM, Dave Walker wrote: > Responses inline. > > On 29 May 2015 6:15 pm, "Haïkel" > wrote: >> >> 2015-05-29 15:41 GMT+02:00 Thierry Carrez >: >> > Hi everyone, >> > >> > TL;DR: >> > - We propose to stop tagging coo

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

On 06/01/2015 10:40 AM, Ihar Hrachyshka wrote: > No time synchronization between projects, no freeze dates, nothing, just > SemVer compatible version bumps e.g. once per two weeks or month. > Would it fix your problem? How do you check if project X in version n works with project Y in version m, u

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

On 06/01/2015 05:32 PM, Alan Pevec wrote: >> *Plan C* would be to just let projects tag stable point releases from >> time to time. That would solve all the original stated problems. And >> that would solve objections 2 and 3, which I think are the most valid ones. > > and *Plan D* would be to sta

Re: [openstack-dev] [neutron] Regarding Flow Classifier proposals for Liberty!

Hi Vikram, Agree with what you stated. Additional use case can be Tap as a Service to allow filtering of the mirrored packets. BR, Irena On Fri, Jun 5, 2015 at 11:47 AM, Vikram Choudhary < [email protected]> wrote: > Dear All, > > > > There are multiple proposal floating around flow c

Re: [openstack-dev] [Neutron] L3 agent rescheduling issue

On 5 June 2015 at 01:29, Itsuro ODA wrote: > Hi, > > > After trying to reproduce this, I'm suspecting that the issue is actually > > on the server side from failing to drain the agent report state queue in > > time. > > I have seen before. > I thought the senario at that time as follows. > * a lo

Re: [openstack-dev] [magnum] Proposing Kai Qiang Wu (Kennan) for Core for Magnum

Thanks All Magnum Guys, It is my honor to work with all of you to make Magnum Better. :) Thanks Stdake. Best Wishes, Kai Qiang Wu (吴开强 Kennan） IBM China System and Technology Lab, Beijing E-mail: [email protected]

Re: [openstack-dev] [Fuel] Call for 7.0 feature design and review

On June 2, 2015 2:57:29 PM EDT, Andrew Woodward wrote: >Updated > >Sean, I see that there is no spec linked in gerrit or the BP do we have >one? > > >On Tue, Jun 2, 2015 at 11:07 AM Sean M. Collins >wrote: > >> Can we update the vxlan bp to target it to 7.0? The series goal is >still >> set to 6.

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

On 6/7/15, 03:41, "Thomas Goirand" wrote: >On 05/29/2015 09:23 PM, Ian Cordasco wrote: >> Could you explain this as well? Do you mean fragmentation between what >> distros are offering? In other words, Ubuntu is packaging Kilo @ SHA1 >>and >> RHEL is at SHA2. I'm not entirely certain that's a bad

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

On 6/7/15, 03:47, "Thomas Goirand" wrote: >On 05/29/2015 09:36 PM, Dave Walker wrote: >> Responses inline. >> >> On 29 May 2015 6:15 pm, "Haïkel" > > wrote: >>> >>> 2015-05-29 15:41 GMT+02:00 Thierry Carrez > >: >>> > Hi everyone,

[openstack-dev] [neutron[dhcp][dnsmask]: duplicate entries in addn_hosts causing no IP allocation

Hi all, I'm running IceHouse (build using Fuel 5.1.1) on Ubuntu where dnsmask version 2.59-4. I have a very basic network layout where i have a private net which has 2 subnets 2fb7de9d-d6df-481f-acca-2f7860cffa60 | private-net | e79c3477-d3e5-471c-a728-8d881cf31bee 192.168.110.0/2

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

On Jun 5, 2015 4:36 AM, "Sean Dague" wrote: > > On 06/05/2015 01:28 AM, Adrian Otto wrote: > > > >> On Jun 4, 2015, at 11:03 AM, Devananda van der Veen > >> mailto:[email protected]>> wrote: > >> > >> > >> On Jun 4, 2015 12:00 AM, "Xu, Hejie" >> > wrote: > >> > >

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

2015-06-06 19:08 GMT+02:00 Ian Cordasco : > Not exactly. PBR/OpenStack follow SemVer and 2015.1.0.38 isn't valid > SemVer (http://semver.org/) Right, so semver compatible versioning on stable/kilo would be 2015.1.N but PBR doesn't support that. > If we want to be pedantic about the version number

Re: [openstack-dev] [nova] [glance] How to deal with aborted image read?

On 6 June 2015 at 13:08, Ian Cordasco wrote: > > > On 6/5/15, 02:55, "Flavio Percoco" wrote: > >>On 04/06/15 11:46 -0600, Chris Friesen wrote: >>>On 06/04/2015 03:01 AM, Flavio Percoco wrote: On 03/06/15 16:46 -0600, Chris Friesen wrote: >We recently ran into an issue where nova couldn't

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

>> and *Plan D* would be to start doing automatic per-project >> micro-versions on each commit: e.g. 2015.1.N where N is increased on >> each commit. > > How do you gpg sign these tags? I hope the solution isn't to store a key > in infra without a passphrase. Plan D doesn't include git tags, 2015.

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

On 7 June 2015 at 05:08, Ian Cordasco wrote: > > > On 6/6/15, 02:03, "Alan Pevec" wrote: > >>2015-06-05 15:16 GMT+02:00 Jeremy Stanley : >>> On 2015-06-05 14:56:30 +0200 (+0200), Thierry Carrez wrote: >>> [...] I was wondering if we could switch to post-versioning on stable branches, an

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

> How do you check if project X in version n works with project Y in > version m, using this non-scheduled point release "free for all" model? That was an illusion of point releases, as Thierry said there wasn't significantly more testing and I don't remember any testing reports during stable free

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

On 8 June 2015 at 10:45, Robert Collins wrote: > >> You'll also note that according to PEP 440, (as Jeremy pointed out) .postN >> is meant for non-code changes. If we want to be pedantic about the version >> numbers generated by PBR (at the gate, in tox, etc.), it should be > version number>.devN

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

On 8 June 2015 at 10:14, Alan Pevec wrote: > 2015-06-06 19:08 GMT+02:00 Ian Cordasco : >> Not exactly. PBR/OpenStack follow SemVer and 2015.1.0.38 isn't valid >> SemVer (http://semver.org/) > > Right, so semver compatible versioning on stable/kilo would be 2015.1.N > but PBR doesn't support that.

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

On 6 June 2015 at 08:53, Joshua Harlow wrote: > Hopefully it's somewhat obvious to folks that altering the PBR version > schema (yet again), breaks *all the people* from using it in a reliable > manner, and if the goal of PBR is to bring reasonableness, well changing it > in a way that breaks thin

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

Robert Collins wrote: On 6 June 2015 at 08:53, Joshua Harlow wrote: Hopefully it's somewhat obvious to folks that altering the PBR version schema (yet again), breaks *all the people* from using it in a reliable manner, and if the goal of PBR is to bring reasonableness, well changing it in a way

Re: [openstack-dev] [global-requirements][pbr] tarball and git requirements no longer supported in requirements.txt

On 4 June 2015 at 21:06, Ihar Hrachyshka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 06/03/2015 11:08 PM, Robert Collins wrote: ... >> One question that this raises, and this is why I wrote the email: >> is there any need to support this at all:- can we say that we won't >> u

Re: [openstack-dev] [global-requirements][pbr] tarball and git requirements no longer supported in requirements.txt

On 5 June 2015 at 04:54, Kevin Benton wrote: > +1. I had setup a CI for a third-party plugin and the easiest thing to do to > make sure it was running tests with the latest copy of the corresponding > neutron branch was to put the git URL in requirements.txt. > > We wanted to always test the lates

Re: [openstack-dev] [global-requirements][pbr] tarball and git requirements no longer supported in requirements.txt

It wasn't using zuul at all. It's a super short bash script that just clones the 3rd party repo, checks out the patch, and then runs 'tox -epy27'. I misspoke in my previous email, because it was setup to use test-requirements.txt to pull in neutron. Did I understand your other email that implied t

Re: [openstack-dev] [kolla] gate failing sporadically

On 6/1/15, 7:38 AM, "Jeff Peeler" wrote: >On Sat, May 30, 2015 at 03:00:04AM +, Steven Dake (stdake) wrote: >>Hey Folks, >> >>I noticed the Kolla functional gate is failing sporadically. >> >>It seems that sometimes an image doesn¹t build. >> >>http://logs.openstack.org/75/186475/1/check/ch

Re: [openstack-dev] [global-requirements][pbr] tarball and git requirements no longer supported in requirements.txt

On 8 June 2015 at 11:16, Kevin Benton wrote: > It wasn't using zuul at all. It's a super short bash script that just clones > the 3rd party repo, checks out the patch, and then runs 'tox -epy27'. > > I misspoke in my previous email, because it was setup to use > test-requirements.txt to pull in ne

[openstack-dev] [Cinder] Need Cinder cores to approve the spec for volume migration improvement

Hi Cinder folks, Can any cores in cinder take a review of this patch https://review.openstack.org/#/c/186327/? I am have already received +1's from Jay, Patrick, Mitsuhiro and Avishay. If you have comments, please feedback to me. If not, can any of you approved this spec? Thank you so much. Bes

Re: [openstack-dev] [Neutron] L3 agent rescheduling issue

Salvatore, By 'fairness' I meant chances for state report greenthread to get the control. In DHCP case, each network processed by a separate greenthread, so the more greenthreads agent has, the less chances that report state greenthread will be able to report in time. Thanks, Eugene. On Sun, Jun

Re: [openstack-dev] [Neutron] L3 agent rescheduling issue

I understand now. So the issue is that the report_state greenthread is just blocking and yielding whenever it tries to actually send a message? On Sun, Jun 7, 2015 at 8:10 PM, Eugene Nikanorov wrote: > Salvatore, > > By 'fairness' I meant chances for state report greenthread to get the > control

Re: [openstack-dev] [Neutron] L3 agent rescheduling issue

No, I think greenthread itself don't do anything special, it's just when there are too many threads, state_report thread can't get the control for too long, since there is no prioritization of greenthreads. Eugene. On Sun, Jun 7, 2015 at 8:24 PM, Kevin Benton wrote: > I understand now. So the i

Re: [openstack-dev] Barbican : Retrieval of the secret in text/plain format generated from Barbican order resource

Hello Asha, The AES type key should require an application/octet-stream Accept header to retrieve the secret as it is a binary type. Please replace 'text/plain' with 'application/octet-stream' in your curl calls below. Thanks, John From: Asha Seshagiri mailto:[email protected]>> Date:

Re: [openstack-dev] Barbican : Retrieval of the secret in text/plain format generated from Barbican order resource

Thanks John for your response. I am aware that application/octet-stream works for the retrieval of secret . We are utilizing the key generated from Barbican in our AES encryption algorithm . Hence we wanted the response in text/plain format from Barbican since AES encryption algorithm would need t

Re: [openstack-dev] [Neutron] L3 agent rescheduling issue

Well a greenthread will only yield when it makes a blocking call like writing to a network socket, file, etc. So once the report_state greenthread starts executing, it won't yield until it makes a call like that. I looked through the report_state code for the DHCP agent and the only blocking call

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

On 06/04/2015 01:25 AM, Thomas Goirand wrote: On 06/03/2015 08:07 PM, Andreas Jaeger wrote: On 06/03/2015 03:57 PM, James Page wrote: [...] After some discussion with Thomas on IRC, I think this is more than one effort; The skills and motivation for developers reviewing proposed packaging chang

Re: [openstack-dev] [puppet] openstacklib::db::sync proposal

On 06/03/2015 02:32 PM, Martin Mágr wrote: > > On 06/02/2015 07:05 PM, Mathieu Gagné wrote: >> On 2015-06-02 12:41 PM, Yanis Guenane wrote: >>> The openstacklib::db::sync[2] is currently only a wrapper around an >>> exec >>> that does the actual db sync, this allow to make any modification to >>>