Re: [openstack-dev] [all] The future of the integrated release

Excerpts from Michael Chapman's message of 2014-08-21 23:30:44 -0700: > On Fri, Aug 22, 2014 at 2:57 AM, Jay Pipes wrote: > > > On 08/19/2014 11:28 PM, Robert Collins wrote: > > > >> On 20 August 2014 02:37, Jay Pipes wrote: > >> ... > >> > >> I'd like to see more unification of implementations

Re: [openstack-dev] [ceilometer] repackage ceilometer and ceilometerclient

But I'm not sure the real problem to move the modules. My understanding is - the ceilometer package has dependency with ceilometerclient so it is easy to move them - all callers for using the moved modules must change paths. The modules you are talking about are part of Ceilometer's core fun

Re: [openstack-dev] [Fuel] Use lrzip for upgrade tarball - reject?

On 21 August 2014 18:47, Sergii Golovatiuk wrote: > I think 15 minutes is not too bad. Additionally, it will reduce download > time and price for bandwidth. It's worth to leave lrzip for customers, as > upgrade is one time operation so user can wait for a while. For development > it would be nice

Re: [openstack-dev] [TripleO][Ironic] Unique way to get a registered machine?

Hi When register-nodes blows up, is the error we get from Ironic sufficiently unique that we can just consume it and move on? I'm all for making the API more powerful wrt inspecting the current setup, but I also like idempotency :) Cheers, -- Chris Jones > On 22 Aug 2014, at 07:32, Steve Kowa

Re: [openstack-dev] [Glance][Heat] Murano split dsicussion

On 08/20/2014 10:14 PM, Georgy Okrokvertskhov wrote: > During last Atlanta summit there were couple discussions about > Application Catalog and Application space projects in OpenStack. These > cross-project discussions occurred as a result of Murano incubation > request [1] during Icehouse cycle.

Re: [openstack-dev] [TripleO][Ironic] Unique way to get a registered machine?

On 22/08/14 17:35, Chris Jones wrote: Hi When register-nodes blows up, is the error we get from Ironic sufficiently unique that we can just consume it and move on? I'm all for making the API more powerful wrt inspecting the current setup, but I also like idempotency :) If the master nodes l

Re: [openstack-dev] [TripleO][Ironic] Unique way to get a registered machine?

Hi Nice, sounds like a very good thing from an operator's perspective. Cheers, -- Chris Jones > On 22 Aug 2014, at 08:44, Steve Kowalik wrote: > >> On 22/08/14 17:35, Chris Jones wrote: >> Hi >> >> When register-nodes blows up, is the error we get from Ironic sufficiently >> unique that we

Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters

Thanks for your feedback. No, I do not yet have code for it. Just wanted to get a feeling if such a feature would get acceptance in the community. But if that helps I can sit down and start some prototyping while I'm preparing a blueprint spec in parallel. The main part of the implementation I

Re: [openstack-dev] [Fuel] Use lrzip for upgrade tarball - reject?

Dmitry, we already use lrzuntar in deploying Docker containers. Use a lower compression ratio and it will decompress faster on virtual envs and it takes under two mins on my virtual env. Compress: https://github.com/stackforge/fuel-main/blob/master/docker/module.mk#L27 Decompress: https://github.

Re: [openstack-dev] Thought on service plugin architecture (was [Neutron][QoS] Request to be considered for neutron-incubator)

+1 The agent number should be limited restrictly. On Thu, Aug 21, 2014 at 8:56 AM, loy wolfe wrote: > > > > On Wed, Aug 20, 2014 at 7:03 PM, Salvatore Orlando > wrote: > >> As the original thread had a completely different subject, I'm starting a >> new one here. >> >> More specifically the ai

Re: [openstack-dev] Criteria for giving a -1 in a review

On Thu, Aug 21, 2014 at 04:52:37PM -0500, Dolph Mathews wrote: > On Thu, Aug 21, 2014 at 11:53 AM, Daniel P. Berrange > wrote: > > > On Thu, Aug 21, 2014 at 11:34:48AM -0500, Dolph Mathews wrote: > > > On Thu, Aug 21, 2014 at 11:21 AM, Daniel P. Berrange < > > berra...@redhat.com> > > > wrote: >

Re: [openstack-dev] Adding GateFailureFix tag to commit messages

On Thu, Aug 21, 2014 at 09:02:17AM -0700, Armando M. wrote: > Hi folks, > > According to [1], we have ways to introduce external references to commit > messages. > > These are useful to mark certain patches and their relevance in the context > of documentation, upgrades, etc. > > I was wondering

Re: [openstack-dev] [Neutron][DevStack] How to increase developer usage of Neutron

Through my experience, RDO should be the most reliable way to do the deployment. Also, there're some more detailed installation scripts, like https://github.com/ChaimaGhribi/OpenStack-Icehouse-Installation/blob/master/OpenStack-Icehouse-Installation.rst . Still, I think, as a developer, it would b

Re: [openstack-dev] [Ceilometer][WSME] Sphinx failing sporadically because of wsme autodoc extension

Gordon, exactly. Moreover, I think percentage of failings is something close to the 15-20% of all the runs - sometimes it passes for the change, and next run on this exactly the same commit will be the failed for some reason. Thanks Dina On Thu, Aug 21, 2014 at 10:46 PM, gordon chung wrote: >

Re: [openstack-dev] [Fuel] Use lrzip for upgrade tarball - reject?

> I think 15 minutes is not too bad. Additionally, it will reduce download time and price for bandwidth. +1 But let's see if we can find some other solution still in 5.1 (hardlinks, whatever else), and we obviously need to seriously address it in next release. > Perhaps for 6 an option can be mad

Re: [openstack-dev] Criteria for giving a -1 in a review

On Thu, Aug 21, 2014 at 05:05:04PM +0100, Matthew Booth wrote: > "I would prefer that you didn't merge this." > > i.e. The project is better off without it. I'm not quite sure how you make that translation, I would interpret -2 as meaning the project would be better off without a change. FWIW, I

Re: [openstack-dev] Thought on service plugin architecture (was [Neutron][QoS] Request to be considered for neutron-incubator)

hi, On Wed, Aug 20, 2014 at 1:03 PM, Salvatore Orlando wrote: > As the original thread had a completely different subject, I'm starting a > new one here. > > More specifically the aim of this thread is about: > 1) Define when a service is best implemented with a service plugin or with a > ML2 dri

[openstack-dev] [oslo] Launchpad tracking of oslo projects

TL;DR: Let's create an Oslo projectgroup in Launchpad to track work across all Oslo libraries. In library projects, let's use milestones connected to published versions rather than the common milestones. Long version: As we graduate more Oslo libraries (which is awesome), tracking Oslo work in Lau

Re: [openstack-dev] Criteria for giving a -1 in a review

On Fri, Aug 22, 2014 at 10:49:51AM +0100, Steven Hardy wrote: > On Thu, Aug 21, 2014 at 05:05:04PM +0100, Matthew Booth wrote: > > I also think it's worth explicitly documenting a few things we > > might/should mention in a review, but which aren't a reason that the > > project would be better off

Re: [openstack-dev] [Fuel] Use lrzip for upgrade tarball - reject?

Mike, others, I believe Jesse was proposing an upgrade that downloads all the files separately on the Fuel Master itself. This is a move that we've gone away from since Fuel 2.0 because of intermittent issues with 3rd party mirrors. It's often better to consume 1 large file that has everything and

Re: [openstack-dev] [ceilometer] repackage ceilometer and ceilometerclient

On Friday, August 22, 2014 2:55 PM, Dean Troyer wrote: > As one data point, the keystone middleware (auth_token) was just recently > moved out of keystoneclient > and into its own repo, partially because it had dependencies that otherwise > were not required for > pure client installations. 

Re: [openstack-dev] [ceilometer] repackage ceilometer and ceilometerclient

On Friday, August 22, 2014 4:15 PM, Nejc Saje wrote: > The modules you are talking about are part of Ceilometer's core > functionality, we can't move them to a completely separate code-tree > that is meant only for client functionality. Thank you for the explanation! I understand your point of th

Re: [openstack-dev] [oslo] Launchpad tracking of oslo projects

Sounds like a good plan going forward @ttx. On Fri, Aug 22, 2014 at 5:59 AM, Thierry Carrez wrote: > TL;DR: > Let's create an Oslo projectgroup in Launchpad to track work across all > Oslo libraries. In library projects, let's use milestones connected to > published versions rather than the commo

Re: [openstack-dev] [oslo] Launchpad tracking of oslo projects

On 08/22/2014 11:59 AM, Thierry Carrez wrote: > TL;DR: > Let's create an Oslo projectgroup in Launchpad to track work across all > Oslo libraries. In library projects, let's use milestones connected to > published versions rather than the common milestones. > > Long version: > As we graduate more

Re: [openstack-dev] [all] The future of the integrated release

On 08/22/2014 01:30 AM, Michael Chapman wrote: > > > > On Fri, Aug 22, 2014 at 2:57 AM, Jay Pipes > wrote: > > On 08/19/2014 11:28 PM, Robert Collins wrote: > > On 20 August 2014 02:37, Jay Pipes > wrote: > ...

[openstack-dev] [glance] [infra] Glance review patterns and their impact on the gate

Earlier this week the freshness checks (the ones that required passing results within 24 hrs for a change to go into the gate) were removed to try to conserve nodes as we get to crunch time. The hopes were that review teams had enough handle on what when code in their program got into a state that

Re: [openstack-dev] [glance] [infra] Glance review patterns and their impact on the gate

On Fri, Aug 22, 2014 at 07:09:10AM -0500, Sean Dague wrote: > Earlier this week the freshness checks (the ones that required passing > results within 24 hrs for a change to go into the gate) were removed to > try to conserve nodes as we get to crunch time. The hopes were that > review teams had eno

[openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

Hi everyone, We all know being a project PTL is an extremely busy job. That's because in our structure the PTL is responsible for almost everything in a project: - Release management contact - Work prioritization - Keeping bugs under control - Communicate about work being planned or done - Make s

[openstack-dev] [all] new testtools breaking gate

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, this week is quite bumpy for unit testing in gate. First, it was upgrade to new 'tox' version that broke quite some branches. And today new testtools 0.9.36 were released and were caught by gate, which resulted in the following unit test fa

Re: [openstack-dev] [Glance][Heat] Murano split dsicussion

On Fri, Aug 22, 2014 at 4:53 PM, Clint Byrum wrote: > Excerpts from Angus Salkeld's message of 2014-08-21 20:14:12 -0700: > > On Fri, Aug 22, 2014 at 12:34 PM, Clint Byrum wrote: > > > > > Excerpts from Georgy Okrokvertskhov's message of 2014-08-20 13:14:28 > -0700: > > > > During last Atlanta s

[openstack-dev] StackTach.v3 - Screencasts ...

Hey y'all, We've started a screencast series on the StackTach.v3 dev efforts [1]. It's still early-days, so subscribe to the playlist for updates. The videos start with the StackTach/Ceilometer integration presentation at the Hong Kong summit, which is useful for background and motivation but t

Re: [openstack-dev] [all] new testtools breaking gate

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 UPD: probably pinning the version is really overkill here, and instead we should fix affected branches. Among them: Havana for neutron, Havana+Icehouse+Juno for Glance. Other projects may also be affected. For Neutron, it should be handled by the fo

Re: [openstack-dev] [Glance][Heat] Murano split dsicussion

On 21/08/14 04:30, Thierry Carrez wrote: Georgy Okrokvertskhov wrote: During last Atlanta summit there were couple discussions about Application Catalog and Application space projects in OpenStack. These cross-project discussions occurred as a result of Murano incubation request [1] during Iceho

Re: [openstack-dev] [all] new testtools breaking gate

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 [resending to include stable-maint.] UPD: probably pinning the version is really overkill here, and instead we should fix affected branches. Among them: Havana for neutron, Havana+Icehouse+Juno for Glance. Other projects may also be affected. For N

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On 08/22/2014 08:33 AM, Thierry Carrez wrote: > Hi everyone, > > We all know being a project PTL is an extremely busy job. That's because > in our structure the PTL is responsible for almost everything in a project: > > - Release management contact > - Work prioritization > - Keeping bugs under c

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On 08/22/2014 09:40 AM, Russell Bryant wrote: > Another area worth calling out is a gate czar. Having someone who > understands infra and QA quite well and is regularly on top of the > status of the project in the gate is helpful and quite important. Oops, you said this one, too. Anyway, +1. --

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On 08/22/2014 07:33 AM, Thierry Carrez wrote: > Hi everyone, > > We all know being a project PTL is an extremely busy job. That's because > in our structure the PTL is responsible for almost everything in a project: > > - Release management contact > - Work prioritization > - Keeping bugs under c

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On Fri, Aug 22, 2014 at 02:33:27PM +0200, Thierry Carrez wrote: > Hi everyone, > > We all know being a project PTL is an extremely busy job. That's because > in our structure the PTL is responsible for almost everything in a project: > > - Release management contact > - Work prioritization > - Ke

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On 08/22/2014 02:33 PM, Thierry Carrez wrote: > Hi everyone, > > We all know being a project PTL is an extremely busy job. That's because > in our structure the PTL is responsible for almost everything in a project: > > - Release management contact > - Work prioritization > - Keeping bugs under c

Re: [openstack-dev] [Neutron] Use public IP address as instance fixed IP

Thank you for your response. Could this be done naturally with Openstack neutron or have to be done manually outside neutron ? As we are expecting to orchestrate hundreds of NFV with all similar network configuration, programmability is another key element. On Thu, Aug 21, 2014 at 3:52 PM, Kevin

Re: [openstack-dev] [Ceilometer][WSME] Sphinx failing sporadically because of wsme autodoc extension

Hi, I couldn’t reproduce this issue either. I’ve tried on precise and on a fresh trusty too, everything worked fine… Cheers, Ildikó From: Dina Belova [mailto:dbel...@mirantis.com] Sent: Friday, August 22, 2014 11:40 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On 22/08/14 08:33, Thierry Carrez wrote: Hi everyone, We all know being a project PTL is an extremely busy job. That's because in our structure the PTL is responsible for almost everything in a project: - Release management contact - Work prioritization - Keeping bugs under control - Communicat

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

Russell Bryant wrote: > On 08/22/2014 09:40 AM, Russell Bryant wrote: >> Another area worth calling out is a gate czar. Having someone who >> understands infra and QA quite well and is regularly on top of the >> status of the project in the gate is helpful and quite important. > > Oops, you said

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

Daniel P. Berrange wrote: > On Fri, Aug 22, 2014 at 02:33:27PM +0200, Thierry Carrez wrote: >> Hi everyone, >> >> We all know being a project PTL is an extremely busy job. That's because >> in our structure the PTL is responsible for almost everything in a project: >> >> - Release management contac

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

Zane Bitter wrote: > On 22/08/14 08:33, Thierry Carrez wrote: >> We also >> still need someone to have the final say in case of deadlocked issues. > > -1 we really don't. I know we disagree on that :) >> People say we don't have that many deadlocks in OpenStack for which the >> PTL ultimate powe

Re: [openstack-dev] [OpenStack-Infra] How to get new package requirements into the CI system using a PPA and EPEL?

On Tue, Jul 15, 2014 at 7:28 PM, Ian Wienand wrote: > On 07/15/2014 11:55 PM, Ken Giusti wrote: >> Good to hear about epel's availability. But on the Ubuntu/Debian >> side - is it possible to add the Qpid project's PPA to the config >> project? From a quick 'grep' of the sources, it appears as i

Re: [openstack-dev] [oslo] Launchpad tracking of oslo projects

I have no problem with the proposed change, so +1 from me. Doug's probably the important one to hear from though, since you and he are the ones who deal with this stuff the most. I think he's travelling today so we'll see if he gets a chance to comment. On 08/22/2014 04:59 AM, Thierry Carrez wro

Re: [openstack-dev] [all] new testtools breaking gate

At least for glance, the tox fix and the double setup problem are both blocking the gate, so it isn't possible to fix cleanly, since both issues need to be fixed in one commit - I think the correct thing is to merge https://review.openstack.org/#/c/116267/ and give projects time to fix up their iss

Re: [openstack-dev] [nova][libvirt] Non-readonly connection to libvirt in unit tests

(response inline) - Original Message - > From: "Daniel P. Berrange" > To: "Solly Ross" > Cc: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Thursday, August 21, 2014 11:23:17 AM > Subject: Re: [openstack-dev] [nova][libvirt] Non-readonly connection to > libvi

Re: [openstack-dev] [QA] Picking a Name for the Tempest Library

On Fri, Aug 15, 2014 at 03:14:21PM -0400, Matthew Treinish wrote: > Hi Everyone, > > So as part of splitting out common functionality from tempest into a library > [1] > we need to create a new repository. Which means we have the fun task of coming > up with something to name it. I'm personally t

Re: [openstack-dev] [nova][libvirt] Non-readonly connection to libvirt in unit tests

On Fri, Aug 22, 2014 at 11:32:31AM -0400, Solly Ross wrote: > (response inline) > > - Original Message - > > From: "Daniel P. Berrange" > > To: "Solly Ross" > > Cc: "OpenStack Development Mailing List (not for usage questions)" > > > > Sent: Thursday, August 21, 2014 11:23:17 AM > > Su

Re: [openstack-dev] [all] The future of the integrated release

On 21 August 2014 19:39, gordon chung wrote: > from the pov of a project that seems to be brought up constantly and maybe > it's my naivety, i don't really understand the fascination with branding and > the stigma people have placed on non-'openstack'/stackforge projects. it > can't be a legal thi

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On Fri, 2014-08-22 at 11:01 -0400, Zane Bitter wrote: > I don't see that as something the wider OpenStack community needs to > dictate. We have a heavyweight election process for PTLs once every > cycle because that used to be the process for electing the TC. Now that > it no longer serves this

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On Fri, Aug 22, 2014 at 9:13 AM, Daniel P. Berrange wrote: > On Fri, Aug 22, 2014 at 02:33:27PM +0200, Thierry Carrez wrote: > > Hi everyone, > > > > We all know being a project PTL is an extremely busy job. That's because > > in our structure the PTL is responsible for almost everything in a > p

Re: [openstack-dev] Criteria for giving a -1 in a review

On Fri, 2014-08-22 at 11:01 +0100, Daniel P. Berrange wrote: > On Fri, Aug 22, 2014 at 10:49:51AM +0100, Steven Hardy wrote: > > On Thu, Aug 21, 2014 at 05:05:04PM +0100, Matthew Booth wrote: > > > I also think it's worth explicitly documenting a few things we > > > might/should mention in a review

Re: [openstack-dev] [all] The future of the integrated release

I would have to agree with Thomas. Many organizations have already worked out strategies and have processes in place to cover contributing to OpenStack which Cover all official project. Contributing to additional non-OpenStack projects may introduce additional barriers in large Organizations wh

Re: [openstack-dev] [all] The future of the integrated release

Excerpts from Sean Dague's message of 2014-08-22 04:51:49 -0700: > On 08/22/2014 01:30 AM, Michael Chapman wrote: > > > > > > > > On Fri, Aug 22, 2014 at 2:57 AM, Jay Pipes > > wrote: > > > > On 08/19/2014 11:28 PM, Robert Collins wrote: > > > > On 20 Au

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On 22 August 2014 16:19, Thierry Carrez wrote: > Zane Bitter wrote: >>> People say we don't have that many deadlocks in OpenStack for which the >>> PTL ultimate power is needed, so we could get rid of them. I'd argue >>> that the main reason we don't have that many deadlocks in OpenStack is >>>

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On 22/08/14 11:19, Thierry Carrez wrote: Zane Bitter wrote: On 22/08/14 08:33, Thierry Carrez wrote: We also still need someone to have the final say in case of deadlocked issues. -1 we really don't. I know we disagree on that :) No problem, you and I work in different programs so we can

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On Fri, Aug 22, 2014 at 11:32 AM, Zane Bitter wrote: > On 22/08/14 11:19, Thierry Carrez wrote: > >> Zane Bitter wrote: >> >>> On 22/08/14 08:33, Thierry Carrez wrote: >>> We also still need someone to have the final say in case of deadlocked issues. >>> >>> -1 we really don't. >>>

Re: [openstack-dev] [mistral] Mistral API v2 - discussion

Dmitri, Thanks for sharing this. We discussed the details of what captured in the etherpad with the team today and looks like folks support most of the ideas we came up with. Anyways, let’s take a couple of days till the next team meeting on Monday to think it over, discuss it all together and

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On 08/22/2014 08:33 AM, Thierry Carrez wrote: Hi everyone, We all know being a project PTL is an extremely busy job. That's because in our structure the PTL is responsible for almost everything in a project: - Release management contact - Work prioritization - Keeping bugs under control - Commu

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On Fri, Aug 22, 2014 at 10:51 AM, Jay Pipes wrote: > On 08/22/2014 08:33 AM, Thierry Carrez wrote: > >> Hi everyone, >> >> We all know being a project PTL is an extremely busy job. That's because >> in our structure the PTL is responsible for almost everything in a >> project: >> >> - Release man

Re: [openstack-dev] [all] The future of the integrated release

On Fri, Aug 22, 2014 at 9:51 PM, Sean Dague wrote: > On 08/22/2014 01:30 AM, Michael Chapman wrote: > > > > > > > > On Fri, Aug 22, 2014 at 2:57 AM, Jay Pipes > > wrote: > > > > On 08/19/2014 11:28 PM, Robert Collins wrote: > > > > On 20 August 2014 02:37,

[openstack-dev] [Cinder][third-party] How to make progress on cinder driver CI post J3

Many of us are still working on setting up and testing 3rd party ci for cinder drivers. None of them currently have gerrit +1/-1 voting, but I heard there's a plan to "disable" those that are "not working" post-J3 (Please correct me if I misunderstood). However, Post-J3 is a great time to work

Re: [openstack-dev] [all] new testtools breaking gate

On Fri, Aug 22, 2014, at 05:55 AM, Ihar Hrachyshka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi all, > > this week is quite bumpy for unit testing in gate. First, it was > upgrade to new 'tox' version that broke quite some branches. > I did a ton of work to make the tox upgr

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On 22/08/14 12:45, Dolph Mathews wrote: >I'm all for getting a final decision, but a 'final' decision that has been >imposed from outside rather than internalised by the participants is... >rarely final. > The expectation of a PTL isn't to stomp around and make "final" decisions, it's to step in

[openstack-dev] [Ironic] [TripleO] How to gracefully quiesce a box?

It has been brought to my attention that Ironic uses the biggest hammer in the IPMI toolbox to control chassis power: https://git.openstack.org/cgit/openstack/ironic/tree/ironic/drivers/modules/ipminative.py#n142 Which is ret = ipmicmd.set_power('off', wait) This is the most abrupt form, wh

Re: [openstack-dev] [all] The future of the integrated release

Comment inline. On Aug 22, 2014, at 10:13 AM, Michael Chapman wrote: > > > > On Fri, Aug 22, 2014 at 9:51 PM, Sean Dague wrote: > On 08/22/2014 01:30 AM, Michael Chapman wrote: > > > > > > > > On Fri, Aug 22, 2014 at 2:57 AM, Jay Pipes > > wrote: > > > > On 08

Re: [openstack-dev] [all] new testtools breaking gate

On 08/22/2014 05:30 PM, Duncan Thomas wrote: > At least for glance, the tox fix and the double setup problem are both > blocking the gate, so it isn't possible to fix cleanly, since both > issues need to be fixed in one commit - I think the correct thing is > to merge https://review.openstack.org/#

Re: [openstack-dev] [neutron] [third-party] What tests are required to be run

Excellent Job! Thanks a lot, I have updated the wiki. Edgar From: Hemanth Ravi mailto:hemanthrav...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Thursday, August 21, 2014 at 1:37 PM To: "OpenStack Developme

Re: [openstack-dev] [neutron] [third-party] What tests are required to be run

Sorry my bad but I just changed. Edgar On 8/21/14, 2:13 PM, "Dane Leblanc (leblancd)" wrote: >Edgar: > >I'm still seeing the comment "Results are not accurate. Needs >clarification..." > >Dane > >-Original Message- >From: Edgar Magana [mailto:edgar.mag...@workday.com] >Sent: Thursday, A

Re: [openstack-dev] [all] The future of the integrated release

> It may be easier for you, but it certainly isn't inside big companies, > e.g. HP have pretty broad approvals for contributing to (official) > openstack projects, where as individual approval may be needed to > contribute to none-openstack projects. i was referring to a company bigger than hp... m

Re: [openstack-dev] [Ironic] [TripleO] How to gracefully quiesce a box?

On 08/22/2014 01:48 PM, Clint Byrum wrote: It has been brought to my attention that Ironic uses the biggest hammer in the IPMI toolbox to control chassis power: https://git.openstack.org/cgit/openstack/ironic/tree/ironic/drivers/modules/ipminative.py#n142 Which is ret = ipmicmd.set_power(

Re: [openstack-dev] [Ceilometer][WSME] Sphinx failing sporadically because of wsme autodoc extension

> I couldn’t reproduce this issue either. I’ve tried on precise and on a fresh > trusty too, everything worked fine… fun from the limited error message. it's because service path isn't found (https://github.com/stackforge/wsme/blob/master/wsmeext/sphinxext.py#L133-L140) and this code is returnin

Re: [openstack-dev] [Ironic] [TripleO] How to gracefully quiesce a box?

Excerpts from Jay Pipes's message of 2014-08-22 11:16:05 -0700: > On 08/22/2014 01:48 PM, Clint Byrum wrote: > > It has been brought to my attention that Ironic uses the biggest hammer > > in the IPMI toolbox to control chassis power: > > > > https://git.openstack.org/cgit/openstack/ironic/tree/iro

[openstack-dev] [neutron] Need community weigh-in on requests-mock

Hi! Need to get the community to weigh in on this… In Neutron there currently is no mock library for the Requests package. During Icehouse, I created unit tests that used the httmock package (a context-library based Requests mock). However, the community did not want me to add this to global re

[openstack-dev] [all] Acceptable methods for establishing per-test-suite behaviors

Hi all - I’ve spent many weeks on a series of patches for which the primary goal is to provide very efficient patterns for tests that use databases and schemas within those databases, including compatibility with parallel tests, transactional testing, and scenario-driven testing (e.g. a test th

[openstack-dev] [Heat] Heat Juno Mid-cycle Meetup report

We held the inaugural Heat mid-cycle meetup in Raleigh, North Carolina this week. There were a dozen folks in attendance, and I think everyone agreed that it was a very successful event. Notes from the meetup are on the Etherpad here: https://etherpad.openstack.org/p/heat-juno-midcycle-meetup

Re: [openstack-dev] [Glance][Heat] Murano split dsicussion

Hi, Let me comment on the reasons why we’ve suggested adding Murano engine to Orchestration program. If we consider the previous Murano incubation discussions, we see that an overlap with the Orchestration program was one of the TC’s concerns. We also find that it was the Heat team that proposed

Re: [openstack-dev] [all] The future of the integrated release

On 08/22/2014 02:13 PM, Michael Chapman wrote: > > We try to target puppet module master at upstream OpenStack master, but > without CI/CD we fall behind. The missing piece is building packages and > creating a local repo before doing the puppet run, which I'm working on > slowly as I want a sin

Re: [openstack-dev] [all] Acceptable methods for establishing per-test-suite behaviors

Hi, One of the things we've wanted for a while in some projects is a completely separate database environment for each test when using MySQL. To that end, I wrote a MySQL schema fixture that is in use in nodepool: http://git.openstack.org/cgit/openstack-infra/nodepool/tree/nodepool/tests/__init__

Re: [openstack-dev] [neutron] Need community weigh-in on requests-mock

I put this in the review but will repeat it here. +1 to adding the dependency with the tests that you've written to require it when those tests have been reviewed and accepted. I don't have an objection to adding requests-mock as a test-requirement. Carl On Fri, Aug 22, 2014 at 12:50 PM, Paul M

Re: [openstack-dev] [Neutron] Use public IP address as instance fixed IP

Yes, you should be able to create a shared/external network within Neutron to accomplish this. On Fri, Aug 22, 2014 at 7:25 AM, Bao Wang wrote: > Thank you for your response. Could this be done naturally with Openstack > neutron or have to be done manually outside neutron ? As we are expecting

Re: [openstack-dev] [Cinder][third-party] How to make progress on cinder driver CI post J3

On Fri, Aug 22, 2014 at 11:19 AM, Asselin, Ramy wrote: > Many of us are still working on setting up and testing 3rd party ci for > cinder drivers. > > > > None of them currently have gerrit +1/-1 voting, but I heard there’s a > plan to “disable” those that are “not working” post-J3 (Please corre

Re: [openstack-dev] [glance] [infra] Glance review patterns and their impact on the gate

On 23/08/14 00:09, Sean Dague wrote: Earlier this week the freshness checks (the ones that required passing results within 24 hrs for a change to go into the gate) were removed to try to conserve nodes as we get to crunch time. The hopes were that review teams had enough handle on what when code

[openstack-dev] [Keystone][Marconi][Heat] Creating accounts in Keystone

Here's an interesting fact about Zaqar (the project formerly known as Marconi) that I hadn't thought about before this week: it's probably the first OpenStack project where a major part of the API primarily faces software running in the cloud rather than facing the user. That is to say, nobody

[openstack-dev] [tc] Procedure for adding official projects

Over the past couple of release cycles, the TC has put together a fairly comprehensive checklist for projects entering into incubation with a view to being included in the integrated release. However, I'm not aware of anything equivalent for projects that are becoming official (i.e. moving to t

Re: [openstack-dev] [neutron] [third-party] What tests are required to be run

Thanks Edgar for updating the APIC status!!! Edgar and Kyle: *PLEASE NOTE** I need your understanding and advice on the following: We are still stuck with a problem stemming from a design limitation of Jenkins that prevents us from being compliant with Neutron 3rd Party CI require

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

/flame-on Ok, this is funny to some of us in the community. The general populace of this community is so against the idea of management that they will use the term for a despotic dictator as a position name rather than "manager". Sorry, but this needed to be said. /flame-off Specific comments

Re: [openstack-dev] [glance] Review priorities

Thanks for sending out, Arnaud. I added two to the etherpad for metadefs: the glance client and related tempest patch. Without the client, we can't get the related Horizon patches landed. Glance Client: https://review.openstack.org/#/c/105231/ Tempest: https://review.openstack.org/113632/ F

Re: [openstack-dev] [Cinder][third-party] How to make progress on cinder driver CI post J3

Fungi (on irc) suggested the following option to run the tests without reporting them to gerrit. I’m still testing it out, but for the benefit of others using the “zuul” ci approach, try the “silent” pipeline [1] Thanks, Ramy [1]https://github.com/openstack-infra/zuul/blob/master/doc/source/zuu

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On Fri, Aug 22, 2014 at 6:17 PM, Rochelle.RochelleGrober < rochelle.gro...@huawei.com> wrote: > /flame-on > Ok, this is funny to some of us in the community. The general populace of > this community is so against the idea of management that they will use the > term for a despotic dictator as a po

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

I think Anne makes some excellent points about the pattern being proposed being unlikely to be commonly implemented across all the programs (or, at best, very difficult). Let's not try to formalize another "best practice" that works many times and force it to work every time. Here's an alternate

Re: [openstack-dev] [TripleO][Ironic] Unique way to get a registered machine?

Excerpts from Steve Kowalik's message of 2014-08-22 06:32:04 +: > At the moment, if you run register-nodes a second time with the same > list of nodes, it will happily try and register them and then blow up > when Ironic or Nova-bm returns an error. If operators are going to > update the

Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective

On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery wrote: > On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> On 20/08/14 18:28, Salvatore Orlando wrote: >>> Some comments inline. >>> >>> Salvatore >>> >>> On 20 August 2014 17:38, Ihar

Re: [openstack-dev] [Keystone][Marconi][Heat] Creating accounts in Keystone

I don't know how Zaqar does its magic, but I'd love to see simple signed URLs rather than users/passwords. This would work for Heat as well. That way we only have to pass in a single predictably formatted string. Excerpts from Zane Bitter's message of 2014-08-22 14:35:38 -0700: > Here's an interes