Re: [openstack-dev] [nova] How to fix the wrong usage of 'format' jsonschema keyword in server create API

Hi Alex, Thanks for pointing this up. 2016-03-06 22:18 GMT-08:00 Alex Xu : > > Due to this regression bug https://launchpad.net/bugs/1552888, found we are > using 'formart' jsonschema keyword in wrong way. The 'format' is not only > for string instance, but all the types. > > So checking the serv

Re: [openstack-dev] [nova][all] Deprecation policy between projects

Hi Gordon, Thank you for the advice, that is very useful for me now :-) Thanks Ken Ohmichi --- 2016-02-15 18:35 GMT-08:00 gordon chung : > > > On 14/02/2016 8:32 AM, Ken'ichi Ohmichi wrote: >> Hi, >> >> Do we have any deprecation policies between projects? >

Re: [openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

2016-02-12 19:06 GMT-08:00 Adam Young : > On 02/12/2016 06:17 AM, Eoghan Glynn wrote: >>> >>> tl;dr >>> = >>> >>> I have long thought that the OpenStack Summits have become too >>> commercial and provide little value to the software engineers >>> contributing to OpenStack. >>> >>> I propose the

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

2016-02-12 11:19 GMT-08:00 Andrew Laski : > On Fri, Feb 12, 2016, at 01:45 PM, John Garbutt wrote: >> On 12 February 2016 at 18:17, Andrew Laski wrote: >> > >> > >> > On Fri, Feb 12, 2016, at 12:15 PM, Matt Riedemann wrote: >> >> Forgive me for thinking out loud, but I'm trying to sort out how nov

[openstack-dev] [nova][all] Deprecation policy between projects

Hi, Do we have any deprecation policies between projects? When we can remove old drivers of the other projects after they were marked as deprecated? In nova, there are many drivers for the other projects and there are patches which remove this kind of code. (e.g: https://review.openstack.org/#/c/2

Re: [openstack-dev] [nova][API] Question about HTTPNotImplementError

Hi Chen, The API guideline came from this Nova's implementation. 501 case is not exception of microversion bumping[1] on Nova's rule now, so I feeling we need a new microversion if changing the 501 response to the other on *current rule*. However, such microversion seems a little overkill for me.

Re: [openstack-dev] [api] service type vs. project name for use in headers

2016-01-28 5:37 GMT+09:00 Ryan Brown : >> >> I think we would be better served in selecting these things thinking >> about the API consumers first. We already have enough for them to wade >> through, the API-WG is making great gains in herding those particular >> cats, I would hate to see giving

Re: [openstack-dev] [api][all] api variation release by release

Thanks for pointing the history out, Matt. According to this thread, I feel the NOTE of each release maximum microversion will help for users because many clouds are deployed from certain releases. https://review.openstack.org/#/c/267247/ is doing that. Thanks Ken Ohmichi 2016-01-13 11:55 GMT+0

Re: [openstack-dev] [QA] Meeting Thursday January 7th at 9:00 UTC

Sorry, as http://lists.openstack.org/pipermail/openstack-dev/2016-January/083397.html the next meeting should be scheduled at 1700 UTC, not 0900 UTC. Thanks 2016-01-07 11:27 GMT+09:00 Ken'ichi Ohmichi : > Hi everyone, > > Please reminder that the weekly OpenStack QA team IRC m

[openstack-dev] [QA] Meeting Thursday January 7th at 9:00 UTC

Hi everyone, Please reminder that the weekly OpenStack QA team IRC meeting will be Thursday, January 7th at 9:00 UTC in the #openstack-meeting channel. The agenda for the meeting can be found here: https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_January_7th_2016_.28170

[openstack-dev] [nova][api] does validation bug-fix require microversion bump?

Hi nova-api team, I'd like to get a feedback about the way to bump a microversion. Short version: We found a validation bug on Nova v2.1 API. To fix the bug, do we need to bump a new microversion? Long version: As LP bug report[1], nova v2.0 API allows a list of server-IDs on scheduler_hint

Re: [openstack-dev] [Keystone][Tempest] OS-INHERIT APIs were skipped by Jenkins because "os_inherit" in keystone.conf was disable.

A devstack patch is https://review.openstack.org/#/c/257085/ for enabling os_inherit extension. 2015-12-14 10:43 GMT+09:00 Ken'ichi Ohmichi : > Hi Henry, > > When adding this extension on https://review.openstack.org/#/c/35986/ > , the extension is disabled as the default sett

Re: [openstack-dev] [Keystone][Tempest] OS-INHERIT APIs were skipped by Jenkins because "os_inherit" in keystone.conf was disable.

Hi Henry, When adding this extension on https://review.openstack.org/#/c/35986/ , the extension is disabled as the default setting. Now can we enable this os_inherit extension on Keystone side like keystone/common/config.py 'os_inherit': [ - cfg.BoolOpt('enabled', default=False, +

Re: [openstack-dev] [nova] jsonschema for scheduler hints

2015-12-09 21:20 GMT+09:00 Sean Dague : > On 12/08/2015 11:47 PM, Ken'ichi Ohmichi wrote: >> Hi Sylvain, >> >> 2015-12-04 17:48 GMT+09:00 Sylvain Bauza : >>>> >>>> That leaves the out-of-tree discussion about custom filters and how we >>&g

Re: [openstack-dev] [nova] jsonschema for scheduler hints

2015-12-09 6:02 GMT+09:00 Andrew Laski : >> >> I'm fine with a new RPC call for getting the schema, but as I explained, I >> think the schema should be accepting all the in-tree filter hints (ie. >> nova.scheduler.filters.all_filters method), not only those which are enabled >> (ie. scheduler_defau

Re: [openstack-dev] [nova] jsonschema for scheduler hints

Hi Sylvain, 2015-12-04 17:48 GMT+09:00 Sylvain Bauza : >> >> That leaves the out-of-tree discussion about custom filters and how we >> could have a consistent behaviour given that. Should we accept something in >> a specific deployment while another deployment could 401 against it ? Mmm, >> bad to

Re: [openstack-dev] [keystone][doc][tempest] What title should be for OS-KSCRUD extension

dmin_crud) which does not require the original password: >> >> >> https://github.com/openstack/keystone/blob/master/keystone/contrib/admin_crud/core.py#L104-L114 >> >> On Tue, Dec 8, 2015 at 8:56 PM, Ken'ichi Ohmichi >> wrote: >>> >>> Hi

[openstack-dev] [keystone][doc][tempest] What title should be for OS-KSCRUD extension

Hi Keystone-team, TL;DR: Keystone v2 API supports PATCH on '/OS-KSCRUD/users/{user_id}', What should we name the operation for? We are adding the api-site link to Tempest docstring for explaining how to use each REST APIs of each project. This work comes from previous discussion on openstack-

[openstack-dev] [nova][doc][tempest] How to handle HTTP203

Hi, Today, we have virtual API document sprint and we are facing a problem related to HTTP203 (Non-Authoritative Information). The api-site(http://developer.openstack.org/api-ref-compute-v2.1.html) contains HTTP203 as one of valid status codes for each API operation, but nova implementation code d

Re: [openstack-dev] [nova] jsonschema for scheduler hints

Hi Sean, 2015-12-02 23:23 GMT+09:00 Sean Dague : > We have previously agreed that scheduler hints in Nova are an open ended > thing. It's expected for sites to have additional scheduler filters > which expose new hints. The way we handle that with our strict > jsonschema is that we allow additiona

Re: [openstack-dev] [QA][Tempest] Use tempest-config for tempest-cli-improvements

cess >>> tests and only 24 skipped. Also, there is a patch, which adds x-fail >>> mechanism(it based on subunit-filter): you can transmit a file with test >>> names + reasons and rally will modify results. >>> >>> [1] - https://review.openstack.org/#/c/94473/

Re: [openstack-dev] [QA] Meeting Thursday November 26th at 9:00 UTC

view https://review.openstack.org/#/c/225575 - Will do Thanks Ken Ohmichi --- 2015-11-26 15:14 GMT+09:00 Ken'ichi Ohmichi : > Hi everyone, > > Please reminder that the weekly OpenStack QA team IRC meeting will be > Thursday, November 26th at 9:00 UTC in the #openstack-meeting channel. >

Re: [openstack-dev] [QA][Tempest] Use tempest-config for tempest-cli-improvements

Hi Daniel, Thanks for pointing this up. 2015-11-25 1:40 GMT+09:00 Daniel Mellado : > Hi All, > > As you might already know, within Red Hat's tempest fork, we do have one > tempest configuration script which was built in the past by David Kranz [1] > and that's been actively used in our CI system.

[openstack-dev] Fwd: [QA] Meeting Thursday November 26th at 9:00 UTC

Hi everyone, Please reminder that the weekly OpenStack QA team IRC meeting will be Thursday, November 26th at 9:00 UTC in the #openstack-meeting channel. The agenda for the meeting can be found here: https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_November_26th_2015_.2

Re: [openstack-dev] [ironic][tempest]Tempest test plugin and microversions

Hi, Nice description for our situation. Yes, qa-spec of microversions testing is already approved. But as you said, we need time for the implementation. Your migration patch for ironic doesn't seem hard to be merged, I feel. So it is also nice option to merge the migration patch first. Technicall

Re: [openstack-dev] [QA] Meeting Thursday November 12th at 9:00 UTC

Hi everyone, # Sorry for sending this main again. # My previous mail contains some bugs. Please reminder that the weekly OpenStack QA team IRC meeting will be Thursday, November 12th at 9:00 UTC in the #openstack-meeting channel. The agenda for the meeting can be found here: https://wiki.opensta

[openstack-dev] [QA] Meeting Thursday November 12th at 9:00 UTC

[QA] Meeting Thursday November 12th at 9:00 UTC Hi everyone, Please reminder that the weekly OpenStack QA team IRC meeting will be Thursday, October 1st at 9:00 UTC in the #openstack-meeting channel. The agenda for the meeting can be found here: https://wiki.openstack.org/wiki/Meetings/QATeamMee

[openstack-dev] [QA][Tempest] Working items for service clients

Hi, As we discussed in Tokyo summit[1], we need to implement service clients for tempest-lib. And we can get many volunteers for doing that. I have prepared an etherpad for managing this working items on the following: https://etherpad.openstack.org/p/mitaka-tempest-service-clients If you are in

Re: [openstack-dev] [nova] Proposal to add Alex Xu to nova-core

+1 for Alex. He is helping us in long term :-) 2015-11-07 0:32 GMT+09:00 John Garbutt : > Hi, > > I propose we add Alex Xu[1] to nova-core. > > Over the last few cycles he has consistently been doing great work, > including some quality reviews, particularly around the API. > > Please respond wit

Re: [openstack-dev] [nova] Proposal to add Sylvain Bauza to nova-core

+1 for Sylvain :-) 2015-11-07 0:32 GMT+09:00 John Garbutt : > Hi, > > I propose we add Sylvain Bauza[1] to nova-core. > > Over the last few cycles he has consistently been doing great work, > including some quality reviews, particularly around the Scheduler. > > Please respond with comments, +1s,

[openstack-dev] [QA] Meeting Thursday October 1st at 9:00 UTC

Hi everyone, Please reminder that the weekly OpenStack QA team IRC meeting will be Thursday, October 1st at 9:00 UTC in the #openstack-meeting channel. The agenda for the meeting can be found here: https://wiki.openstack.org/wiki/Meetings/QATeamMeeting Anyone is welcome to add an item to the agen

Re: [openstack-dev] [murano] Fix order of arguments in assertEqual

Hi 2015-09-29 10:09 GMT+09:00 Ian Wienand : > On 09/24/2015 08:18 PM, Andrey Kurilin wrote: >> >> I agree that wrong order of arguments misleads while debugging errors, BUT >> how we can prevent regression? > > > Spell it out and use keyword args? > > assertEqual(expected="foo", observed=...) >

Re: [openstack-dev] [nova] API v2.1 reference documentation

Hi Melanie, 2015-09-09 8:00 GMT+09:00 melanie witt : > Hi All, > > With usage of v2.1 picking up (devstack) I find myself going to the API ref > documentation [1] often and find it lacking compared with the similar v2 doc > [2]. I refer to this doc whenever I see a novaclient bug where something

Re: [openstack-dev] Should v2 compatibility mode (v2.0 on v2.1) fixes be applicable for v2.1 too?

2015-09-08 19:45 GMT+09:00 Sean Dague : > On 09/06/2015 11:15 PM, GHANSHYAM MANN wrote: >> Hi All, >> >> As we all knows, api-paste.ini default setting for /v2 was changed to >> run those on v2.1 (v2.0 on v2.1) which is really great think for easy >> code maintenance in future (removal of v2 code).

Re: [openstack-dev] Scheduler hints, API and Objects

Hi Sylvain, 2015-09-04 19:56 GMT+09:00 Sylvain Bauza : > > > Le 04/09/2015 12:18, Ken'ichi Ohmichi a écrit : > > Hi Alex, > > Thanks for your comment. > IMO, this idea is different from the extension we will remove. > That is modularity for the maintenance burden

Re: [openstack-dev] Scheduler hints, API and Objects

Hi Andrew, 2015-09-04 23:45 GMT+09:00 Andrew Laski : >>> >>> Now we are discussing this on https://review.openstack.org/#/c/217727/ >>> for allowing out-of-tree scheduler-hints. >>> When we wrote API schema for scheduler-hints, it was difficult to know >>> what are available API parameters for sch

Re: [openstack-dev] Scheduler hints, API and Objects

Hi Alex, Thanks for your comment. IMO, this idea is different from the extension we will remove. That is modularity for the maintenance burden. By this idea, we can put the corresponding schema in each filter. 2015年9月4日(金) 19:04 Alex Xu : > 2015-09-04 11:14 GMT+08:00 Ken'ichi Ohmichi :

Re: [openstack-dev] Scheduler hints, API and Objects

2015-09-04 12:14 GMT+09:00 Ken'ichi Ohmichi : > Hi Andrew, > > Sorry for this late response, I missed it. > > 2015-06-25 23:22 GMT+09:00 Andrew Laski : >> I have been growing concerned recently with some attempts to formalize >> scheduler hints, both with API vali

Re: [openstack-dev] Scheduler hints, API and Objects

Hi Andrew, Sorry for this late response, I missed it. 2015-06-25 23:22 GMT+09:00 Andrew Laski : > I have been growing concerned recently with some attempts to formalize > scheduler hints, both with API validation and Nova objects defining them, > and want to air those concerns and see if others a

[openstack-dev] [QA] Meeting Thursday September 3rd at 9:00 UTC

Hi everyone, Please reminder that the weekly OpenStack QA team IRC meeting will be Thursday, September 3th at 9:00 UTC in the #openstack-meeting channel. The agenda for the meeting can be found here: https://wiki.openstack.org/wiki/Meetings/QATeamMeeting Anyone is welcome to add an item to the ag

Re: [openstack-dev] [Neutron] Netaddr 0.7.16 and gate breakage

Yeah, The latest netaddr seems broken. The behavior is changed like * PREVIOUS: netaddr-0.7.15 >>> import netaddr >>> >>> mac = 'fa:16:3e:4e:a1:0a' >>> netaddr.valid_mac(mac) True >>> * LATEST: netaddr-0.7.16 >>> import netaddr >>> mac = 'fa:16:3e:4e:a1:0a' >>> netaddr.valid_mac(mac) False >>>

Re: [openstack-dev] [api] [docs] Generating API samples

2015-08-26 12:15 GMT+09:00 GHANSHYAM MANN : > Hi Ken'ichi, Nice idea. > > On Wed, Aug 26, 2015 at 11:36 AM, Ken'ichi Ohmichi > wrote: >> Hi Anne, Nova API guys, >> >> I'd like to explain how to generate API docs from Tempest log. >> >

Re: [openstack-dev] [api] [docs] Generating API samples

ma or by hands. Any thought? Thanks Ken Ohmichi --- [1]: http://specs.openstack.org/openstack/qa-specs/specs/tempest-external-plugin-interface.html 2015-08-26 10:36 GMT+09:00 Ken'ichi Ohmichi : > Hi Anne, > > 2015-08-25 0:51 GMT+09:00 Anne Gentle : >> Hi all, >> >&g

Re: [openstack-dev] [api] [docs] Generating API samples

Hi Anne, 2015-08-25 0:51 GMT+09:00 Anne Gentle : > Hi all, > > I'm writing to find out how teams keep API sample requests and responses > up-to-date. I know the nova team has a sample generator [1] that they've > maintained for a few years now. Do other teams have something similar? If > so, is yo

Re: [openstack-dev] [QA][tempest] schema extensions

Hi Viktor, 2015-08-17 23:26 GMT-07:00 Tikkanen, Viktor (Nokia - FI/Espoo) : > > I have I question regarding validating responses during API tests. > > Has it been decided some time ago that no additional properties > are allowed when verifying response schemas during API tests? There was the rela

Re: [openstack-dev] [Tempest] Can we add testcase for download image v2?

" Hi Deore, 2015-08-13 15:33 GMT+09:00 Deore, Pranali11 : > Hi, > > > > While going through the tempest code, I have found that image-download v2 > api test is missing in tempest. > > Can I add the api test for the same? Please suggest? I guess https://github.com/openstack/tempest/blob/master/te

Re: [openstack-dev] [nova] change of day for API subteam meeting?

Nice idea :-) 2015年8月8日(土) 9:05 Alex Xu : > > > 在 2015年8月8日，上午12:48，Sean Dague 写道： > > > > Friday's have been kind of a rough day for the Nova API subteam. It's > > already basically the weekend for folks in AP, and the weekend is right > > around the corner for everyone else. > > > > I'd like t

[openstack-dev] [QA] Meeting Thursday August 6th at 9:00 UTC

Hi everyone, As Matt said on http://lists.openstack.org/pipermail/openstack-dev/2015-July/070213.html , the alternative time slot of QA meeting is changed to 9:00 UTC. Please reminder that the weekly OpenStack QA team IRC meeting will be tomorrow Thursday, August 6th at 9:00 UTC in the #openstack

Re: [openstack-dev] [qa][tempest] "kwargs" of service clients for POST/PUT methods

that ? ( > the topic has been mentioned in yesterday's QA meeting). > > Jordan > On Fri, Jul 10, 2015 at 9:02 AM, Ken'ichi Ohmichi > wrote: > >> Hi Anne, >> >> 2015-07-09 12:22 GMT+09:00 Anne Gentle : >> > On Wed, Jul 8, 2015 at 9:48 PM, GH

Re: [openstack-dev] [keystone] the status of ec2 api

Hi Brant, 2015-07-30 3:50 GMT+09:00 Brant Knudson : >> On Mon, Jul 13, 2015 at 9:50 PM, Ken'ichi Ohmichi >> wrote: >>> >>> Hi Keystone team, >>> >>> Now the test of ec2 credentials[1] is been proposed to Tempest, and >>> I'd

Re: [openstack-dev] [nova] Why is osapi_v3.enabled = False by default?

2015-07-16 3:03 GMT+09:00 Sean Dague : > On 07/15/2015 01:44 PM, Matt Riedemann wrote: >> The osapi_v3.enabled option is False by default [1] even though it's >> marked as the CURRENT API and the v2 API is marked as SUPPORTED (and >> we've frozen it for new feature development). >> >> I got looking

[openstack-dev] [keystone] the status of ec2 api

Hi Keystone team, Now the test of ec2 credentials[1] is been proposed to Tempest, and I'd like to know current situation of ec2 api on Keystone as a Tempest reviewer. On Nova instead, ec2 api is deprecated in Nova and the standalone service of ec2 api is separated from Nova to https://github.com/

Re: [openstack-dev] [qa][tempest] "kwargs" of service clients for POST/PUT methods

Hi Anne, 2015-07-09 12:22 GMT+09:00 Anne Gentle : > On Wed, Jul 8, 2015 at 9:48 PM, GHANSHYAM MANN > wrote: >> On Thu, Jul 9, 2015 at 9:39 AM, Ken'ichi Ohmichi >> wrote: >> > 2015-07-08 16:42 GMT+09:00 Ken'ichi Ohmichi : >> >> 2015-07-08 14:0

Re: [openstack-dev] [qa][tempest] "kwargs" of service clients for POST/PUT methods

2015-07-08 16:42 GMT+09:00 Ken'ichi Ohmichi : > 2015-07-08 14:07 GMT+09:00 GHANSHYAM MANN : >> On Wed, Jul 8, 2015 at 12:27 PM, Ken'ichi Ohmichi >> wrote: >>> >>> By defining all parameters on each method like update_quota_set(), it >>> is ea

Re: [openstack-dev] [qa][tempest] "kwargs" of service clients for POST/PUT methods

Hi Ghansyham, Thank you for your comment. 2015-07-08 14:07 GMT+09:00 GHANSHYAM MANN : > On Wed, Jul 8, 2015 at 12:27 PM, Ken'ichi Ohmichi > wrote: >> >> By defining all parameters on each method like update_quota_set(), it >> is easy to know what parameters are av

[openstack-dev] [qa][tempest] "kwargs" of service clients for POST/PUT methods

Hi tempest team, We are working for refactoring service clients in tempest for preparing to migrate them to tempest-lib, and I found an inconsistency between them. So I'd like to ask opinions for considering which is the best as library methods. On some methods, a caller can specify whole body fo

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

2015-06-26 4:21 GMT+09:00 Dean Troyer : > On Thu, Jun 25, 2015 at 7:10 AM, Sean Dague wrote: >> >> For someone that's extremely familiar with what they are doing, they'll >> understand that http://service.provider/compute is Nova, and can find >> their way to Nova docs on the API. But for new folk

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

2015-06-25 18:16 GMT+09:00 Dmitry Tantsur : > On 06/25/2015 11:11 AM, Ken'ichi Ohmichi wrote: >> >> 2015-06-25 17:31 GMT+09:00 Dmitry Tantsur : >>> >>> On 06/25/2015 10:18 AM, Ken'ichi Ohmichi wrote: >>>> >>>> >>>> Sorr

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

2015-06-25 17:31 GMT+09:00 Dmitry Tantsur : > On 06/25/2015 10:18 AM, Ken'ichi Ohmichi wrote: >> >> Sorry for late response here, >> >> 2015-06-20 9:14 GMT+09:00 Devananda van der Veen >> : >>> >>> >>> Long version... >>&

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

2015-06-25 17:25 GMT+09:00 Lucas Alvares Gomes : > Hi, > >> If renaming "Ironic" to the other, is it still necessary to keep the >> name in the header? >> There are some projects which are already renamed like Neutron, Zaqar >> and the others. >> So "OpenStack-API-Version" which doesn't contain pro

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

Sorry for late response here, 2015-06-20 9:14 GMT+09:00 Devananda van der Veen : > > Long version... > Every HTTP response from Ironic today includes three headers: min, max, and > version. The service can present an older API version, as long as it is > greater-than-or-equal-to the minimum suppor

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

2015-06-20 4:40 GMT+09:00 Devananda van der Veen : >> >> > * We have a vendor endpoint. This endpoint allows vendor to extend our >> > API to expose new hardware capabilities that aren't present in the >> > core API. Once multiple vendors starts implementing the same feature >> > on this endpoint w

Re: [openstack-dev] [QA][Tempest] Proposing Jordan Pittier for Tempest Core

+1 :-) 2015年6月23日(火) 5:24 Matthew Treinish : > > > Hi Everyone, > > I'd like to propose we add Jordan Pittier (jordanP) to the tempest core > team. > Jordan has been a steady contributor and reviewer on tempest over the past > few > cycles and he's been actively engaged in the Tempest community.

Re: [openstack-dev] [QA] [Ironic] [Inspector] Where should integration tests for non-core projects live now? (Was: Toward 2.0.0 release)

2015-06-17 12:38 GMT+09:00 Yuiko Takada : > > Then, as you and Matt and Dimitry talked about this on IRC few days ago, > We can add Ironic/Ironic-inspector tests into Tempest still, right? > So that I've started to implement a test in Tempest, > but I'm facing another issue. > As you know, Ironic A

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

2015-06-16 21:14 GMT+09:00 Sean Dague : > On 06/16/2015 07:38 AM, Alex Xu wrote: >> >> >> 2015-06-16 18:57 GMT+08:00 Sean Dague > >: >> >> On 06/15/2015 03:45 PM, Kevin L. Mitchell wrote: >> > On Mon, 2015-06-15 at 13:07 -0400, Jay Pipes wrote: >> >> The original

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

2015-06-16 21:16 GMT+09:00 Jay Pipes : > On 06/16/2015 08:00 AM, Dmitry Tantsur wrote: >> >> >> 16 июня 2015 г. 13:52 пользователь "Jay Pipes" > > написал: >> > >> > On 06/16/2015 04:36 AM, Alex Xu wrote: >> >> >> >> So if our min_version is 2.1 and the max_version is

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

2015-06-16 20:52 GMT+09:00 Jay Pipes : > >> but I have the same question with Dmitry. >> If using service names in the header, how to define these name before >> that? >> Current big-tent situation can make duplications between projects like >> X-OpenStack-Container-API-Version or something. >> Pro

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

2015-06-16 6:30 GMT+09:00 Michael Davies : > On Tue, Jun 16, 2015 at 5:15 AM, Kevin L. Mitchell > wrote: >> >> Given the disagreement evinced by the responses to this thread, let me >> ask a question: Would there be any particular problem with using >> "X-OpenStack-API-Version"? > > > Well, perhap

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

2015-06-16 2:07 GMT+09:00 Jay Pipes : > It has come to my attention in [1] that the microversion spec for Nova [2] > and Ironic [3] have used the project name -- i.e. Nova and Ironic -- instead > of the name of the API -- i.e. "OpenStack Compute" and "OpenStack Bare > Metal" -- in the HTTP header t

Re: [openstack-dev] [QA] [Ironic] [Inspector] Where should integration tests for non-core projects live now? (Was: Toward 2.0.0 release)

2015-06-10 16:48 GMT+09:00 Dmitry Tantsur : > On 06/10/2015 09:40 AM, Ken'ichi Ohmichi wrote: >> To solve it, we have decided the scope of Tempest as the etherpad >> mentioned. >> >>> Are there any hints now on where we can start with our integration tests? >

Re: [openstack-dev] [QA] [Ironic] [Inspector] Where should integration tests for non-core projects live now? (Was: Toward 2.0.0 release)

external interfaces of Tempest on the summit, so that Tempest gathers tests from each project repository and runs them at the same time. There is a qa-spec for https://review.openstack.org/#/c/184992/ Thanks Ken'ichi Ohmichi > On 06/10/2015 08:07 AM, Yuiko Takada wrote: >> >>

Re: [openstack-dev] [nova] Proposal to add Melanie Witt to nova-core

+1 :) 2015-04-30 20:30 GMT+09:00 John Garbutt : > Hi, > > I propose we add Melanie to nova-core. > > She has been consistently doing great quality code reviews[1], > alongside a wide array of other really valuable contributions to the > Nova project. > > Please respond with comments, +1s, or objec

Re: [openstack-dev] [qa] official clients and tempest

2015-04-14 8:04 GMT+09:00 Matthew Treinish : > On Thu, Apr 09, 2015 at 11:05:10AM +0900, Ken'ichi Ohmichi wrote: >> 2015-04-09 4:14 GMT+09:00 Sean Dague : >> > On 04/08/2015 02:58 PM, David Kranz wrote: >> >> On 04/08/2015 02:36 PM, Matthew Treinish wrote: >&g

Re: [openstack-dev] [qa] official clients and tempest

2015-04-09 4:14 GMT+09:00 Sean Dague : > On 04/08/2015 02:58 PM, David Kranz wrote: >> On 04/08/2015 02:36 PM, Matthew Treinish wrote: >>> On Wed, Apr 08, 2015 at 01:08:03PM -0400, David Kranz wrote: Since tempest no longer uses the official clients as a literal code dependency, except fo

Re: [openstack-dev] In loving memory of Chris Yeoh

2015-04-08 13:49 GMT+09:00 Michael Still : > It is my sad duty to inform the community that Chris Yeoh passed away this > morning. Chris leaves behind a daughter Alyssa, aged 6, who I hope will > remember Chris as the clever and caring person that I will remember him as. > I haven’t had a chance to

[openstack-dev] [qa][nova][ironic] How to run microversions tests on the gate

Hi, Now Nova and Ironic have implemented API microversions in Kilo. Nova's microversions are v2.1 - v2.3. Ironic's microversions are v1.1 - v1.6. Now Tempest is testing the lowest microversion on the gate, and Ironic's microversions test patch[1] is on the gerrit. Before merging the patch, I'd li

Re: [openstack-dev] [nova] how to handle vendor-specific API microversions?

2015-03-28 4:03 GMT+09:00 Chris Friesen : > On 03/27/2015 12:44 PM, Dan Smith wrote: >>> >>> To quote John from an earlier email in this thread: >>> >>> Its worth noting, we do have the "experimental" flag: >>> " >>> The first header specifies the version number of the API which was >>> executed. E

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

2015-03-24 23:20 GMT+09:00 Joe Gordon : > On Tue, Mar 24, 2015 at 7:10 AM, Jay Pipes wrote: >> On Tue, Mar 24, 2015 at 01:04:46PM +, Jeremy Stanley wrote: >> > On 2015-03-23 21:31:30 -0400 (-0400), Jay Pipes wrote: >> > > On Mon, Mar 23, 2015 at 09:35:50PM +, Jeremy Stanley wrote: >> > > >

Re: [openstack-dev] [nova] what is our shipped paste.ini going to be for Kilo

2015-03-17 11:56 GMT+09:00 Robert Collins : > On 17 March 2015 at 14:27, Ken'ichi Ohmichi wrote: > >>> I am worried about SDKs making requests that have additional JSON >>> attributes that were previously ignored by v2, but will be considered >>> invalid by t

Re: [openstack-dev] [nova] what is our shipped paste.ini going to be for Kilo

2015-03-17 0:08 GMT+09:00 John Garbutt : > On 16 March 2015 at 14:15, Sean Dague wrote: >> Our current top level shipped example paste.ini for Nova includes the >> following set of endpoint definitions: >> >> [composite:osapi_compute] >> use = call:nova.api.openstack.urlmap:urlmap_factory >> /: os

Re: [openstack-dev] [nova] what is our shipped paste.ini going to be for Kilo

Hi Sean, 2015-03-16 23:15 GMT+09:00 Sean Dague : > Our current top level shipped example paste.ini for Nova includes the > following set of endpoint definitions: > > [composite:osapi_compute] > use = call:nova.api.openstack.urlmap:urlmap_factory > /: oscomputeversions > /v1.1: openstack_compute_ap

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

2015-03-09 20:36 GMT+09:00 Christopher Yeoh : > > > On Mon, Mar 9, 2015 at 9:35 PM, Sean Dague wrote: >> >> On 03/07/2015 07:31 PM, Jay Pipes wrote: >> > Hi Stackers, >> > >> > Now that microversions have been introduced to the Nova API (meaning we >> > can now have novaclient request, say, versio

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

Hi, 2015-03-09 20:38 GMT+09:00 John Garbutt : > On 8 March 2015 at 12:10, Alex Xu wrote: >> Thanks for Jay point this out! If we have agreement on this and document it, >> that will be great for guiding developer how to add new API. > > +1 > > Please could you submit a dev ref for this? > > We ca

Re: [openstack-dev] [nova] Feature Freeze Exception request for x509 keypairs

2015-02-12 21:20 GMT+09:00 Claudiu Belu : > > Hello. > > I would like to ask for a FFE for the x509 keypairs blueprint: > https://blueprints.launchpad.net/nova/+spec/keypair-x509-certificates > > This blueprint is split up into 3 commits: > > [1] Database migration: previously merged, but had to be

Re: [openstack-dev] [nova][api] How to handle API changes in contrib/*.py

Hi Claudiu, 2015-02-03 7:51 GMT+09:00 Claudiu Belu : > > There have been some discussion on what nova-api should return after a > change in the API itself. > > So, the change that generated this discussion is an API change to 2.2 is: > https://review.openstack.org/#/c/140313/23 > > - **2.2** > >

Re: [openstack-dev] [nova] will the real v2.1/v3 API status please stand up?

2015-02-09 9:26 GMT+09:00 Christopher Yeoh : >> >> I wasn't at the mid-cycle meetup for Kilo but even for Juno I'll admit I >> was a bit lost. It's not my fault, I'm more good looks than brains. :) >> >> When I look at approved specs for Kilo, three pop out: >> >> 1. https://blueprints.launchpad.ne

Re: [openstack-dev] [api][nova] Openstack HTTP error codes

2015-01-30 18:13 GMT+09:00 Simon Pasquier : > On Fri, Jan 30, 2015 at 3:05 AM, Kenichi Oomichi > wrote: >> >> > -Original Message- >> > From: Roman Podoliaka [mailto:rpodoly...@mirantis.com] >> > Sent: Friday, January 30, 2015 2:12 AM >> > To: OpenStack Development Mailing List (not for us

Re: [openstack-dev] [QA] Moving tempest clients to tempest-lib (was Meeting Thursday January 8th at 22:00 UTC)

2015-01-21 12:08 GMT+09:00 Matthew Treinish : > On Wed, Jan 21, 2015 at 11:20:12AM +0900, Ken'ichi Ohmichi wrote: >> Hi David, >> >> As we told today, I tried Neutron service client migration to tempest-lib. >> but I found some blocking thing for it and I'd l

Re: [openstack-dev] [QA] Moving tempest clients to tempest-lib (was Meeting Thursday January 8th at 22:00 UTC)

-- >> From: David Kranz [mailto:dkr...@redhat.com] >> Sent: Wednesday, January 14, 2015 4:25 AM >> To: openstack-dev@lists.openstack.org >> Subject: Re: [openstack-dev] [QA] Moving tempest clients to tempest-lib (was >> Meeting Thursday January 8th at 22:00 UTC) >&

[openstack-dev] [nova] Requesting exception for JSON-Home spec

] for this feature, and I have known it is not difficult to implement this feature. Thanks Ken'ichi Ohmichi --- [1]: https://review.openstack.org/#/c/130715/ [2]: https://review.openstack.org/#/c/145100/ __ Open

Re: [openstack-dev] [QA] Meeting Thursday January 8th at 22:00 UTC

Hi, Unfortunately, I cannot join tomorrow meeting. So I'd like to share the progress of tempest-lib RestClient dev before the meeting. As Paris summit consensus, we have a plan to move RestClient from tempest to tempest-lib for moving API tests to each project in the future. And we are cleaning t

Re: [openstack-dev] Problem installing devstack

2015-01-06 12:40 GMT+09:00 Rajdeep Dua : > Getting this error while running stack.sh in devstack > > Could not find a version that satisfies the requirement > SQLAlchemy<=0.8.99,<=0.9.99,>=0.8.4,>=0.9.7 (from keystone==2014.2.dev114) > (from versions: 0.4.2p3, 0.4.7p1, 0.5.4p1, 0.5.4p2, 0.1.0, 0.1.

Re: [openstack-dev] [qa] How to delete a VM which is in ERROR state?

Hi, This case is always tested by Tempest on the gate. https://github.com/openstack/tempest/blob/master/tempest/api/compute/servers/test_delete_server.py#L152 So I guess this problem wouldn't happen on the latest version at least. Thanks Ken'ichi Ohmichi --- 2014-12-10 6:32 GMT

Re: [openstack-dev] [nova] policy on old / virtually abandoned patches

2014-11-18 21:06 GMT+09:00 Sean Dague : > Nova currently has 197 patches that have seen no activity in the last 4 > weeks (project:openstack/nova age:4weeks status:open). > > Of these > * 108 are currently Jenkins -1 (project:openstack/nova age:4weeks > status:open label:Verified<=-1,jenkins) > *

Re: [openstack-dev] [QA][All] Prelude to functional testing summit discussions

Hi Matt, Thanks for bringing this up, I am so interested in. 2014-10-30 1:30 GMT+09:00 Matthew Treinish : > > Before we start the larger discussion at summit next week about the future of > testing in OpenStack - specifically about spinning up functional testing and > how > it relates to tempest

Re: [openstack-dev] [api] Request Validation - Stoplight

Hi Chris, 2014-10-21 13:41 GMT+09:00 Christopher Yeoh : > > On Tue, Oct 21, 2014 at 12:15 PM, Kenichi Oomichi > wrote: >> >> Hi Amit, >> >> Thanks for picking this topic up, >> >> Honestly I don't have a strong opinion about validation libraries. >> Each project implements based on different web

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

Re: [openstack-dev] [Nova] Some ideas for micro-version implementation

'{"user": {"email": null, "password": null, "enabled": true, "name": "nobody", "tenantId": null}}' In this case, I hope Keystone can advertise the above attributes("email", "name", etc

[openstack-dev] [all] REST API style guide (Re: [Nova] Some ideas for micro-version implementation)

7;t show accurate internal status. So how about just using HTTP 200(OK) only for status codes? That would give up providing accurate internal status to clients but backwards backwards incompatibilities never happen. # just one stupid idea :) >> (3.2) Return 204(No Content) if a resource dele

Re: [openstack-dev] No one replying on tempest issue?Please share your experience

tBuildErrorException: Snapshot 6b1eb319-33ef-4357-987a-58eb15549520 > failed to build and is in > ERROR status What happens if running the same operation as Tempest by hands on your environment like the following ? [1] $ cinder create 1 [2

<    1   2   3   >