Re: [openstack-dev] [Fuel] [Rally] Using fuelclient as a library - battle report

Ilya, would that be possible to contribute your changes back to our upstream client? We are willing it to be evolved in this exact direction, though we never had enough resources for it. We will be happy to review and accept your requests. It should be easier for you too - instead of maintaining th

[openstack-dev] [Python-novaclient] Python-novaclient tests fail

Hi All, I am trying to test *python-novaclient* using /*pythonsetup.pytes**t*/asreported in http://docs.openstack.org/developer/python-novaclient/ . In order to figure out the test logic I ran tests but an error is occurred: Exception: Traceback (most recent call last): File "/usr/

Re: [openstack-dev] [Python-novaclient] Python-novaclient tests fail

Just a permission issue. Use a “sudo”. You could alternatively install novaclient under a virtualenv and run the same “python setup.py test” without sudo. -Vishnu From: Daniele Casini [mailto:daniele.cas...@dektech.com.au] Sent: Monday, October 13, 2014 3:50 PM To: openstack-dev@lists.openstack

Re: [openstack-dev] [Python-novaclient] Python-novaclient tests fail

Simple way to run tests is using tox: $ tox -epy27 For more details, look at nova guide: http://docs.openstack.org/developer/nova/devref/unit_tests.html PS: Why novaclient guide recommends to use "python setup.py test"? A bit strange for me. On Mon, Oct 13, 2014 at 1:19 PM, Daniele Casini <

Re: [openstack-dev] [api] Forming the API Working Group

Zhipeng Huang wrote: > HI all, will we have a discussion on this issun at Paris Summit? I expect the API WG to propose API discussions within the "Cross-project workshops" track and get space granted to them. https://etherpad.openstack.org/p/kilo-crossproject-summit-topics Cheers, -- Thierry C

[openstack-dev] [nova]Instance console.log

Hi, Is there a way to disable "console.log" or redirect it to a custom location? Use-case: we have a "custom" distributed storage-solution, and to enable faster migration we symlinked the /opt/stack/dara/nova/instances to a directory on our mountpoint (which is backed by our shared storage). The p

Re: [openstack-dev] [horizon] Packaging Sinon.JS as xstatic

Hello folks! Discussing the proposed Sinon.js dependency to Horizon on the last meeting has brought quite an expected question: why should we add it when there is already such wonderful testing framework as Jasmine? And if you need some testing feature present in Jasmine, why not rewrite your QUni

Re: [openstack-dev] [Python-novaclient] Python-novaclient tests fail

I have already used "sudo" but it still fails: ImportError: cannot import name exceptions Ran 63 tests in 0.146s (+0.014s) FAILED (id=3, failures=63) error: testr failed (1) So, it is quite strange because I do not modify the source code. Let me know if you have some suggestions. Thanks, Danie

[openstack-dev] [all][oslo] projects still using obsolete oslo modules

I’ve put together a little script to generate a report of the projects using modules that used to be in the oslo-incubator but that have moved to libraries [1]. These modules have been deleted, and now only exist in the stable/juno branch of the incubator. We do not anticipate back-porting fixes

Re: [openstack-dev] [all][oslo] projects still using obsolete oslo modules

Doug, Thank you for script. This really simplifies life! Best regards, Boris Pavlovic On Mon, Oct 13, 2014 at 5:20 PM, Doug Hellmann wrote: > I’ve put together a little script to generate a report of the projects > using modules that used to be in the oslo-incubator but that have moved to > l

[openstack-dev] [all] Resolving a possible meeting conflict

Hi all: I've setup a weekly meeting for the neutron-drivers team on IRC at 1500UTC [1], but I noticed it conflicts with the PHP SDK IRC meeting at 1530UTC [2]. However, I see the PHP SDK IRC meeting hasn't happened since August 6 [3]. Can I assume this meeting is no longer going on? If so, can I c

Re: [openstack-dev] [Python-novaclient] Python-novaclient tests fail

I have already use "tox" instead of "python setup.py test" and the test is successfully passed. However, I do not understand because it does not pass using the way reported in the official document. Thus, two questions occour to me: Can I use tox in order to test python-novaclient? Should th

[openstack-dev] [Fuel] Propose adding Igor K. to core reviewers for fuel-web projects

Hi everyone! I would like to propose Igor Kalnitsky as a core reviewer on the Fuel-web team. Igor has been working on openstack patching, nailgun, fuel upgrade and provided a lot of good reviews [1]. In addition he's also very active in IRC and mailing list. Can the other core team members please

Re: [openstack-dev] [Fuel] Propose adding Igor K. to core reviewers for fuel-web projects

+1. I'm not core, but he has done the most thorough reviews lately and shows great initiative in maintaining quality in Fuel. On Mon, Oct 13, 2014 at 5:53 PM, Evgeniy L wrote: > Hi everyone! > > I would like to propose Igor Kalnitsky as a core reviewer on the > Fuel-web team. Igor has been workin

[openstack-dev] [all][oslo] reviewing oslo specs

The openstack/oslo-specs repository is open for submissions for Kilo, and the Oslo team would appreciate your help in reviewing the proposed changes. Changes to Oslo libraries affect all projects, so we want to collect as much input as we can before committing to a direction. There are several s

Re: [openstack-dev] [Python-novaclient] Python-novaclient tests fail

>Can I use tox in order to test python-novaclient? `tox` is used in novaclient gates, so you SHOULD use tox instead of "python setup.py test" :) To make sure in my words, you can see gate-python-novaclient-python27/console.html (for example: http://logs.openstack.org/50/123850/4/check/gate-python-

Re: [openstack-dev] [Fuel] Propose adding Igor K. to core reviewers for fuel-web projects

+1 On Mon, Oct 13, 2014 at 1:53 PM, Evgeniy L wrote: > Hi everyone! > > I would like to propose Igor Kalnitsky as a core reviewer on the > Fuel-web team. Igor has been working on openstack patching, > nailgun, fuel upgrade and provided a lot of good reviews [1]. In > addition he's also very acti

Re: [openstack-dev] [api] Forming the API Working Group

Hi Thierry, THX for the link ! So we will have the workshop on Nov 3th at Meridien Etoile Hotel? On Mon, Oct 13, 2014 at 8:40 PM, Thierry Carrez wrote: > Zhipeng Huang wrote: > > HI all, will we have a discussion on this issun at Paris Summit? > > I expect the API WG to propose API discussions

Re: [openstack-dev] [Fuel] Propose adding Igor K. to core reviewers for fuel-web projects

+1 2014-10-13 20:53 GMT+07:00 Evgeniy L : > Hi everyone! > > I would like to propose Igor Kalnitsky as a core reviewer on the > Fuel-web team. Igor has been working on openstack patching, > nailgun, fuel upgrade and provided a lot of good reviews [1]. In > addition he's also very active in IRC an

Re: [openstack-dev] [api] Forming the API Working Group

On 10/10/2014 02:05 AM, Christopher Yeoh wrote: I agree with what you've written on the wiki page. I think our priority needs to be to flesh out https://wiki.openstack.org/wiki/Governance/Proposed/APIGuidelines so we have something to reference when reviewing specs. At the moment I see that docum

[openstack-dev] [neutron] neutron-specs is open for Kilo submissions

This was mentioned in the neutron meeting [1], but I wanted to send an email to the list so everyone knows. We've opened up Kilo specs for Neutron now. Please note the template has changed, so if you are resubmitting an old spec, make sure to change it to follow the new template [2]. I also wanted

Re: [openstack-dev] [all][oslo] projects still using obsolete oslo modules

On Mon, Oct 13, 2014 at 09:20:38AM -0400, Doug Hellmann wrote: > I’ve put together a little script to generate a report of the projects using > modules that used to be in the oslo-incubator but that have moved to > libraries [1]. These modules have been deleted, and now only exist in the > stabl

Re: [openstack-dev] [api] Forming the API Working Group

On 10/10/2014 12:09 PM, Jay Pipes wrote: > Thanks for getting this going, Everett! Comments inline... > > On 10/08/2014 07:05 PM, Everett Toews wrote: >> https://wiki.openstack.org/wiki/API_Working_Group >> >> This is the start of the API Working Group (API WG). > > yay! :) > >> To avoid bike sh

Re: [openstack-dev] [all][oslo] projects still using obsolete oslo modules

On Oct 13, 2014, at 11:06 AM, Steven Hardy wrote: > On Mon, Oct 13, 2014 at 09:20:38AM -0400, Doug Hellmann wrote: >> I’ve put together a little script to generate a report of the projects using >> modules that used to be in the oslo-incubator but that have moved to >> libraries [1]. These mod

Re: [openstack-dev] [api] Forming the API Working Group

On 10/13/2014 11:10 AM, Russell Bryant wrote: On 10/10/2014 12:09 PM, Jay Pipes wrote: Thanks for getting this going, Everett! Comments inline... On 10/08/2014 07:05 PM, Everett Toews wrote: https://wiki.openstack.org/wiki/API_Working_Group This is the start of the API Working Group (API WG).

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

Hi, We've discussed what we will be able to do for the current release and what we will not be able to implement. We have not only technical problems, but also we don't have a lot of time for implementation. We were trying to find solution which will work well enough with all of the constraints. F

Re: [openstack-dev] [api] Forming the API Working Group

Zhipeng Huang wrote: > THX for the link ! So we will have the workshop on Nov 3th at Meridien > Etoile Hotel? The workshops happen on the 4th (Tuesday). -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://li

Re: [openstack-dev] [all][oslo] projects still using obsolete oslo modules

Awesome! Thanks Doug for this, I will start working on moving the ironic* stuff to use the oslo libraries. Lucas On Mon, Oct 13, 2014 at 2:20 PM, Doug Hellmann wrote: > I’ve put together a little script to generate a report of the projects using > modules that used to be in the oslo-incubator

Re: [openstack-dev] [Python-novaclient] Python-novaclient tests fail

On 10/13/2014 06:19 AM, Murugan, Visnusaran wrote: > Just a permission issue. Use a “sudo”. You could alternatively install > novaclient under a virtualenv and run the same “python setup.py test” without > sudo. To my knowledge you should never have to run our unit tests with sudo, and I wouldn'

Re: [openstack-dev] [Fuel] Let's remove "fuelweb" from repo paths

Hi folks, I want to bring this topic up again. We had a blocker in Fuel-Web project - Evgeniy L found a bug for old releases, so I had to add data migration. Today I built a new ISO and it successfully passed BVT tests. So I would ask you to merge this patches if there are no objections. Thanks,

Re: [openstack-dev] [Python-novaclient] Python-novaclient tests fail

On 10/13/2014 08:08 AM, Daniele Casini wrote: > I have already used "sudo" but it still fails: > > ImportError: cannot import name exceptions > Ran 63 tests in 0.146s (+0.014s) > FAILED (id=3, failures=63) > error: testr failed (1) > > So, it is quite strange because I do not modify the source co

Re: [openstack-dev] [Fuel] Propose adding Igor K. to core reviewers for fuel-web projects

+1 On Mon, Oct 13, 2014 at 6:49 PM, Vitaly Kramskikh wrote: > +1 > > 2014-10-13 20:53 GMT+07:00 Evgeniy L : > >> Hi everyone! >> >> I would like to propose Igor Kalnitsky as a core reviewer on the >> Fuel-web team. Igor has been working on openstack patching, >> nailgun, fuel upgrade and provide

Re: [openstack-dev] [Python-novaclient] Python-novaclient tests fail

> the novaclient docs should really be updated. simple fix: https://review.openstack.org/#/c/127971/ but, imo, docs should contains more information(I will fix it a little bit later, if no one takes this) On Mon, Oct 13, 2014 at 7:49 PM, Ben Nemec wrote: > On 10/13/2014 08:08 AM, Daniele Casini

[openstack-dev] [neutron] Updates to the weekly Neutron meting

As part of stream lining how we work as a team in Neutron, and to make better use of our weekly meeting, I'm changing the format of the weekly meeting. This involves removing the meeting as a sort of status report tool from our plethora of sub-teams into more of an On-Demand agenda [1]. We'll leave

Re: [openstack-dev] Neutron documentation to update about new vendor plugin, but without code in repository?

Hi, If the plan is to move ALL existing vendor specific plugins/drivers out-of-tree, then having a place-holder within the OpenStack domain would suffice, where the vendors can list their plugins/drivers along with their documentation as how to install and use etc. The main Openstack Neutron docu

[openstack-dev] [Keystone] keystone-specs is open for Kilo submissions

This has actually been the case since just after the cut of the RC1 for Juno, but I wanted to make sure that it was explicitly called out on the mailing list. Keystone has opened up for Kilo specifications, please submit your specifications to the keystone-specs[1] repository. Ideally we will ap

Re: [openstack-dev] [neutron] Updates to the weekly Neutron meting

Kyle, This works for me. My only comment is that linking sub team pages from the Neutron meeting page served a dual purpose. It attached it to the agenda -- which is now deprecated -- and it served as sort of an anchor for the sub team in to the Neutron team on the wiki. At least for the L3 sub

Re: [openstack-dev] [neutron] Updates to the weekly Neutron meting

Thanks Carl. I agree, we need to collapse the pages so we can get a status readout on the wiki. Keep in mind we also have this page [1], which is much fresher than the Teams page. I'd prefer to see the Teams page either marked as deprecated or updated to reflect the content in [1], with even more c

Re: [openstack-dev] [neutron] Updates to the weekly Neutron meting

Kyle, I missed that one! Thanks for the pointer. I'll get this started today. Carl On Mon, Oct 13, 2014 at 1:47 PM, Kyle Mestery wrote: > Thanks Carl. I agree, we need to collapse the pages so we can get a > status readout on the wiki. Keep in mind we also have this page [1], > which is much

Re: [openstack-dev] [all][oslo] projects still using obsolete oslo modules

Filed https://bugs.launchpad.net/sahara/+bug/1380725 for sahara stuff. Andrew. On Mon, Oct 13, 2014 at 6:20 AM, Doug Hellmann wrote: > I’ve put together a little script to generate a report of the projects > using modules that used to be in the oslo-incubator but that have moved to > libraries

[openstack-dev] [all][policy][keystone] Better Policy Model and Representing Capabilites

Description of the problem: Without attempting an action on an endpoint with a current scoped token, it is impossible to know what actions are available to a user. Horizon makes some attempts to solve this issue by sourcing all of the policy files from all of the services to determine what a u

Re: [openstack-dev] [Fuel] Propose adding Igor K. to core reviewers for fuel-web projects

+1 Best Regards, Sergii Golovatiuk > On 13 Oct 2014, at 18:55, Mike Scherbakov wrote: > > +1 > >> On Mon, Oct 13, 2014 at 6:49 PM, Vitaly Kramskikh >> wrote: >> +1 >> >> 2014-10-13 20:53 GMT+07:00 Evgeniy L : >>> Hi everyone! >>> >>> I would like to propose Igor Kalnitsky as a core revie

[openstack-dev] [Nova] Automatic evacuate

[switching to openstack-dev] Has anyone automated nova evacuate so that VM's on a failed compute host using shared storage are automatically moved onto a new host or is manually entering *nova compute * required in all cases? If it's manual only or require custom Heat/Ceilometer templates, how h

[openstack-dev] [neutron] allow-mac-to-be-updated

Hi, Is anyone working on this blueprint[1]? I have an implementation [2] and would like to write up a spec. Thanks, Chuck [1] https://blueprints.launchpad.net/neutron/+spec/allow-mac-to-be-updated [2] https://review.openstack.org/#/c/112129/ ___ O

Re: [openstack-dev] [Nova] Automatic evacuate

Looks like this was proposed and denied to be part of Nova for some reason last year. Thoughts on why and is the reasoning (whatever it was) still applicable? *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 Inter

Re: [openstack-dev] [all][policy][keystone] Better Policy Model and Representing Capabilites

This is a hot topic for some brainstorms here, since I started to hack a bit with OpenStack =) Regarding the given options, the second one looks better IMO, and we could avoid some of the token bloating issues by having a parameter where the service specifies what is set of actions that are impor

Re: [openstack-dev] [UX] [Heat] [Mistral] Merlin project PoC update: shift from HOT builder to Mistral Workbook builder

The HOT Builder code is available now at https://github.com/rackerlabs/hotbuilder although at the moment it is non-functional because it has not been ported over to Horizon. Drago From: Angus Salkeld mailto:asalk...@mirantis.com>> Reply-To: "OpenStack Development Mailing List (not for usage que

Re: [openstack-dev] [all][oslo] projects still using obsolete oslo modules

Thanks for putting this together Doug! I've opened https://bugs.launchpad.net/trove/+bug/1380789 to track the changes that are needed here for Trove. Cheers, Nikhil Doug Hellmann writes: > I’ve put together a little script to generate a report of the projects using > modules that used to be

Re: [openstack-dev] [Nova] Automatic evacuate

On Mon, Oct 13, 2014 at 1:32 PM, Adam Lawson wrote: > Looks like this was proposed and denied to be part of Nova for some reason > last year. Thoughts on why and is the reasoning (whatever it was) still > applicable? > Link? > > > *Adam Lawson* > > AQORN, Inc. > 427 North Tatnall Street > Ste

Re: [openstack-dev] [Nova] Automatic evacuate

I think Adam is talking about this bp: https://blueprints.launchpad.net/nova/+spec/evacuate-instance-automatically For now, we're using Nagios probe/event to trigger the Nova evacuate command, but I think it's possible to do that in Nova if we can find a good way to define the trigger policy. O

Re: [openstack-dev] Treating notifications as a contract

On Tue, 7 Oct 2014, Sandy Walsh wrote: Haven't had any time to get anything written down (pressing deadlines with StackTach.v3) but open to suggestions. Perhaps we should just add something to the olso.messaging etherpad to find time at the summit to talk about it? Have you got a link for that

Re: [openstack-dev] [Nova] Automatic evacuate

Nice timing. I was working on a blog post on this topic. On 10/13/2014 05:40 PM, Fei Long Wang wrote: > I think Adam is talking about this bp: > https://blueprints.launchpad.net/nova/+spec/evacuate-instance-automatically > > For now, we're using Nagios probe/event to trigger the Nova evacuate >

[openstack-dev] [Infra] Meeting Tuesday October 14th at 19:00 UTC

Hi everyone, The OpenStack Infrastructure (Infra) team is hosting our weekly meeting on Tuesday October 14th, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is welcome to to add agenda items) Everyone interested

Re: [openstack-dev] [Nova] Automatic evacuate

This is also a use case for Congress, please check use case 3 in the following link. https://docs.google.com/document/d/1ExDmT06vDZjzOPePYBqojMRfXodvsk0R8nRkX-zrkSw/edit# 2014-10-14 5:59 GMT+08:00 Russell Bryant : > Nice timing. I was working on a blog post on this topic. > > On 10/13/2014 05:4

Re: [openstack-dev] 2 Minute tokens

Too-short token expiration times are one of my concerns, in my current exercise. Working on a replacement for Nova backup. Basically creating backups jobs, writing the jobs into a queue, with a background worker that reads jobs from the queue. Tokens could expire while the jobs are in the queue (n

Re: [openstack-dev] [Nova] Automatic evacuate

On 10/13/2014 06:18 PM, Jay Lau wrote: > This is also a use case for Congress, please check use case 3 in the > following link. > > https://docs.google.com/document/d/1ExDmT06vDZjzOPePYBqojMRfXodvsk0R8nRkX-zrkSw/edit# Wow, really? That honestly makes me very worried about the scope of Congress b

Re: [openstack-dev] [api] Forming the API Working Group

On Mon, 13 Oct 2014 10:52:26 -0400 Jay Pipes wrote: > On 10/10/2014 02:05 AM, Christopher Yeoh wrote: > > I agree with what you've written on the wiki page. I think our > > priority needs to be to flesh out > > https://wiki.openstack.org/wiki/Governance/Proposed/APIGuidelines > > so we have somet

Re: [openstack-dev] Neutron documentation to update about new vendor plugin, but without code in repository?

>The OpenStack dev and docs team dont have to worry about gating/publishing/maintaining the vendor specific plugins/drivers. I disagree about the gating part. If a vendor wants to have a link that shows they are compatible with openstack, they should be reporting test results on all patches. A lin

Re: [openstack-dev] [Nova] Automatic evacuate

> > *I think Adam is talking about this > bp: > https://blueprints.launchpad.net/nova/+spec/evacuate-instance-automatically > > * Correct - yes. Sorry about that. ; ) So it would seem the question is not whether to s

[openstack-dev] [cinder] Any plan on cinder for kilo?

Hi, I noticed nova has already opened blueprint and specs for kilo, so I was wondering what is the plan on cinder for kilo? If I want to contribute some code(add new feature) for cinder, whether the step is the same with nova (need write specs first)? Thanks! Yoo __

Re: [openstack-dev] [all][policy][keystone] Better Policy Model and Representing Capabilites

On 10/13/2014 01:17 PM, Morgan Fainberg wrote: > Description of the problem: Without attempting an action on an endpoint with > a current scoped token, it is impossible to know what actions are available > to a user. > > > Horizon makes some attempts to solve this issue by sourcing all of the

Re: [openstack-dev] Neutron documentation to update about new vendor plugin, but without code in repository?

On Mon, Oct 13, 2014 at 6:44 PM, Kevin Benton wrote: >>The OpenStack dev and docs team dont have to worry about >> gating/publishing/maintaining the vendor specific plugins/drivers. > > I disagree about the gating part. If a vendor wants to have a link that > shows they are compatible with opensta

Re: [openstack-dev] [neutron] allow-mac-to-be-updated

On Mon, Oct 13, 2014 at 3:31 PM, Chuck Carlino wrote: > Hi, > > Is anyone working on this blueprint[1]? I have an implementation [2] and > would like to write up a spec. > This was registered by Aaron Rosen back in July of 2013, with no movement since then. I think it's safe to say he's not worki

[openstack-dev] [neutron][all] Naming convention for unused variables

(Context: https://review.openstack.org/#/c/117418/) I'm looking for some rough consensus on what naming conventions we want for unused variables in Neutron, and across the larger OpenStack python codebase since there's no reason for Neutron to innovate here. As far as I can see, there are two c

Re: [openstack-dev] [neutron][all] Naming convention for unused variables

On 14 October 2014 14:28, Angus Lees wrote: > (Context: https://review.openstack.org/#/c/117418/) > > I'm looking for some rough consensus on what naming conventions we want for > unused variables in Neutron, and across the larger OpenStack python codebase > since there's no reason for Neutron to

Re: [openstack-dev] [api] Forming the API Working Group

On 10/13/2014 07:11 PM, Christopher Yeoh wrote: On Mon, 13 Oct 2014 10:52:26 -0400 Jay Pipes wrote: On 10/10/2014 02:05 AM, Christopher Yeoh wrote: I agree with what you've written on the wiki page. I think our priority needs to be to flesh out https://wiki.openstack.org/wiki/Governance/Propo

Re: [openstack-dev] [neutron][all] Naming convention for unused variables

+1 for readable, well-documented code On Mon, Oct 13, 2014 at 8:28 PM, Angus Lees wrote: > (Context: https://review.openstack.org/#/c/117418/) > > I'm looking for some rough consensus on what naming conventions we want for > unused variables in Neutron, and across the larger OpenStack python >

Re: [openstack-dev] [cinder] Any plan on cinder for kilo?

On 08:09 Tue 14 Oct , yoo bright wrote: > Hi, > I noticed nova has already opened blueprint and specs for kilo, so I was > wondering what is the plan on cinder for kilo? If I want to contribute some > code(add new feature) for cinder, whether the step is the same with nova > (need > write spe

Re: [openstack-dev] [api] Forming the API Working Group

2014-10-13 16:52 GMT+02:00 Jay Pipes : > On 10/10/2014 02:05 AM, Christopher Yeoh wrote: >> >> I agree with what you've written on the wiki page. I think our priority >> needs to be to flesh out >> https://wiki.openstack.org/wiki/Governance/Proposed/APIGuidelines >> so we have something to referenc

[openstack-dev] [kolla] on Dockerfile patterns

I've been reading a bunch of the existing Dockerfiles, and I have two humble requests: 1. It would be good if the "interesting" code came from python sdist/bdists rather than rpms. This will make it possible to rebuild the containers using code from a private branch or even unsubmitted code,

Re: [openstack-dev] [api] Forming the API Working Group

On Mon, 13 Oct 2014 22:20:32 -0400 Jay Pipes wrote: > On 10/13/2014 07:11 PM, Christopher Yeoh wrote: > > On Mon, 13 Oct 2014 10:52:26 -0400 > > Jay Pipes wrote: > > > >> On 10/10/2014 02:05 AM, Christopher Yeoh wrote: > >>> I agree with what you've written on the wiki page. I think our > >>> pr

Re: [openstack-dev] [api] Forming the API Working Group

On Tue, 14 Oct 2014 05:27:21 +0200 "Ken'ichi Ohmichi" wrote: > 2014-10-13 16:52 GMT+02:00 Jay Pipes : > > On 10/10/2014 02:05 AM, Christopher Yeoh wrote: > >> > >> I agree with what you've written on the wiki page. I think our > >> priority needs to be to flesh out > >> https://wiki.openstack.org

[openstack-dev] [bashate] towards "inbox zero" on bashate changes, release?

Hi, I took the liberty of rebasing and approving the fairly obvious and already +1'd bashate changes today that had been sitting for quite a while. What's left is minimal and fall into three categories 1) changes for auto-detection. IMO, we should drop all these and just leave bashate as tak

Re: [openstack-dev] Neutron documentation to update about new vendor plugin, but without code in repository?

I agree with Kevin and Kyle. Even if we decided to use separate tree for neutron plugins and drivers, they still will be regarded as part of the upstream. These plugins/drivers need to prove they are well integrated with Neutron master in some way and gating integration proves it is well tested and

[openstack-dev] [gantt] Scheduler group meeting - Agenda 10/14

1) Forklift status 2) Kilo Summit sessions 3) Kilo BPs 4) Opens -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale Ph: 303/443-3786 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailma

Re: [openstack-dev] [Fuel] [Rally] Using fuelclient as a library - battle report

Mike, I never mentioned us having any fork. What I said is that fuelclient is not currently usable as a library and that is why we are more inclined to write our own client that solves the limited scope of our problems. On Mon, Oct 13, 2014 at 11:53 AM, Mike Scherbakov wrote: > Ilya, > would th