f the
>> current Tempest repository, into their own repo called
>> "openstack-integration-tests" or "os-integration-tests“.
>
> why not keeping it simple:
>
> tempest: importable test library
> tempest-tests:
2014-09-03 20:31 GMT+09:00 Gary Kotton :
>
> On 9/3/14, 12:50 PM, "Nikola Đipanov" wrote:
>
>>On 09/02/2014 09:23 PM, Michael Still wrote:
>>> On Tue, Sep 2, 2014 at 1:40 PM, Nikola Đipanov
>>>wrote:
On 09/02/2014 08:16 PM, Michael Still wrote:
> Hi.
>
> We're soon to hit feature
gt; https://review.openstack.org/#/c/11/
>
> They have all already been approved and were in the gate for a while
> but just didn't quite make it through in time. So they shouldn't put any
> load on reviewers.
>
> Sponsoring cores:
> Kenichi Ohmichi
> John Gar
ut it stops merging with temporary -2.
The other ones have gotten one +2 on each PS.
This work will make v2.1 API strong.
Thanks
Ken'ichi Ohmichi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailma
ck.org/#/c/114979/ : quota-sets API
https://review.openstack.org/#/c/115197/ : security_groups API
I think these API are used in many cases and important, so I'd like
to test v2.1 API with them together on RC phase.
Two of them have gotten one +2 on each PS and the other one
have gotten one +1.
2014-09-04 22:36 GMT+09:00 Sean Dague :
> On 09/04/2014 09:30 AM, Ken'ichi Ohmichi wrote:
>> Hi
>>
>> I'd like to request FFE for patches of v3-api-schema.
>> The list is the following:
>>
>> https://review.openstack.org/#/c/67428/
>
port quota information and the
> need to protect the change in V2 via yet another extension.
>
> https://review.openstack.org/#/c/104957/
> https://review.openstack.org/#/c/116073/
> https://review.openstack.org/#/c/116079/
I am happy to sponsor this work.
Thanks
Ken'ichi ohmichi
ou want!"
> Icehouse ?
> Juno "strict asci!"
> Kilo "utf8"
Correct validation history is
Essex: "use anything you want!"
Folsom: "strict asci!"
[..]
Juno: "strict asci!"
So I don't think we should make the input validation loose
S-EXT-STS:locked_by": null, "progress": 0,
"OS-EXT-STS:power_state": 1, "config_drive": "", "metadata": {}}]}
$
DevStack doesn't register v2.1 endpoint to keytone now, but we can use
it with calling it directly.
It is true that i
193/
The patch can avoid this problem 4 times, but I am not sure this is
worth or not.
Thanks
Ken'ichi Ohmichi
---
> 2) https://bugs.launchpad.net/bugs/1251784
> neutron, Nova
> 328 Hits
> 3) https://bugs.launchpad.net/bugs/1249065
> neutron
> 122 hits
> 4) https:
es at
> http://status.openstack.org/elastic-recheck/
Thank you for the info, that is interesting.
Thanks
Ken'ichi Ohmichi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
://review.openstack.org/#/c/59616/1/nova/api/openstack/compute/schemas/v3/agents_schema.py
Thanks
Ken'ichi Ohmichi
---
2013/12/7 David Kranz :
> On 11/13/2013 06:09 PM, Christopher Yeoh wrote:
>
> On Thu, Nov 14, 2013 at 7:52 AM, David Kranz wrote:
>>
>> On 11/13/2013 08:30 A
k you for pointing this bp out.
> I added the etherpad link Ken'ichi pointed to this bp. Ken'ichi, should you
> be the owner of this bp?
Unfortunately, I could not change the items of this bp from my
launchpad account.
Could you be the owner?
Thanks
Ken'ichi Ohmichi
---
>
Hi David,
2013/12/7 David Kranz :
> On 12/06/2013 03:57 PM, Ken'ichi Ohmichi wrote:
>>
>> Hi,
>>
>> We are implementing Nova v3 API validation with jsonschema.
>> The schemas of API parameters are defined under
>> nova/api/openstack/compute/schemas/
Hi Sean,
That is good idea, I also am in.
BTW, what time will this work start?
I tried to join this kind of work, but I could not find anyone on IRC
in my timezone.
Thanks
Ken'ichi Ohmichi
2014/1/9 Sean Dague :
> On 01/09/2014 08:01 AM, Thierry Carrez wrote:
>>
>&
i David, Marc,
I guess the negative test generator of Tempest would need each API definition.
Glance can provide API definitions through API with jsonschema format, but
Nova does not have such feature.
We need to port these API schema from Nova to Tempest, I guess. right?
Thanks
Ken'ich
Glance feature provides the schemas of request body only.
That does not contain the http method type and the endpoint.
> Additionally, the schema for the request json in these patches is not enough
> for the negative test generator. The schema for negative generation also
> needs the http
to pass arbitrary data, though.
> Part of the point of WSME is to define the inputs and outputs of the API for
> validation.
Is there a plan to release new WSME which includes new type classes?
I'd like to try applying these classes to Ceilometer after the release because
Ceilo
use of fixing the deserializing rule.
Thanks
Ken'ichi Ohmichi
---
> On 2014年01月13日 22:38, Sean Dague wrote:
>>
>> I know we've been here before, but I want to raise this again while there
>> is still time left in icehouse.
>>
>> I would like to propose
Hi Chris,
Thanks for your info, I got it.
That is a quick response and enough for me:-)
Thanks
Ken'ichi Ohmichi
---
2014-02-13 Christopher Yeoh :
> Hi Kenichi,
>
> Ah yes, it was decided at the mid cycle meetup to delay the nova network
> changes
> until Juno. Sorry I
ility issues happen. That is why we are implementing input
validation for
v3 API. If staying v2 API forever, we should have this kind of problem forever.
v2 API is fragile now. So the interoperability should depend on v2
API, that seems
sandbox.. (I know that it is a little overstatement, but we have
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
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.
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
] 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
--
>> 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)
>&
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
reciate if considering re-schedule of them.
>
> So, it sounds like just swapping the order of these two might fix the issue?
Yes, that would fix the issue.
Thanks for considering.
Thanks
Ken'ichi Ohmichi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--*---*---*---*--
>> Nova:new parameter 'A'
>> Tempest: define 'A' as 'required'
>>block 'A' removal block
>> ..
>>
in the jet lag Sunday, but the meet-up would be nice for me;-)
Thanks
Ken'ichi Ohmichi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Hi,
Since this is the scheduled off week, I'm going to cancel this week's
Nova API meeting.
The next meeting will be on May 8th and will be at 00:00 UTC.
Thanks
Ken'ichi Ohmichi
___
OpenStack-dev mailing list
OpenStack-dev@lists.ope
ps://review.openstack.org/#/c/87438 , I don't
have strong opinion for including the validation also. These schemas will be
large sometimes and the combination in the same patch would make reviews
difficult. In current Nova API test implementations, we are separating them
t.
http://junodesignsummit.sched.org/event/e3999a28ec02aa14b69ad67848be570a
Nova also contains request schema under
https://github.com/openstack/nova/tree/master/nova/api/openstack/compute/schemas/v3
These schemas are used only for Nova v3 API, there is nothing for v2
API(current) because
v2 API doe
e everything we expected.
Any thoughts?
Thanks
Ken'ichi Ohmichi
---
[1]: http://lists.openstack.org/pipermail/openstack-dev/2014-March/028724.html
http://lists.openstack.org/pipermail/openstack-dev/2014-February/027896.html
[2]:
https://review.openstack.org/#/q/status:open+proje
Hi Matthew,
2014-04-28 11:54 GMT+09:00 Ken'ichi Ohmichi :
> 2014-04-28 11:02 GMT+09:00 Matthew Treinish :
>> On Mon, Apr 28, 2014 at 01:01:00AM +, Kenichi Oomichi wrote:
>>>
>>> Now we are working for adding Nova API responses checks to Tempest[1] to
>>
# Sorry for sending this again, previous mail was unreadable.
2014-04-28 11:54 GMT+09:00 Ken'ichi Ohmichi :
>>
>> This is also why there are a bunch of nova v2 extensions that just add
>> properties to an existing API. I think in v3 the proposal was to do this with
&g
Hi David,
2014-05-07 22:53 GMT+09:00 David Kranz :
> I just looked at a patch https://review.openstack.org/#/c/90310/3 which was
> given a -1 due to not checking that every call to list_hosts returns 200. I
> realized that we don't have a shared understanding or policy about this. We
> need to mak
Hi Sean,
2014-05-07 23:28 GMT+09:00 Sean Dague :
> On 05/07/2014 10:23 AM, Ken'ichi Ohmichi wrote:
>> Hi David,
>>
>> 2014-05-07 22:53 GMT+09:00 David Kranz :
>>> I just looked at a patch https://review.openstack.org/#/c/90310/3 which was
>>> given
use of not
backporting the Nova patch into Icehouse branch yet.
I'm not sure we can backport this kind of patches into Icehouse
because Nova v3 API of Icehouse must be experimental in future.
So how about disabling v3 API tests in check-tempest-dsvm-full-icehouse?
Thanks
Ken'ichi Ohmichi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
2014-05-10 0:29 GMT+09:00 Matthew Treinish :
> On Thu, May 08, 2014 at 09:50:03AM -0400, David Kranz wrote:
>> On 05/07/2014 10:48 AM, Ken'ichi Ohmichi wrote:
>> >Hi Sean,
>> >
>> >2014-05-07 23:28 GMT+09:00 Sean Dague :
>> >>On 05/07/
2014-05-09 22:57 GMT+09:00 Matthew Treinish :
> On Fri, May 09, 2014 at 10:31:00PM +0900, Ken'ichi Ohmichi wrote:
>> 2014-05-09 15:00 GMT+09:00 Ghanshyam Mann
>> :
>> > Hi Sean,
>> >
>> >> -Original Message-
>> >> From: Sean Da
using to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated."
would fit to out of quota.
Thanks
Ken'ichi Ohmichi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
t is deprecated and I think we can disable them:
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L82
Thanks
Ken'ichi Ohmichi
---
> [1] https://review.openstack.org/#/c/98525/
[2] https://review.openstack.org/#/c/84695/
_
ose, much like checking/rechecking 3rd party CI results.
>>>
>>> One issue I've had with the nightly periodic job is finding out where
>>> the results are in an easy to consume format. Is there something out
>>> there for that? I'm thinkin
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
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
'{"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
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
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
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
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)
> *
need everyone that submitted specs to be around and active if we want to clear
> out the backlog.
>
> I'll send out another reminder the day before the review day.
+1 for qa-spec review day.
I've written it on my schedule.
Thanks
Ken'ichi Ohmichi
__
Hi Jay,
I faced the same problem and can pass it with adding the following line
into localrc:
LOGFILE=/opt/stack/logs/stack.sh.log
Thanks
Ken'ichi Ohmichi
---
2014-07-02 14:58 GMT+09:00 Jay Lau :
> Hi,
>
> Does any one encounter this error when install devstack? How did you
big +1 :-)
2014-07-30 14:56 GMT-07:00 Sean Dague :
> +1
>
> On 07/30/2014 02:19 PM, Chris Behrens wrote:
>> +1
>>
>> On Jul 30, 2014, at 2:02 PM, Michael Still wrote:
>>
>>> Greetings,
>>>
>>> I would like to nominate Jay Pipes for the nova-core team.
>>>
>>> Jay has been involved with nova for a
SON/XML samples and integration of them
> into the api documentation
> is all autogenerated via wsme?
>
I'm not good at this feature.
but Ceilometer's document(
http://docs.openstack.org/developer/ceilometer/webapi/v2.html) would be
generated from
https://github.com/openstack/ceilometer/blob/master/ceilometer/api/controllers/v2.py#L891
etc.
API samples also would be autogenerated from sample() method.
I hope some experts will help us about this feature.
The API sample implementations of Nova v3 API seemed very hard processes in
Havana cycle.
There are a lot of API parameters, and some API parameter names are renamed
to right ones.
Reviewers should check their name and the data types of API samples.
I feel this feature is good for Nova v3 API, but I'm not sure whether we
should replace with Pecan/WSME in Icehouse.
Thanks
Ken'ichi Ohmichi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
e tests, some patches have been queued already in Gerrit.
I wrote these patches' URLs on the etherpad.
I'm glad if developers check this contents before starting this work.
Thanks
Ken'ichi Ohmichi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
a, and it seems
working fine.
I have written it on https://etherpad.openstack.org/NovaApiValidationFramework
I think each project can select original WSME validation or jsonschema by its
necessity, when each project moves to Pecan/WSME in the future.
Thanks
Ken'ichi Ohmichi
+1
He gives good suggestions to my patch now :-)
On Wed, 26 Jun 2013 16:00:50 +
Qing He wrote:
>
> +1
>
> -Original Message-
> From: Dan Smith [mailto:d...@danplanet.com]
> Sent: Wednesday, June 26, 2013 8:25 AM
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-de
+1
On Tue, 02 Jul 2013 18:40:31 -0400
Russell Bryant wrote:
>
> Greetings,
>
> I would like to propose Christopher Yoeh to be added to the nova-core team.
>
> Christopher has been prolific in his contributions to nova lately, both
> in code and his general leadership of the v3 API effort. He
ml
- http://lists.openstack.org/pipermail/openstack-dev/2013-June/009970.html
- http://lists.openstack.org/pipermail/openstack-dev/2013-June/010057.html
[4]: http://lists.openstack.org/pipermail/openstack-dev/2013-June/010814.html
Thanks
Ken&#x
I.
* Possible to choose APIs which are applied with this framework.
We can apply this framework to Nova v3 API only, the existing API (v2) can
be out of scope of this framework.
* Possible to migrate other web framework.
The API validation of this framework is executed with the decorator o
Hi Russell,
I assigned you as the approver of bp "nova-api-validation-fw",
so could you take a look at this bp?
You have changed the priority from Medium to Low these days.
Could you show your concerns about this bp if you have.
Thanks
Ken'ichi Ohmichi
---
On Tue, 9 Jul 2013
l.
https://review.openstack.org/#/c/25358/
Thanks,
Ken'ichi Ohmichi
---
On Tue, 16 Jul 2013 13:37:15 +0900
"Ken'ichi Ohmichi" wrote:
>
> Hi Russell,
>
> I assigned you as the approver of bp "nova-api-validation-fw",
> so could you take a look at this bp
: Re: [openstack-dev] [Nova] Review request: Blurprint of API
> validation
>
>
>
>
> On Fri, Aug 2, 2013 at 4:35 PM, Russell Bryant wrote:
>
>
> On 07/09/2013 07:45 AM, Ken'ichi Ohmichi wrote:
> >
> > Hi,
> >
>
+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,
+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
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
[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
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
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
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
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.
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.
>
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/
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
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
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-
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
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
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
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
2016-05-29 19:25 GMT-07:00 Alex Xu :
>
>
> 2016-05-20 20:05 GMT+08:00 Sean Dague :
>>
>> There are a number of changes up for spec reviews that add parameters to
>> LIST interfaces in Newton:
>>
>> * keypairs-pagination (MERGED) -
>>
>> https://github.com/openstack/nova-specs/blob/8d16fc11ee6d01b5a
Hi,
There are many patches which are not updated in Tempest review queue
even if having gotten negative feedback from reviewers or jenkins.
Nova team is abandoning such patches like [1].
I feel it would be nice to abandone such patches which are not updated
since the end of 2015.
Any thoughts?
[1
Thanks for feedback here.
There are not any objections, so I will drop old code reviews on Tempest queue.
Thanks
Ken Ohmichi
---
2016-05-31 23:55 GMT-07:00 Masayuki Igawa :
> On Wed, Jun 1, 2016 at 3:05 AM, Andrea Frittoli
> wrote:
>> On Mon, 30 May 2016, 6:25 p.m. Ken'ichi O
2016-06-10 17:01 GMT-07:00 Assaf Muller :
> On Fri, Jun 10, 2016 at 12:02 PM, Andrea Frittoli
> wrote:
>> Dear all,
>>
>> I'm working on making the client manager in Tempest a stable interface, so
>> that in future it may be used safely by plugins to easily gain access
>> service clients [0].
>>
>
This discussion was expected when we implemented the Tempest patch,
then I sent a mail to defcore comittee[1]
As the above ml, "A DefCore Guideline typically covers three OpenStack
releases".
That means the latest guideline needs to cover Mitaka, Liberty and Kilo, right?
In the Kilo development, w
Hi Everyone,
As we've done the past 3 cycles we'll be having another QA/Infra code
sprint this cycle.
Previous code sprints were amazing, and we could concentrate on the
development with working together directly.
At this time, we have gotten an opportunity to hold a code sprint with
QA team and I
2016-06-14 17:00 GMT-07:00 Andrea Frittoli :
> Dear all,
>
> TL;DR: I'd like to propose to start running some of the existing dsvm
> check/gate jobs using Tempest pre-provisioned credentials.
>
> Full Text:
> Tempest provides tests with two mechanisms to acquire test credentials [0]:
> dynamic cred
2016-06-16 2:26 GMT-07:00 Morgan Fainberg :
> On Wed, Jun 15, 2016 at 11:54 PM, Ken'ichi Ohmichi
> wrote:
>>
>> This discussion was expected when we implemented the Tempest patch,
>> then I sent a mail to defcore comittee[1]
>> As the above ml, "A
2016-03-30 12:26 GMT-07:00 Sean Dague :
>
> One other issue that we've been blocking on for a while has been
> Capabilities discovery. Some API proposed adds like live resize have
> been conceptually blocked behind this one. Once upon a time there was a
> theory that JSON Home was a thing, and woul
2016-03-30 12:54 GMT-07:00 Matt Riedemann :
>>> - Microversion Testing in Tempest (underway)
>
> How much coverage do we have today? This could be like novaclient where
> people just start hacking on adding tests for each microversion (assuming
> gmann would be working on this).
Yeah, gmann is wor
I much prefer this lib work.
Thanks, Chris
2016/04/08 4:32、Chris Dent
>> On Thu, 7 Apr 2016, michael mccune wrote:
>>
>> 1. version discover guideline for API microversions
>> https://review.openstack.org/243429
>>
>> 2. client interaction guideline for API microversions
>> https://review.open
2016/04/08 10:55、Anita Kuno :
>> On 04/08/2016 01:42 PM, Dmitry Tantsur wrote:
>> 2016-04-08 19:26 GMT+02:00 Davanum Srinivas :
>>
>>> Team,
>>>
>>> Steve pointed out to a problem in Stackalytics:
>>> https://twitter.com/stevebot/status/718185667709267969
>>
>>
>> There are many ways to game
+1
Thanks for implementing microversion support, Andrey.
2016-04-13 10:53 GMT-07:00 Matt Riedemann :
> I'd like to propose that we make Andrey Kurilin core on python-novaclient.
>
> He's been doing a lot of the maintenance the last several months and a lot
> of times is the first to jump on any m
Hi,
Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, April 14th at 17:00 UTC in the #openstack-meeting channel.
The agenda for the meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_April_14th_2016_.281700_UTC.29
Anyone is
Hi QA-team,
Thanks for joining QA sessions on OpenStack Summit Austin.
They were interesting and good to get directions to move forward in
this development cycle.
This is a summary of these sessions for next steps and hope this helps
our works.
1. Tempest: Cleanup
https://etherpad.openstack.org
Hi Heat-team,
Thanks for talking the topic of devstack plugin with us in Austin summit.
As you know, many projects have started to use devstack plugin in each
project repo.
and it is nice to use the plugin in heat also.
A good sample is ironic one:
https://review.openstack.org/#/q/topic:ironic-de
to do the devstack plugin in heat if there is no one is
> doing it now.
>
>
>
> Thanks
> dixiaoli
>
>
>
>
>
>
> At 2016-04-30 05:30:02, "Ken'ichi Ohmichi" wrote:
>>Hi Heat-team,
>>
>>Thanks for talking the topic of devstack
Hi Masayuki,
Sorry for late response.
That is nice because we had much conversation at the summit.
Next QA meeting is May 12th 1700UTC.
I put the agenda for the next meeting on
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_May_12th_2016_.281700_UTC.29
It is nice to add more top
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,
+
1 - 100 of 251 matches
Mail list logo
