Re: [openstack-dev] [Openstack-i18n] [stable][i18n] What is the backport policy on i18n changes?

On 2016-02-18 01:16, Matt Riedemann wrote: > I don't think we have an official policy for stable backports with > respect to translatable string changes. > > I'm looking at a release request for ironic-inspector on stable/liberty > [1] and one of the changes in that has translatable string

[openstack-dev] Installing devstack with multi-region setting fails

2016-01-29 03:26:29.317 | + source /home/stack/devstack/userrc_early 2016-01-29 03:26:29.317 | ++ export OS_IDENTITY_API_VERSION=3 2016-01-29 03:26:29.317 | ++ OS_IDENTITY_API_VERSION=3 2016-01-29 03:26:29.318 | ++ export OS_AUTH_URL=http://192.168.56.101:35357 2016-01-29 03:26:29.318 | ++

Re: [openstack-dev] Questions regarding image "location" and glanceclient behaviour ...

But this procedure will force me to download all images in advance, which I can not do. I NEED the previous behavior, where Glance download the images by itself, on demand. How to do this with V2 ? On 18 February 2016 at 01:47, Fei Long Wang wrote: > Glance v2 doesn't

Re: [openstack-dev] Questions regarding image "location" and glanceclient behaviour ...

Glance v2 doesn't support 'location' anymore, now there are multi locations for image in V2. You can use 'glance location-add' after create the the image by 'glance image-create --file xxx' On 18/02/16 15:51, Martinx - ジェームズ wrote: > Hey guys, any news about this? > > I want to use Glance v2 but,

Re: [openstack-dev] [neutron] [ovs] How to update flows inbr-tun proactively

Hi, JingTing Normally , when the vm is migrated to destination compute node, the rarp will be send by qemu, and the flow tables of other nodes will be caused to be updated by rarp. This is done immediately after the vm is migrated to destination node, then rarps will be received by other

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

On Wed, Feb 17, 2016 at 06:58:18PM -0500, Sean Dague wrote: > On 02/17/2016 05:05 PM, Doug Hellmann wrote: > > Excerpts from Tony Breeds's message of 2016-02-18 08:04:00 +1100: > > >> I think we're in a tough spot. > >> > >> My $0.02 is that we have to cap at <0.18.0 however > >> > >> We're

Re: [openstack-dev] [ironic] Midcycle summary part 3/6

On Wed, Feb 17, 2016 at 12:14:29PM -0800, Jim Rollenhagen wrote: > Hi all, > > As our midcycle is virtual and split into 6 "sessions" for the sake of > timezones, we'll be sending a brief summary of each session so that > folks can catch up before the next one. All of this info should be on > the

[openstack-dev] [ironic] Midcycle summary part 4/6

Hi all, As our midcycle is virtual and split into 6 "sessions" for the sake of timezones, we'll be sending a brief summary of each session so that folks can catch up before the next one. All of this info should be on the etherpad as well. Session 4/6 was February 18, -0400 UTC. * Did a nova

Re: [openstack-dev] [OpenStackClient] New core team members

Congrats Richard and Tang! Thanks for all the contribution. Welcome to the team! -Lin On Wed, Feb 17, 2016 at 9:50 AM, Steve Martinelli wrote: > Congrats to both Richard Theis and Tang Chen -- very well deserved!!! > Thank you for guarding the gate! > > stevemar > >

Re: [openstack-dev] [neutron] [ovs] How to update flows inbr-tun proactively

Hi Maxiao: Thanks for your reply. This flow indeed been updated, when ovs receive any packets sent from migrated vm. The flow in table10(br-tun) is used to learn the mac address, and put the learned flow into table20. It just takes longer to complete. And is there any way to update the flow

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

On Wed, Feb 17, 2016 at 6:58 PM Sean Dague wrote: > > Question. Are we only tripping this up in unit tests because the tests > are doing things we'd never really do in real life? > I think that some of the issues have been real. Keystone had issues with 0.18.0 because it dropped

Re: [openstack-dev] Questions regarding image "location" and glanceclient behaviour ...

Hey guys, any news about this? I want to use Glance v2 but, without --location that points to a URL and, for me, without it, it is impossible to use it (v2). So, any plans to bring back --location, I want to use v2 like this: -- glance image-create --location

[openstack-dev] [app-catalog] IRC Meeting Thursday February 18th at 17:00UTC

Join us Thursday for our weekly meeting, scheduled for February 18th at 17:00UTC in #openstack-meeting-3 The agenda can be found here, and please add to if you want to get something on the agenda: https://wiki.openstack.org/wiki/Meetings/app-catalog Looking forward to seeing all interested

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

> -Original Message- > From: Clint Byrum [mailto:cl...@fewbar.com] > Sent: Thursday, February 18, 2016 1:53 AM > To: openstack-dev > Subject: Re: [openstack-dev] [nova] A prototype implementation towards the > "shared state scheduler" > > Excerpts from

Re: [openstack-dev] [OpenStackClient] New core team members

Hi guys, Thank you for your help and the precious opportunity for me. And congratulations Richard. :) Thanks. On 02/18/2016 12:31 AM, Dean Troyer wrote: I would like to announce the addition of Richard Theis and Tang Chen to the OpenStackClient core team. They both have been contributing

Re: [openstack-dev] [Congress] Nominating Masahito for core

+1 Congratulations! 2016-02-18 2:14 GMT+08:00 Masahito MUROI : > Thank you folks. I'm glad to be a part of this team and community, and > appreciate all supports from you. > > On 2016/02/17 12:10, Anusha Ramineni wrote: > >> +1 >> >> Best Regards, >> Anusha >> >>

Re: [openstack-dev] [all] [tc] unconstrained growth, why?

On Wed, 2016-02-17 at 13:25 -0500, Jay Pipes wrote: > On 02/17/2016 09:28 AM, Doug Hellmann wrote: > > Are people confused about what OpenStack is because they're looking > > for a single turn-key system from a vendor? Because they don't know > > what features they want/need? Or are we just doing

Re: [openstack-dev] [infra][neutron] publish and update Gerrit dashboard link automatically

On 2016-02-16 14:52:04 -0700 (-0700), Carl Baldwin wrote: [...] > No matter how it is done, there is the problem of where to host such a > page which can be automatically updated daily (or more often) by this > script. > > Any thoughts from infra on this? A neat idea, and sounds like an

Re: [openstack-dev] [ceilometer] [openstack-ansible] OpenStack-Ansible Ceilometer Configuration

Nate, The mongodb host can be anywhere, so long as it can reached by the ceilometer containers (on the same network). What branch are you working from? Master and Liberty should have no problems as far as I'm aware. There is a bug open in regards to authentication with swift, but everything

Re: [openstack-dev] [Rdo-list] [TripleO] Should we rename "RDO Manager" to "TripleO" ?

+1 for this. Having already navigated the depths of RDO, this eliminates a big point of confusion. On Wed, Feb 17, 2016 at 8:27 AM, David Moreau Simard wrote: > Greetings, > > (Note: cross-posted between rdo-list and openstack-dev to reach a > larger audience) > > Today,

[openstack-dev] [stable][i18n] What is the backport policy on i18n changes?

I don't think we have an official policy for stable backports with respect to translatable string changes. I'm looking at a release request for ironic-inspector on stable/liberty [1] and one of the changes in that has translatable string changes to user-facing error messages [2]. mrunge

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

On 02/17/2016 05:05 PM, Doug Hellmann wrote: > Excerpts from Tony Breeds's message of 2016-02-18 08:04:00 +1100: >> I think we're in a tough spot. >> >> My $0.02 is that we have to cap at <0.18.0 however >> >> We're (the openstack community) finding issues with eventlet which is good >>

[openstack-dev] [keystone] [horizon] [qa] keystone versionless endpoints and v3

I've been having some issues with keystone v3 and versionless endpoints and I'd like to know what's expected to work exactly in Liberty and beyond. I thought with v3 we used versionless endpoints but it seems to cause some breakages and some disagreement as to what should work. Here's what I've

Re: [openstack-dev] [heat] intrinsic function bugfixes and hot versioning

On 17/02/16 13:54, Steven Hardy wrote: Hi all, So, Zane and I have discussed $subject and it was suggested I take this to the list to reach consensus. Recently, I've run into a couple of small but inconvenient limitations in our intrinsic function implementations, specifically for str_replace

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

Excerpts from Morgan Fainberg's message of 2016-02-17 14:27:13 -0800: > On Wed, Feb 17, 2016 at 2:24 PM, Doug Hellmann > wrote: > > > Excerpts from Morgan Fainberg's message of 2016-02-17 10:44:50 -0800: > > > I am very much against adding extra data to paste-ini

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

I've finally compiled a spec for this topic https://review.openstack.org/#/c/281557/ On Wed, Feb 17, 2016 at 2:13 PM Alex Schultz wrote: > On Wed, Feb 17, 2016 at 10:23 AM, Bogdan Dobrelya > wrote: > >> > So we'll have tons of conditionals in

Re: [openstack-dev] [mitaka][hackathon] Mitaka Bug Smash Hackathon in Bay Area (March 7-9)

Just making sure that everybody saw this topic. Best regards, Boris Pavlovic On Thu, Feb 11, 2016 at 11:21 AM, Boris Pavlovic wrote: > Hi stackers, > > If you are in Bay Area and you would to work together with your friends > from community on fixing non trivial bugs

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On Wed, Feb 17, 2016 at 2:24 PM, Doug Hellmann wrote: > Excerpts from Morgan Fainberg's message of 2016-02-17 10:44:50 -0800: > > I am very much against adding extra data to paste-ini especially config > > data that is consumed by the applications. I generally understand

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

Excerpts from Morgan Fainberg's message of 2016-02-17 10:44:50 -0800: > I am very much against adding extra data to paste-ini especially config > data that is consumed by the applications. I generally understand why it > was implemented in the way it has. The oslo_config change that Doug linked >

[openstack-dev] [ceilometer] [openstack-ansible] OpenStack-Ansible Ceilometer Configuration

Hi everyone, I've been working on setting up a 10 node OpenStack installation with ceilometer using openstack-ansible, but the way I've configured it isn't working for me. I've tried following these instructions

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

Excerpts from Tony Breeds's message of 2016-02-18 08:04:00 +1100: > On Wed, Feb 17, 2016 at 12:44:11PM -0500, Doug Hellmann wrote: > > Excerpts from Henry Gessau's message of 2016-02-17 11:00:53 -0500: > > > Doug Hellmann wrote: > > > > Excerpts from Morgan Fainberg's

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

On Wed, Feb 17, 2016 at 10:23 AM, Bogdan Dobrelya wrote: > > So we'll have tons of conditionals in composition layer, right? Even if > > some puppet-openstack class have just one new parameter in new release, > > then we'll have to write a conditional and duplicate class

Re: [openstack-dev] [fuel] Merge freeze for CI switch to Mitaka

The merge freeze is now lifted, the transition to Mitaka has completed successfully. Fuel CI jobs for master are now based on Mitaka packages: https://ci.fuel-infra.org/job/master.fuel-library.pkgs.ubuntu.smoke_neutron/2188/

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

On Wed, Feb 17, 2016 at 12:44:11PM -0500, Doug Hellmann wrote: > Excerpts from Henry Gessau's message of 2016-02-17 11:00:53 -0500: > > Doug Hellmann wrote: > > > Excerpts from Morgan Fainberg's message of 2016-02-17 07:10:34 -0800: > > >> On Wed, Feb 17, 2016 at 5:55 AM,

[openstack-dev] [ironic] Midcycle summary part 3/6

Hi all, As our midcycle is virtual and split into 6 "sessions" for the sake of timezones, we'll be sending a brief summary of each session so that folks can catch up before the next one. All of this info should be on the etherpad as well. Session 2/6 was February 17, 1500-2000 UTC. * Discussed

Re: [openstack-dev] [fuel] Merge freeze for CI switch to Mitaka

Folks First of all, there is a critical bug which is not fixed. It may be floating because it is related to implicit resources ordering in puppet. But it does not mean that it is not a merge blocker. Secondly, I do not share your optimism about easiness of bugfixing of possible regressions

Re: [openstack-dev] [tacker][networking-sfc] Tacker VNFFG - SFC integration updates

On Wed, Feb 17, 2016 at 11:23 AM, Russell Bryant wrote: > On 02/16/2016 02:51 PM, Sridhar Ramaswamy wrote: > > Hi folks, > > > > Based on the recent discussions in [1] & [2] we are proposing to > > rearrange our tasks related to Tacker's VNFFG component integrating with > >

Re: [openstack-dev] [keystone][cinder] Projects acting as a domain at the top of the project hierarchy

So just recapping, http://review.openstack.org/#/c/274825 separates Cinder NestedQuota support into its own driver which is no longer the default. Once ^ lands, http://review.openstack.org/#/c/231289 should no longer be blocked in Tempest (because NestedQuotas support won't get flexed by default).

Re: [openstack-dev] [Neutron] Check queue broken on master

On 17 February 2016 at 11:22, Assaf Muller wrote: > On Wed, Feb 17, 2016 at 2:16 PM, Armando M. wrote: > > > > > > On 17 February 2016 at 11:12, Armando M. wrote: > >> > >> Hi folks, > >> > >> It looks like something slipped in and how

Re: [openstack-dev] [Neutron] Check queue broken on master

On Wed, Feb 17, 2016 at 2:16 PM, Armando M. wrote: > > > On 17 February 2016 at 11:12, Armando M. wrote: >> >> Hi folks, >> >> It looks like something slipped in and how we got persistent failures on >> functional/fullstack jobs [1]. Has anyone triaged? I

Re: [openstack-dev] [tacker][networking-sfc] Tacker VNFFG - SFC integration updates

On 02/16/2016 02:51 PM, Sridhar Ramaswamy wrote: > Hi folks, > > Based on the recent discussions in [1] & [2] we are proposing to > rearrange our tasks related to Tacker's VNFFG component integrating with > the lower level SFC APIs. We now plan to integrate with networking-sfc > APIs first. > >

Re: [openstack-dev] [Neutron] Check queue broken on master

On 17 February 2016 at 11:12, Armando M. wrote: > Hi folks, > > It looks like something slipped in and how we got persistent failures on > functional/fullstack jobs [1]. Has anyone triaged? I couldn't find anything > in [2]. > Looks like [1] fixed it. Thanks Assaf. Be safe

[openstack-dev] [Neutron] Check queue broken on master

Hi folks, It looks like something slipped in and how we got persistent failures on functional/fullstack jobs [1]. Has anyone triaged? I couldn't find anything in [2]. The effect for this: we can't merge anything until this gets resolved. Some might argue this is not necessarily a bad thing...

Re: [openstack-dev] [all] [tc] unconstrained growth, why?

On Wed, 17 Feb 2016, Doug Hellmann wrote: Excerpts from Jay Pipes's message of 2016-02-17 13:25:58 -0500: I think we are doing a bad job of communicating the product vs. kit nature of OpenStack. Yeah, I tend to think that's it, too. I'll concede to that and agree we can and should do

[openstack-dev] [oslo][doc][all] Removal of deprecate oslo.og log_format configuration option

The deprecated log_format option is being removed [1] This option can be found across many projects generally in sample configuration files [2]. These should be automatically removed if these files are auto generated via oslo-config-generator or in sphinx generated documentation. In other

Re: [openstack-dev] [Rdo-list] [TripleO] Should we rename "RDO Manager" to "TripleO" ?

+1 This has been very confusing and it would be nice to finally get that clearer. On Wed, Feb 17, 2016 at 7:49 PM, Haïkel wrote: > +1 it fuels the confusion that RDO Manager has downstream-only patches > which is not the case anymore. > > And I'll bite anyone who will

[openstack-dev] [heat] intrinsic function bugfixes and hot versioning

Hi all, So, Zane and I have discussed $subject and it was suggested I take this to the list to reach consensus. Recently, I've run into a couple of small but inconvenient limitations in our intrinsic function implementations, specifically for str_replace and repeat, both of which did not behave

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

Excerpts from Henry Gessau's message of 2016-02-17 13:00:03 -0500: > Doug Hellmann wrote: > > Excerpts from Henry Gessau's message of 2016-02-17 11:00:53 -0500: > >> Doug Hellmann wrote: > >>> Excerpts from Morgan Fainberg's message of 2016-02-17

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

I am very much against adding extra data to paste-ini especially config data that is consumed by the applications. I generally understand why it was implemented in the way it has. The oslo_config change that Doug linked will make this need mostly go away however. I would like to move us towards

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On Wed, Feb 17, 2016 at 9:41 AM Doug Hellmann wrote: > > The next release of oslo.config will have this. > https://review.openstack.org/#/c/278604/ http://stjent.pinnaclecart.com/images/products/preview/55008.jpg Michael

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

You should be able to test that the functionality of using the api, and seeing an appropriate plugin call gets called without a proprietary back end. Then its up to each plugin to test for their own compliance to the reference. Another approach for testing, maybe you could create the "dead

Re: [openstack-dev] [all] [tc] unconstrained growth, why?

Excerpts from Jay Pipes's message of 2016-02-17 13:25:58 -0500: > On 02/17/2016 09:28 AM, Doug Hellmann wrote: > > Excerpts from Chris Dent's message of 2016-02-17 11:30:29 +: > >> A reason _I_[1] think we need to limit things is because from the > >> outside OpenStack doesn't really look like

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

Excerpts from Anne Gentle's message of 2016-02-17 12:28:42 -0600: > On Wed, Feb 17, 2016 at 12:20 PM, Jay Pipes wrote: > > > On 02/17/2016 09:30 AM, Doug Hellmann wrote: > > > >> Excerpts from Mike Perez's message of 2016-02-17 03:21:51 -0800: > >> > >>> On 02/16/2016 11:30

[openstack-dev] [release][stable][oslo] oslo.service 0.9.1 release (liberty)

We are chuffed to announce the release of: oslo.service 0.9.1: oslo.service library This release is part of the liberty stable release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.service With package available at:

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On Wed, Feb 17, 2016 at 12:20 PM, Jay Pipes wrote: > On 02/17/2016 09:30 AM, Doug Hellmann wrote: > >> Excerpts from Mike Perez's message of 2016-02-17 03:21:51 -0800: >> >>> On 02/16/2016 11:30 AM, Doug Hellmann wrote: >>> So I think the project team is doing everything

Re: [openstack-dev] [all] [tc] unconstrained growth, why?

On 02/17/2016 09:28 AM, Doug Hellmann wrote: Excerpts from Chris Dent's message of 2016-02-17 11:30:29 +: A reason _I_[1] think we need to limit things is because from the outside OpenStack doesn't really look like anything that you can put a short description on. It's more murky than that

[openstack-dev] [release][keystone] keystonemiddleware 4.3.0 release (mitaka)

We are eager to announce the release of: keystonemiddleware 4.3.0: Middleware for OpenStack Identity This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/keystonemiddleware With package available at:

Re: [openstack-dev] [infra][neutron] publish and update Gerrit dashboard link automatically

Hi all, I automated a non-dashboard version of Rossella’s script. The tweaked script that gets run: https://review.openstack.org/#/c/281446/ Results, updated hourly (bookmarkable, will redirect to gerrit): http://104.236.79.17/ http://104.236.79.17/current http://104.236.79.17/current-min

Re: [openstack-dev] [Congress] Nominating Masahito for core

Thank you folks. I'm glad to be a part of this team and community, and appreciate all supports from you. On 2016/02/17 12:10, Anusha Ramineni wrote: +1 Best Regards, Anusha On 17 February 2016 at 00:59, Peter Balland > wrote: +1

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 02/17/2016 09:30 AM, Doug Hellmann wrote: Excerpts from Mike Perez's message of 2016-02-17 03:21:51 -0800: On 02/16/2016 11:30 AM, Doug Hellmann wrote: So I think the project team is doing everything we've asked. We changed our policies around new projects to emphasize the social aspects

[openstack-dev] [release][keystone] keystoneauth1 2.3.0 release (mitaka)

We are satisfied to announce the release of: keystoneauth1 2.3.0: Authentication Library for OpenStack Identity This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/keystoneauth With package available at:

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 02/17/2016 03:10 AM, Sean M. Collins wrote: > Thomas Goirand wrote: >> s/I dislike/is not free software/ [*] >> >> It's not a mater of taste. Having Poppy requiring a non-free component, >> even indirectly (ie: the Oracle JVM that CassandraDB needs), makes it >> non-free. > > Your definition

Re: [openstack-dev] [fuel] Move virtualbox scripts to a separate directory

Hi Fabrizio, The project-config patch is on the review now, waiting for a core-reviewers to merge the changes. On Wed, Feb 17, 2016 at 5:47 PM, Fabrizio Soppelsa wrote: > Vladimir, > a dedicated repo - good to hear. > Do you have a rough estimate for how long this

Re: [openstack-dev] [all] [tc] unconstrained growth, why?

To use the parallel of the Linux OS again, what Linux user doesn't use a vendor (distro) to deploy their machine? Sure, you can linux from scratch it, but who does but for education/entertainment purposes? Yes, its important to be able to do it without a vendor. The same way its important to

Re: [openstack-dev] [fuel] Merge freeze for CI switch to Mitaka

Vladimir, Obviously, there will be regressions in other scenarios. However, it's better to catch them now. We have not much time before FF, and it'd be better to merge such features as early as possible, and do not wait for merge hell a day before FF. The thing we need to know is that BVT is

[openstack-dev] [release][keystone] pycadf 2.1.0 release (mitaka)

We are satisfied to announce the release of: pycadf 2.1.0: CADF Library This release is part of the mitaka release series. With source available at: https://git.openstack.org/cgit/openstack/pycadf With package available at: https://pypi.python.org/pypi/pycadf Please report issues

Re: [openstack-dev] [fuel] Merge freeze for CI switch to Mitaka

BVT for master has been unblocked earlier today, and a custom ISO with Mitaka packages is passing BVT, so switching to Mitaka will not regress Fuel CI deployment tests. Lets not make this process more complicated than it has to be, non-BVT swarm regressions will have to be fixed either way, and it

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

Doug Hellmann wrote: > Excerpts from Henry Gessau's message of 2016-02-17 11:00:53 -0500: >> Doug Hellmann wrote: >>> Excerpts from Morgan Fainberg's message of 2016-02-17 07:10:34 -0800: On Wed, Feb 17, 2016 at 5:55 AM, Sean Dague

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

On Wed, Feb 17, 2016 at 9:29 AM Bogdan Dobrelya wrote: > > So we'll have tons of conditionals in composition layer, right? Even if > > some puppet-openstack class have just one new parameter in new release, > > then we'll have to write a conditional and duplicate class

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

Excerpts from Cheng, Yingxin's message of 2016-02-14 21:21:28 -0800: > Hi, > > I've uploaded a prototype https://review.openstack.org/#/c/280047/ to testify > its design goals in accuracy, performance, reliability and compatibility > improvements. It will also be an Austin Summit Session if

Re: [openstack-dev] [OpenStackClient] New core team members

Congrats to both Richard Theis and Tang Chen -- very well deserved!!! Thank you for guarding the gate! stevemar From: Dean Troyer To: OpenStack Development Mailing List Date: 2016/02/17 11:34 AM Subject:

[openstack-dev] [fuel][nailgun][volume-manager][fuel-agent] lvm metadata size value. why was it set to 64M?

Hi, Apparently, nailgun assumes that lvm metadata size is always set to 64M [1] It seems that it was defined here since the early beginning of nailgun as a project, therefore it's impossible to figure out for what purposes that was done as early commit messages are not so informative. According

Re: [openstack-dev] [keystone][cinder] Projects acting as a domain at the top of the project hierarchy

Hi all, I discussed the change with other cores in -keystone and, looking at the API change guidelines, it should be an allowed API change. I had a doubt whether the rule "Changing or removing a property in a resource representation." could make it a forbidden API change or not. However, since

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

Excerpts from Henry Gessau's message of 2016-02-17 11:00:53 -0500: > Doug Hellmann wrote: > > Excerpts from Morgan Fainberg's message of 2016-02-17 07:10:34 -0800: > >> On Wed, Feb 17, 2016 at 5:55 AM, Sean Dague wrote: > >> > >>> On 02/17/2016 08:42 AM,

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

On Wed, Feb 17, 2016 at 8:38 AM Aleksandr Didenko wrote: > > This requires the loss of all of the features in the newer version of > fuel since it relies on the older version of the serialized data from > nailgun. > > Yes. But isn't it how "stable" branches are supposed to

Re: [openstack-dev] [Rdo-list] [TripleO] Should we rename "RDO Manager" to "TripleO" ?

+1 it fuels the confusion that RDO Manager has downstream-only patches which is not the case anymore. And I'll bite anyone who will try to sneak downstream-only patches in RDO package of tripleO. Regards, H. __ OpenStack

Re: [openstack-dev] [fuel] Merge freeze for CI switch to Mitaka

Fuelers I have strong opinion against this merge freeze right now. We have critical bugs blocking bvt and we do not have enough info on mitaka readiness for other scenarios than bvt. 17 февр. 2016 г. 20:45 пользователь "Dmitry Borodaenko" < dborodae...@mirantis.com> написал: > Fuel core

[openstack-dev] [fuel] Merge freeze for CI switch to Mitaka

Fuel core reviewers, Fuel CI is being migrated to an ISO image with Mitaka packages, please don't merge any commits to any Fuel repositories without coordination with Aleksandra until further notice. This merge freeze is expected to last a few hours. -- Dmitry Borodaenko

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

Excerpts from Michael Krotscheck's message of 2016-02-17 17:26:57 +: > We (that is, the cores, contributors, and consumers that I've been > collaborating with over the past year on this) came to the consensus that > leaving the cors middleware as generic & configurable as possible was >

Re: [openstack-dev] [all] [tc] unconstrained growth, why?

Excerpts from Chris Dent's message of 2016-02-17 17:00:00 +: > On Wed, 17 Feb 2016, Doug Hellmann wrote: > > Excerpts from Chris Dent's message of 2016-02-17 11:30:29 +: > >> A reason _I_[1] think we need to limit things is because from the > >> outside OpenStack doesn't really look like

Re: [openstack-dev] [barbican] Nominating Fernando Diaz for Barbican Core

+1 On 2/16/16, 12:52 PM, "Ade Lee" wrote: >+1 > >On Mon, 2016-02-15 at 11:45 -0600, Douglas Mendizábal wrote: >> Hi All, >> >> I would like to nominate Fernando Diaz for the Barbican Core team. >> Fernando has been an enthusiastic contributor since joining the >> Barbican

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

We (that is, the cores, contributors, and consumers that I've been collaborating with over the past year on this) came to the consensus that leaving the cors middleware as generic & configurable as possible was preferable, and that an openstack-specific version that automatically initializes

[openstack-dev] [fuel] Supporting multiple Openstack versions

> So we'll have tons of conditionals in composition layer, right? Even if > some puppet-openstack class have just one new parameter in new release, > then we'll have to write a conditional and duplicate class declaration. Or > write complex parameters hash definitions/merges and use >

Re: [openstack-dev] [TripleO] Should we rename "RDO Manager" to "TripleO" ?

+1, I will also add for reference, that there is no other project in RDO that is renamed/rebranded. In fact, even the TripleO packages in RDO have the same naming as the upstream projects. On 02/17/2016 11:27 AM, David Moreau Simard wrote: > Greetings, > > (Note: cross-posted between rdo-list

Re: [openstack-dev] [all] [tc] unconstrained growth, why?

On Wed, 17 Feb 2016, Doug Hellmann wrote: Excerpts from Chris Dent's message of 2016-02-17 11:30:29 +: A reason _I_[1] think we need to limit things is because from the outside OpenStack doesn't really look like anything that you can put a short description on. It's more murky than that and

Re: [openstack-dev] [Rdo-list] [TripleO] Should we rename "RDO Manager" to "TripleO" ?

+1. There are already arguably too many names involved in OpenStack, let alone having multiple names for the same thing. :) Thanks, Kevin From: rdo-list-boun...@redhat.com [rdo-list-boun...@redhat.com] on behalf of David Moreau Simard [d...@redhat.com]

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

> This requires the loss of all of the features in the newer version of fuel since it relies on the older version of the serialized data from nailgun. Yes. But isn't it how "stable" branches are supposed to work? Introducing new features into "stable" branches will make them not so "stable",

[openstack-dev] [OpenStackClient] New core team members

I would like to announce the addition of Richard Theis and Tang Chen to the OpenStackClient core team. They both have been contributing quality reviews and code for some time now, particularly in the areas of SDK integration and new Network commands. Thank you Richard and Tang for your work and

[openstack-dev] [TripleO] Should we rename "RDO Manager" to "TripleO" ?

Greetings, (Note: cross-posted between rdo-list and openstack-dev to reach a larger audience) Today, because of the branding and the name "RDO Manager", you might think that it's something other than TripleO - either something entirely different or perhaps with downstream patches baked in. You

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

On Wed, 17 February 2016, Sylvain Bauza wrote (sorry, quoting off-context, but I feel it's a side point, not the main discussion) Le 17/02/2016 16:40, Cheng, Yingxin a écrit : IMHO, the authority to allocate resources is not limited by compute nodes, but also include network service, storage

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

Doug Hellmann wrote: > Excerpts from Morgan Fainberg's message of 2016-02-17 07:10:34 -0800: >> On Wed, Feb 17, 2016 at 5:55 AM, Sean Dague wrote: >> >>> On 02/17/2016 08:42 AM, Doug Hellmann wrote: Excerpts from Victor Stinner's message of 2016-02-17

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

(sorry, quoting off-context, but I feel it's a side point, not the main discussion) Le 17/02/2016 16:40, Cheng, Yingxin a écrit : IMHO, the authority to allocate resources is not limited by compute nodes, but also include network service, storage service or all other services which have

Re: [openstack-dev] [Watcher] Nominating Vincent Francoise to Watcher Core

+1 On Wed, Feb 17, 2016 at 3:07 PM, Jean-Émile DARTOIS < jean-emile.dart...@b-com.com> wrote: > +2 > > > Jean-Emile > DARTOIS > > {P} Software Engineer > Cloud Computing > {T} +33 (0) 2 56 35 8260 > {W} www.b-com.com > -- > *De :* Joe Cropper >

Re: [openstack-dev] [Nova][API] Does nova API allow the server_id parem as DB index?

On Wed, Feb 17, 2016 at 8:49 AM, Sean Dague wrote: > I did push a speculative patch which would address this by not exposing > the lookup by int id backdoor - https://review.openstack.org/#/c/281277/ > - the results were better than I expected. > > Andrey, is this going to

Re: [openstack-dev] [ceilometer]ceilometer-collector high CPU usage

Hi all, I did some more debugging with pdb, and seems to be the problem somehow connected to this eventlet issue: https://github.com/eventlet/eventlet/issues/30 I don't have a clue if it has any connections to the Rabbit heartbeat thing, but if I change the self.wait(0) to self.wait(0.1) in

Re: [openstack-dev] [Fuel][Puppet] New Rspec Noop Tests Matcher to Ensure Transitive Dependencies

On 17.02.2016 16:23, Vladimir Kuklin wrote: > Fuelers > > It seems that this change [0] into Fuel came unnoticed, but it may help > you in testing your puppet catalogues. > > I was refactoring our code pieces that actually wait for Load Balancer > to be ready to serve requests. I ended putting

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

On Wed, 17 February 2016, Sylvain Bauza wrote Le 17/02/2016 12:59, Chris Dent a écrit : On Wed, 17 Feb 2016, Cheng, Yingxin wrote: To better illustrate the differences between shared-state, resource- provider and legacy scheduler, I've drew 3 simplified pictures [1] in emphasizing the location

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

Excerpts from Morgan Fainberg's message of 2016-02-17 07:10:34 -0800: > On Wed, Feb 17, 2016 at 5:55 AM, Sean Dague wrote: > > > On 02/17/2016 08:42 AM, Doug Hellmann wrote: > > > Excerpts from Victor Stinner's message of 2016-02-17 14:14:18 +0100: > > >> Le 17/02/2016 13:43,

[openstack-dev] [Fuel][Puppet] New Rspec Noop Tests Matcher to Ensure Transitive Dependencies

Fuelers It seems that this change [0] into Fuel came unnoticed, but it may help you in testing your puppet catalogues. I was refactoring our code pieces that actually wait for Load Balancer to be ready to serve requests. I ended putting things into a special define called `wait_for_backend`.

[openstack-dev] [Ironic] Heads up: Third Party CI systems

Hi, This email is just a heads up to the people working on 3rd Party CI systems for Ironic. There's a patch in the review queue now [0] that may break you guys (the fix is simple). The patch is adding the ability to deploy nodes using the {pxe, agent}_ipmitool drivers with VMs. But, the problem

  1   2   >