Re: [openstack-dev] [Octavia] Temporary project leadership team

Le 01/07/2014 00:08, Stephen Balukoff a écrit : > > > Obviously, please feel free to disagree with our process and/or > decision for doing this, but I would ask that if you do, please also > do us the courtesy of explaining how we're supposed to merge code > using the gerrit system without having a

Re: [openstack-dev] oslosphinx & hacking build-depending on each other

On 06/30/2014 10:43 PM, Jeremy Stanley wrote: > On 2014-06-30 22:11:30 +0800 (+0800), Thomas Goirand wrote: >> It'd be nice to fix the fact that oslosphinx & hacking are >> build-depending on each other. How can we fix this? > > They're only build-depending on one another (in the Debian sense) > b

Re: [openstack-dev] [nova][scheduler] Proposal: FairShareScheduler.

On 06/30/2014 04:35 PM, Jesse Pretorius wrote: On 30 June 2014 16:05, Eric Frizziero > wrote: In more detail, some features of the FairshareScheduler are: a) It assigns dynamically the proper priority to every new user requests; b) The priority o

Re: [openstack-dev] [nova][scheduler] Proposal: FairShareScheduler.

Hi Belmiro, On 06/30/2014 11:42 PM, Belmiro Moreira wrote: Hi Eric, definitely... In my view a "FairShareScheduler" could be a very interesting option for private clouds that support scientific communities. Basically this is the model used by batch systems in order to fully use the available

Re: [openstack-dev] [nova][scheduler] Proposal: FairShareScheduler.

Hi Tim, for sure this is one of the main issues we are facing and the approach you suggested is the same we are investigating on. Could you provide some details about the Heat proxy renew mechanism? Thank you very much for your feedback. Cheers, Lisa On 01/07/2014 08:46, Tim Bell wrote: Eric

[openstack-dev] [Neutron] request for review

Hi folks, Could anyone please review this spec for adding a new API to count resources in Neutron? https://review.openstack.org/#/c/102199/ Thanks Xurong Yang ___ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cg

Re: [openstack-dev] [nova][sriov] weekly meeting for july 1st and july 8th

I'll chair this week PCI SR-IOV pass-through meeting for those who would like to attend. BR, Irena From: Robert Li (baoli) [mailto:[email protected]] Sent: Tuesday, July 01, 2014 5:00 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [nova][sriov] weekly

Re: [openstack-dev] [nova][scheduler] Proposal: FairShareScheduler.

Hi Don, I and my colleague Lisa attend both IRC meetings (today and next week). In the meantime you can find more info about the FairShareScheduler at the following link: https://agenda.infn.it/getFile.py/access?contribId=17&sessionId=3&resId=0&materialId=slides&confId=7915 Thank you very m

Re: [openstack-dev] [nova][scheduler][keystone] Renewable tokens (was Proposal: FairShareScheduler.)

> -Original Message- > From: Lisa [mailto:[email protected]] > Sent: 01 July 2014 10:45 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [nova][scheduler] Proposal: FairShareScheduler. > > Hi Tim, > > for sure this is one of the mai

Re: [openstack-dev] [nova][scheduler] Proposal: FairShareScheduler.

Le 01/07/2014 10:45, Lisa a écrit : > Hi Tim, > > for sure this is one of the main issues we are facing and the approach > you suggested is the same we are investigating on. > Could you provide some details about the Heat proxy renew mechanism? > Thank you very much for your feedback. > Cheers, > L

Re: [openstack-dev] [nova][scheduler][keystone] Renewable tokens (was Proposal: FairShareScheduler.)

Le 01/07/2014 11:09, Tim Bell a écrit : >> -Original Message- >> From: Lisa [mailto:[email protected]] >> Sent: 01 July 2014 10:45 >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [nova][scheduler] Proposal: FairShareScheduler. >> >

Re: [openstack-dev] [Fuel] Triaging bugs: milestones vs release series

+1 On Tue, Jul 1, 2014 at 2:33 AM, Dmitry Borodaenko wrote: > When you create a bug against a project (in our case, fuel) in > Launchpad, it is always initially targeted at the default release > series (currently, 5.1.x). On the bug summary, that isn't explicitly > stated and shows as being tar

[openstack-dev] [Fuel] Bug sqashing

We are really close to 5.0.1 release and 5.1 feature freeze. So I skip bug squash day this week. And I suggest additional action for next squash: let's review all existing bugs and link them to blueprints if fix requires new functionality. And close every bug report if it is not related to any iss

Re: [openstack-dev] [all] 3rd Party CI vs. Gerrit

On 30 June 2014 16:49, Anita Kuno wrote: > Right now that dashboard introduces more confusion than it alleviates > since the definition of "success" in regards to third party ci systems > has yet to be defined by the community. For the record, cinder gave a very clear definition of success in ou

Re: [openstack-dev] [Ironic] Juno priorities and spec review timeline

Hello Devananda Design spec for the remote firmware setting feature is under review ( https://review.openstack.org/#/c/101122 ). Have received comments on the APIs and we are converging on the set of required APIs. Have posted the new patch addressing the comments on the same. Please check, if w

Re: [openstack-dev] [Fuel] Blueprints process

I have some objections. We are trying to follow a strict development workflow with feature freeze stage. In this case we will have to miss small enhancements that can emerge after FF date and can bring essential benefits along with small risks of breaking anything (e.g. changing some config options

[openstack-dev] [Fuel] New official tag: "to-be-covered-by-tests"

Fuelers, I created new official tag in Fuel called "to-be-covered-by-tests". If you see the bug that (or bugs similar to this) could be caught by tests, please add this tag, so we could collect this information and write corresponding tests in future. -- Yours Faithfully, Vladimir Kuklin, Fuel L

[openstack-dev] Swift: reason for using xfs on devices

Hi, In the following document, there is a setup up procedure for storage and it seems that swift recommends to use xfs. http://docs.openstack.org/icehouse/install-guide/install/yum/content/installing-and-configuring-storage-nodes.html === 2. For each device on the node that you want to use for

Re: [openstack-dev] [Neutron] DVR demo and how-to

Thank you for the video, keep up the good work!, - Original Message - > Hi folks, > > The DVR team is working really hard to complete this important task for Juno > and Neutron. > > In order to help see this feature in action, a video has been made available > and link can be found in [

[openstack-dev] Using tmux instead of screen in devstack

Hi, I use tmux (an alternative to screen) a lot and I believe lot of other developers use it. I have been using devstack for some time now and would like to add the option of using tmux instead of screen for creating sessions for openstack services. I couldn't find a way to do that in current impl

Re: [openstack-dev] [TripleO] Time to break backwards compatibility for *cloud-password file location?

On 06/25/2014 11:25 AM, [email protected] wrote: On 25/06/14 10:52, James Polley wrote: Until https://review.openstack.org/#/c/83250/, the setup-*-password scripts used to drop password files into $CWD, which meant that if you ran the script from a different location next time, your old password

Re: [openstack-dev] Using tmux instead of screen in devstack

On Tue, Jul 1, 2014 at 2:11 PM, Anant Patil wrote: > Hi, > > I use tmux (an alternative to screen) a lot and I believe lot of other > developers use it. I have been using devstack for some time now and would > like to add the option of using tmux instead of screen for creating > sessions for open

Re: [openstack-dev] Using tmux instead of screen in devstack

On 07/01/2014 08:11 AM, Anant Patil wrote: > Hi, > > I use tmux (an alternative to screen) a lot and I believe lot of other > developers use it. I have been using devstack for some time now and > would like to add the option of using tmux instead of screen for > creating sessions for openstack ser

Re: [openstack-dev] Swift: reason for using xfs on devices

On Tue, Jul 1, 2014 at 6:21 AM, Osanai, Hisashi < [email protected]> wrote: > > Hi, > > In the following document, there is a setup up procedure for storage and > it seems that swift recommends to use xfs. > > > http://docs.openstack.org/icehouse/install-guide/install/yum/content/insta

Re: [openstack-dev] Using tmux instead of screen in devstack

Anant Patil wrote: >I use tmux (an alternative to screen) a lot and I believe lot of other >developers use it. >I have been using devstack for some time now and would like to add the option >of >using tmux instead of screen for creating sessions for openstack services. >I couldn't find a way to d

[openstack-dev] [qa] issues adding functionality to javelin2

I've been working to add ceilometer checks in javelin2. Doing so has revealed some issues that appear to be a fairly big deal but I suppose there's some chance I'm doing things completely wrong. For reference my experiments are being done with a devstack with ceilometer enabled, running javelin

Re: [openstack-dev] [neutron]Performance of security group

Ok, I was talking with Édouard @ IRC, and as I have time to work into this problem, I could file an specific spec for the security group RPC optimization, a masterplan in two steps: 1) Refactor the current RPC communication for security_groups_for_devices, which could be used for full syncs,

[openstack-dev] Call for Speakers Open, OpenStack Summit in Paris

Hi Everyone, *The Call for Speakers is OPEN for the November OpenStack Summit in Paris! Submit your talks here: https://www.openstack.org/summit/openstack-paris-summit-2014/call-for-speakers/.* There are a few new speaking tracks in the Summit lineup this year so please review the below list

Re: [openstack-dev] [Nova][Oslo.cfg] Configuration string substitution

Hello On Fri, Jun 20, 2014 at 12:48 PM, Radoslav Gerganov wrote: > Hi, > > > On Wed, Jun 18, 2014 at 4:47 AM, Gary Kotton wrote: > > > Hi, > > > I have encountered a problem with string substitution with the nova > > > configuration file. The motivation was to move all of the glance > settings

Re: [openstack-dev] [oslo][messaging] Further improvements and refactoring

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 30/06/14 21:34, Alexei Kornienko wrote: > Hello, > > > My understanding is that your analysis is mostly based on running > a profiler against the code. Network operations can be bottlenecked > in other places. > > You compare 'simple script usi

[openstack-dev] [Nova] Mid-cycle sprint for remote people ?

Hi, I won't be able to attend the mid-cycle sprint due to a good family reason (a new baby 2.0 release expected to land by these dates), so I'm wondering if it's possible to webcast some of the sessions so people who are not there can still share their voices ? -Sylvain

Re: [openstack-dev] [all] stevedore 1.0.0.0a1

Hello, Doug. On Mon, Jun 23, 2014 at 6:11 PM, Doug Hellmann wrote: > $ git log --abbrev-commit --pretty=oneline 0.15..1.0.0.0a1 > d37b47f Merge "Updated from global requirements" > bc2d08a Updated from global requirements > e8e9ca1 Fix incorrect image reference in documentation > d39ef75 Fix req

Re: [openstack-dev] [third-party-ci][neutron] What is "Success" exactly?

On 06/30/2014 09:13 PM, Jay Pipes wrote: > On 06/30/2014 07:08 PM, Anita Kuno wrote: >> On 06/30/2014 04:22 PM, Jay Pipes wrote: >>> Hi Stackers, >>> >>> Some recent ML threads [1] and a hot IRC meeting today [2] brought up >>> some legitimate questions around how a newly-proposed Stackalytics >>>

Re: [openstack-dev] [all] 3rd Party CI vs. Gerrit

On 07/01/2014 05:56 AM, Duncan Thomas wrote: > On 30 June 2014 16:49, Anita Kuno wrote: > >> Right now that dashboard introduces more confusion than it alleviates >> since the definition of "success" in regards to third party ci systems >> has yet to be defined by the community. > > For the reco

Re: [openstack-dev] [Nova] Mid-cycle sprint for remote people ?

At minimum I can arrange for a phone bridge at the sprint (Intel `lives` on phone conferences) so we can certainly do that. Video might be more problematic, I know we did something with Google Plus at the last sprint but I don't know the details on that. -- Don Dugger "Censeo Toto nos in Kansa

Re: [openstack-dev] [qa] issues adding functionality to javelin2

On Tue, Jul 01, 2014 at 02:01:19PM +0100, Chris Dent wrote: > > I've been working to add ceilometer checks in javelin2. Doing so has > revealed some issues that appear to be a fairly big deal but I suppose > there's some chance I'm doing things completely wrong. > > For reference my experiments a

Re: [openstack-dev] [oslo][messaging] Further improvements and refactoring

Hi, Thanks for detailed answer. Please see my comments inline. Regards, On 07/01/2014 04:28 PM, Ihar Hrachyshka wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 30/06/14 21:34, Alexei Kornienko wrote: Hello, My understanding is that your analysis is mostly based on running a profi

Re: [openstack-dev] [all] 3rd Party CI vs. Gerrit

On 1 July 2014 14:44, Anita Kuno wrote: > On 07/01/2014 05:56 AM, Duncan Thomas wrote: >> For the record, cinder gave a very clear definition of success in our >> 3rd party guidelines: Passes every test in tempest-dsm-full. If that >> needs documenting somewhere else, please let me know. It may o

[openstack-dev] Small MongoDB World summary

Hi, I attended MongoDB World last week and I thought about giving y'all a heads up of what's coming next in mongodb-2.8. - DB Lock will be pushed down to the document level. They demoed this and I gotta admit, it was quite mind-blowing. - Support for different storage engines (ala MySQL). They

Re: [openstack-dev] [qa] issues adding functionality to javelin2

On Tue, 1 Jul 2014, Matthew Treinish wrote: In the mean-time you can easily re-enable the full tracebacks by setting both verbose and debug logging in the tempest config file. Is there a way to say, via config, "no, I really do want exceptions to cause the code to exit and pooh on the console"

Re: [openstack-dev] [Horizon] Nominations to Horizon Core

Welcome Zhenguo and Ana to Horizon core. David On 6/20/14, 3:17 PM, "Lyle, David" wrote: >I would like to nominate Zhenguo Niu and Ana Krivokapic to Horizon core. > >Zhenguo has been a prolific reviewer for the past two releases providing >high quality reviews. And providing a significant numb

Re: [openstack-dev] [oslo][messaging] Further improvements and refactoring

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/07/14 15:55, Alexei Kornienko wrote: > Hi, > > Thanks for detailed answer. Please see my comments inline. > > Regards, > > On 07/01/2014 04:28 PM, Ihar Hrachyshka wrote: On 30/06/14 21:34, > Alexei Kornienko wrote: Hello, >>

Re: [openstack-dev] [oslo][messaging] Further improvements and refactoring

Hi, Please see some minor comments inline. Do you think we can schedule some time to discuss this topic on one of the upcoming meetings? We can come out with some kind of the summary and actions plan to start working on. Regards, On 07/01/2014 05:52 PM, Ihar Hrachyshka wrote: -BEGIN PGP

Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects

On Mon, Jun 30 2014, Joshua Harlow wrote: > There is a balance here that needs to be worked out and I've seen > specs start to turn into requirements for every single patch (even if > the patch is pretty small). I hope we can rework the 'balance in the > force' to avoid being so strict that every

Re: [openstack-dev] [Neutron] request for review

Please don't send review requests to the list. The preferred methods are discussed here: http://lists.openstack.org/pipermail/openstack-dev/2013-September/015264.html Thanks. -Ben On 07/01/2014 03:45 AM, Xurong Yang wrote: > Hi folks, > > Could anyone please review this spec for adding a new A

Re: [openstack-dev] [infra][oslo][neutron] Need help getting oslo.messaging 1.4.0.0a2 in global requirements

On 06/30/2014 02:28 PM, Mark McLoughlin wrote: > On Mon, 2014-06-30 at 16:52 +, Paul Michali (pcm) wrote: >> I have out for review 103536 to add this version to global >> requirements, so that Neutron has an oslo fix (review 102909) for >> encoding failure, which affects some gate runs. This re

Re: [openstack-dev] [TripleO] Use MariaDB by default on Fedora

I propose making mysql an abstract element and user must choose either percona or mariadb-rpm element.CI must be setup correctly Michael On Monday 30 June 2014 12:02:09 Clint Byrum wrote: > Excerpts from Michael Kerrin's message of 2014-06-30 02:16:07 -0700: > > I am trying to finish off https:/

Re: [openstack-dev] [DevStack] neutron config not working

Rob Crittenden wrote: > Mark Kirkwood wrote: >> On 25/06/14 10:59, Rob Crittenden wrote: >>> Before I get punted onto the operators list, I post this here because >>> this is the default config and I'd expect the defaults to just work. >>> >>> Running devstack inside a VM with a single NIC configur

Re: [openstack-dev] Small MongoDB World summary

Did they change the license? ;) Sent from my really tiny device... > On Jul 1, 2014, at 7:17 AM, "Flavio Percoco" wrote: > > Hi, > > I attended MongoDB World last week and I thought about giving y'all a > heads up of what's coming next in mongodb-2.8. > > - DB Lock will be pushed down to the

[openstack-dev] [Keystone] [Swift] Question re. keystone domains

We have a change [1] under review in Swift to make access control lists compatible with migration to keystone v3 domains. The change makes two assumptions that I'd like to double-check with keystone folks: 1. That a project can never move from one domain to another. 2. That the under

Re: [openstack-dev] [all] 3rd Party CI vs. Gerrit

Anita, This line [1] is effectively a sub-set of tempest-dsm-full, and what we're currently running manually now. I far as I understood, this is the current minimum. The exact sub-set (or full set, or if additional tests are allowed) is still under discussion. I created a WIP reference patch

Re: [openstack-dev] [infra][oslo][neutron] Need help getting oslo.messaging 1.4.0.0a2 in global requirements

Thanks for the update! Is there anything I need to do for my review 103536 for adding 1.4.0.0a2 to global requirements? Regards, PCM (Paul Michali) MAIL …..…. [email protected] IRC ……..… pcm_ (irc.freenode.com) TW ………... @pmichali GPG Key … 4525ECC253E31A83 Fingerprint .. 307A 96BB 1A4C D2C7 931D

[openstack-dev] [Fuel] Few hot questions related to patching for openstack

Hi fuelers, I'm working on Patching for OpenStack and I have the following questions: 1/ We need to save new puppets and repos under some versioned folder: /etc/puppet/{version}/ or /var/www/nailgun/{version}/centos. So the question is which version to use? Fuel or OpenStack? 2/ Which vers

[openstack-dev] [Neutron][ML2] Migration bug - Bug #1332564

Hi, Anthony Veiga and I are currently working on migrating a lab environment from Neutron Havana w/ OVS plugin to Icehouse w/ ML2 plugin and ran into a bug[0]. Now the patch that adds the ml2 migration[1] mentions that it was tested without any data, and that it is waiting on grenade support for

Re: [openstack-dev] [DevStack] neutron config not working

Hi Rob: Can you try adding the following config to your local.conf? I'd like to see if this gets you going or not. It will force it to use gre tunnels for tenant networks. By default it will not. ENABLE_TENANT_TUNNELS=True On Tue, Jul 1, 2014 at 10:53 AM, Rob Crittenden wrote: > Rob Crittenden

Re: [openstack-dev] [Fuel] Few hot questions related to patching for openstack

1) Puppet manifests are part of Fuel so the version of Fuel should be used. It is possible to have more than one version of Fuel per OpenStack version, but not the other way around: if we upgrade OpenStack version we also increase version of Fuel. 2) Should be a combination of both: it should indi

Re: [openstack-dev] [neutron][third-party] Simple and robust CI script?

Howdy! I wrote a new version of shellci today and have it up and running and voting on the sandbox. It's described on the Github page: https://github.com/SnabbCo/shellci Currently this is simple shell scripts to receive review.openstack.org gerrit events, run tests and determine results, then po

[openstack-dev] [third-party] - rebasing patches for CI

Hello, What is the expected behavior of 3rd-party CI systems with regard to checking out a patch. Should it be tested 'as-is' or should it be merged into the proposed branch first and then tested? As I understand it, this behavior for the main OpenStack CI check queue changed to the latter some t

Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects

The argument has been made in the past that small features will require correspondingly small specs. If there's a counter-argument to this example (a "small" feature requiring a relatively large amount of spec effort), I'd love to have links to both the spec and the resulting implementation so we c

[openstack-dev] [cinder] 3rd party ci names for use by official cinder mandated tests

3rd party ci names is currently becoming a bit controversial for what we're trying to do in cinder: https://review.openstack.org/#/c/101013/ The motivation for the above change is to aid developers understand what the 3rd party ci systems are testing in order to avoid confusion. The goal is to ai

Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects

I meant the administrative overhead of the contributor having to submit a spec to Gerrit and then everyone having to deal with yet another review, not the overhead of writing/reviewing the spec itself. On Tue, Jul 01 2014, Dolph Mathews wrote: > The argument has been made in the past that small f

[openstack-dev] [QA] Spec Review Day July 9th

Hi Everyone, During the last qa meeting we were discussing ways to try an increase throughput on the qa-specs repo. We decided to have a dedicated review day for the specs repo. Right now specs approval is a relatively slow process, reviews seem to take too long (an average wait time of ~12 days)

Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects

Much as I dislike the overhead and the extra latency involved (now you need to have a review cycle for the spec plus the review cycle for the patch itself) I agreed with the `small features require small specs’. The problem is that even a small change can have a big impact. Forcing people to c

Re: [openstack-dev] [Fuel] Few hot questions related to patching for openstack

Hi, my 2 cents: 1) Fuel version (+1 to Dmitry) 2) Could you please clarify what exactly you mean by "our patches" / "our first patch"? On Tue, Jul 1, 2014 at 8:04 PM, Dmitry Borodaenko wrote: > 1) Puppet manifests are part of Fuel so the version of Fuel should be > used. It is possible to h

Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects

On Tue, Jul 1, 2014 at 10:02 AM, Dolph Mathews wrote: > The argument has been made in the past that small features will require > correspondingly small specs. If there's a counter-argument to this example > (a "small" feature requiring a relatively large amount of spec effort), I'd > love to have

Re: [openstack-dev] [Keystone] [Swift] Question re. keystone domains

On Tue, Jul 1, 2014 at 11:20 AM, Coles, Alistair wrote: > We have a change [1] under review in Swift to make access control lists > compatible with migration to keystone v3 domains. The change makes two > assumptions that I’d like to double-check with keystone folks: > > > > 1. That a proje

[openstack-dev] [heat] health maintenance in autoscaling groups

In AWS, an autoscaling group includes health maintenance functionality --- both an ability to detect basic forms of failures and an ability to react properly to failures detected by itself or by a load balancer. What is the thinking about how to get this functionality in OpenStack? Since Open

Re: [openstack-dev] [Nova] Mid-cycle sprint for remote people ?

We were talking about doing something with google+ for Chris Yeoh, but haven't really progressed the plan. Does someone want to pick up the ball with that or shall I? Michael On Tue, Jul 1, 2014 at 11:50 PM, Dugger, Donald D wrote: > At minimum I can arrange for a phone bridge at the sprint (Int

[openstack-dev] [nova] how to unit test scripts outside of nova/nova?

As part of the enforce-unique-instance-uuid-in-db blueprint [1] I'm writing a script to scan the database and find any NULL instance_uuid records that will cause the new database migration to fail so that operators can run this before they run the migration, otherwise the migration blocks if th

[openstack-dev] [heat] autoscaling across regions and availability zones

An AWS autoscaling group can span multiple availability zones in one region. What is the thinking about how to get analogous functionality in OpenStack? Warmup question: what is the thinking about how to get the levels of isolation seen between AWS regions when using OpenStack? What is the t

[openstack-dev] [Keystone] Feature to enable domain-related role validation

Hi all, We created a POC that enables domain-related role checking to components that do not support domains (such as Nova and Cinder). The code can be found here: https://github.com/rodrigods/keystone/tree/domain-check The idea is to use the HttpCheck feature: https://github.com/openstack/o

[openstack-dev] [heat] One more lifecycle plug point - in scaling groups

Thinking about my favorite use case for lifecycle plug points for cloud providers (i.e., giving something a chance to make a holistic placement decision), it occurs to me that one more is needed: a scale-down plug point. A plugin for this point has a distinctive job: to decide which group memb

Re: [openstack-dev] [nova] how to unit test scripts outside of nova/nova?

On Tue, Jul 01, 2014 at 03:21:06PM -0500, Matt Riedemann wrote: > As part of the enforce-unique-instance-uuid-in-db blueprint [1] I'm writing > a script to scan the database and find any NULL instance_uuid records that > will cause the new database migration to fail so that operators can run this >

Re: [openstack-dev] [Infra] Meeting Tuesday July 1st at 19:00 UTC

On Mon, Jun 30, 2014 at 11:18 AM, Elizabeth K. Joseph wrote: > Hi everyone, > > The OpenStack Infrastructure (Infra) team is hosting our weekly > meeting on Tuesday July 1st at 19:00 UTC in #openstack-meeting Meeting minutes and log available: Minutes: http://eavesdrop.openstack.org/meetings/in

[openstack-dev] [compute][tempest] Upgrading libvirt-lxc support status

Greetings list,- Over the next few weeks I will be working on developing additional Tempest gating unit and functional tests for the libvirt-lxc compute driver. I am trying to figure out exactly what is required in order to accomplish the goal of ensuring the continued inclusion (without deprecat

[openstack-dev] [Containers][Nova] Containers Mid-Cycle Meetup

Team, Please help us select dates for the Containers Team Midcycle Meetup: http://doodle.com/2mebqhdxpksf763m Thanks, Adrian ___ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac

Re: [openstack-dev] [Containers][Nova] Containers Mid-Cycle Meetup

On 07/01/2014 05:59 PM, Adrian Otto wrote: > Team, > > Please help us select dates for the Containers Team Midcycle Meetup: > > http://doodle.com/2mebqhdxpksf763m Why not just join the Nova meetup? -- Russell Bryant ___ OpenStack-dev mailing list Op

Re: [openstack-dev] [cinder]a problem about the implement of limit-volume-copy-bandwidth

Hi Zhou, >Hi stackers, > >I found some problems about the current implement of >limit-volume-copy-bandwidth (this patch has been merged in last week.) > >Firstly, assume that I configurate volume_copy_bps_limit=10M, If >the path is a block device, cgroup blkio can limit copy-bandwidth >sep

[openstack-dev] Inter Cloud Resource Federation (Alliance)

All, I am working on a new service to address the problems of "Inter Cloud Resource Federation" use cases (e.g. multi region, cloud bursting, resource sharing across clouds, etc . ). The new service will integrate multiple OpenStack cloud to work in alliance to provide resource federation

Re: [openstack-dev] [heat] autoscaling across regions and availability zones

On 01/07/14 16:23, Mike Spreitzer wrote: An AWS autoscaling group can span multiple availability zones in one region. What is the thinking about how to get analogous functionality in OpenStack? Correct, you specify a list of availability zones (instead of just one), and AWS distributes server

Re: [openstack-dev] [heat] health maintenance in autoscaling groups

On 01/07/14 15:47, Mike Spreitzer wrote: In AWS, an autoscaling group includes health maintenance functionality --- both an ability to detect basic forms of failures and an ability to react properly to failures detected by itself or by a load balancer. What is the thinking about how to get this

Re: [openstack-dev] [third-party] - rebasing patches for CI

On 2014-07-01 10:05:45 -0700 (-0700), Kevin Benton wrote: [...] > As I understand it, this behavior for the main OpenStack CI check > queue changed to the latter some time over the past few months. [...] I'm not sure what you think changed, but we've (upstream OpenStack CI) been testing proposed p

Re: [openstack-dev] [heat] One more lifecycle plug point - in scaling groups

On 01/07/14 16:30, Mike Spreitzer wrote: Thinking about my favorite use case for lifecycle plug points for cloud providers (i.e., giving something a chance to make a holistic placement decision), it occurs to me that one more is needed: a scale-down plug point. A plugin for this point has a dist

Re: [openstack-dev] nova networking API and CLI are poorly documented and buggy

On Jun 14, 2014, at 9:12 AM, Mike Spreitzer wrote: > I am not even sure what is the intent, but some of the behavior looks like it > is clearly unintended and not useful (a more precise formulation of "buggy" > that is not defeated by the lack of documentation). > > IMHO, the API and CLI docu

Re: [openstack-dev] [QA] Spec Review Day July 9th

2014-07-02 2:30 GMT+09:00 Matthew Treinish : > Hi Everyone, > > During the last qa meeting we were discussing ways to try an increase > throughput > on the qa-specs repo. We decided to have a dedicated review day for the specs > repo. Right now specs approval is a relatively slow process, reviews

Re: [openstack-dev] Swift: reason for using xfs on devices

On Tuesday, July 01, 2014 9:44 PM, Anne Gentle wrote: Thank you for the quick response. > The install guide only recommends a single path, not many options, to ensure > success. I understand the point for writing the document. > There's a little bit of discussion in the developer docs: > htt

Re: [openstack-dev] [nova] how to unit test scripts outside of nova/nova?

On 7/1/2014 4:03 PM, Matthew Treinish wrote: On Tue, Jul 01, 2014 at 03:21:06PM -0500, Matt Riedemann wrote: As part of the enforce-unique-instance-uuid-in-db blueprint [1] I'm writing a script to scan the database and find any NULL instance_uuid records that will cause the new database migrat

Re: [openstack-dev] [heat] One more lifecycle plug point - in scaling groups

Zane Bitter wrote on 07/01/2014 07:05:15 PM: > On 01/07/14 16:30, Mike Spreitzer wrote: > > Thinking about my favorite use case for lifecycle plug points for cloud > > providers (i.e., giving something a chance to make a holistic placement > > decision), it occurs to me that one more is needed:

[openstack-dev] [Keystone] HTTP Get and HEAD requests mismatch on resulting HTTP status (proposed REST API Response Status Changes)

In the endeavor to move from the default deployment of Keystone being eventlet (in devstack) to Apache + mod_wsgi, I noticed that there was an odd mis-match on a single set of tempest tests relating to trusts. Under eventlet a HTTP 204 No Content was being returned, but under mod_wsgi an HTTP 20

Re: [openstack-dev] [Ironic] Juno priorities and spec review timeline

Hi Devananda, I noticed that firmware update is not on the priority list. I thought there was strong interest in this capability. The design spec of out-of-band firmware update has been submitted https://review.openstack.org/#/c/100842/. We will address the review comments and uplaod a new ve

Re: [openstack-dev] DVR and FWaaS integration

From: Carl Baldwin [[email protected]] Sent: Monday, June 30, 2014 3:43 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] DVR and FWaaS integration On Mon, Jun 30, 2014 at 3:43 AM, Carl Baldwin mailto:[email protected]>> wrote: In line...

[openstack-dev] [cinder][tempest]how to get cinder coverage using tempest?

I have manually deployed cinder and it is up and running. Now I wanted to get the live code coverage for cinder using tempest, I tried to running each cinder-api services as "coverage run /usr/bin/cinder-api" it started but when I tried same with cinder-volume with volume types configured it failed

Re: [openstack-dev] [neutron]Performance of security group

hi Miguel Angel Ajo Pelayo! I agree with you and modify my spes, but I will also optimization the RPC from security group agent to neutron server. Now the modle is 'port[rule1,rule2...], port...', I will change it to 'port[sg1, sg2..]', this can reduce the size of RPC respose message from neu

Re: [openstack-dev] [Horizon] Nominations to Horizon Core

Thank you everyone, I'll do my best! 发自我的 iPhone > 在 Jul 1, 2014，22:37，"Lyle, David" 写道： > > Welcome Zhenguo and Ana to Horizon core. > > David > > >> On 6/20/14, 3:17 PM, "Lyle, David" wrote: >> >> I would like to nominate Zhenguo Niu and Ana Krivokapic to Horizon core. >> >> Zhenguo has

Re: [openstack-dev] [heat] One more lifecycle plug point - in scaling groups

Zane, If you happen to have a link to this blueprint, could you reply with it? I took a look, but did not find it. I’d like to suggest that the implementation allow apps to call unauthenticated (signed) webhook URLs in order to trigger a scale up/down event within a scaling group. This is abou

[openstack-dev] [neutron] Timeline for the remainder of Juno

All: I've updated the Neutron Juno Project Plan [1] page with a timeline for the remainder of Juno. Similar to Nova, we're going to participate in both Spec Proposal Deadline (SPD) and Spec Approval Deadline (SAD). The dates are listed on the wiki, but since these are new, I'm calling them out her

Re: [openstack-dev] [Keystone] HTTP Get and HEAD requests mismatch on resulting HTTP status (proposed REST API Response Status Changes)

Wearing my HTTP fanatic hat - I think this is actually an important change to do. Skew like this can cause all sorts of odd behaviours in client libraries. -Rob On 2 July 2014 13:13, Morgan Fainberg wrote: > In the endeavor to move from the default deployment of Keystone being > eventlet (in de

[openstack-dev] [Horizon] Custom Gerrit Dashboard for Juno-2

Heya, I was trying to help with the Horizon Juno-2 reviews, and found the launchpad link (https://launchpad.net/horizon/+milestone/juno-2) a bit unhelpful in figuring out which items actually need reviews, as some of the items marked 'Needs Code Review' are works in progress, or already reviewe

Re: [openstack-dev] [Keystone] HTTP Get and HEAD requests mismatch on resulting HTTP status (proposed REST API Response Status Changes)

On 07/01/2014 07:48 PM, Robert Collins wrote: > Wearing my HTTP fanatic hat - I think this is actually an important > change to do. Skew like this can cause all sorts of odd behaviours in > client libraries. +1. The current behavior of inconsistent response codes between the two recommended met

Re: [openstack-dev] [third-party] - rebasing patches for CI

It could be that it this behavior has merely become more noticeable since Jenkins is now reverifying patch sets when new comments show up and it sees that the patch set hasn't been verified recently. Carl On Tue, Jul 1, 2014 at 5:00 PM, Jeremy Stanley wrote: > On 2014-07-01 10:05:45 -0700 (-0700

  1   2   >