Re: [openstack-dev] [Ceilometer] Is that possible to implement new APIs for horizon to show the usage report and charts?

Thanks for your reply. 1.Actually, statistics is used by horizon now to render the tables and grouping by resource is needed. The number of http requests should be reduced to speed up the page loading. 2. /statistics can't do this. You know, horizon may need hundreds or thousands of value to rend

Re: [openstack-dev] [Ceilometer] Is that possible to implement new APIs for horizon to show the usage report and charts?

Thanks for your reply. 1.Actually, statistics is used by horizon now to render the tables and grouping by resource is needed. The number of http requests should be reduced to speed up the page loading. 2. /statistics can't do this. You know, horizon may need hundreds or thousands of value to rend

Re: [openstack-dev] Usage of mox through out the Openstack project.

On Wed, Jul 24 2013, Russell Bryant wrote: > A practical approach would probably be: > > 1) Prefer mock for new tests. > > 2) Use suggestion #2 above to mitigate the Python 3 concern. > > 3) Convert tests to mock over time, opportunistically, as tests are > being updated anyway. (Or if someone *r

Re: [openstack-dev] [Ceilometer] Is that possible to implement new APIs for horizon to show the usage report and charts?

On Thu, Jul 25 2013, Brooklyn Chen wrote: > 1.Actually, statistics is used by horizon now to render the tables and > grouping by resource is needed. The number of http requests should be > reduced to speed up the page loading. What kind of HTTP requests are you doing currently? > 2. /statistics c

Re: [openstack-dev] [Openstack-dev][nova] Disable per-user rate limiting by default

I'd like to turn it off by default, as already pointed in [1] I think the rate limiting should be managed by something else (for example load balancers) in front of the API. Regards -- Andrea Rosa [1] http://www.gossamer-threads.com/lists/openstack/operators/28599 From: Joe Gordon [mailto:joe

Re: [openstack-dev] [tripleo] removing sudoers.d rules from disk-image-builder

Hi On 24 July 2013 22:18, Derek Higgins wrote: > - setup passwordless sudo or > Doesn't sound like a super awesome option to me, it places an ugly > security problem on anyone wanting to set this up anywhere, imo. I don't think its any worse then the security implications of running di-b as

Re: [openstack-dev] [keystone] Extending policy checking to include target entities

I have responded to your post, as I dont think it solves the identified problem regards David On 24/07/2013 23:26, Tiwari, Arvind wrote: I have added my proposal @ https://etherpad.openstack.org/api_policy_on_target. Thanks, Arvind -Original Message- From: Henry Nash [mailto:hen...@

Re: [openstack-dev] [Stackalytics] 0.1 release

A suggestion: sort bugs number as int is much better than string, because '112' < '8' but actually 112 > 8 http://stackalytics.com/companies/unitedstack On Thu, Jul 25, 2013 at 9:31 AM, Alex Freedland wrote: > Roman, > > Thank you for your comment. I agree that is should not be the only way to

Re: [openstack-dev] [Neutron] Chalenges with highly available service VMs - port adn security group options.

Hi, I had to patch the security groups to add the following rule, otherwise broadcast is blocked: -m pkttype --pkt-type multicast -j RETURN Ex: In /opt/stack/quantum/quantum/agent/linux/iptables_firewall.py def _allow_multicats_rule(self, iptables_rules): iptables_rules += ['-m pktty

[openstack-dev] [savanna] Team meeting reminder July 25 18:00 UTC

Hi folks, We'll be have the Savanna team meeting today as usual in #openstack-meeting-alt channel. Agenda: https://wiki.openstack.org/wiki/Meetings/SavannaAgenda#Agenda_for_July.2C_25 http://www.timeanddate.com/worldclock/fixedtime.html?msg=Savanna+Meeting&iso=20130725T18 Sincerely yours, Ser

Re: [openstack-dev] [tripleo] removing sudoers.d rules from disk-image-builder

On 25/07/13 09:41, Chris Jones wrote: > Hi > > On 24 July 2013 22:18, Derek Higgins > wrote: >> - setup passwordless sudo or >> Doesn't sound like a super awesome option to me, it places an ugly >> security problem on anyone wanting to set this up anywhere, imo. >

Re: [openstack-dev] Usage of mox through out the Openstack project.

On Jul 25, 2013, at 4:01 AM, Julien Danjou wrote: > On Wed, Jul 24 2013, Russell Bryant wrote: > >> A practical approach would probably be: >> >> 1) Prefer mock for new tests. >> >> 2) Use suggestion #2 above to mitigate the Python 3 concern. >> >> 3) Convert tests to mock over time, opportu

[openstack-dev] [qa] QA discussions moving to openstack-dev mailing list

Last week we decided on the QA meeting to deprecate the openstack-qa list and drive out conversations on openstack-dev instead, using the [qa] tag. We're still figuring out if there will be an alias for compatibility or not, but until then, please send your traffic over to openstack-dev. Than

[openstack-dev] [qa] Reminder - Weekly QA Meeting 17:00 UTC today (Thursday)

So far we have the following proposed agenda items: * Blueprints (sdague) - Current state of implementation * WebDav status codes in nova? Consistently using the 404 or 422 on actions. * Adding test cases with skip attribute vote? Exact rule (afazekas) * py26 compatibility (afazekas) * Consist

[openstack-dev] [nova] 422 status codes from API

Some new tempest tests have been showing up that push deeper into the Nova API, and popping out seem to be a lot of places where we are returning 422 status codes. 422 is WebDav reserved code, not in a proper HTTP spec (WebDAV; RFC 4918), and a lot of the other projects have purged it out of t

Re: [openstack-dev] Usage of mox through out the Openstack project.

On Thu, Jul 25 2013, Mark McClain wrote: > The Neutron project has been enforcing this approach for about a year now. > We're down to 8 files that still rely on Mox. Awesome, we'll have to bring Python 3 badges at the next summit for Neutron devs. ;) -- Julien Danjou /* Free Software hacker * f

Re: [openstack-dev] [nova] 422 status codes from API

Just as a data point, we considered these a *bug* in Cinder and fixed them as I recall. On Thu, Jul 25, 2013 at 8:29 AM, Sean Dague wrote: > Some new tempest tests have been showing up that push deeper into the Nova > API, and popping out seem to be a lot of places where we are returning 422 >

Re: [openstack-dev] [openstack-qa] [qa] A tempest test cann't pass gate-grenade-devstack-vm

On Thu, Jul 25, 2013 at 10:16:54AM +0930, Christopher Yeoh wrote: > On Wed, 24 Jul 2013 10:22:32 -0400 > Matthew Treinish wrote: > > On Wed, Jul 24, 2013 at 10:48:19PM +0930, Christopher Yeoh wrote: > > > On Wed, 24 Jul 2013 21:08:03 +0800 > > > Zhu Bo wrote: > > > Just to expand on this a bit, f

Re: [openstack-dev] [Heat] Multi region support for Heat

First of all sorry for the late reply. I needed some time to understand you vision and check a few things. On 07/24/2013 08:40 AM, Clint Byrum wrote: Excerpts from Adrian Otto's message of 2013-07-23 21:22:14 -0700: Clint, On Jul 23, 2013, at 10:03 AM, Clint Byrum wrote: Excerpts from St

Re: [openstack-dev] [savanna] scalable architecture

Hi Matt, thank you for your comments. First of all, I want to say that personally I like the approach with agents because of much more theoretical flexibility and scalability. I want to share several overall comments of using agents. We’ve already discussed such approach several times includi

[openstack-dev] [keystone] Does authorization not needed on “/auth/tokens” API??

Thanks David. Since we are discussing authorization and access control, I would like to gain little attention on the below bug which basically propose authorization check on identity:check_token, identity:validate_token and identity:revoke_token APIs https://bugs.launchpad.net/keystone/+bug/1

Re: [openstack-dev] [nova] 422 status codes from API

On 07/25/2013 10:29 AM, Sean Dague wrote: > Some new tempest tests have been showing up that push deeper into the > Nova API, and popping out seem to be a lot of places where we are > returning 422 status codes. > > 422 is WebDav reserved code, not in a proper HTTP spec (WebDAV; RFC > 4918), and a

Re: [openstack-dev] [savanna] scalable architecture

On Jul 23, 2013 12:34 PM, "Sergey Lukjanov" wrote: > > Hi evereyone, > > We’ve started working on upgrading Savanna architecture in version 0.3 to make it horizontally scalable. > > The most part of information is in the wiki page - https://wiki.openstack.org/wiki/Savanna/NextGenArchitecture. > >

Re: [openstack-dev] [Openstack-dev][nova] Disable per-user rate limiting by default

+1 to turning it off. Having something that doesn't really work on by default now we have a threaded API is just wrong From: Rosa, Andrea (HP Cloud Services) Sent: 25 July 2013 09:35 To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Openstack-dev][nova] Disable per-user rate

Re: [openstack-dev] [keystone] Does authorization not needed on “/auth/tokens” API??

Hi Arvind thanks for pointing me to this issue, which I was not aware of. I have posted my twopence worth to the bug. Basically I agree with you, that if you want audit of third parties revoking tokens, then you need the token of the subject to be revoked and the third party requesting it. r

[openstack-dev] [Netron] Allow OVS default veth MTU to be configured.

Neutron Core Reviewers, Could you please review and approve the following bug fix? https://review.openstack.org/#/c/27937/ Thanks, -Jun ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinf

Re: [openstack-dev] [Heat] Multi region support for Heat

On 25/07/13 17:08, Bartosz Górski wrote: First of all sorry for the late reply. I needed some time to understand you vision and check a few things. On 07/24/2013 08:40 AM, Clint Byrum wrote: Excerpts from Adrian Otto's message of 2013-07-23 21:22:14 -0700: Clint, On Jul 23, 2013, at 10:03 AM,

Re: [openstack-dev] [Swift] question on Application class concurrency; paste.app_factory mechanism

On Wed, 24 Jul 2013 02:31:45 + "Luse, Paul E" wrote: > I was thinking that each connection would get its own instance thus it > would be sage to store connection-transient information there but I was > surprised by my quick test. Yeah, you have it tracked in __call__, typically hanging off c

Re: [openstack-dev] [keystone] Does authorization not needed on “/auth/tokens” API??

Thanks David for your comments. I will try to fix it as per my suggestion in bug. Arvind -Original Message- From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] Sent: Thursday, July 25, 2013 10:27 AM To: Tiwari, Arvind Cc: OpenStack Development Mailing List Subject: Re: [openstack-dev

Re: [openstack-dev] [Heat] Multi region support for Heat

On 07/25/2013 06:38 PM, Zane Bitter wrote: On 25/07/13 17:08, Bartosz Górski wrote: First of all sorry for the late reply. I needed some time to understand you vision and check a few things. On 07/24/2013 08:40 AM, Clint Byrum wrote: Excerpts from Adrian Otto's message of 2013-07-23 21:22:14 -

Re: [openstack-dev] Validating Flavor IDs

The data type is string. Vish On Jul 24, 2013, at 1:41 AM, "Karajgi, Rohit" wrote: > Hi, > > Referring to https://bugs.launchpad.net/nova/+bug/1202136, it seems that the > novaclient > validates the flavor ID to be either an integer or a UUID string. This check > does not exist in Nova, so c

Re: [openstack-dev] Discussing Amazon API compatibility [Nova][Swift]

On Jul 24, 2013, at 8:51 AM, Stefano Maffulli wrote: > Hello > > I have seen lots of discussions on blogs and twitter heating up around > Amazon API compatibility and OpenStack. This seems like a recurring > topic, often raised by pundits and recently joined by members of the > community. I thi

Re: [openstack-dev] [tripleo] removing sudoers.d rules from disk-image-builder

Hi On 25 July 2013 14:20, Derek Higgins wrote: > which only gives people an incorrect sense of security. > I agree with your analysis of the effects of the sudoers file and I think it makes a great argument for recommending people run the main command itself with sudo, rather than a blanket pas

Re: [openstack-dev] [keystone] Does authorization not needed on “/auth/tokens” API??

On 07/25/2013 01:03 PM, Tiwari, Arvind wrote: Thanks David for your comments. I will try to fix it as per my suggestion in bug. Arvind -Original Message- From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] Sent: Thursday, July 25, 2013 10:27 AM To: Tiwari, Arvind Cc: OpenStack Develo

[openstack-dev] Python overhead for rootwrap

Hi All, We have recently hit some performance issues with nova-network. It turns out the root cause of this was we do roughly 20 rootwrapped shell commands, many inside of global locks. (https://bugs.launchpad.net/oslo/+bug/1199433) It turns out starting python itself, has a fairly significant o

Re: [openstack-dev] [Openstack-dev][nova] Disable per-user rate limiting by default

+1 to turn it off -- dims On Thu, Jul 25, 2013 at 12:07 PM, Day, Phil wrote: > +1 to turning it off. Having something that doesn’t really work on by > default now we have a threaded API is just wrong > > > > From: Rosa, Andrea (HP Cloud Services) > Sent: 25 July 2013 09:35 > To: OpenStack Devel

Re: [openstack-dev] Python overhead for rootwrap

In my opinion: 1. Stop using rootwrap completely and get strong argument checking support into sudo (regex). 2. Some sort of long lived rootwrap process, either forked by the service that want's to shell out or a general purpose rootwrapd type thing. I prefer #1 because it's surprising that sudo

Re: [openstack-dev] Python overhead for rootwrap

On 07/25/2013 04:40 PM, Mike Wilson wrote: > In my opinion: > > 1. Stop using rootwrap completely and get strong argument checking > support into sudo (regex). > 2. Some sort of long lived rootwrap process, either forked by the > service that want's to shell out or a general purpose rootwrapd type

Re: [openstack-dev] [Openstack-dev][nova] Disable per-user rate limiting by default

I agree with this, but perhaps we should discuss with openstack-operators@ as well? Michael On Fri, Jul 26, 2013 at 6:33 AM, Davanum Srinivas wrote: > +1 to turn it off > > -- dims > > On Thu, Jul 25, 2013 at 12:07 PM, Day, Phil wrote: >> +1 to turning it off. Having something that doesn’t rea

Re: [openstack-dev] Python overhead for rootwrap

Russell Bryant wrote: > On 07/25/2013 04:40 PM, Mike Wilson wrote: >> In my opinion: >> >> 1. Stop using rootwrap completely and get strong argument checking >> support into sudo (regex). >> 2. Some sort of long lived rootwrap process, either forked by the >> service that want's to shell out or a g

Re: [openstack-dev] [Stackalytics] 0.1 release

Thank you Gareth, this makes total sense. We will make sure to include this in the next release. Alex Freedland Mirantis, Inc. On Thu, Jul 25, 2013 at 3:21 AM, Gareth wrote: > A suggestion: > > sort bugs number as int is much better than string, because '112' < '8' > but actually 112 > 8 >

[openstack-dev] [Glance] property protections -- final call for comments

After lots of discussion, I think we've come to a consensus on what property protections should look like in Glance. Please reply with comments! The blueprint: https://blueprints.launchpad.net/glance/+spec/api-v2-property-protection The full specification: https://wiki.openstack.org/wiki/Glan

Re: [openstack-dev] Discussing Amazon API compatibility [Nova][Swift]

Stefano Maffulli wrote: > I have seen lots of discussions on blogs and twitter heating up around > Amazon API compatibility and OpenStack. This seems like a recurring > topic, often raised by pundits and recently joined by members of the > community. I think it's time to bring the discussions insid

Re: [openstack-dev] [tripleo] removing sudoers.d rules from disk-image-builder

Chris Jones wrote: > I agree with your analysis of the effects of the sudoers file and I > think it makes a great argument for recommending people run the main > command itself with sudo, rather than a blanket passwordless sudo, but > really all we need to say is "this tool needs to be run as root"

Re: [openstack-dev] Discussing Amazon API compatibility [Nova][Swift]

On 07/25/2013 06:11 PM, Thierry Carrez wrote: > Stefano Maffulli wrote: >> I have seen lots of discussions on blogs and twitter heating up around >> Amazon API compatibility and OpenStack. This seems like a recurring >> topic, often raised by pundits and recently joined by members of the >> communi

Re: [openstack-dev] [tripleo] removing sudoers.d rules from disk-image-builder

On 26 July 2013 10:19, Thierry Carrez wrote: > Chris Jones wrote: >> I agree with your analysis of the effects of the sudoers file and I >> think it makes a great argument for recommending people run the main >> command itself with sudo, rather than a blanket passwordless sudo, but >> really all w

Re: [openstack-dev] Discussing Amazon API compatibility [Nova][Swift]

On Fri, Jul 26, 2013 at 8:30 AM, Russell Bryant wrote: > If an external proxy (like AWSOME) is what you want, one of those > already exists (at least for the EC2 API). > > http://deltacloud.apache.org/ > > It supports EC2 on the frontend and the OpenStack compute API on the > backend. I'm not su

Re: [openstack-dev] Python overhead for rootwrap

On Fri, Jul 26, 2013 at 7:43 AM, Thierry Carrez wrote: > I would rather support solution 3: create a single, separate executable > that does those 20 things that need to be done (can be a shell script > with some logic in it), and have rootwrap call that *once*. That way you > increase speed by

Re: [openstack-dev] [Stackalytics] 0.1 release [metrics]

On 07/23/2013 07:25 AM, Roman Prykhodchenko wrote: > I still think counting lines of code is evil because it might encourage > some developers to write longer code just for statistics. Data becomes evil when you decide to use them for evil purposes :) I don't think that lines of code is a bad metr

Re: [openstack-dev] [Openstack-dev][nova] Disable per-user rate limiting by default

You mean process/forking API right? Honestly I'd sort of think the whole limits.py that is this rate-limiting could also be turned off by default (or a log warn message occurs) when multi-process nova-api is used since the control for that paste module actually returns the currently enforced li

Re: [openstack-dev] Discussing Amazon API compatibility [Nova][Swift]

When you have so much state to maintain then aren't the APIs incorrect?? Or can there be new API's that expose this translation, something seems/feels wrong if there is so much state to maintain u can't do a translation layer. My 2 cents. On 7/25/13 4:36 PM, "Michael Still" wrote: >On Fri, Jul

Re: [openstack-dev] [Swift] question on Application class concurrency; paste.app_factory mechanism

Thanks for the reply Pete. Don't quite follow you so will continue to do some reading and experimenting and see if I can't come up some additional questions... Thx Paul -Original Message- From: Pete Zaitcev [mailto:zait...@redhat.com] Sent: Thursday, July 25, 2013 9:51 AM To: OpenStac

[openstack-dev] [OpenStack][Cinder] Driver qualification

Hey Everyone, Something I've been kicking around for quite a while now but never really been able to get around to is the idea of requiring that drivers in Cinder run a qualification test and submit results prior to introduction in to Cinder. To elaborate a bit, the idea could start as something

Re: [openstack-dev] [OpenStack][Cinder] Driver qualification

On 07/25/2013 08:44 PM, John Griffith wrote: > Hey Everyone, > > Something I've been kicking around for quite a while now but never > really been able to get around to is the idea of requiring that drivers > in Cinder run a qualification test and submit results prior to > introduction in to Cinder

Re: [openstack-dev] [OpenStack][Cinder] Driver qualification

100% agree, its hard to handle these 3rd party type of drivers but I think we need to find out a way that will test it in a way that doesn't require having said 3rd party gear directly available. Could it be possible to have CI gating be blocked/tested by individual subfolders of cinder. For e

Re: [openstack-dev] [OpenStack][Cinder] Driver qualification

Great idea and 100% agree. It'd be even better if maintainer can publish functional test results using their own back-ends on a regular basis (weekly/bi-weekly test report) to 'openstack-dev' mailing list. On Fri, Jul 26, 2013 at 9:05 AM, Joshua Harlow wrote: > 100% agree, its hard to handle t

Re: [openstack-dev] [OpenStack][Cinder] Driver qualification

+1. I like this idea. With this qualification test, is each driver still required to have its own unit test? Thanks, Xing On Jul 25, 2013, at 8:46 PM, "John Griffith" mailto:john.griff...@solidfire.com>> wrote: Hey Everyone, Something I've been kicking around for quite a while now but neve

Re: [openstack-dev] Python overhead for rootwrap

On 26 July 2013 09:43, Thierry Carrez wrote: > Russell Bryant wrote: >> On 07/25/2013 04:40 PM, Mike Wilson wrote: >>> In my opinion: >>> >>> 1. Stop using rootwrap completely and get strong argument checking >>> support into sudo (regex). >>> 2. Some sort of long lived rootwrap process, either fo

Re: [openstack-dev] A vision for Keystone

On 07/19/2013 10:56 AM, Brad Topol wrote: Adam, Your essay below is outstanding! Any chance part of it could be included within the keystone project documentation? I think having it in the project and at folks fingertips would really help folks that are trying to get up to speed with keyst

Re: [openstack-dev] [OpenStack][Cinder] Driver qualification

On Thu, Jul 25, 2013 at 7:37 PM, yang, xing wrote: > +1. I like this idea. With this qualification test, is each driver still > required to have its own unit test? > Keep in mind this is just a proposal that I wanted to get feed-back on, I'll likely submit something more concrete shortly. Tha

[openstack-dev] [Keystone] Alembic support

I've been looking into Alembic support. It seems that there is one thing missing that I was counting on: multiple migration repos. It might be supported, but the docs are thin, and reports vary. In the current Keystone implementation, we have a table like this: mysql> desc migrate_version; +-

Re: [openstack-dev] [Keystone] Alembic support

+1 to getting the multiple repos in place. Moving to Alembric later on in H or even as the first commit of I should meet our goals to be on Alembric in a reasonable timeframe. This also allows us to ensure we aren't rushing the work to get our migration repos over to Alembric. I think that allow

[openstack-dev] [nova] generate_sample.sh

Hi, Over the last few days I have been battling with this script (I am only human). Recently there was a nice change that removed the number of entries which helps with the merges. One thing that I have encountered over the last 2 days is that the pep8 passes with my environment and fails with t

[openstack-dev] [Nova] Random gate failures

Hi, Since the addition of https://review.openstack.org/#/c/32966/ there have been a number of failures with unit tests (sadly this is not consistent) but examples are: https://review.openstack.org/#/c/35189/ https://review.openstack.org/#/c/33504/ I have managed to reproduce this on a local setup

Re: [openstack-dev] [nova] generate_sample.sh

2013-7-26，1:58 pm，Gary Kotton Wrote： > Hi, > Over the last few days I have been battling with this script (I am only > human). Recently there was a nice change that removed the number of entries > which helps with the merges. One thing that I have encountered over the last > 2 days is that t