Re: [openstack-dev] [Octavia] Object Model and DB Structure

Comments in-line On Fri, 2014-08-15 at 17:18 -0700, Stephen Balukoff wrote: > Hi folks, > > > I'm OK with going with no shareable child entities (Listeners, Pools, > Members, TLS-related objects, L7-related objects, etc.). This will > simplify a lot of things (like status reporting), and we can

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

wrong link- please take a look at this one after log fixes have been put in - Gerrit Code Review             Gerrit Code Review Loading Gerrit Code Review ... Gerrit requires a JavaScript enabled browser. View on review.openstack.org Preview by Yahoo   F

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

hi edgar, the IBM SDNVE system runs a subset of tempest tests currently, but is triggered for all neutron changes. we are working on adding more tests to our system.  There was an issue with uploading all the logs properly, which i have fixed. one pending item is to upload the console log as well

Re: [openstack-dev] [nova][core] Expectations of core reviewers

I've literally just finished the Cinder mid-cycle meetup (I'm still in my hotel room), and the value was huge and undeniable. Reading through this thread, I've just realised one massive advantage of the mid-cycle meetup that improved our productivity massively: it is in the middle of a cycle. We h

[openstack-dev] [specs] script to help with spec reviews to convert them in html or pdf

Hello, If like me you find it difficult to read a large text file like the rst specs inside gerrit diff interface viewer, I have created a script that gets rst files in a review to generate them in a html or pdf files and open it with your desktop default viewer (linux/mac) . Script is available

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

Hi Edgar, Brocade Vyatta CI is reporting the results and providing log links. For Brocade Vyatta Plugin, I have updated my name as the owner. For Brocade VDX Plugin, Shiv Haris is the owner. Please let me know if you have any questions. Thanks, Karthik -Original Message- From: Edgar Maga

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

Hi Edgar, I am the reference for the Embrane CI (added my name to the page you linked) Our Ci had some issues that were pointed out during a third party meeting some weeks ago, we solved the issues that were reported and the CI was running fine. There was a list of issues tracked on this etherp

Re: [openstack-dev] [oslo][db] Nominating Mike Bayer for the oslo.db core reviewers team

+1 from me!! On Fri, Aug 15, 2014 at 4:30 PM, Morgan Fainberg wrote: > > -Original Message- > From: Doug Hellmann > Reply: OpenStack Development Mailing List (not for usage questions) > > > Date: August 15, 2014 at 13:29:15 > To: Ben Nemec >, OpenStack Development Mailing List > (not f

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

Hi, Edgar MetapluginCI didn't run for document changes. I changed filter so that CI run for ALL changes include documents. Thanks, Hirofumi 2014-08-16 7:35 GMT+09:00 Edgar Magana : > Team, > > I did a quick audit on the Neutron CI. Very sad results. Only few plugins > and drivers are running p

Re: [openstack-dev] [Octavia] Object Model and DB Structure

Hi folks, I'm OK with going with no shareable child entities (Listeners, Pools, Members, TLS-related objects, L7-related objects, etc.). This will simplify a lot of things (like status reporting), and we can probably safely work under the assumption that any user who has a use case in which a shar

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

Also, you can add me as a contact person for the Cisco VPNaaS driver. -Original Message- From: Dane Leblanc (leblancd) Sent: Friday, August 15, 2014 8:14 PM To: OpenStack Development Mailing List (not for usage questions) Subject: RE: [openstack-dev] [neutron] [third-party] What tests are

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

Edgar: For the Notes for the Cisco APIC, can you change the comment "results are fake" to something like "results are only valid for APIC-related commits"? I think this more accurately represents our current results (for reasons we chatted about on another thread). Thanks, Dane -Original

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

Hi Edgar, I am running the Nuage CI. The Nuage CI has run and posted successfully the result for the first review. Because of infra issue(internet can be down, etc) we are running manually the -1 -1 take some time away for developper and before doing a -1, I want to be sure that it's a valid iss

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

You didn't wait long enough for the Big Switch CI to reach your negative test. :-) Currently the CI system is backed by about 100 patches to push responses out ~22 hours. This does bring up an old discussion that was never resolved. What is the minimum expected response time for CI systems? On

Re: [openstack-dev] [TripleO] fix poor tarball support in source-repositories

Looks like a good solution to me. If there are no philosophical objections to it, I'll prepare a patch next week to make this happen. -JB -Original Message- From: Clint Byrum [mailto:cl...@fewbar.com] Sent: Friday, August 15, 2014 12:58 PM To: openstack-dev Subject: Re: [openstack-dev]

Re: [openstack-dev] [Neutron][QA] Enabling full neutron Job

On Aug 15, 2014, at 6:20 PM, Salvatore Orlando mailto:sorla...@nicira.com>> wrote: The neutron full job is finally voting, and the first patch [1] has already passed it in gate checks! I've collected a few data points before it was switched to voting, and we should probably expect a failure ra

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

That's great! Also, I would suggest we decide on a 'standard' way for CI owners to comunicate their CIs status (eg. MyCompany CI is not voting waiting for bug #9001 to be fixed). Using the ML for that may be confusing... What about an etherpad (linked from [0]) or a dedicated section of [0] itself

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

VMware minesweeper has filters which have been designed to cover the largest possible subset of submissions without add unnecessary load to our scarce resources for CI validation. This is probably why the analysis reveals not all patches are covered. Therefore our filters exclude neutral changes s

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

Ivar, Very valid point. This is why I need clarification from those CI owner. I will run a new test with a basic change in the Neutron DB code. That should be covered by almost all CI systems. Edgar From: Ivar Lazzaro mailto:ivarlazz...@gmail.com>> Reply-To: "OpenStack Development Mailing List

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

Correction The right links are: https://review.openstack.org/#/c/114629/ https://review.openstack.org/#/c/114393/ Not this one: https://review.openstack.org/#/c/40296/ Edgar On 8/15/14, 3:35 PM, "Edgar Magana" wrote: >Team, > >I did a quick audit on the Neutron CI. Very sad results. Only

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

Hi Edgar, Nice shot, to be the inquisitor is not necessarily a bad thing :) I know some CIs are 'stuck' waiting for bugs to be fixed or certain patches to be merged, but I was wondering if it is a requirement that CIs vote *ALL* the Neutron patches. Some may have missed your call just because of

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

On 2014-08-15 15:14:21 -0400 (-0400), Matthew Treinish wrote: [...] > So as a first step I figured that I'd bring it up on the ML to see > if anyone had any other suggestions. [...] Twas a clever quibble. Here, a garment for it: http://en.wikipedia.org/wiki/The_Tempest#Characters Now I will

Re: [openstack-dev] Enabling silent Docker tests for Nova?

On 2014-08-16 08:11:42 +1000 (+1000), Michael Still wrote: > Agreed. I think this should be in unless infra vetos it for load > reasons. I don't think the Infra Team minds if you run reasonable jobs to determine whether a candidate driver for a free-software backend is suitable for inclusion into

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

Team, I did a quick audit on the Neutron CI. Very sad results. Only few plugins and drivers are running properly and testing all Neutron commits. I created a report here: https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugin _and_Drivers We will discuss the actions to take

Re: [openstack-dev] [Ceilometer] Way to get wrapped method's name/class using Pecan secure decorators?

Eric, Doug's correct - this looks like a bug in pecan that occurs when you subclass both rest.RestController and hooks.HookController. I'm working on a bug fix as

Re: [openstack-dev] [Neutron][QA] Enabling full neutron Job

The neutron full job is finally voting, and the first patch [1] has already passed it in gate checks! I've collected a few data points before it was switched to voting, and we should probably expect a failure rate around 4%. This is not bad, but neither great, and everybody's contribution will be a

Re: [openstack-dev] Enabling silent Docker tests for Nova?

Agreed. I think this should be in unless infra vetos it for load reasons. Michael On Sat, Aug 16, 2014 at 5:11 AM, Dan Smith wrote: >> Feature freeze is only a few weeks away (Sept 4). How about we just >> leave it in experimental until after that big push? That seems pretty >> reasonable. > >

Re: [openstack-dev] [Octavia] Object Model and DB Structure

Yeah, need details on that. Maybe he's talking about having haproxy listen on many ips and ports, each one being a separate front end section and in the haproxy config with each mapped to its own default_backend. Even if that is the case, the load balancer + listener woudl still make up one of th

Re: [openstack-dev] [nova] Review priorities as we approach juno-3

On Fri, Aug 15, 2014 at 7:28 PM, Daniel P. Berrange wrote: > On Fri, Aug 15, 2014 at 06:53:41AM +1000, Michael Still wrote: >> On Fri, Aug 15, 2014 at 6:37 AM, Dan Smith wrote: >> >> == Move Virt Drivers to use Objects (Juno Work) == >> >> >> >> I couldn't actually find any code out for review fo

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

On Fri, Aug 15, 2014 at 4:31 PM, Jay Pipes wrote: > current Tempest repository, into their own repo called > "openstack-integration-tests" or "os-integration-tests". > I see what you did there... +1 anyway dt Dean Troyer dtro...@gmail.com ___ OpenSt

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

> On Aug 15, 2014, at 5:39 PM, Jay Pipes wrote: > >> On 08/15/2014 03:14 PM, 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

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

On 08/15/2014 03:14 PM, 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 thought we should call it:

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

"OpenTest is a library for integrational and functional testing of OpenStack cloud technology." Sounds? On Fri, Aug 15, 2014 at 10:48 PM, Russell Bryant wrote: > On 08/15/2014 03:26 PM, Drew Fisher wrote: > > What about 'teapot' (as in the idiom 'tempest in a teapot'[1]) > > > > -Drew > > > >

Re: [openstack-dev] [Neutron][IPv6]

Hi Harm It’s highly unlikely that it would work with a current version of Neutron (Icehouse was where the original effort went). I’ve just run out of cycles to work on this. I know Sean Collins continues to drive this effort, and the roadmap may have this BP (or a similar one) targeted for Kilo

Re: [openstack-dev] [Octavia] Object Model and DB Structure

--Basically no shareable entities. +1 That will make me insanely happy :-) Regarding Listeners: I was assuming that a LoadBalancer would map to an haproxy instance - and a listener would be part of that haproxy. But I heard Stephen say that this so not so clear cut. So maybe listeners map to ha

Re: [openstack-dev] [oslo][db] Nominating Mike Bayer for the oslo.db core reviewers team

-Original Message- From: Doug Hellmann Reply: OpenStack Development Mailing List (not for usage questions) > Date: August 15, 2014 at 13:29:15 To: Ben Nemec >, OpenStack Development Mailing List (not for usage questions) > Subject:  Re: [openstack-dev] [oslo][db] Nominating Mike Bayer f

Re: [openstack-dev] [Keystone] What to do with Specs after they are approved?

On Fri, Aug 15, 2014 at 3:11 PM, Dolph Mathews wrote: > Regarding the connection to release notes, it'd be useful to link from > official release note bullet points back to the corresponding spec on > specs.openstack.org to provide additional detail. > > I disagree, the people reading release not

Re: [openstack-dev] [oslo][db] Nominating Mike Bayer for the oslo.db core reviewers team

On Aug 15, 2014, at 10:00 AM, Ben Nemec wrote: > On 08/15/2014 08:20 AM, Russell Bryant wrote: >> On 08/15/2014 09:13 AM, Jay Pipes wrote: >>> On 08/15/2014 04:21 AM, Roman Podoliaka wrote: Hi Oslo team, I propose that we add Mike Bayer (zzzeek) to the oslo.db core reviewers

Re: [openstack-dev] [Keystone] What to do with Specs after they are approved?

Regarding the connection to release notes, it'd be useful to link from official release note bullet points back to the corresponding spec on specs.openstack.org to provide additional detail. On Fri, Aug 15, 2014 at 2:58 PM, Anne Gentle wrote: > > > > On Fri, Aug 15, 2014 at 2:47 PM, Adam Young

Re: [openstack-dev] [neutron][all] switch from mysqldb to another eventlet aware mysql client

On Aug 15, 2014, at 9:29 AM, Ihar Hrachyshka wrote: > Signed PGP part > Some updates on the matter: > > - oslo-spec was approved with narrowed scope which is now 'enabled > mysqlconnector as an alternative in gate' instead of 'switch the > default db driver to mysqlconnector'. We'll revisit the

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

On Thu, Aug 14, 2014 at 4:02 PM, Eoghan Glynn wrote: > > > > Additional cross-project resources can be ponied up by the large > > > contributor companies, and existing cross-project resources are not > > > necessarily divertable on command. > > > > Sure additional cross-project resources can and

Re: [openstack-dev] gettext question about oslo.i18n library

On Aug 15, 2014, at 3:18 AM, Peng Wu wrote: > Hi, > > Recently I just read the code of oslo.i18n library, > The lazy translation idea is great! > > But I found a question about gettext "contextual markers" > and "plural form", such as pgettext and ungettext functions, > see [3]. > > It s

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

On Thu, Aug 14, 2014 at 4:02 PM, Eoghan Glynn wrote: > > > > Additional cross-project resources can be ponied up by the large > > > contributor companies, and existing cross-project resources are not > > > necessarily divertable on command. > > > > Sure additional cross-project resources can and

Re: [openstack-dev] [Keystone] What to do with Specs after they are approved?

On Fri, Aug 15, 2014 at 2:47 PM, Adam Young wrote: > We are putting a lot of effort into the Specs process. It seems like a > pity to let them go to waste after the features they describe are > implemented. Ideally, they should be part of the official documentation. > Many are too detailed to b

Re: [openstack-dev] [TripleO] fix poor tarball support in source-repositories

Excerpts from Brownell, Jonathan C (Corvallis)'s message of 2014-08-15 08:11:18 -0700: > The current DIB element support for downloading tarballs via > "source-repository" allows an entry in the following form: > > tar > > Today, this feature is currently used only by the mysql DIB element.

Re: [openstack-dev] [Keystone] What to do with Specs after they are approved?

The are still alive - http://specs.openstack.org/openstack/keystone-specs/ Regards, Steve Martinelli Software Developer - OpenStack Keystone Core Member Phone: 1-905-413-2851 E-mail: steve...@ca.ibm.com 8200 Warden Ave Markham, ON L6G 1C7 Canada From:        Adam Young To:        Ope

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

On Fri, Aug 15, 2014 at 8:17 AM, Sandy Walsh wrote: > On 8/14/2014 6:42 PM, Doug Hellmann wrote: > > > On Aug 14, 2014, at 4:41 PM, Joe Gordon wrote: > > > > > On Wed, Aug 13, 2014 at 12:24 PM, Doug Hellmann > wrote: > >> >> On Aug 13, 2014, at 3:05 PM, Eoghan Glynn wrote: >> >> > >> >>> At

[openstack-dev] [Keystone] What to do with Specs after they are approved?

We are putting a lot of effort into the Specs process. It seems like a pity to let them go to waste after the features they describe are implemented. Ideally, they should be part of the official documentation. Many are too detailed to be a release note. Should they be part of the patch, and

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

On 08/15/2014 03:26 PM, Drew Fisher wrote: > What about 'teapot' (as in the idiom 'tempest in a teapot'[1]) > > -Drew > > [1] http://en.wikipedia.org/wiki/Tempest_in_a_teapot Though in this case it'd be teacup in tempest, I think? There's also a TCup project [1] that uses tempest. So, you have

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

I definitely agree that reviewer time is wasted reviewing changes. However, I don't think moving them to a different repo with different cores is going to make them less brittle without some very strict guidelines about what a driver/plugin is allowed to do. For example, without neutron core revie

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

What about 'teapot' (as in the idiom 'tempest in a teapot'[1]) -Drew [1] http://en.wikipedia.org/wiki/Tempest_in_a_teapot On 08/15/2014 01:14 PM, 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 repo

Re: [openstack-dev] [nova][core] Expectations of core reviewers

On Fri, Aug 15, 2014 at 8:20 AM, Jeremy Stanley wrote: > On 2014-08-14 09:33:20 -0400 (-0400), Russell Bryant wrote: > [...] > > Another issue is that some folks are just fundamentally opposed to > > using Google > [...] > > I think that's a shallow depiction of the issue. I'm sure *some* > peopl

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

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 thought we should call it: - mesocyclone Which has the advantage of being a c

Re: [openstack-dev] Enabling silent Docker tests for Nova?

On Fri, Aug 15, 2014 at 11:55 AM, Russell Bryant wrote: > On 08/15/2014 02:53 PM, Russell Bryant wrote: > > On 08/15/2014 02:45 PM, Eric Windisch wrote: > >> I have proposed a _silent_ check for Nova for integration of the Docker > >> driver: > >> > >> https://review.openstack.org/#/c/114547/

Re: [openstack-dev] Enabling silent Docker tests for Nova?

> Feature freeze is only a few weeks away (Sept 4). How about we just > leave it in experimental until after that big push? That seems pretty > reasonable. Joe just proposed dropping a bunch of semi-useless largeops runs. Maybe that leaves room to sneak this in? If the infra team is okay with it

Re: [openstack-dev] Enabling silent Docker tests for Nova?

> > Given resource concerns, maybe just adding it to the experimental > pipeline would be sufficient? For clarity, the discussed patch is to promote an existing experimental job to silent. Regards -Eric ___ OpenStack-dev mailing list OpenStack-dev@lists

Re: [openstack-dev] Enabling silent Docker tests for Nova?

On 08/15/2014 02:53 PM, Russell Bryant wrote: > On 08/15/2014 02:45 PM, Eric Windisch wrote: >> I have proposed a _silent_ check for Nova for integration of the Docker >> driver: >> >> https://review.openstack.org/#/c/114547/ >> >> It has been established that this code cannot move back into No

Re: [openstack-dev] Enabling silent Docker tests for Nova?

On 08/15/2014 02:45 PM, Eric Windisch wrote: > I have proposed a _silent_ check for Nova for integration of the Docker > driver: > > https://review.openstack.org/#/c/114547/ > > It has been established that this code cannot move back into Nova until > the tests are running and have a solid hi

[openstack-dev] Enabling silent Docker tests for Nova?

I have proposed a _silent_ check for Nova for integration of the Docker driver: https://review.openstack.org/#/c/114547/ It has been established that this code cannot move back into Nova until the tests are running and have a solid history of success. That cannot happen unless we're allowed t

Re: [openstack-dev] OS or os are not acronyms for OpenStack

I really think we have much bigger fish to fry than to start policing community shorthand where nearly every meeting and communication is typed. That's just my two cents for what it's worth. Mahalo, Adam *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-223

Re: [openstack-dev] OS or os are not acronyms for OpenStack

Russell Bryant wrote on 08/15/2014 01:49:40 PM: > ... > but surely when it comes to learning OpenStack itself, the OpenStack > community, dev processes, tools, etc this has got to be extremely > far down the list of barriers to entry. No argument there. I am spending decimal orders of magn

[openstack-dev] [Solum] Juno-3 Items

Hi, following up from last week's IRC meeting, I updated the Solum roadmap wiki with items for consideration for Juno-3. Please mail back your comments/suggestions, as well as we can discuss more in the next IRC and finalize Juno release scope. Wiki link: https://wiki.openstack.org/wiki/Solum/

Re: [openstack-dev] OS or os are not acronyms for OpenStack

On 08/15/2014 01:28 PM, Mike Spreitzer wrote: > Anita Kuno wrote on 08/15/2014 01:08:44 PM: > >> ... >> I think you hit the nail on the head here, Russell, "it's fine in the >> right context". >> >> The definition of the right context however is somewhat elusive. I have >> chosen (it is my own fa

Re: [openstack-dev] OS or os are not acronyms for OpenStack

Anita Kuno wrote on 08/15/2014 01:08:44 PM: > ... > I think you hit the nail on the head here, Russell, "it's fine in the > right context". > > The definition of the right context however is somewhat elusive. I have > chosen (it is my own fault) to place myself in the area where the folks > I de

Re: [openstack-dev] OS or os are not acronyms for OpenStack

On 08/15/2014 09:12 AM, Russell Bryant wrote: > On 08/15/2014 11:00 AM, Mike Spreitzer wrote: >> Anita Kuno wrote on 08/15/2014 10:38:20 AM: >> >>> OpenStack is OpenStack. The use of openstack is also acceptable in our >>> development conversations. >>> >>> OS or os is operating system. I am start

Re: [openstack-dev] [Cinder] 3'rd party CI systems: Not Whitelisted Volume type with name * could not be found.

On Fri, Aug 15, 2014 at 10:29 AM, Asselin, Ramy wrote: > John, > > > > We’re running master on every patch set. What needs to be set in localrc? > > Actually, I think I know what could be the issue (still need to confirm) > > > > 1. devstack-gate/devstack-vm-gate-wrap.sh configures localrc

Re: [openstack-dev] [Cinder] 3'rd party CI systems: Not Whitelisted Volume type with name * could not be found.

John, We’re running master on every patch set. What needs to be set in localrc? Actually, I think I know what could be the issue (still need to confirm) 1. devstack-gate/devstack-vm-gate-wrap.sh configures localrc 2. We configuring the cinder backend in local.conf. We’re not setting

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

On Thu, Aug 14, 2014 at 12:09:26PM +0200, Salvatore Orlando wrote: > I think there will soon be a discussion regarding what the appropriate > location for plugin and drivers should be. > My personal feeling is that Neutron has simply reached the tipping point > where the high number of drivers and

Re: [openstack-dev] [nova] Deprecating CONF.block_device_allocate_retries_interval

On 08/15/2014 11:43 AM, Matthew Booth wrote: On 15/08/14 16:12, Andrew Laski wrote: On 08/08/2014 08:42 AM, Nikola Đipanov wrote: On 08/06/2014 07:54 PM, Jay Pipes wrote: I bring this up on the mailing list because I think Liyi's patch offers an interesting future direction to the way that we

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

> But, if someone asked me what they should use for metering today, > I'd point them towards Monasca in a heartbeat. FWIW my view is that Monasca is an interesting emerging project, with a team accreting around it that seems to be interested in collaboration. We've had ongoing discussions with t

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

I think the review time alone is a huge issue. Even worse, for the most part, core reviewers are reviewing code for which they themselves can't test because it requires proprietary hardware or software, making the situation brittle at best. Having a separate git repository which is gated by stringe

Re: [openstack-dev] [nova] Deprecating CONF.block_device_allocate_retries_interval

On 15/08/14 16:12, Andrew Laski wrote: > > On 08/08/2014 08:42 AM, Nikola Đipanov wrote: >> On 08/06/2014 07:54 PM, Jay Pipes wrote: >>> I bring this up on the mailing list because I think Liyi's patch offers >>> an interesting future direction to the way that we think about our retry >>> approach

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

On 8/14/2014 6:42 PM, Doug Hellmann wrote: On Aug 14, 2014, at 4:41 PM, Joe Gordon mailto:joe.gord...@gmail.com>> wrote: On Wed, Aug 13, 2014 at 12:24 PM, Doug Hellmann mailto:d...@doughellmann.com>> wrote: On Aug 13, 2014, at 3:05 PM, Eoghan Glynn mailto:egl...@redhat.com>> wrote: > >>>

Re: [openstack-dev] OS or os are not acronyms for OpenStack

On 08/15/2014 11:00 AM, Mike Spreitzer wrote: > Anita Kuno wrote on 08/15/2014 10:38:20 AM: > >> OpenStack is OpenStack. The use of openstack is also acceptable in our >> development conversations. >> >> OS or os is operating system. I am starting to see some people us OS or >> os to mean OpenSta

[openstack-dev] [TripleO] fix poor tarball support in source-repositories

The current DIB element support for downloading tarballs via "source-repository" allows an entry in the following form: tar Today, this feature is currently used only by the mysql DIB element. You can see how it's used here: https://github.com/openstack/tripleo-image-elements/blob/master/ele

Re: [openstack-dev] [nova] Deprecating CONF.block_device_allocate_retries_interval

On 08/08/2014 08:42 AM, Nikola Đipanov wrote: On 08/06/2014 07:54 PM, Jay Pipes wrote: I bring this up on the mailing list because I think Liyi's patch offers an interesting future direction to the way that we think about our retry approach in Nova. Instead of having hard-coded or configurable

Re: [openstack-dev] OS or os are not acronyms for OpenStack

Anita Kuno wrote on 08/15/2014 10:38:20 AM: > OpenStack is OpenStack. The use of openstack is also acceptable in our > development conversations. > > OS or os is operating system. I am starting to see some people us OS or > os to mean OpenStack. This is confusing and also incorrect[0]. > > ...

Re: [openstack-dev] OS or os are not acronyms for OpenStack

> OS or os is operating system. I am starting to see some people us OS or > os to mean OpenStack. This is confusing and also incorrect[0]. Except in the nova API code, where 'os' means 'openstack'. I too think that policing the use of abbreviations is silly. It's a confusing abbreviation, but ser

Re: [openstack-dev] Which program for Rally

On 2014-08-13 19:28:48 -0700 (-0700), Joe Gordon wrote: > We actually run out of nodes almost every day now (except > weekends), we have about 800 nodes, and hit that quota most days [...] It's worth noting that a lot of the recent exhaustion has been due to OpenStack bugs impacting the providers

Re: [openstack-dev] OS or os are not acronyms for OpenStack

- Original Message - > From: "Anita Kuno" > To: "openStack Development Mailing List" > > OpenStack is OpenStack. The use of openstack is also acceptable in our > development conversations. > > OS or os is operating system. I am starting to see some people us OS or > os to mean OpenStack

Re: [openstack-dev] OS or os are not acronyms for OpenStack

> > > "No alterations: When using OpenStack Marks, you shall never vary the > spelling, hyphenation or spacing of the any portion of the marks. > > Examples of Improper Display of an OpenStack Mark: Open-Stack; Open > Stack; OS Stack Examples of Proper Display of an OpenStack Mark: > OpenStack; OPE

Re: [openstack-dev] [TripleO] Review metrics - what do we want to measure?

On 2014-08-13 19:51:52 -0500 (-0500), Ben Nemec wrote: [...] > make the check-tripleo job leave an actual vote rather than just a > comment. [...] That, as previously discussed, will require some design work in Zuul. Gerrit uses a single field per account for verify votes, which means that if you

[openstack-dev] OS or os are not acronyms for OpenStack

OpenStack is OpenStack. The use of openstack is also acceptable in our development conversations. OS or os is operating system. I am starting to see some people us OS or os to mean OpenStack. This is confusing and also incorrect[0]. "No alterations: When using OpenStack Marks, you shall never var

Re: [openstack-dev] [nova][core] Expectations of core reviewers

On 2014-08-14 09:33:20 -0400 (-0400), Russell Bryant wrote: [...] > Another issue is that some folks are just fundamentally opposed to > using Google [...] I think that's a shallow depiction of the issue. I'm sure *some* people really do just avoid Google specifically, but a bigger concern should

Re: [openstack-dev] [TripleO] Python 3 support in os-*-config

On 08/15/2014 02:30 AM, Dougal Matthews wrote: > Great stuff, really happy to see Python 3 support. > > - Original Message - >> From: "Steve Kowalik" >> To: openstack-dev@lists.openstack.org >> Sent: Friday, 15 August, 2014 4:11:04 AM >> Subject: [openstack-dev] [TripleO] Python 3 support

Re: [openstack-dev] [Sahara] Swift authentication and backwards compatibility

thanks for the thoughts Trevor, On 08/15/2014 09:32 AM, Trevor McKay wrote: I think backward compatibility is a good idea. We can make the user/pass inputs for data objects optional (they are required currently), maybe even gray them out in the UI with a checkbox to turn them on, or something

Re: [openstack-dev] [heat] heat docker multi host scheduling support

On Thu, Aug 14, 2014 at 3:21 AM, Malawade, Abhijeet < abhijeet.malaw...@nttdata.com> wrote: > Hi all, > > > > I am trying to use heat to create docker containers. I have configured > heat-docker plugin. > > I am also able to create stack using heat successfully. > > > > To start container on diff

Re: [openstack-dev] [oslo][db] Nominating Mike Bayer for the oslo.db core reviewers team

On 08/15/2014 08:20 AM, Russell Bryant wrote: > On 08/15/2014 09:13 AM, Jay Pipes wrote: >> On 08/15/2014 04:21 AM, Roman Podoliaka wrote: >>> Hi Oslo team, >>> >>> I propose that we add Mike Bayer (zzzeek) to the oslo.db core >>> reviewers team. >>> >>> Mike is an author of SQLAlchemy, Alembic, Ma

Re: [openstack-dev] [Cinder] 3'rd party CI systems: Not Whitelisted Volume type with name * could not be found.

On Fri, Aug 15, 2014 at 6:39 AM, Kerr, Andrew wrote: > Can the default_volume_type be left empty and get the original "None" > type, so we don't have to create the volume type prior to running tempest > tests? > > Andrew Kerr > OpenStack QA > Cloud Solutions Group > NetApp > > > > On 8/14/14, 5:2

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

On 08/14/2014 03:21 AM, Nikola Đipanov wrote: On 08/13/2014 06:05 PM, Sylvain Bauza wrote: Le 13/08/2014 12:21, Sylvain Bauza a écrit : Le 12/08/2014 22:06, Sylvain Bauza a écrit : Le 12/08/2014 18:54, Nikola Đipanov a écrit : On 08/12/2014 04:49 PM, Sylvain Bauza wrote: (sorry for repostin

Re: [openstack-dev] [Sahara] Swift authentication and backwards compatibility

Thoughts, rapidfire :) In short, I think we should plan on backward compat unless some stubborn technical problem gets in our way I think backward compatibility is a good idea. We can make the user/pass inputs for data objects optional (they are required currently), maybe even gray them out

Re: [openstack-dev] [neutron][all] switch from mysqldb to another eventlet aware mysql client

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Some updates on the matter: - - oslo-spec was approved with narrowed scope which is now 'enabled mysqlconnector as an alternative in gate' instead of 'switch the default db driver to mysqlconnector'. We'll revisit the switch part the next cycle once

Re: [openstack-dev] [oslo][db] Nominating Mike Bayer for the oslo.db core reviewers team

On 08/15/2014 09:13 AM, Jay Pipes wrote: > On 08/15/2014 04:21 AM, Roman Podoliaka wrote: >> Hi Oslo team, >> >> I propose that we add Mike Bayer (zzzeek) to the oslo.db core >> reviewers team. >> >> Mike is an author of SQLAlchemy, Alembic, Mako Templates and some >> other stuff we use in OpenStac

Re: [openstack-dev] [oslo][db] Nominating Mike Bayer for the oslo.db core reviewers team

On 08/15/2014 04:21 AM, Roman Podoliaka wrote: Hi Oslo team, I propose that we add Mike Bayer (zzzeek) to the oslo.db core reviewers team. Mike is an author of SQLAlchemy, Alembic, Mako Templates and some other stuff we use in OpenStack. Mike has been working on OpenStack for a few months contr

Re: [openstack-dev] [nova][core] Expectations of core reviewers

Maybe we need to think about this from a distributed software perspective? * Divide and Conquer? Can we split the topics to create more manageable sub-groups? This way it's not core-vs-non-core but intererested-vs-moderately-interested. (of course, this is much the way the mailing list works)

Re: [openstack-dev] [oslo][db] Nominating Mike Bayer for the oslo.db core reviewers team

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 +1. [Not being an oslo core in any way,] I think Mike, with all his prior experience and vision on where oslo.db should strive to, will be a great addition to the core team. /Ihar On 15/08/14 10:21, Roman Podoliaka wrote: > Hi Oslo team, > > I prop

Re: [openstack-dev] [Cinder] 3'rd party CI systems: Not Whitelisted Volume type with name * could not be found.

Can the default_volume_type be left empty and get the original "None" type, so we don't have to create the volume type prior to running tempest tests? Andrew Kerr OpenStack QA Cloud Solutions Group NetApp On 8/14/14, 5:23 PM, "Martin, Kurt Frederick (ESSN Storage MSDU)" wrote: >They need to b

Re: [openstack-dev] backport fixes to old branches

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/08/14 13:09, Osanai, Hisashi wrote: > > Hi, > > On Tuesday, August 05, 2014 8:57 PM, Ihar Hrachyshka wrote: >>> Thanks. To facilitate quicker backport, you may also propose >>> the patch for review yourself. It may take time before stable >>>

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

Le 15 août 2014 08:16, "Nikola Đipanov" a écrit : > > On 08/14/2014 10:25 PM, Sylvain Bauza wrote: > > Hi mikal, > > > > Le 14 août 2014 01:49, "Michael Still" > > a écrit : > >> > >> So, there's been a lot of email in the last few days and I feel I am > >> not keeping u

Re: [openstack-dev] [nova] Review priorities as we approach juno-3

On Fri, Aug 15, 2014 at 06:53:41AM +1000, Michael Still wrote: > On Fri, Aug 15, 2014 at 6:37 AM, Dan Smith wrote: > >> == Move Virt Drivers to use Objects (Juno Work) == > >> > >> I couldn't actually find any code out for review for this one apart > >> from https://review.openstack.org/#/c/94477/

  1   2   >