[openstack-dev] Tempest Testcases for ML2 Mechanism drivers - Help

Hi - With respect to writing test cases with Tempest for Neutron, I have a Freescale Mechanism Driver which support a Cloud Resource Discovery (CRD) Service . The complete data flow is show below. [cid:image001.png@01CF0BA3.7DB6CAE0] The FSL Mechanism driver partly depends on ML2 Plug-in (_p

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

On Wed, 2014-01-08 at 17:20 +1300, Robert Collins wrote: > On 8 January 2014 12:18, James Slagle wrote: > > Sure, the crux of the problem was likely that versions in the distro > > were too old and they needed to be updated. But unless we take on > > building the whole OS from source/git/whatever

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

Excerpts from Fox, Kevin M's message of 2014-01-07 16:27:35 -0800: > Another piece to the conversation I think is update philosophy. If > you are always going to require a new image and no customization after > build ever, ever, the messiness that source usually cause in the file > system image rea

Re: [openstack-dev] [Solum] Devstack gate is failing

On Wed, Jan 8, 2014 at 9:43 AM, Georgy Okrokvertskhov wrote: > Should we rather revert patch to make gate working? > I think it is always good to have test packages reside in test-requirements.txt. So -1 on reverting that patch. Here [1] is a temporary solution. Regards, Noorul [1] https://rev

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

On 8 January 2014 12:18, James Slagle wrote: > I'm reminded of when I first started looking at TripleO there were a > few issues with installing from git (I'll say that from now on :) > related to all the python distribute -> setuptools migration. Things > like if you're base cloud image had the

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

On 8 January 2014 09:23, Clint Byrum wrote: > What would be the benefit of using packages? - Defense in depth - tests at the package build time + tests of the image. - Enumeration of installed software using the admins expected tooling (dpkg / rpm etc) - Familiarity > We've specifically avoided

Re: [openstack-dev] [Openstack][Nova][Docker] Devstack with docker driver

Let me know in case I can be of any help getting this resolved. Best Regards, Swapnil On Wed, Jan 8, 2014 at 12:38 AM, Eric Windisch wrote: > On Tue, Jan 7, 2014 at 1:16 AM, Swapnil Kulkarni < > swapnilkulkarni2...@gmail.com> wrote: > >> Thanks Eric. >> >> I had already tried the solution pres

Re: [openstack-dev] [Solum] Devstack gate is failing

Should we rather revert patch to make gate working? Thanks Georgy On Tue, Jan 7, 2014 at 7:19 PM, Murali Allada wrote: > I'm ok with making this non-voting for Solum until this gets fixed. > > -Murali > > > On Jan 7, 2014, at 8:53 PM, Noorul Islam Kamal Malmiyoda < > noo...@noorul.com> wrote: >

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

On 8 January 2014 12:26, Fox, Kevin M wrote: > One of the major features using a distro over upstream gives is integration. > rhel6 behaves differently then ubuntu 13.10. Sometimes it takes a while to > fix upstream for a given distro, and even then it may not even be accepted > because "the dis

Re: [openstack-dev] [Solum] Devstack gate is failing

I'm ok with making this non-voting for Solum until this gets fixed. -Murali On Jan 7, 2014, at 8:53 PM, Noorul Islam Kamal Malmiyoda wrote: > Hi team, > > After merging [1] devstack gate started failing. There is already a > thread [2] related to this in mailing list. Until this gets fixed >

[openstack-dev] [Solum] Devstack gate is failing

Hi team, After merging [1] devstack gate started failing. There is already a thread [2] related to this in mailing list. Until this gets fixed shall we make this job non-voting? Regards, Noorul [1] https://review.openstack.org/64226 [2] http://www.mail-archive.com/openstack-dev@lists.openstack.o

Re: [openstack-dev] [Neutron][qa] Parallel testing update

Mathieu, Thank you for clarification. I'll take a look at the patches. On Tue, Jan 07, 2014 at 02:34:24PM +0100, Salvatore Orlando wrote: > Thanks Mathieu! > > I think we should first merge Edouard's patch, which appears to be a > prerequisite. > I think we could benefit a lot by applying this

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

Excerpts from James Slagle's message of 2014-01-07 15:18:00 -0800: > On Tue, Jan 7, 2014 at 6:04 PM, Clint Byrum wrote: > > Excerpts from Chris Jones's message of 2014-01-07 14:43:31 -0800: > >> Hi > >> > >> > On 7 Jan 2014, at 22:18, Clint Byrum wrote: > >> > Packages do the opposite, > >> > and

[openstack-dev] [Nova][Vmware]Bad Performance when creating a new VM

Stackers, I tried to create a new VM using the driver VMwareVCDriver, but I found it's very slow when I try to create a new VM, for example, 7GB Windows Image spent 3 hours. Then I tried to use curl to upload a iso to vcenter directly. curl -H "Expect:" -v --insecure --upload-file windows2012_ser

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

On Tue, Jan 7, 2014 at 6:45 PM, Clint Byrum wrote: > Excerpts from James Slagle's message of 2014-01-07 15:03:33 -0800: >> On Tue, Jan 7, 2014 at 5:18 PM, Clint Byrum wrote: >> > Excerpts from James Slagle's message of 2014-01-07 12:53:57 -0800: >> >> On Tue, Jan 7, 2014 at 3:23 PM, Clint Byrum

Re: [openstack-dev] [Neutron][qa]API testing update

Hi Miguel, As I am using neutron API tempest tests, I notice that in the create_port tests, the port context is set partially - i.e. only network Id is available. ML2 drivers expect more in formation in the port context in order to test the API on the back-ends. I noticed such an enhancement is n

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

Another piece to the conversation I think is update philosophy. If you are always going to require a new image and no customization after build ever, ever, the messiness that source usually cause in the file system image really doesn't matter. The package system allows you to easily update, add,

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

- Original Message - > From: "Clint Byrum" > To: "openstack-dev" > Sent: Tuesday, January 7, 2014 3:23:24 PM > Subject: Re: [openstack-dev] [TripleO] Installing from packages in > tripleo-image-elements > > What would be the benefit of using packages? > > We've specifically avoide

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

Hi > On 7 Jan 2014, at 23:04, Clint Byrum wrote: > > My question still stands, what are the real advantages? So far the only > one that matters to me is "makes it easier for people to think about > using it." If I were to put on my former sysadmin hat, I would always strongly prefer to use pac

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

- Original Message - > From: "James Slagle" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Tuesday, January 7, 2014 3:53:57 PM > Subject: Re: [openstack-dev] [TripleO] Installing from packages in > tripleo-image-elements > > On Tue, Jan 7, 2014 at 3

Re: [openstack-dev] [elastic-recheck] Thoughts on next steps

On 01/07/2014 06:44 PM, Matt Riedemann wrote: On 1/7/2014 5:26 PM, Sean Dague wrote: On 01/07/2014 06:20 PM, Matt Riedemann wrote: On 1/2/2014 8:29 PM, Sean Dague wrote: A lot of elastic recheck this fall has been based on the ad hoc needs of the moment, in between diving down into the rac

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

- Original Message - > From: "James Slagle" > To: "OpenStack Development Mailing List" > Sent: Tuesday, January 7, 2014 3:01:07 PM > Subject: [openstack-dev] [TripleO] Installing from packages in > tripleo-image-elements > > Hi, > > I'd like to discuss some possible ways we co

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

On Tue, Jan 7, 2014 at 6:12 PM, Clint Byrum wrote: > Excerpts from Fox, Kevin M's message of 2014-01-07 13:11:13 -0800: >> I was going to stay silent on this one, but since you asked... >> >> /me puts his customer hat on >> >> We source OpenStack from RDO for the packages and additional integratio

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

Excerpts from James Slagle's message of 2014-01-07 15:03:33 -0800: > On Tue, Jan 7, 2014 at 5:18 PM, Clint Byrum wrote: > > Excerpts from James Slagle's message of 2014-01-07 12:53:57 -0800: > >> On Tue, Jan 7, 2014 at 3:23 PM, Clint Byrum wrote: > >> > What would be the benefit of using packages

Re: [openstack-dev] [elastic-recheck] Thoughts on next steps

On 1/7/2014 5:26 PM, Sean Dague wrote: On 01/07/2014 06:20 PM, Matt Riedemann wrote: On 1/2/2014 8:29 PM, Sean Dague wrote: A lot of elastic recheck this fall has been based on the ad hoc needs of the moment, in between diving down into the race bugs that were uncovered by it. This week awa

Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

On 01/08/2014 03:10 AM, Nachi Ueno wrote: > Hi Anita > > Let's me join this session also. > > Nachi Ueno > NTT i3 Wonderful Nachi. We have spoken on irc to ensure you have your questions answered. It will be great to have another neutron-core at the code sprint. Thank you, Anita. > > 2014/1/5

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

One of the major features using a distro over upstream gives is integration. rhel6 behaves differently then ubuntu 13.10. Sometimes it takes a while to fix upstream for a given distro, and even then it may not even be accepted because "the distro's too old, go away". Packages allow a distro to ma

Re: [openstack-dev] [elastic-recheck] Thoughts on next steps

On 01/07/2014 06:20 PM, Matt Riedemann wrote: On 1/2/2014 8:29 PM, Sean Dague wrote: A lot of elastic recheck this fall has been based on the ad hoc needs of the moment, in between diving down into the race bugs that were uncovered by it. This week away from it all helped provide a little pers

Re: [openstack-dev] [elastic-recheck] Thoughts on next steps

On 1/2/2014 8:29 PM, Sean Dague wrote: A lot of elastic recheck this fall has been based on the ad hoc needs of the moment, in between diving down into the race bugs that were uncovered by it. This week away from it all helped provide a little perspective on what I think we need to do to call i

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

On Tue, Jan 7, 2014 at 6:04 PM, Clint Byrum wrote: > Excerpts from Chris Jones's message of 2014-01-07 14:43:31 -0800: >> Hi >> >> > On 7 Jan 2014, at 22:18, Clint Byrum wrote: >> > Packages do the opposite, >> > and encourage entropy by promising to try and update software >> >> Building with pa

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

Excerpts from Fox, Kevin M's message of 2014-01-07 13:11:13 -0800: > I was going to stay silent on this one, but since you asked... > > /me puts his customer hat on > > We source OpenStack from RDO for the packages and additional integration > testing that comes from the project instead of using

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

Excerpts from Chris Jones's message of 2014-01-07 14:43:31 -0800: > Hi > > > On 7 Jan 2014, at 22:18, Clint Byrum wrote: > > Packages do the opposite, > > and encourage entropy by promising to try and update software > > Building with packages doesn't require updating running systems with packa

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

On Tue, Jan 7, 2014 at 5:18 PM, Clint Byrum wrote: > Excerpts from James Slagle's message of 2014-01-07 12:53:57 -0800: >> On Tue, Jan 7, 2014 at 3:23 PM, Clint Byrum wrote: >> > What would be the benefit of using packages? >> >> We're building images on top of different distributions of Linux. >

Re: [openstack-dev] [nova] Bogus -1 scores from turbo hipster

Hi. Thanks for reaching out about this. It seems this patch has now passed turbo hipster, so I am going to treat this as a more theoretical question than perhaps you intended. I should note though that Joshua Hesketh and I have been trying to read / triage every turbo hipster failure, but that has

Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer

For multi-node deployments, implementing something like inotify would allow administrators to push configuration changes out to multiple targets using puppet/chef/etc. and have the daemons pick it up without restart. Thumbs up to that. As Tim Bell suggested, API-based enabling/disabling would a

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

Hi > On 7 Jan 2014, at 22:18, Clint Byrum wrote: > Packages do the opposite, > and encourage entropy by promising to try and update software Building with packages doesn't require updating running systems with packages and more than building with git requires updating running systems with git

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

Hi > On 7 Jan 2014, at 21:17, James Slagle wrote: > > Could you expand on this a bit? I'm not sure what inconsistency > you're referring to. That multiple repos work, but the docs don't say so, and the DIB_REPO foo doesn't support multiple repos. > I wonder if we could have a global build o

Re: [openstack-dev] [Solum][Pecan][Security] Pecan SecureController vs. Nova policy

You might also consider doing this in WSGI middleware: Pros: * Consolidates policy code in once place, making it easier to audit and maintain * Simple to turn policy on/off – just don’t insert the middleware when off! * Does not preclude the use of oslo.policy for rule checking *

Re: [openstack-dev] [Tempest][Solum] Writing functional tests in tempest style

Hi Jay, Thank you very much for working on that! Thanks Georgy On Tue, Jan 7, 2014 at 12:50 PM, Jay Pipes wrote: > On Mon, 2014-01-06 at 11:46 -0800, Georgy Okrokvertskhov wrote: > > > Thank you for your input. Right now this approach allows to run > > integration tests with and without tempe

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

Excerpts from James Slagle's message of 2014-01-07 12:53:57 -0800: > On Tue, Jan 7, 2014 at 3:23 PM, Clint Byrum wrote: > > What would be the benefit of using packages? > > We're building images on top of different distributions of Linux. > Those distributions themselves offer packaged and suppor

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

On Tue, Jan 7, 2014 at 3:48 PM, Chris Jones wrote: > Hi > > Assuming we want to do this, but not necessarily agreeing that we do want to, > I would suggest: > > 1) I think it would be nice if we could avoid separate dpkg/rpm types by > having a package type and reusing the package map facility.

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

I was going to stay silent on this one, but since you asked... /me puts his customer hat on We source OpenStack from RDO for the packages and additional integration testing that comes from the project instead of using OpenStack directly. I was a little turned off from Triple-O when I saw it was

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

Hi (FWIW I suggested using the element arguments like "nova/package" to avoid a huge and crazy environment by using DIB_REPO foo for every element) Cheers, -- Chris Jones > On 7 Jan 2014, at 20:32, James Slagle wrote: > >> On Tue, Jan 7, 2014 at 3:22 PM, Fox, Kevin M wrote: >> Sounds very u

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

On Tue, Jan 7, 2014 at 3:23 PM, Clint Byrum wrote: > What would be the benefit of using packages? We're building images on top of different distributions of Linux. Those distributions themselves offer packaged and supported OpenStack components. So, one benefit is that you'd be using what's "ble

Re: [openstack-dev] [Tempest][Solum] Writing functional tests in tempest style

On Mon, 2014-01-06 at 11:46 -0800, Georgy Okrokvertskhov wrote: > Thank you for your input. Right now this approach allows to run > integration tests with and without tempest. I think this is valuable > for the project as anyone can run integration tests on their laptop > having only keystone avai

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

Hi Assuming we want to do this, but not necessarily agreeing that we do want to, I would suggest: 1) I think it would be nice if we could avoid separate dpkg/rpm types by having a package type and reusing the package map facility. 2) Clear up the source-repositories inconsistency by making it

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

Hi My guess for the easiest answer to that: distro vendor support. Cheers, -- Chris Jones > On 7 Jan 2014, at 20:23, Clint Byrum wrote: > > What would be the benefit of using packages? > > We've specifically avoided packages because they complect[1] configuration > and system state management

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

On Tue, Jan 7, 2014 at 3:22 PM, Fox, Kevin M wrote: > Sounds very useful. Would there be a diskimage-builder flag then to say you > prefer packages over source? Would it fall back to source if you specified > packages and there were only source-install.d for a given element? Yes, you could pick

Re: [openstack-dev] [nova] Change I005e752c: Whitelist external netaddr requirement, for bug 1266513, ineffective for me

On 1/6/2014 8:55 PM, Sean Dague wrote: On 01/06/2014 09:33 PM, Mike Spreitzer wrote: I am suffering from bug 1266513, when trying to work on nova. For example, on MacOS 10.8.5, I clone nova and then (following the instructions at https://wiki.openstack.org/wiki/DependsOnOSX) run `cd nova; pyt

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

What would be the benefit of using packages? We've specifically avoided packages because they complect[1] configuration and system state management with software delivery. The recent friction we've seen with MySQL is an example where the packages are not actually helping us, they're hurting us bec

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

Sounds very useful. Would there be a diskimage-builder flag then to say you prefer packages over source? Would it fall back to source if you specified packages and there were only source-install.d for a given element? Thanks, Kevin From: James Slagle [jam

Re: [openstack-dev] [elastic-recheck] Thoughts on next steps

Everything sounds good! On Mon, Jan 6, 2014 at 6:52 PM, Sean Dague wrote: > On 01/06/2014 07:04 PM, Joe Gordon wrote: > >> Overall this looks really good, and very spot on. >> >> >> On Thu, Jan 2, 2014 at 6:29 PM, Sean Dague > > wrote: >> >> A lot of elastic recheck t

[openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

Hi, I'd like to discuss some possible ways we could install the OpenStack components from packages in tripleo-image-elements. As most folks are probably aware, there is a "fork" of tripleo-image-elements called tripleo-puppet-elements which does install using packages, but it does so using Puppet

Re: [openstack-dev] [Ceilometer] Sharing the load test result

On Mon, 2014-01-06 at 00:14 +, Deok-June Yi wrote: > Hi, Ceilometer team. > > I'm writing to share my load test result and ask you for advice about > Ceilometer. > > Before starting, for whom doesn’t know Synaps [1], Synaps is > 'monitoring as a service' project that provides AWS CloudWatch >

Re: [openstack-dev] [heat] Sofware Config progress

I'd say it isn't so much cloud-init that you need, but "some kind of bootstrapper". The point of hot-software-config is to help with in-instance orchestration. That's not going to happen without some way to push the desired configuration into the instance. Excerpts from Susaant Kondapaneni's messa

Re: [openstack-dev] [keystone] Changes to keystone-core!

Sounds like a good decision all around. Cleaning out -core lists seems to be the hip thing to do lately. ;-) All the best, - Gabriel From: Dolph Mathews [mailto:dolph.math...@gmail.com] Sent: Tuesday, January 07, 2014 11:16 AM To: OpenStack Development Mailing List Cc: Steve Martinel

Re: [openstack-dev] [heat] Sofware Config progress

We work with images provided by vendors over which we do not always have control. So we are considering the cases where vendor image does not come installed with cloud-init. Is there a way to support heat software config in such scenarios? Thanks Susaant On Mon, Jan 6, 2014 at 4:47 PM, Steve Bak

[openstack-dev] [keystone] Changes to keystone-core!

Hello everyone! We've been talking this for a long while, and we finally have a bunch of changes to make to keystone-core all at once. A few people have moved on, the project has grown a bit, and our review queue grows ever longer. As ayoung phrased it in today's keystone meeting, with entirely se

Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

Hi Anita Let's me join this session also. Nachi Ueno NTT i3 2014/1/5 Anita Kuno : > On 01/05/2014 03:42 AM, Sukhdev Kapur wrote: >> Folks, >> >> I finally got over my fear of weather and booked my flight and hotel for >> this sprint. >> >> I am relatively new to OpenStack community with a strong

Re: [openstack-dev] [Openstack][Nova][Docker] Devstack with docker driver

On Tue, Jan 7, 2014 at 1:16 AM, Swapnil Kulkarni < swapnilkulkarni2...@gmail.com> wrote: > Thanks Eric. > > I had already tried the solution presented on ask.openstack.org. > It was worth a shot. I also found a bug [1] and applied code changes in [2], but to no success. Ah. I hadn't seen that

Re: [openstack-dev] olso.config error on running Devstack

On 01/07/2014 01:44 PM, Ben Nemec wrote: > On 2014-01-07 12:11, Noorul Islam Kamal Malmiyoda wrote: >> On Tue, Jan 7, 2014 at 4:54 PM, Michael Kerrin >> wrote: >>> I have been seeing this problem also. >>> >>> >>> >>> My problem is actually with oslo.sphinx. I ran sudo pip install -r >>> test-requ

Re: [openstack-dev] olso.config error on running Devstack

On 2014-01-07 12:11, Noorul Islam Kamal Malmiyoda wrote: On Tue, Jan 7, 2014 at 4:54 PM, Michael Kerrin wrote: I have been seeing this problem also. My problem is actually with oslo.sphinx. I ran sudo pip install -r test-requirements.txt in cinder so that I could run the tests there, which

Re: [openstack-dev] olso.config error on running Devstack

On Tue, Jan 7, 2014 at 4:54 PM, Michael Kerrin wrote: > I have been seeing this problem also. > > > > My problem is actually with oslo.sphinx. I ran sudo pip install -r > test-requirements.txt in cinder so that I could run the tests there, which > installed oslo.sphinx. > > > > Strange thing is th

Re: [openstack-dev] [nova] Bogus -1 scores from turbo hipster

On 12/30/2013 6:21 AM, Michael Still wrote: Hi. The purpose of this email to is apologise for some incorrect -1 review scores which turbo hipster sent out today. I think its important when a third party testing tool is new to not have flakey results as people learn to trust the tool, so I want

Re: [openstack-dev] olso.config error on running Devstack

On 2014-01-07 07:16, Doug Hellmann wrote: > On Tue, Jan 7, 2014 at 6:24 AM, Michael Kerrin wrote: > >> I have been seeing this problem also. >> >> My problem is actually with oslo.sphinx. I ran sudo pip install -r >> test-requirements.txt in cinder so that I could run the tests there, whi

Re: [openstack-dev] [nova] minimum review period for functional changes that break backwards compatibility

+1 from me too UpgradeImpact is a much better term. Tim > -Original Message- > From: Jay Pipes [mailto:jaypi...@gmail.com] > Sent: 07 January 2014 17:53 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [nova] minimum review period for functional > changes that b

Re: [openstack-dev] Keystone Hashing MD5 to SHA256

On Tue, Jan 7, 2014 at 11:01 AM, Adam Young wrote: > On 01/06/2014 01:10 PM, Jeremy Stanley wrote: > >> On 2014-01-06 10:19:39 -0500 (-0500), Adam Young wrote: >> >>> If it were as easy as just replaceing hteh hash algorithm, we >>> would have done it a year + ago. I'm guessing you figured that

Re: [openstack-dev] Keystone Hashing MD5 to SHA256

On 01/06/2014 01:10 PM, Jeremy Stanley wrote: On 2014-01-06 10:19:39 -0500 (-0500), Adam Young wrote: If it were as easy as just replaceing hteh hash algorithm, we would have done it a year + ago. I'm guessing you figured that by now. [...] With the lack of In-Reply-To header and not finding

Re: [openstack-dev] [nova] minimum review period for functional changes that break backwards compatibility

On Tue, 2014-01-07 at 11:04 +0100, Thierry Carrez wrote: > Matt Riedemann wrote: > > There is discussion in this thread about "wouldn't it be nice to have a > > tag on commits for changes that impact upgrades?". There is. > > > > http://lists.openstack.org/pipermail/openstack-dev/2013-October/016

Re: [openstack-dev] coding standards question

So it turns out that trove just has this rule disabled. At least I now know more about how this stuff works, I guess. Sorry for the confusion. Greg On Jan 7, 2014, at 9:54 AM, Sean Dague wrote: > On 01/07/2014 10:19 AM, Greg Hill wrote: >> Thanks Sean. I'll work on adding this one to the ha

Re: [openstack-dev] [Fuel] Error when compiling nailgun

Hi Kevein the development setup docs are at http://docs.mirantis.com/fuel-dev/develop/env.html (although they could be slightly stale). The gist of it is that for nailgun, you need to install all of the packages in nailgun/requirements.txt (pip install -r requirements.txt) this should set you up p

[openstack-dev] [Neutron][IPv6] Meeting time - now Tuesdays at 1400 UTC in #openstack-meeting

The 1500 UTC time conflicts with Marconi, although the time was not listed on the Meetings wikipage. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] coding standards question

On 01/07/2014 10:19 AM, Greg Hill wrote: > Thanks Sean. I'll work on adding this one to the hacking repo. That brings > up another question, though, what are the implications of suddenly enforcing > a rule that wasn't previously enforced? I know there are at least 30 other > violations of thi

Re: [openstack-dev] coding standards question

Yes, you turn it off. Once the change to enforce this rule is merged into hacking, other projects can start refresh their hacking dependency (e.g. upgrading to latest version). The patch to update the dependency has to turn the newly added check off and then consecutive patches can fix all violat

Re: [openstack-dev] coding standards question

Thanks Sean. I'll work on adding this one to the hacking repo. That brings up another question, though, what are the implications of suddenly enforcing a rule that wasn't previously enforced? I know there are at least 30 other violations of this rule just within trove, and I imagine larger pr

[openstack-dev] NVP patch breaks Neutron install on Windows

Hi guys, This patch breaks “setup.py install” on Windows due to the usage on symbolic links: https://review.openstack.org/#/c/64747/ error: can't copy 'etc\neutron\plugins\nicira\nvp.ini': doesn't exist or not a regular file I filed up a bug here: https://bugs.launchpad.net/neutron/+bug/126679

Re: [openstack-dev] coding standards question

On 01/07/2014 09:26 AM, Greg Hill wrote: I got a -1 on a review for a standards violation that isn't caught by the automated checks, so I was wondering why the automated check doesn't catch it. The violation was: from X import Y, Z According to the coding standards page on the openstack wiki,

Re: [openstack-dev] [Neutron][IPv6] Several topics for tomorrow's meeting

I will make sure to add these items to the agenda. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] minimum review period for functional changes that break backwards compatibility

Day, Phil wrote: > Would be nice in this specific example though if the actual upgrade impact > was explicitly called out in the commit message. Yes, UpgradeImpact should definitely also elaborate on the exact impact, rather than expect the reviewer to deduce it from the patch. > [...] > So it l

[openstack-dev] coding standards question

I got a -1 on a review for a standards violation that isn't caught by the automated checks, so I was wondering why the automated check doesn't catch it. The violation was: from X import Y, Z According to the coding standards page on the openstack wiki, the coding standards are PEP8 (they just

Re: [openstack-dev] [nova] where to expose network quota

On Mon, Jan 6, 2014 at 4:47 PM, Yaguang Tang wrote: > Hi all, > > Now Neutron has its own quota management API for network related > items(floating ips, security groups .etc) which are also manged by Nova. > when using nova with neutron as network service, the network related quota > items are st

[openstack-dev] [Fuel] Error when compiling nailgun

Greetings! I'm compiling one of the Fuel components, which named nailgun. Before build it, I need to create the database, but it shows the following error: ~~~ 2014-01-07 21:38:23.653 INFO [7fdbe5f30700] (manage) Syncing database... Traceback (most recent call last): File "./manage.py", line 1

Re: [openstack-dev] [Nova] libvirt unit test errors

On Tue, Jan 7, 2014 at 2:28 PM, Gary Kotton wrote: > 2014-01-07 > 11:59:47.428| > Requirement already satisfied (use --upgrade to upgrade): markupsafe in > ./.tox/py27/lib/python2.7/site

Re: [openstack-dev] [Nova] libvirt unit test errors

Gary, Please search email with title as "[openstack-dev] [nova][infra] nova py27 unit test failures in libvirt", a bug has been filed for this: https://bugs.launchpad.net/nova/+bug/1266711 Thanks, Jay 2014/1/7 Gary Kotton > Hi, > Anyone aware of the following: > > 2014-01-07 11:59:47.428 >

Re: [openstack-dev] [Nova] libvirt unit test errors

Hi Gray, This problem is https://bugs.launchpad.net/nova/+bug/1266711 . The thread is http://lists.openstack.org/pipermail/openstack-dev/2014-January/023575.html . Thanks Ken'ichi Ohmichi --- > -Original Message- > From: Gary Kotton [mailto:gkot...@vmware.com] > Sent: Tuesday, Januar

Re: [openstack-dev] [Nova] libvirt unit test errors

Yes, please see the email thread "nova py27 unit test failures in libvirt" from 4 hrs ago. :) -Sean On 01/07/2014 08:28 AM, Gary Kotton wrote: > Hi, > Anyone aware of the following: > > 2014-01-07 11:59:47.428 >

Re: [openstack-dev] [Neutron][qa] Parallel testing update

Thanks Mathieu! I think we should first merge Edouard's patch, which appears to be a prerequisite. I think we could benefit a lot by applying this mechanism to process_network_ports. However, I am not sure if there could be drawbacks arising from the fact that the agent would assign the local VLA

[openstack-dev] [Nova] libvirt unit test errors

Hi, Anyone aware of the following: 2014-01-07 11:59:47.428 | Requirement already satisfied (use --upgrade to upgrade): markupsafe in ./.tox/py27/lib/python2.7/site-packages (from Jinja2

Re: [openstack-dev] olso.config error on running Devstack

On Tue, Jan 7, 2014 at 6:24 AM, Michael Kerrin wrote: > I have been seeing this problem also. > > > > My problem is actually with oslo.sphinx. I ran sudo pip install -r > test-requirements.txt in cinder so that I could run the tests there, which > installed oslo.sphinx. > > > > Strange thing is t

Re: [openstack-dev] [Neutron][qa] Parallel testing update

I think that isaku is talking about a more intensive usage of defer_apply_on/off as it is done in the patch of gongysh [1]. Isaku, i don't see any reason why this could not be done in precess_network_ports, if needed. Moreover the patch from edouard [2] resolves multithreading issues while precess

[openstack-dev] [nova][neutron][ipv6]Hairpinning in libvirt, once more

See Sean Collins' review https://review.openstack.org/#/c/56381 which disables hairpinning when Neutron is in use. tl;dr - please upvote the review. Long form reasoning follows... There's a solid logical reason for enabling hairpinning, but it only applies to nova-network. Hairpinning is used i

Re: [openstack-dev] [Solum][Pecan][Security] Pecan SecureController vs. Nova policy

On Mon, Jan 6, 2014 at 6:26 PM, Georgy Okrokvertskhov < gokrokvertsk...@mirantis.com> wrote: > Hi Dough, > > Thank you for pointing to this code. As I see you use OpenStack policy > framework but not Pecan security features. How do you implement fine grain > access control like user allowed to rea

Re: [openstack-dev] [requirements] - taskflow preventing sqla 0.8 upgrade

On Mon, Jan 6, 2014 at 6:21 PM, Jeremy Stanley wrote: > On 2014-01-06 17:23:31 -0500 (-0500), Doug Hellmann wrote: > [...] > > The global requirements syncing seems to have fixed the issue for > > apps, although it just occurred to me that I'm not sure we check > > that the requirements lists are

Re: [openstack-dev] [Nova][BluePrint Register]Shrink the volume when file in the instance was deleted.

> On 25 December 2013 05:14, Qixiaozhen wrote: > > Hi,all > > > > A blueprint is registered that is about shrinking the volume in thin > > provision. > > Have you got the link? The address is https://blueprints.launchpad.net/nova/+spec/shrink-volume-in-thin-provisoning > > > Thin provision m

Re: [openstack-dev] [Neutron] Availability of external testing logs

My problem seem to be the same as reported here: https://bitbucket.org/pypa/setuptools/issue/129/assertionerror-egg-info-pkg-info-is-not-a Not quite shure however how to bring in the fix into my setup. Cheers, Tobbe On 2014-01-07 10:38, Torbjorn Tornkvist wrote: Hi, Sorry for the problems. I

Re: [openstack-dev] [nova][infra] nova py27 unit test failures in libvirt

This looks like it's a 100% failure bug at this point. I expect that because of timing it's based on a change in the base image due to nodepool rebuilding. -Sean On 01/07/2014 06:56 AM, Jay Lau wrote: A bug was filed: https://bugs.launchpad.net/nova/+bug/1266711 Thanks, Jay 2014/1

Re: [openstack-dev] [nova][infra] nova py27 unit test failures in libvirt

A bug was filed: https://bugs.launchpad.net/nova/+bug/1266711 Thanks, Jay 2014/1/7 Lu, Lianhao > Hi guys, > > This afternoon I suddenly find that there are quite a lot of nova py27 > unit test failures on Jenkins, like > http://logs.openstack.org/15/62815/5/gate/gate-nova-python27/82d5d52/con

Re: [openstack-dev] olso.config error on running Devstack

I have been seeing this problem also. My problem is actually with oslo.sphinx. I ran sudo pip install -r test-requirements.txt in cinder so that I could run the tests there, which installed oslo.sphinx. Strange thing is that the oslo.sphinx installed a directory called oslo in /usr/local/lib/

Re: [openstack-dev] [nova] minimum review period for functional changes that break backwards compatibility

Would be nice in this specific example though if the actual upgrade impact was explicitly called out in the commit message. >From the DocImpact it looks as if some Neutron config options are changing >names - in which case the impact would seem to be that running systems have >until the end of

Re: [openstack-dev] [DevStack] Nominate Chmouel Boudjnah for core team

+1 On 1/6/14 7:55 PM, "Florent Flament" wrote: >+1 > >- Original Message - >From: "Sean Dague" >To: "OpenStack Development Mailing List (not for usage questions)" > >Sent: Monday, January 6, 2014 5:30:09 PM >Subject: Re: [openstack-dev] [DevStack] Nominate Chmouel Boudjnah for >core tea

  1   2   >