Re: [openstack-dev] [tempest] Proposing Felipe Monteiro for Tempest core

[Ken';ichi Ohmichi]

+1
Thanks for your contribution, Felipe

2018年4月28日(土) 3:29 Ghanshyam Mann :

> Hi Tempest Team,
>
> I would like to propose  Felipe Monteiro (irc: felipemonteiro) to Tempest
> core.
>
> Felipe has been an active contributor to the Tempest  since the Pike
> cycle. He has been doing lot of review and commits since then. Filling
> the gaps on service clients side and their testing and lot other
> areas. He has demonstrated the good quality and feedback while his
> review.
>
> He has good understanding of Tempest source code and project missions
> & goal. IMO his efforts are highly valuable and it will be great to
> have him in team.
>
>
> As per usual practice, please vote +1 or -1 to the nomination. I will
> keep this nomination open for a week or until everyone voted.
>
> Felipe Reviews and Commit -
>
> https://review.openstack.org/#/q/reviewer:felipe.monte...@att.com+project:openstack/tempest
>
> https://review.openstack.org/#/q/owner:felipe.monte...@att.com+project:openstack/tempest
>
> -gmann
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Proposing Eric Fried for nova-core

[Ken';ichi Ohmichi]

+1

2018-03-27 6:39 GMT-07:00 Dan Smith :
>> To the existing core team members, please respond with your comments,
>> +1s, or objections within one week.
>
> +1.
>
> --Dan
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Adding Takashi Natsume to python-novaclient core

[Ken';ichi Ohmichi]

+1


2018年2月9日(金) 8:09 Stephen Finucane :

> On Fri, 2018-02-09 at 09:01 -0600, Matt Riedemann wrote:
> > I'd like to add Takashi to the python-novaclient core team.
> >
> > python-novaclient doesn't get a ton of activity or review, but Takashi
> > has been a solid reviewer and contributor to that project for quite
> > awhile now:
> >
> > http://stackalytics.com/report/contribution/python-novaclient/180
> >
> > He's always fast to get new changes up for microversion support and help
> > review others that are there to keep moving changes forward.
> >
> > So unless there are objections, I'll plan on adding Takashi to the
> > python-novaclient-core group next week.
>
> Easy +1 from me. Would be good to have him on the team.
>
> Stephen
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] PTL Election Season

[Ken';ichi Ohmichi]

2018-01-22 15:09 GMT-08:00 Matt Riedemann :
> On 1/15/2018 11:04 AM, Kendall Nelson wrote:
>>
>> Election details: https://governance.openstack.org/election/
>>
>> Please read the stipulations and timelines for candidates and electorate
>> contained in this governance documentation.
>>
>> Be aware, in the PTL elections if the program only has one candidate, that
>> candidate is acclaimed and there will be no poll. There will only be a poll
>> if there is more than one candidate stepping forward for a program's PTL
>> position.
>>
>> There will be further announcements posted to the mailing list as action
>> is required from the electorate or candidates. This email is for information
>> purposes only.
>>
>> If you have any questions which you feel affect others please reply to
>> this email thread.
>>
>
> To anyone that cares, I don't plan on running for Nova PTL again for the
> Rocky release. Queens was my fourth tour and it's definitely time for
> someone else to get the opportunity to lead here. I don't plan on going
> anywhere and I'll be here to help with any transition needed assuming
> someone else (or a couple of people hopefully) will run in the election.
> It's been a great experience and I thank everyone that has had to put up
> with me and my obsessive paperwork and process disorder in the meantime.

I was surprised because you leaded the team in multiple wide areas and
I guessed you can run as the PTL forever :-)
Anyways thank you so much for your great work in 4 cycles.

Thanks

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Clarifying testing recommendation for interop programs

[Ken';ichi Ohmichi]

2018-01-18 12:36 GMT-08:00 Doug Hellmann :
> Excerpts from Doug Hellmann's message of 2018-01-18 15:21:12 -0500:
>> Excerpts from Graham Hayes's message of 2018-01-18 19:25:02 +:
>> >
>> > On 18/01/18 18:52, Doug Hellmann wrote:
>> > > Excerpts from Graham Hayes's message of 2018-01-18 17:52:39 +:
>> > >> On 18/01/18 16:25, Doug Hellmann wrote:
>> > >>> Excerpts from Graham Hayes's message of 2018-01-18 15:33:12 +:
>> > >>
>> > >> 
>> > >>
>> > >>>
>> > >>> In the past the QA team agreed to accept trademark-related tests from
>> > >>> all projects in the tempest repo. Has that changed?
>> > >>>
>> > >>
>> > >> There has not been an explict rejection but in all conversations the
>> > >> response has been "non core projects are outside the scope of tempest".
>> > >>
>> > >> Honestly, everytime we have tried to do something to core tempest
>> > >> we have had major pushback, and I want to clarify this before I or
>> > >> someone else put in the work of porting the base clients, getting CI
>> > >> configured*, and proposing the tests to tempest.
>> > >
>> > > OK.
>> > >
>> > > The current policy doesn't say anything about "core" or different
>> > > trademark programs or any other criteria.
>> > >
>> > >   The TC therefore encourages the DefCore committee to consider it an
>> > >   indication of future technical direction that we do not want tests
>> > >   outside of the Tempest repository used for trademark enforcement, and
>> > >   that any new or existing tests that cover capabilities they want to
>> > >   consider for trademark enforcement should be placed in Tempest.
>> > >
>> > > That all seems very clear to me (setting aside some specific word
>> > > choices like "future technical direction" that tie the resolution
>> > > to language in the bylaws).  Regardless of technical reasons why
>> > > it may not be necessary, we still have many social justifications
>> > > for doing it the way we originally set out to do it.  Tests related
>> > > to trademark enforcement need to go into the tempest repository.
>> > >
>> > > The way I think this should work (and the way I remember us describing
>> > > it at the time the policy was established) is the Interop WG
>> > > (previously DefCore) should identify capabilities and tests, then
>> > > ask project teams to reproduce those tests in the tempest repo.
>> > > When the tests land, they can be used by the trademark program.
>> > > Teams can also, at their leisure, decide whether to remove the
>> > > original versions of the tests from whatever repo they existed in
>> > > to begin with.
>> > >
>> > > Graham, you've proposed a new resolution with several options for
>> > > where to put tests for "add-on programs." I don't think we need
>> > > that resolution if we want the tests to continue to live in tempest.
>> > > The existing resolution doesn't qualify which tests, beyond "for
>> > > trademark enforcement" and more words won't make that more clear,
>> > > IMO.
>> > >
>> > > Now if you *do* want to change the policy, we should talk about
>> > > that.  But I can't tell whether you want to change it, you're worried
>> > > the policy is unclear, or it is not being followed.  Can you clarify
>> > > which it is?
>> >
>> > It is not being followed.
>> >
>> > I have brought this up at every forum session on these programs, and the
>> > people in the room from QA have *always* pushed back on it.
>>
>> OK, so that's a problem. I need to hear from the QA team why they've
>> reversed that decision.
>>
>> >
>> > And, for clarity (I saw this in a few logs) QA have *never* said that
>> > they will take the interop designated tests for the DNS project into
>> > openstack/tempest.
>>
>> When we approved the resolution that describes the current policy, the
>> QA team agreed that they would take tests for trademark. There was no
>> stipulation about which projects those apply to.
>
> I feel pretty sure that was discussed in a TC meeting, but I can't
> find that. I do find Matt and Ken'ichi voting +1 on the resolution
> itself.  https://review.openstack.org/#/c/312718/. If I remember
> correctly, Ken'ichi was the PTL at the time.

Yeah, I have still agreed with the resolution.
When I voted +1 on that, core projects were defined as 6 projects like
Nova, Cinder, Glance, Keystone, Neutron and Swift.
And the project navigator also showed these 6 projects as core projects.
Now I cannot find such definition on the project navigator[1], the
definition has been changed?
I just want to clarify "is it true that designate and heat become core
projects?"
If there is a concrete decision, I don't have any objections against
that we have these projects tests in Tempest as the resolution.

Thanks
Ken Ohmichi

---
[1]: https://www.openstack.org/software/project-navigator

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://l

[openstack-dev] [doc] [glance] backport patch doesn't seem to be applied to doc site

[Ken';ichi Ohmichi]

Hi

I tried to install glance manually according to docs site[1] for Pike
release, and current doc site doesn't show how to create glance
database.
The bug has been already fixed and the backport patch[2] also has been
merged into Pike branch.
So how to affect these backport patches to actual doc site?

Thanks
Kenichi Omichi

---
[1]: https://docs.openstack.org/glance/pike/install/install-ubuntu.html
[2]: https://review.openstack.org/#/c/508279

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Proposing Balazs Gibizer for nova-core

[Ken';ichi Ohmichi]

Yay (^_^)



2017-08-22 18:18 GMT-07:00 Matt Riedemann :
> I'm proposing that we add gibi to the nova core team. He's been around for
> awhile now and has shown persistence and leadership in the multi-release
> versioned notifications effort, which also included helping new contributors
> to Nova get involved which helps grow our contributor base.
>
> Beyond that though, gibi has a good understanding of several areas of Nova,
> gives thoughtful reviews and feedback, which includes -1s on changes to get
> them in shape before a core reviewer gets to them, something I really value
> and look for in people doing reviews who aren't yet on the core team. He's
> also really helpful with not only reporting and triaging bugs, but writing
> tests to recreate bugs so we know when they are fixed, and also works on
> fixing them - something I expect from a core maintainer of the project.
>
> So to the existing core team members, please respond with a yay/nay and
> after about a week or so we should have a decision (knowing a few cores are
> on vacation right now).
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][ptl][tc] IMPORTANT upcoming change to technical elections

[Ken';ichi Ohmichi]

Hi Clark,

Thanks for your support, that works for me :-)

Thanks

---

2017-08-07 10:10 GMT-07:00 Clark Boylan :
> On Mon, Aug 7, 2017, at 10:01 AM, Ken'ichi Ohmichi wrote:
>> Hi
>>
>> My name is on the nonmembers list and I guess that could be because of
>> "Current Member Level: Speaker", not "Current Member Level: Foundation
>> Member".
>> Can I know how to change this member level?
>>
>> Thanks
>> Ken'ichi Ohmichi
>>
>
> If you login to your foundation profile there should be a button that
> says "Make me a foundation member" or similar. There are more details on
> that process in the answer for
> https://ask.openstack.org/en/question/56720/cannot-store-contact-information-when-updating-info-in-openstack-gerrit/.
>
> Clark
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][ptl][tc] IMPORTANT upcoming change to technical elections

[Ken';ichi Ohmichi]

Hi

My name is on the nonmembers list and I guess that could be because of
"Current Member Level: Speaker", not "Current Member Level: Foundation
Member".
Can I know how to change this member level?

Thanks
Ken'ichi Ohmichi

---


2017-08-03 8:07 GMT-07:00 Doug Hellmann :
>
>> On Aug 2, 2017, at 10:53 PM, Jeremy Stanley  wrote:
>>
>> On 2017-07-17 16:17:00 + (+), Jeremy Stanley wrote:
>>> If you want to run or vote in upcoming elections for PTL and TC,
>>> make sure your Foundation Individual Membership is active and has at
>>> least one Email address which matches an Email address in your
>>> Gerrit account: log in at https://www.openstack.org/profile/ and
>>> check that it says "Current Member Level: Foundation Member" near
>>> the top and that at least one of the Primary, Second or Third Email
>>> Address fields contains an address which matches at least one of the
>>> entries available in the Preferred Email drop-down at
>>> https://review.openstack.org/#/settings/contact (case sensitivity
>>> doesn't matter but they at least need to be spelled the same).
>>>
>>> If you're an "extra-ATC" and don't have a Gerrit account (this is
>>> common for translators on the I18n team) then you still need to be a
>>> Foundation Member to participate in technical elections and should
>>> make sure your member profile includes the Email address listed for
>>> you on your team's page at
>>> https://governance.openstack.org/tc/reference/projects/ .
>> [...]
>>
>> For those who haven't double-checked their memberships, I am
>> attaching a list of OpenStack Foundation Individual Member IDs and
>> names for contributors to official deliverable repositories between
>> 2016-09-17 and the present (members.txt.gz, 2315 entries in total,
>> these should be eligible to vote in elections for projects to which
>> they contributed if a runoff is held). I'm also attaching a list of
>> the names of contributors over the same time period who could not be
>> automatically matched up to foundation membership profiles
>> (nonmembers.txt.gz, 291 entries in total).
>>
>> If you want to vote in upcoming elections and your membership isn't
>> lining up with your contributor account/addresses (that is to say,
>> your name is in the attached nonmembers.txt.gz file) then please
>> follow the quoted instructions above from my earlier message as soon
>> as possible.
>>
>> Should you have any trouble reading the attached compressed lists,
>> you can also view them in a browser at the following URLs:
>>
>>members.txt - http://paste.openstack.org/raw/617357/
>>
>>nonmembers.txt - http://paste.openstack.org/raw/617358/
>>
>
> I had a quick look at that nonmembers.txt list and noticed several 
> long-standing members of our community are included. PLEASE EVERYONE go check 
> your settings so you are not left out of this election.
>
> Doug
>
>> --
>> Jeremy Stanley
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [forum] Future of Stackalytics

[Ken';ichi Ohmichi]

2017-06-08 10:51 GMT-07:00 Jeremy Stanley :
> On 2017-06-08 09:49:03 -0700 (-0700), Ken'ichi Ohmichi wrote:
>> 2017-06-08 7:19 GMT-07:00 Jeremy Stanley :
> [...]
>> > There is a foundation member directory API now which provides
>> > affiliation details and history, so if it were my project (it's
>> > not though) I'd switch to querying that and delete all the
>> > static affiliation mapping out of that config instead. Not only
>> > would it significantly reduce the reviewer load for
>> > Stackalytics, but it would also provide a greater incentive for
>> > contributors to keep their affiliation data updated in the
>> > foundation member directory.
>>
>> Interesting idea, thanks. It would be nice to centralize such
>> information into a single place. Can I know the detail of the API?
>> I'd like to take a look for some prototyping.
>
> It only _just_ rolled to production at
> https://openstackid-resources.openstack.org/api/public/v1/members
> yesterday so I don't know how stable it should be considered at this
> particular moment. The implementation is at
>  https://git.openstack.org/cgit/openstack-infra/openstackid-resources/tree/app/Models/Foundation/Main/Member.php
>  >
> but details haven't been added to the API documentation in that repo
> yet. (I also just now realized we haven't added a publishing job for
> those API docs either, so I'm working on that bit immediately.)
>
> The relevant GET parameters for this case are
> filter=email==someb...@example.com and relations=all_affiliations
> which gets you a list under the "affiliations" key with all
> start/end dates and organizations for the member associated with
> that address. This of course presumes contributors update their
> foundation profiles to include any E-mail addresses they use with
> Git, as well as recording appropriate affiliation timeframes. Those
> fields in the member directory profiles have existed for quite a few
> years now, so hopefully at least some of us have already done that.

Thanks for the info, Jeremy.

The difference between current stackalytics config and the above API
is stackalytics contains gerrit-id and launchpad-id on the config but
the API doesn't.
I guess we can use e-mail address instead of gerrit-id and
launchpad-id and hope them from stackalytics config.
I will dig more deeply anyways.

Thanks

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [forum] Future of Stackalytics

[Ken';ichi Ohmichi]

2017-06-08 7:19 GMT-07:00 Jeremy Stanley :
> On 2017-06-07 16:36:45 -0700 (-0700), Ken'ichi Ohmichi wrote:
> [...]
>> one of config files is 30KL due to much user information and that
>> makes the maintenance hard now. I am trying to separate user part
>> from the existing file but I cannot find the way to make a
>> consensus for such thing.
>
> There is a foundation member directory API now which provides
> affiliation details and history, so if it were my project (it's not
> though) I'd switch to querying that and delete all the static
> affiliation mapping out of that config instead. Not only would it
> significantly reduce the reviewer load for Stackalytics, but it
> would also provide a greater incentive for contributors to keep
> their affiliation data updated in the foundation member directory.

Interesting idea, thanks.
It would be nice to centralize such information into a single place.
Can I know the detail of the API? I'd like to take a look for some prototyping.

>> In addition, we have two ways for managing bug reports: launchpad and
>> storyboard if considering it as infra project.
>
> It's not (at least presently) an Infrastructure team deliverable.
> It's only an unofficial project which happens to have granted the
> infra-core team approval rights (for reasons I don't recall, if I
> ever even knew it was the case before now).
>
>> It would be necessary to transport them from launchpad, I guess.
> [...]
>
> If its maintainers want to migrate from LP to SB, we already have an
> import script which copies in all the existing bug reports so that's
> not really a challenge.

Oh, cool. Glad to hear that :)

Thanks

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [forum] Future of Stackalytics

[Ken';ichi Ohmichi]

2017-05-17 11:55 GMT-07:00 Jeremy Stanley :
> On 2017-05-17 16:16:30 +0200 (+0200), Thierry Carrez wrote:
> [...]
>> we need help with completing the migration to infra. If interested
>> you can reach out to fungi (Infra team PTL) nor mrmartin (who
>> currently helps with the transition work).
> [...]
>
> The main blocker for us right now is addressed by an Infra spec
> (Stackalytics is an unofficial project and it's unclear to us where
> design discussions for it happen):
>
> https://review.openstack.org/434951

I also want to find a good design discussion space for stackalytics future.
For example, one of config files is 30KL due to much user information
and that makes the maintenance hard now.
I am trying to separate user part from the existing file but I cannot
find the way to make a consensus for such thing.
In addition, we have two ways for managing bug reports: launchpad and
storyboard if considering it as infra project.
It would be necessary to transport them from launchpad, I guess.

> In particular, getting the current Stackalytics developers on-board
> with things like this is where we've been failing to make progress
> mainly (I think) because we don't have a clear venue for discussions
> and they're stretched pretty thin with other work. If we can get
> some additional core reviewers for that project (and maybe even talk
> about turning it into an official team or joining them up as a
> deliverable for an existing team) that might help.

Yeah, diversity will be great for our future.

Thanks

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tempest] Proposing Fanglei Zhu for Tempest core

[Ken';ichi Ohmichi]

+1, thanks Zhu for your work.

2017-05-16 4:22 GMT-04:00 Andrea Frittoli :
> Hello team,
>
> I'm very pleased to propose Fanglei Zhu (zhufl) for Tempest core.
>
> Over the past two cycle Fanglei has been steadily contributing to Tempest
> and its community.
> She's done a great deal of work in making Tempest code cleaner, easier to
> read, maintain and
> debug, fixing bugs and removing cruft. Both her code as well as her reviews
> demonstrate a
> very good understanding of Tempest internals and of the project future
> direction.
> I believe Fanglei will make an excellent addition to the team.
>
> As per the usual, if the current Tempest core team members would please vote
> +1
> or -1(veto) to the nomination when you get a chance. We'll keep the polls
> open
> for 5 days or until everyone has voted.
>
> References:
> https://review.openstack.org/#/q/owner:zhu.fanglei%2540zte.com.cn
> https://review.openstack.org/#/q/reviewer:zhufl
>
> Thank you,
>
> Andrea (andreaf)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][api] GET or HEAD for checking trait existence

[Ken';ichi Ohmichi]

Hi Jay,

Thanks for your reply.

2017-03-29 12:26 GMT-07:00 Jay Pipes :
> On 03/29/2017 02:04 PM, Ken'ichi Ohmichi wrote:
>>
>> Hi
>>
>> I have some questions about plancement API design from
>> https://review.openstack.org/#/c/376200
>> Current implementation of the above patch (PS26) adds GET method for
>> checking trait existence, and tags.rst of api-wg guideline[1] requires
>> GET for checking trait existence.
>> On the other hand, http.rst of api-wg guideline[2] requires HEAD instead.
>>
>> So there are two questions.
>> 1. Why the part of tags.rst is different from http.rst?
>> I checked the review history of
>> https://review.openstack.org/#/c/155620/ which have added the part,
>> but I could not find the reason.
>> 2. trait should follow tags.rst? or http.rst?
>
>
> This is from the http.rst guideline in the API-WG:
>
> "TODO: HEAD is weird in a bunch of our wsgi frameworks and you don't have
> access to it. Figure out if there is anything useful there."
>
> and frankly, I tend to agree with the above statement. I'd say use GET for
> exists checking.

Ed submitted a LP about this as
https://bugs.launchpad.net/openstack-api-wg/+bug/1677360
On the LP, Chris did put a nice comment like:

  "HEAD is a shortcut to use when you don't want to pay the price of GET"

We can use HEAD without receiving a response body to check a resource
existence if the response body could be huge on GET.
In this case, IIUC trait API doesn't return a response body when
getting the detail of resource, that would be the same as a resource
existence check.
Both GET and HEAD could be acceptable in this case.
I was confused when seeing the conflict between tags.rst and http.rst,
I will try it clear later on api-wg guideline.

Thanks

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][api] GET or HEAD for checking trait existence

[Ken';ichi Ohmichi]

Hi

I have some questions about plancement API design from
https://review.openstack.org/#/c/376200
Current implementation of the above patch (PS26) adds GET method for
checking trait existence, and tags.rst of api-wg guideline[1] requires
GET for checking trait existence.
On the other hand, http.rst of api-wg guideline[2] requires HEAD instead.

So there are two questions.
1. Why the part of tags.rst is different from http.rst?
I checked the review history of
https://review.openstack.org/#/c/155620/ which have added the part,
but I could not find the reason.
2. trait should follow tags.rst? or http.rst?

Any comments are welcome.

Thanks

---
[1]: 
https://github.com/openstack/api-wg/blob/master/guidelines/tags.rst#addressing-individual-tags
[2]: 
https://github.com/openstack/api-wg/blob/master/guidelines/http.rst#http-methods

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa][cinder] RFC: Cinder test on Tempest

[Ken';ichi Ohmichi]

2017-03-22 19:31 GMT-07:00  :
> To have only one folder (tempest/api/volume/ ) looks really good, and, do we
> plan to deem "api_version" and "microversion" as one thing?
>
> i.e., we will use the mechanism of microversion to skip v3 new functional
> tests when the environment only supports v2?

Yeah, that is right.
Tempest has the range of microversions with the config options
min/max_microversions and we can select the target  microversions.
If both min_microversion and max_microversion are not specified(means
None), microversion tests run as the help message[1].

So the configuration would be like

gate-tempest-dsvm-neutron-full-ubuntu-xenial - (existing job): testing
Cinder V3 API
  catalog_type: Specify Cinder V3 API's one
  min_microversion: Don't specify
  max_microversion: Specify max microversion of the branch (master, stable)

gate-tempest-dsvm-neutron-full-ubuntu-xenial-cinder-v2: (new job):
testing Cinder V2 API
  catalog_type: Specify Cinder V2 API's one
  min_microversion: Don't specify
  max_microversion: Don't specify

Thanks

---
[1]: https://github.com/openstack/tempest/blob/master/tempest/config.py#L776


> On Thu, Mar 23, 2017 at 7:02 AM, Ken'ichi Ohmichi ＜ken1ohmi...@gmail.com＞
> wrote:
>>
>> 2017-03-22 14:32 GMT-07:00 Andrea Frittoli ＜andrea.fritt...@gmail.com＞:
>> ＞
>> ＞
>> ＞ On Wed, Mar 22, 2017 at 8:31 PM Sean McGinnis ＜sean.mcgin...@gmx.com＞
>> wrote:
>> ＞＞
>> ＞＞ On Wed, Mar 22, 2017 at 01:08:23PM -0700, Ken'ichi Ohmichi wrote:
>> ＞＞ ＞ Hi,
>> ＞＞ ＞
>> ＞＞ ＞ Now we need to update Tempest for following Cinder API status..
>> ＞＞ ＞ I have an idea for restructuring and happy to see feedback about
>> that.
>>
>> ＞＞ ＞
>> ＞＞ ＞ Now Cinder API status is
>> ＞＞ ＞   V1: Deprecated
>> ＞＞ ＞   V2: Deprecated
>> ＞＞ ＞   V3: Current
>> ＞＞ ＞ V1 API tests have been removed from Tempest side already, so we just
>> ＞＞ ＞ need to concentrate on V2 and V3 now.
>> ＞＞
>> ＞＞ ＞
>> ＞＞ ＞ **Gate jobs**
>> ＞＞ ＞ Most Cinder tests are implemented for V2 API on Tempest side and the
>> ＞＞ ＞ base microversion of V3 is the same as V2.
>> ＞＞ ＞ Then we can re-use V2 API tests for the base microversion of V3 API.
>> ＞＞ ＞ One idea is that we can have Cinder V3 API tests as the default on
>> the
>> ＞＞ ＞ gate jobs and the V2 API tests as another job like the following
>> ＞＞ ＞ because the V2 API is deprecated.
>> ＞＞ ＞
>> ＞＞ ＞   gate-tempest-dsvm-neutron-full-ubuntu-xenial - (existing job):
>> ＞＞ ＞ testing Cinder V3 API
>> ＞＞ ＞   gate-tempest-dsvm-py35-ubuntu-xenial - (existing job): testing
>> Cinder
>> ＞＞ ＞ V3 API
>> ＞＞ ＞   ...
>> ＞＞ ＞   gate-tempest-dsvm-neutron-full-ubuntu-xenial-cinder-v2: (new job):
>> ＞＞ ＞ testing Cinder V2 API
>> ＞＞ ＞
>> ＞＞
>> ＞ I guess this job would run against tempest and cinder only?
>>
>> A nice point, I think so.
>>
>> ＞＞ +1 I like this idea.
>> ＞＞
>> ＞＞ ＞ We had the same testing way for Nova V2 API and V2.1 API before, and
>> ＞＞ ＞ we could avoid copy&paste V2 test code for V2.1 API on Tempest.
>> ＞＞ ＞
>> ＞＞ ＞ **Test Structure**
>> ＞＞ ＞ Current test structure is like:
>> ＞＞ ＞   tempest/api/volume/  - V2 API tests
>> ＞＞ ＞   tempest/api/volume/v2 - V2 API tests
>> ＞＞ ＞   tempest/api/volume/v3 - V3 API tests
>> ＞＞ ＞ Yes, this is mess.
>> ＞＞ ＞ For re-using V2 API tests for V3 API, it would be better to remove
>> ＞＞ ＞ "v2" from V2 API tests for avoiding confusions.
>> ＞＞ ＞
>> ＞＞ ＞ A new structure could be
>> ＞＞ ＞   tempest/api/volume/  - All tests for V2 API and the base
>> ＞＞ ＞ microversion of V3 API
>> ＞＞ ＞   tempest/api/volume/v3 - V3 API specific tests for newer
>> microversions
>> ＞＞ ＞ or
>> ＞＞ ＞   tempest/api/volume/  - All tests for V2 API and V3 API which
>> ＞＞ ＞ includes newer microversions
>
>
> +1, this looks better as no more version specific tests and all v2 tests
> should run as it is on v3 base version.
>
>
>>
>> ＞＞ ＞
>> ＞＞ ＞ As the reference, Nova API structure is like the later.
>> ＞＞
>> ＞＞ I like the last one better as well.
>> ＞＞
>> ＞ My favourite option would be that that generates less churn in the code
>> :)
>> ＞ One folder for everything means moving 4 or 5 modules only, so I think
>> that
>> ＞ would
>> ＞ be a good option.
>> ＞
>> ＞ I would prefer to avoid though having a lot of v3 test classes that
>> inherit
>> ＞ from
>> ＞ v2 test classes, and just set _api_version = 3.
>>
>> Yeah, I agree :-)
>
>
>
> yea we should not have that.
>
>
>&g

Re: [openstack-dev] [qa][cinder] RFC: Cinder test on Tempest

[Ken';ichi Ohmichi]

2017-03-22 14:32 GMT-07:00 Andrea Frittoli :
>
>
> On Wed, Mar 22, 2017 at 8:31 PM Sean McGinnis  wrote:
>>
>> On Wed, Mar 22, 2017 at 01:08:23PM -0700, Ken'ichi Ohmichi wrote:
>> > Hi,
>> >
>> > Now we need to update Tempest for following Cinder API status.
>> > I have an idea for restructuring and happy to see feedback about that.
>> >
>> > Now Cinder API status is
>> >   V1: Deprecated
>> >   V2: Deprecated
>> >   V3: Current
>> > V1 API tests have been removed from Tempest side already, so we just
>> > need to concentrate on V2 and V3 now.
>>
>> >
>> > **Gate jobs**
>> > Most Cinder tests are implemented for V2 API on Tempest side and the
>> > base microversion of V3 is the same as V2.
>> > Then we can re-use V2 API tests for the base microversion of V3 API.
>> > One idea is that we can have Cinder V3 API tests as the default on the
>> > gate jobs and the V2 API tests as another job like the following
>> > because the V2 API is deprecated.
>> >
>> >   gate-tempest-dsvm-neutron-full-ubuntu-xenial - (existing job):
>> > testing Cinder V3 API
>> >   gate-tempest-dsvm-py35-ubuntu-xenial - (existing job): testing Cinder
>> > V3 API
>> >   ...
>> >   gate-tempest-dsvm-neutron-full-ubuntu-xenial-cinder-v2: (new job):
>> > testing Cinder V2 API
>> >
>>
> I guess this job would run against tempest and cinder only?

A nice point, I think so.

>> +1 I like this idea.
>>
>> > We had the same testing way for Nova V2 API and V2.1 API before, and
>> > we could avoid copy&paste V2 test code for V2.1 API on Tempest.
>> >
>> > **Test Structure**
>> > Current test structure is like:
>> >   tempest/api/volume/  - V2 API tests
>> >   tempest/api/volume/v2 - V2 API tests
>> >   tempest/api/volume/v3 - V3 API tests
>> > Yes, this is mess.
>> > For re-using V2 API tests for V3 API, it would be better to remove
>> > "v2" from V2 API tests for avoiding confusions.
>> >
>> > A new structure could be
>> >   tempest/api/volume/  - All tests for V2 API and the base
>> > microversion of V3 API
>> >   tempest/api/volume/v3 - V3 API specific tests for newer microversions
>> > or
>> >   tempest/api/volume/  - All tests for V2 API and V3 API which
>> > includes newer microversions
>> >
>> > As the reference, Nova API structure is like the later.
>>
>> I like the last one better as well.
>>
> My favourite option would be that that generates less churn in the code :)
> One folder for everything means moving 4 or 5 modules only, so I think that
> would
> be a good option.
>
> I would prefer to avoid though having a lot of v3 test classes that inherit
> from
> v2 test classes, and just set _api_version = 3.

Yeah, I agree :-)

> As long as we can assume we will never run v2 and v3 in the same job, we
> could
> have cinder_api_version as a configuration setting, to determine which
> cinder
> endpoint to hit when running the volume tests.

Or it would be enough to have the existing "catalog_type",
"min_microversion" and "max_microversion" only without api_v1/v2/v3 to
control the target API version, because of the above separated gate
jobs.

> Apart from the volume tests, if we split the gate jobs into standard one
> running v3
> plus and extra v2 one, we should make sure that all tests that use the
> volume API
> use a consistent version of the volume API. Nova as well should be
> configured if
> possible to use the same volume API version.

This also is a nice point.
Nova team also has a plan to use cinder v3 as the default in Pike.
We have consistent direction now.

Thanks

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [qa][cinder] RFC: Cinder test on Tempest

[Ken';ichi Ohmichi]

Hi,

Now we need to update Tempest for following Cinder API status.
I have an idea for restructuring and happy to see feedback about that.

Now Cinder API status is
  V1: Deprecated
  V2: Deprecated
  V3: Current
V1 API tests have been removed from Tempest side already, so we just
need to concentrate on V2 and V3 now.

**Gate jobs**
Most Cinder tests are implemented for V2 API on Tempest side and the
base microversion of V3 is the same as V2.
Then we can re-use V2 API tests for the base microversion of V3 API.
One idea is that we can have Cinder V3 API tests as the default on the
gate jobs and the V2 API tests as another job like the following
because the V2 API is deprecated.

  gate-tempest-dsvm-neutron-full-ubuntu-xenial - (existing job):
testing Cinder V3 API
  gate-tempest-dsvm-py35-ubuntu-xenial - (existing job): testing Cinder V3 API
  ...
  gate-tempest-dsvm-neutron-full-ubuntu-xenial-cinder-v2: (new job):
testing Cinder V2 API

We had the same testing way for Nova V2 API and V2.1 API before, and
we could avoid copy&paste V2 test code for V2.1 API on Tempest.

**Test Structure**
Current test structure is like:
  tempest/api/volume/  - V2 API tests
  tempest/api/volume/v2 - V2 API tests
  tempest/api/volume/v3 - V3 API tests
Yes, this is mess.
For re-using V2 API tests for V3 API, it would be better to remove
"v2" from V2 API tests for avoiding confusions.

A new structure could be
  tempest/api/volume/  - All tests for V2 API and the base
microversion of V3 API
  tempest/api/volume/v3 - V3 API specific tests for newer microversions
or
  tempest/api/volume/  - All tests for V2 API and V3 API which
includes newer microversions

As the reference, Nova API structure is like the later.

Any thoughts?

Thanks
Ken Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api][qa][tc][glance][keystone][cinder] Testing of deprecated API versions

[Ken';ichi Ohmichi]

2017-03-10 8:51 GMT-08:00 Sean McGinnis :
>> >
>> As far as I can tell:
>> - Cinder v1 if I'm not mistaken has been deprecated in Juno, so it's
>> deprecated in all supported releases.
>> - Glance v1 has been deprecated in Newton, so it's deprecated in all
>> supported releases
>> - Keystone v2 has been deprecated in Mitaka, so testing *must* stay in
>> Tempest until Mitaka EOL, which is in a month from now
>>
>> We should stop testing these three api versions in the common gate
>> including stable branches now (except for keystone v2 on stable/mitaka
>> which can run for one more month).
>>
>> Are cinder / glance / keystone willing to take over the API tests and run
>> them in their own gate until removal of the API version?
>>
>> Doug
>
> With Cinder's v1 API being deprecated for quite awhile now, I would
> actually prefer to just remove all tempest tests and drop the API
> completely. There was some concern about removal a few cycles back since
> there was concern (rightly so) that a lot of deployments and a lot of
> users were still using it.
>
> I think it has now been marked as deprecated long enough that if anyone
> is still using it, it's just out of obstinance. We've removed the v1
> api-ref documentation, and the default in the client has been v2 for
> awhile.
>
> Unless there's a strong objection, and a valid argument to support it,
> I really would just like to drop v1 from Cinder and not waste any more
> cycles on redoing tempest tests and reconfiguring jobs to support
> something we have stated for over two years that we were no longer going
> to support. Juno went EOL in December of 2015. I really hope it's safe
> now to remove.

OK, let's remove the Cinder v1 API tests from Tempest [1].

Thanks

---
[1]: https://review.openstack.org/#/c/446233/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa][neutron-fwaas][networking-bgpvpn][nova-lxd] Removing old data_utils from Tempest

[Ken';ichi Ohmichi]

2017-03-14 18:52 GMT-07:00 Takashi Yamamoto :
> thank you for heads up.
>
> On Wed, Mar 15, 2017 at 2:18 AM, Ken'ichi Ohmichi  
> wrote:
>> Hi,
>>
>> Many projects are using data_utils library which is provided by
>> Tempest for creating test resources with random resource names.
>> Now the library is provided as stable interface (tempest.lib) and old
>> unstable interface (tempest.common) will be removed after most
>> projects are switching to the new one.
>> We can see remaining projects from
>> https://review.openstack.org/#/q/status:open+branch:master+topic:tempest-data_utils
>
> are you going to backport?

Backport is not necessary on Tempest side, because Tempest is
branchless and we are using the same Tempest for stable branches.
If using the package of Tempest on tempest-plugin gate, the old
data_utils still exists with putting the Tempest version limitation
after the removal.
If using the latest Tempest on tempest-plugin gate, we need to
backport the corresponding patches to tempest-plugin after the
removal.
The above ways are different on projects.

Thanks

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [qa][neutron-fwaas][networking-bgpvpn][nova-lxd] Removing old data_utils from Tempest

[Ken';ichi Ohmichi]

Hi,

Many projects are using data_utils library which is provided by
Tempest for creating test resources with random resource names.
Now the library is provided as stable interface (tempest.lib) and old
unstable interface (tempest.common) will be removed after most
projects are switching to the new one.
We can see remaining projects from
https://review.openstack.org/#/q/status:open+branch:master+topic:tempest-data_utils

I hope these patches also can be merged before the
patch(https://review.openstack.org/#/c/72/) which removes the old
one to keep all gates stable.

Thanks
Ken Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api][qa][tc][nova][cinder] Testing of a microversioned world

[Ken';ichi Ohmichi]

2017-03-13 12:23 GMT-07:00 Jim Rollenhagen :
> On Mon, Mar 13, 2017 at 12:58 PM, Chris Friesen
>  wrote:
>>
>> On 03/10/2017 01:37 PM, John Griffith wrote:
>>
>>> Now that micro-versions are *the API versioning scheme to rule them all*
>>> one
>>> question I've not been able to find an answer for is what we're going to
>>> promise
>>> here for support and testing.  My understanding thus far is that the
>>> "community"
>>> approach here is "nothing is ever deprecated, and everything is supported
>>> forever".
>>
>>
>> Nova has so far taken this approach, but there has been talk of bumping
>> the minimum required microversion at every dev gathering.  It hasn't
>> happened yet, but if the support costs of maintaining the compat code
>> becomes too high then it could happen.
>
>
> Indeed. We discussed this at the PTG a bit[0], and plan to use ironic as an
> experiment for this. It's an admin-only API, so the API users should be the
> same (or in contact with) the folks deploying it, and so it shouldn't be as
> surprising. We hope to get some feedback and find out if doing this is as
> terrible as we keep saying.

That seems a nice plan.
The effective scope of bumping minimum microversion could be small and
it would be easier to get feedback from administrators by comparing
normal API consumers.

Thanks

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api][qa][tc][nova][cinder] Testing of a microversioned world

[Ken';ichi Ohmichi]

2017-03-10 13:32 GMT-08:00 Matthew Treinish :
> On Fri, Mar 10, 2017 at 12:34:31PM -0800, Ken'ichi Ohmichi wrote:
>> Hi John,
>>
>> Now Tempest is testing microversions only for Nova and contains some
>> testing framework for re-using for another projects.
>> On this framework, we can implement necessary microversions tests as
>> we want and actually many microversions of Nova are not tested by
>> Tempest.
>> We can see the tested microversion of Nova on
>> https://github.com/openstack/tempest/blob/master/doc/source/microversion_testing.rst#microversion-tests-implemented-in-tempest
>>
>> Before implementing microversion testing for Cinder, we will implement
>> JSON-Schema validation for API responses for Cinder.
>> The validation will be helpful for testing base microversion of Cinder
>> API and we will be able to implement the microversion tests based on
>> that.
>> This implementation is marked as 7th priority in this Pike cycle as
>> https://etherpad.openstack.org/p/pike-qa-priorities
>>
>> In addition, now Cinder V3 API is not tested. So we are going to
>> enable v3 tests with some restructure of Tempest in this cycle.
>> The detail is described on the part of "Volume API" of
>> https://etherpad.openstack.org/p/tempest-api-versions-in-pike
>
>
> Umm, I don't know what you're basing that on, but there have been cinder v3
> tests and cinder microversion support in Tempest since Newton. It was 
> initially
> added in this patch: https://review.openstack.org/#/c/300639/

Yeah, that is for v3 but that is only I think at this time.

>> 2017-03-10 11:37 GMT-08:00 John Griffith :
>> > Hey Everyone,
>> >
>> > So along the lines of an earlier thread that went out regarding testing of
>> > deprecated API's and Tempest etc [1].
>> >
>> > Now that micro-versions are *the API versioning scheme to rule them all* 
>> > one
>> > question I've not been able to find an answer for is what we're going to
>> > promise here for support and testing.  My understanding thus far is that 
>> > the
>> > "community" approach here is "nothing is ever deprecated, and everything is
>> > supported forever".
>> >
>> > That's sort of a tall order IMO, but ok.  I've already had some questions
>> > from folks about implementing an explicit Tempest test for every
>> > micro-versioned implementation of an API call also.  My response has been
>> > "nahh, just always test latest available".  This kinda means that we're not
>> > testing/supporting the previous versions as promised though.
>> >
>> > Anyway; I'm certain that between Nova and the API-WG this has come up and 
>> > is
>> > probably addressed, just wondering if somebody can point me to some
>> > documentation or policies in this respect.
>> >
>> > Thanks,
>> > John
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api][qa][tc][nova][cinder] Testing of a microversioned world

[Ken';ichi Ohmichi]

Hi John,

Now Tempest is testing microversions only for Nova and contains some
testing framework for re-using for another projects.
On this framework, we can implement necessary microversions tests as
we want and actually many microversions of Nova are not tested by
Tempest.
We can see the tested microversion of Nova on
https://github.com/openstack/tempest/blob/master/doc/source/microversion_testing.rst#microversion-tests-implemented-in-tempest

Before implementing microversion testing for Cinder, we will implement
JSON-Schema validation for API responses for Cinder.
The validation will be helpful for testing base microversion of Cinder
API and we will be able to implement the microversion tests based on
that.
This implementation is marked as 7th priority in this Pike cycle as
https://etherpad.openstack.org/p/pike-qa-priorities

In addition, now Cinder V3 API is not tested. So we are going to
enable v3 tests with some restructure of Tempest in this cycle.
The detail is described on the part of "Volume API" of
https://etherpad.openstack.org/p/tempest-api-versions-in-pike

Thanks
Ken Ohmichi

---

2017-03-10 11:37 GMT-08:00 John Griffith :
> Hey Everyone,
>
> So along the lines of an earlier thread that went out regarding testing of
> deprecated API's and Tempest etc [1].
>
> Now that micro-versions are *the API versioning scheme to rule them all* one
> question I've not been able to find an answer for is what we're going to
> promise here for support and testing.  My understanding thus far is that the
> "community" approach here is "nothing is ever deprecated, and everything is
> supported forever".
>
> That's sort of a tall order IMO, but ok.  I've already had some questions
> from folks about implementing an explicit Tempest test for every
> micro-versioned implementation of an API call also.  My response has been
> "nahh, just always test latest available".  This kinda means that we're not
> testing/supporting the previous versions as promised though.
>
> Anyway; I'm certain that between Nova and the API-WG this has come up and is
> probably addressed, just wondering if somebody can point me to some
> documentation or policies in this respect.
>
> Thanks,
> John
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [qa][keystone] Tempest will use Keystone v3 API as the default

[Ken';ichi Ohmichi]

Hi,

This is a kind of notification as the mail title.

Now QA-team is trying to test most recent stable APIs which are marked
as CURRENT in most components.
The investigation is written on
https://etherpad.openstack.org/p/tempest-api-versions-in-pike

On Keystone side, the V3 API is CURRENT and the V2 API is DEPRECATED.
Until last week, the default config value of Tempest was the V2 for
the authentication and the patch [1] has changed it to the V3.
However Devstack still sets the V2 for Tempest config and we are using
the V2 on the gate.
The devstack patch [2] will change the config to the V3 for Tempest.
I hope this change will be helpful for our future.

Thanks
Ken Ohmichi

---
[1]: https://review.openstack.org/#/c/441530/
[2]: https://review.openstack.org/#/c/441531/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA]Refactoring Scenarios manager.py

[Ken';ichi Ohmichi]

I see Jordan's opinion here and I also faced this situation before.
I proposed a hacking patch [1] to notify wrong usage of Tempest
methods to projects and I saw some users of these methods didn't know
the definition of stable interfaces of Tempest.
We always face this issue on developments which change *internal*
methods of Tempest.

2017-02-26 10:13 GMT-08:00 Andrea Frittoli :
>
> Scenario tests will go through a significant number of changes as part of
> the refactor and if every change risks to break someone's gate job it won't
> work.
> I propose we proceed as follows:
> - identify projects that import from tempest.scenario
> - send a notification to the ML about the changes that are going to happen
> - help the affected teams to identify a way decouple them from tempest
> scenario code - most likely copy the relevant code in-tree
> - meanwhile continue to work on patches for scenario tests but do not merge
> them yet

Yeah, this approach is very nice to land patches softly.
Users can find solutions if facing this issue on the own gate.

> This process shouldn't take long and be rather straight forward.
>
> I already have some data from codesearch, I will send out the e-mail
> tomorrow.

++, thanks for your leadership.

Thanks
Ken Ohmichi

---

[1]: https://review.openstack.org/#/c/328651

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all][qa] Use stable call_until_true()

[Ken';ichi Ohmichi]

Hi,

QA team defines stable interfaces of Tempest for using them from
outside(tempest plugins).
We are removing a deprecated call_until_true() method from unstable
module(test.py of Tempest), but some projects are still using it.
We have prepared patches[1] for soft-landing on these projects,
hopefully these patches are merged before a Tempest patch[2] which
removes the method.

Thanks
Ken Ohmichi

---
[1]: https://review.openstack.org/#/q/status:open+topic:switch-call_until_true
[2]: https://review.openstack.org/#/c/431701/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA] Pike PTG Schedule

[Ken';ichi Ohmichi]

Hi Andrea,

Thanks for organizing QA sessions for PTG.

2017-02-13 16:16 GMT-08:00 Andrea Frittoli :
> Hello team,
>
> I did some work on the etherpad [0] to organise the QA PTG schedule based on
> the proposed sessions.
> I separated discussion sessions from hands-on type of actives. I thing the
> former will require a fixed schedule so folks may know when to pop-in to
> attend; the latter may happen more ad-hoc based on who's there an not busy
> in a session. We can have a final discussion on this in the QA meeting on
> Thursday [1].

It is a nice idea to separate discussion sessions from hands-on (code
sprint) sessions.
Now we have 9 discussion sessions which don't require arranging the
time schedule with the other teams.
So I feel it is nice to schedule them in the first day and schedule
hands-on sessions(working items based on discussion sessions and 3
original hands-on session) in the second day so that we get feedback
and discuss them again during the second day.
That is an idea, I am happy to see the other schedule idea :-)

> I haven't fixed the exact schedule yet, I will do it soon; meanwhile please
> let me know if you think your session will need more or less then 30' which
> is the standard time I would allocate.
> Discussions that overrun the planned time can go in a parking lot, which we
> can pick up later at the PTG or during meetings.
> Any session preparation work / existing material, previous discussions,
> links and so can go in the respective etherpad.
>
> I think we have a good set of topics to discuss and code to write, enough to
> keep us busy for more than the time we have.
> Nonetheless, if you have more topic to propose please continue adding them
> to the etherpad.

Yes, it is nice to make us busy in PTG.

Thanks
Ken Ohmichi

---

> [0] https://etherpad.openstack.org/p/qa-ptg-pike
> [1]
> https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_February_16th_2017_.281700_UTC.29
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][api] POST /api-wg/news

[Ken';ichi Ohmichi]

2017-02-07 10:31 GMT-08:00 Ed Leafe :
> On Feb 6, 2017, at 3:28 PM, Ken'ichi Ohmichi  wrote:
>>
>>> To summarize, my point is that we shouldn't be worried that this case is
>>> going to set a precedent.  It would be worrisome if it were going to set
>>> a *bad* precedent, but when you look at the details of the situation, I
>>> don't think it will.  So it looks to me, anyway, that a compromise is in
>>> order here.  (In case I'm being too obscure, what I mean is: we should
>>> agree that it's OK for the Glance team to fix this bug in the code with
>>> patch https://review.openstack.org/#/c/420038/.)
>>
>> I feel this case is very common case when we want to chang success status 
>> code.
>> Because I cannot find the other motivation for changing success status
>> code except we are finding bugs like this case.
>
> Success codes are different than failure codes, because when you fail, you 
> need to know why. When your request succeeds, that’s pretty much all you need 
> to know. So the pain involved should be much less.
>
> But aside from this particular case, there are a lot of differing opinions on 
> how APIs should be treated, so I wrote up my take on things:
>
> https://blog.leafe.com/api-longevity/
>
>> So if accepting this case, I guess we drop the following guideline 
>> completely[1]
>>
>>  The following types of changes are generally *not* considered acceptable:
>>   Changing which response code is returned on success.
>
> I’ll propose a change to the wording for that, but dropping the guideline 
> completely would be an overreaction, IMO.

I am not sure what you mean, I feel you are saying it is meaningless
to specify particular success status code on each API..
One my stupid idea is it is good to specify HTTP200 only on all APIs
on the guideline.
It would be easy to make APIs consistent and avoid this kind of bugs.
I know many people don't prefer this idea ;)

Thanks
Ken Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][api] POST /api-wg/news

[Ken';ichi Ohmichi]

2017-02-07 6:56 GMT-08:00 Brian Rosmaita :
> On 2/6/17 4:28 PM, Ken'ichi Ohmichi wrote:
>> 2017-02-06 6:45 GMT-08:00 Brian Rosmaita :
>>> On 2/6/17 5:51 AM, Jordan Pittier wrote:
>>> [super-enormous snip -- Chris, Ken, and Jordan make good points, I
>>> encourage you to read the entire thread; I just want to concentrate on
>>> one point]
>>>>
>>>> I would say we should make compromise, not solve dilemma. I can live in a
>>>> world where we sometimes allow an API change and sometimes prevent it.
>>>>
>>> +1000
>>>
>>> I agree with Jordan.  We need to look at the context of each specific
>>> case and decide whether a change is OK based on the details.  We've
>>> already got the guideline that says "in general", you shouldn't change
>>> the response code, and we respect that.  The Glance team isn't claiming
>>> that the guideline is incorrect--we're just saying that given the
>>> context of this specific bug (that is, it's been documented for a long
>>> time to return a 204, all other metadefs DELETE calls are documented to
>>> return a 204, all the other metadefs DELETE calls do in fact return a
>>> 204, etc.), it makes sense that this case is an exception.
>>>
>>> Granting an exception here doesn't mean that the floodgates have opened
>>> for an "anything goes" approach to API changes.  It just means that an
>>> exception is appropriate in this particular case.  I am being a bit
>>> disingenuous there because if an exception is appropriate in this case,
>>> then it will be appropriate in other relevantly similar cases.  But
>>> "relevant similarity" will include the entire context of the case, for
>>> example, whether there was a published API contract, whether the other
>>> similar calls behave as documented, etc.  From 10,000 meters, it looks
>>> like what we're advocating is "It's OK to change a response code".  But
>>> when you look more closely, our claim is that given the details of this
>>> particular bug, it makes sense to fix it in the code and not in the docs.
>>>
>>> To summarize, my point is that we shouldn't be worried that this case is
>>> going to set a precedent.  It would be worrisome if it were going to set
>>> a *bad* precedent, but when you look at the details of the situation, I
>>> don't think it will.  So it looks to me, anyway, that a compromise is in
>>> order here.  (In case I'm being too obscure, what I mean is: we should
>>> agree that it's OK for the Glance team to fix this bug in the code with
>>> patch https://review.openstack.org/#/c/420038/.)
>>
>> I feel this case is very common case when we want to chang success status 
>> code.
>> Because I cannot find the other motivation for changing success status
>> code except we are finding bugs like this case.
>>
>> So if accepting this case, I guess we drop the following guideline 
>> completely[1]
>>
>>   The following types of changes are generally *not* considered acceptable:
>>Changing which response code is returned on success.
>
> I think that's a separate discussion that shouldn't hold up whether we
> can get this particular bug properly fixed soon.
>
> It doesn't follow that if Glance makes this change, the guideline is
> pointless.  As I said earlier, given the context of this particular bug
> (the success code for the call has been documented as a 204, all the
> other metadefs DELETE calls return a 204, all the other calls are also
> documented to return 204s, etc.), one can argue that this is a
> legitimate exception allowed under the guideline.  And in fact the API
> Working Group has accepted that argument.  If the facts of the case were
> different, they might very well have told me to go boil my head.
>
> My point here is that we can accept the guideline *and* also accept this
> particular change.  Hence, worrying about the status of the guideline is
> not a reason to reject the fix proposed by the patch
> https://review.openstack.org/#/c/420038/ .

Again, this case is not particular case. Very common case.
It was just forgot to specify status code (204 in this case) in the
code, and the wsgi framework returns 200 as the default.
Nova also has multiple same bugs on the API, so I feel this is common case.

My point is "Do we really need to do that ?" with
- Possible to break the existing users APIs
- Break the OpenStack interoperability on multiple different version clouds
- Make the guideline fuzzy when facing the smiler issues

only for us, developers.

Thanks
Ken Ohmichi

---

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][api] POST /api-wg/news

[Ken';ichi Ohmichi]

2017-02-06 6:45 GMT-08:00 Brian Rosmaita :
> On 2/6/17 5:51 AM, Jordan Pittier wrote:
> [super-enormous snip -- Chris, Ken, and Jordan make good points, I
> encourage you to read the entire thread; I just want to concentrate on
> one point]
>>
>> I would say we should make compromise, not solve dilemma. I can live in a
>> world where we sometimes allow an API change and sometimes prevent it.
>>
> +1000
>
> I agree with Jordan.  We need to look at the context of each specific
> case and decide whether a change is OK based on the details.  We've
> already got the guideline that says "in general", you shouldn't change
> the response code, and we respect that.  The Glance team isn't claiming
> that the guideline is incorrect--we're just saying that given the
> context of this specific bug (that is, it's been documented for a long
> time to return a 204, all other metadefs DELETE calls are documented to
> return a 204, all the other metadefs DELETE calls do in fact return a
> 204, etc.), it makes sense that this case is an exception.
>
> Granting an exception here doesn't mean that the floodgates have opened
> for an "anything goes" approach to API changes.  It just means that an
> exception is appropriate in this particular case.  I am being a bit
> disingenuous there because if an exception is appropriate in this case,
> then it will be appropriate in other relevantly similar cases.  But
> "relevant similarity" will include the entire context of the case, for
> example, whether there was a published API contract, whether the other
> similar calls behave as documented, etc.  From 10,000 meters, it looks
> like what we're advocating is "It's OK to change a response code".  But
> when you look more closely, our claim is that given the details of this
> particular bug, it makes sense to fix it in the code and not in the docs.
>
> To summarize, my point is that we shouldn't be worried that this case is
> going to set a precedent.  It would be worrisome if it were going to set
> a *bad* precedent, but when you look at the details of the situation, I
> don't think it will.  So it looks to me, anyway, that a compromise is in
> order here.  (In case I'm being too obscure, what I mean is: we should
> agree that it's OK for the Glance team to fix this bug in the code with
> patch https://review.openstack.org/#/c/420038/.)

I feel this case is very common case when we want to chang success status code.
Because I cannot find the other motivation for changing success status
code except we are finding bugs like this case.

So if accepting this case, I guess we drop the following guideline completely[1]

  The following types of changes are generally *not* considered acceptable:
   Changing which response code is returned on success.

Thanks
Ken Ohmichi

---
[1]: 
https://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html#guidance

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][api] POST /api-wg/news

[Ken';ichi Ohmichi]

2017-02-06 2:51 GMT-08:00 Jordan Pittier :
>>
>> >> If we change the success status code (200 ->204) without any version
>> >> bumps, OpenStack clouds return different status codes on the same API
>> >> operations.
>> >> That will break OpenStack interoperability and clients' APPs need to
>> >> be changed for accepting 204 also as success operation.
>> >> That could make APPs code mudness.
>> >> I also think this is basically code bug, but this is hard to fix
>> >> because of big impact against the existing users.
>> >
>> >
>> > There have been lots of different opinions and perspective on this
>> > (in the reviews and elsewhere), all of which are pretty sensible but
>> > as a mass are hard to reconcile. The below is reporting evidence, not
>> > supporting a plan:
>> >
>> >   The API-WG is striving for OpenStack APIs to be consistent within
>> >   themselves, with each other and with the HTTP RFCs. This particular
>> >   issue is an example where none of those are satisfied.
>> >
>> > Yet it is true that if client code is specifically looking for a
>> > 200 response this change, without a version signal, will break
>> > that code.
>> >
>> >   But glance isn't set up with microversions or something like.
>> >
>> >   But isn't checking specifically for 200 as "success" unusual so
>> >   this is unlikely to be as bad as changing a 4xx to some other
>> >   4xx.
>> >
>> >   But correcting the docs so they indicate this one request out of
>> >   several in a group breaks the 204 pattern set by the rest of
>> >   the group and could easily be perceived as a typo and thus need
>> >   to be annotated as "special".
>> >
>> > How do we reconcile that?
>>
>> This API has been implemented since 2 years ago, and it is easy to
>> imagine many users are using the API.
>> If changing success status code like this, we send a message "status
>> code could be changed anytime" to users and users would recognize "the
>> success status code is unstable and it is better to check status code
>> range(20X) instead of a certain code(200, 201, etc) for long-term
>> maintenance".
>
>
> I think we should be pragmatic. There's a a difference between changing one
> return code from 200->204 (still in the 2XX range), for one endpoint
> exceptionally and saying "we keep changing status code, OpenStack is not
> stable".
>
> Microversions are great, but not all projects support them yet. In the mean
> time, if a project properly documents through a release note a minor API
> change (like this one), that sounds reasonable. Sure some user code will
> break, at upgrade, but let's be realistic here things get broken after a
> major upgrade of every software, that's why operators/deployers test the
> upgrades beforehand.

On the above scenario, I feel we need to distinguish users between
operators and API consumers.
It is true that operators tend to face upgrade issues many times and
they are testing on each upgrade.
They can see the corresponding release note because they upgrade the
cloud by themselves.
However, API consumers don't read release notes because they don't
maintain the used clouds, they just use clouds.
In addition, API consumers should be able to switch OpenStack clouds on-demand.
It is better that clouds do the same behaviors for the
interoperability even if the destination cloud is older version.

>> If the above is we expect/hope, why should we fix/change success code
>> to ideal one?
>> On the above scenario, we are expecting users should not check a certain
>> code.
>> So even if changing status code, users would not be affected by the
>> change.
>> Whom we are changing the status code for?
>
>
> That's a good question. In that case we should do it "for us, the
> developers". I prefer to work with a sane code base, sane API, small
> technical debt. But I also understand the users are paying us for stability.

Yeah, I can see the motivation as a developer.
However, I cannot be confident to say the impact of the change is
small for users.

Thanks
Ken Ohmichi

---


>> > Some opinions of my own:
>> >
>> > I worry that we're making it ever harder to fix bugs and technical
>> > debt in many areas of OpenStack. Sure, there are very good reasons
>> > for the constraints we build in, but how much tech debt are we
>> > making ourselves carry? We have the versioning concepts to help (for
>> > those projects that use them) but we haven't yet agreed how to
>> > cleanly deprecate past stuff or even if we can or should.
>> >
>> > I don't feel too bad about that worry, because I know there are
>> > plenty of people who worry about other things that balance it out
>> > for a reasonable compromise.
>> >
>> >
>> > --
>> > Chris Dent ¯\_(ツ)_/¯   https://anticdent.org/
>> > freenode: cdent tw: @anticdent
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not fo

Re: [openstack-dev] [all][api] POST /api-wg/news

[Ken';ichi Ohmichi]

2017-02-03 9:56 GMT-08:00 Chris Dent :
> On Thu, 2 Feb 2017, Ken'ichi Ohmichi wrote:
>>>
>>> In today's meeting [0] after briefly covering old business we spent
>>> nearly
>>> 50 minutes going round in circles discussing the complex interactions of
>>> expectations of API stability, the need to fix bugs and the costs and
>>> benefits of microversions. We didn't make a lot of progress on the
>>> general
>>> issues, but we did #agree that a glance issue [4] should be treated as a
>>> code bug (not a documentation bug) that should be fixed. In some ways
>>> this
>>> position is not aligned with the ideal presented by stability guidelines
>>> but
>>> it is aligned with an original goal of the API-WG: consistency. It's
>>> unclear
>>> how to resolve this conflict, either in this specific instance or in the
>>> guidelines that the API-WG creates. As stated in response to one of the
>>> related reviews [5]: "If bugs like this don't get fixed properly in the
>>> code, OpenStack risks going down the path of Internet Explorer and people
>>> wind up writing client code to the bugs and that way lies madness."
>>
>>
>> I am not sure the code change can avoid the madness.
>
>
> Just for the record, I'm not the speaker of that quote. I included
> it because I think it does a good job of representing the complexity
> and confusion that we have going on or at least in inspiring
> responses that help to do so.
>
> Which is a round about way of saying: Thank you very much for
> responding.

Haha, I see.

>> If we change the success status code (200 ->204) without any version
>> bumps, OpenStack clouds return different status codes on the same API
>> operations.
>> That will break OpenStack interoperability and clients' APPs need to
>> be changed for accepting 204 also as success operation.
>> That could make APPs code mudness.
>> I also think this is basically code bug, but this is hard to fix
>> because of big impact against the existing users.
>
>
> There have been lots of different opinions and perspective on this
> (in the reviews and elsewhere), all of which are pretty sensible but
> as a mass are hard to reconcile. The below is reporting evidence, not
> supporting a plan:
>
>   The API-WG is striving for OpenStack APIs to be consistent within
>   themselves, with each other and with the HTTP RFCs. This particular
>   issue is an example where none of those are satisfied.
>
> Yet it is true that if client code is specifically looking for a
> 200 response this change, without a version signal, will break
> that code.
>
>   But glance isn't set up with microversions or something like.
>
>   But isn't checking specifically for 200 as "success" unusual so
>   this is unlikely to be as bad as changing a 4xx to some other
>   4xx.
>
>   But correcting the docs so they indicate this one request out of
>   several in a group breaks the 204 pattern set by the rest of
>   the group and could easily be perceived as a typo and thus need
>   to be annotated as "special".
>
> How do we reconcile that?

This API has been implemented since 2 years ago, and it is easy to
imagine many users are using the API.
If changing success status code like this, we send a message "status
code could be changed anytime" to users and users would recognize "the
success status code is unstable and it is better to check status code
range(20X) instead of a certain code(200, 201, etc) for long-term
maintenance".

If the above is we expect/hope, why should we fix/change success code
to ideal one?
On the above scenario, we are expecting users should not check a certain code.
So even if changing status code, users would not be affected by the change.
Whom we are changing the status code for?
That seems a dilemma.

Thanks
Ken Ohmichi

---

> Some opinions of my own:
>
> I worry that we're making it ever harder to fix bugs and technical
> debt in many areas of OpenStack. Sure, there are very good reasons
> for the constraints we build in, but how much tech debt are we
> making ourselves carry? We have the versioning concepts to help (for
> those projects that use them) but we haven't yet agreed how to
> cleanly deprecate past stuff or even if we can or should.
>
> I don't feel too bad about that worry, because I know there are
> plenty of people who worry about other things that balance it out
> for a reasonable compromise.
>
>
> --
> Chris Dent ¯\_(ツ)_/¯   https://anticdent.org/
> freenod

Re: [openstack-dev] [all][api] POST /api-wg/news

[Ken';ichi Ohmichi]

2017-02-02 9:38 GMT-08:00 Chris Dent :
>
> Greetings OpenStack community,
>
> In today's meeting [0] after briefly covering old business we spent nearly
> 50 minutes going round in circles discussing the complex interactions of
> expectations of API stability, the need to fix bugs and the costs and
> benefits of microversions. We didn't make a lot of progress on the general
> issues, but we did #agree that a glance issue [4] should be treated as a
> code bug (not a documentation bug) that should be fixed. In some ways this
> position is not aligned with the ideal presented by stability guidelines but
> it is aligned with an original goal of the API-WG: consistency. It's unclear
> how to resolve this conflict, either in this specific instance or in the
> guidelines that the API-WG creates. As stated in response to one of the
> related reviews [5]: "If bugs like this don't get fixed properly in the
> code, OpenStack risks going down the path of Internet Explorer and people
> wind up writing client code to the bugs and that way lies madness."

I am not sure the code change can avoid the madness.
If we change the success status code (200 ->204) without any version
bumps, OpenStack clouds return different status codes on the same API
operations.
That will break OpenStack interoperability and clients' APPs need to
be changed for accepting 204 also as success operation.
That could make APPs code mudness.
I also think this is basically code bug, but this is hard to fix
because of big impact against the existing users.

Thanks
Ken Ohmichi

---

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][qa] gate-grenade-dsvm-neutron-multinode-live-migration-nv is 100% fail since 1/21

[Ken';ichi Ohmichi]

2017-01-27 19:35 GMT-08:00 Matt Riedemann :
> On 1/27/2017 5:00 PM, Matt Riedemann wrote:
>>
>> I noticed that this job is 100% failure since 1/21:
>>
>> http://tinyurl.com/zjh5bc5
>>
>>
>> http://logs.openstack.org/61/417961/40/check/gate-grenade-dsvm-neutron-multinode-live-migration-nv/8c363cd/logs/devstack-gate-post_test_hook.txt.gz#_2017-01-27_23_43_40_367
>>
>>
>> For whatever reason, live_migration=False in tempest.conf:
>>
>>
>> http://logs.openstack.org/61/417961/40/check/gate-grenade-dsvm-neutron-multinode-live-migration-nv/8c363cd/logs/new/tempest_conf.txt.gz
>>
>>
>
> The only thing I can think that might be causing some mischief is the
> devstack-tools stuff that was integrated recently into the CI system, which
> messes with local.conf. But I don't know enough about how that works, so
> would need sdague to investigate.

Yeah, this misconfiguration happens only on grenade multinode jobs only.
The live_migration config is set correctly on tempest multinode jobs
like 
http://logs.openstack.org/16/411816/5/check/gate-tempest-dsvm-multinode-live-migration-ubuntu-xenial/4a95eca/logs/tempest_conf.txt.gz
which its grenade multinode jobs fails on the same time.

Thanks

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Planning for the Pike PTG

[Ken';ichi Ohmichi]

I am preparing for PTG sessions.
How much capacity is in each room ? 30 people or more?

We might want to have different discussions or coding meetups in
parallel in the same room, because each developer concentrates on
different working topics (Tempest, Devstack, Grenade, Patrole, etc
under QA project).
So it is nice to make a few circles with desks and chairs for each topics.
Maybe this is a common thing in the other projects and I'd like to
know how many topics can run in parallel from the room capacity.

Thanks
Ken Ohmichi

---



2017-01-04 2:16 GMT-08:00 Thierry Carrez :
> Matt Riedemann wrote:
>> I haven't been living under a rock but I'm not aware of any major
>> announcements regarding session planning for the PTG - has that happened
>> somewhere and I'm just in the dark?
>>
>> I'm mostly wondering about the Monday and Tuesday cross-project sessions
>> - are those time-boxed sessions like at the summit and will have a
>> schedule? Or are we just playing fast and loose and hoping someone will
>> lead us out of a hallway and into a room for Major Synergy (tm)?
>
> There are no "cross-project sessions" on Monday-Tuesday. There are a
> number of horizontal team meetings (Infrastructure, QA, Documentation,
> Security, Oslo...), transverse team meetings (Horizon, Kolla,
> OpenStackClient, AppCatalog, RPM packaging...), and workgroup meetings
> (Architecture WG, Stewardship WG, Interop WG...). All of those are full
> days (or full 2-days) in a room owned by a given team (and PTL or chair)
> and they are free to organize in whatever way they see fit (there are no
> time-boxed sessions, so we expect most teams to use an etherpad-based
> open agenda).
>
> We'll also have a room (or two) dedicated to the Pike goals (currently
> under discussion) -- whoever wants to meet and make quick progress on
> the Pike goals during the PTG should be able to find facilitators there.
> We are still waiting on the final list of goals to formally make
> progress on that front.
>
> Additionally from Monday to Thursday we'll have one openly-scheduled
> fishbowl room, in case we need to have specific discussions. Think a
> Cinder/Nova/os-brick discussion outside of the Nova and Cinder-specific
> rooms, but for which you'd rather not all stand in the hallway. For that
> room I thought we could set up an etherpad with time slots and let
> people schedule topics there on the spot... But I'm happy to take
> suggestions.
>
>> I see project teams are working on getting etherpads together for
>> topics, including myself, which got me thinking about how to plan the
>> Wed-Friday sessions which for a midcycle meetup would normally be a list
>> of topics that we'd go through in order (or by priority) but not
>> time-boxed or scheduled. But then I got thinking about how the PTG is
>> right before we start working on Pike, so I'm now thinking we need more
>> structure than what we did at the midcycles, and more like what we do at
>> the design summit with respect to scheduled discussions about things
>> that are going to be worked on in the upcoming release, figuring out
>> goals, determining review priorities, etc - which is actually a lot more
>> work to plan and schedule ahead of time, especially when we consider
>> (vertical) cross-project sessions like between nova/cinder or nova/neutron.
>
> One of the goals of splitting the Design Summit into PTG & Forum is to
> separate the "feedback/requirements gathering" phase (at the Forum) from
> the "let's plan and bootstrap the actual work" phase (at the PTG). The
> Pike PTG is arguably a transition PTG, since we won't have had a "Forum"
> in the months before. The PTG is still happening at a point where most
> people already started working on Pike though (rather than "right before
> we start working on Pike"), and ideally should be focused on
> implementation plans, review priorities and getting things done, without
> the constraints of time-boxed slots.
>
> That said, you should definitely take advantage of having everyone
> around (and with less scheduling constraints compared to Summit) to
> discuss inter-project questions (think Nova/Neutron or Nova/Cinder). You
> can hold those within your room if you think all team members should
> follow them, or take advantage of the aforementioned extra fishbowl room
> to hold those.
>
>> In other words, the fact I haven't had anxiety yet about planning the
>> PTG makes me anxious that I'm falling way behind already.
>
> I don't think you are way behind. Now is a good time to brainstorm on an
> etherpad what your team needs to discuss and do during those days. If
> you identify inter-project discussions, there is still time to reach out
> to those other teams to make sure it's on their radar as well, and
> arrange a common time for the discussion. I like to think we can achieve
> that without the stress and constraints of strict centralized
> scheduling, using a more peer-to-peer/unconference approach to magically
> make the best use of our time 

[openstack-dev] [qa] PTL non-candidacy

[Ken';ichi Ohmichi]

Hi,

I will step down as PTL after this Ocata cycle.
I was happy to see new ideas and folks who try making ideas true in
this 2 cycles.
Now QA project has a lot of components with many people's effort and
we help each other as a community.
This experience is very exciting for me, I am proud to being a member
in this community.

Today, I'd like to concentrate on coding and reviewing again as a developer.
I think we have good candidates for a next PTL, and I will keep active
under the next PTL's leadership.

Thanks for choosing me anyways, let's make OpenStack quality better together :-)

Thanks
Ken Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance][tempest][api] community images, tempest tests, and API stability

[Ken';ichi Ohmichi]

2017-01-13 9:25 GMT-08:00 Ian Cordasco :
> -Original Message-
> From: Ian Cordasco 
> Reply: Ian Cordasco 
> Date: January 13, 2017 at 08:12:12
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject:  Re: [openstack-dev] [glance][tempest][api] community images,
> tempest tests, and API stability
>
>> And besides "No one uses Glance" [ref: 
>> http://lists.openstack.org/pipermail/openstack-dev/2013-February/005758.html]
>
> I was being a bit glib when I wrote this last sentence this morning,
> but in commenting on the Gerrit patch to skip the test in question, I
> realized this is actually far more valid than I realized.
>
> Let's look at the state of Glance v2 and be brutally honest:
>
> Interoperability
>
> Glance v2 is currently incapable of being truly interoperable between
> existing publicly accessible clouds. There are two ways to currently
> upload images to Glance. Work is being done to add a third way that
> suits the needs of all cloud providers. This introduces further
> interoperability incompatibility (say *that* three times fast ;)) and
> honestly, I don't see it being a problem for the next reason.
>
> Further, the tasks API presents a huge number of interoperability
> problems. We've limited that to users with the admin role, but if you
> have an admin on two clouds operated by different people, there is a
> good likelihood the tasks will not be the same.
>
>
> v2 deployment and usage
>
> The best anyone working on Glance can determine, v2 is rarely deployed
> for users and if it is, it isn't chosen. v2 was written to specifically
> excise some problematic "features" that some users still rely on. A
> such, you see conversations even between Glance and *other services*
> about how to migrate to v2. Nova only recently made the migration. Heat
> still has yet to do so and I think has only just relented in their
> desire to avoid it.

Humm, Defcore list contains Glance v2 tests for the interoperability
like https://github.com/openstack/defcore/blob/master/2016.08.json#L1366
# We can see Tempest tests of Glance v2 API by searching "tempest.api.image.v2".
I guess many deployments provide the v2 API today..

> Security Concerns
>
> There are some serious security issues that will be fixed by this
> change. If we were to add the backwards compatibility shim that the QA
> team has suggested repeatedly that we add, we'd be keeping those security
> issues.

Security issues/problems should be solved as the highest priority.
The progress should be nice if having CVE.

> In short, I feel like the constant refrain from the QA team has been two fold:
>
> - "This will cause interoperability problems"
> - "This is backwards incompatible"
>
> The Glance team has come to terms with this over the course of several
> cycles. I don't think anyone is thrilled about the prospect of
> potentially breaking some users' workflows. If we had been that
> enthusiastic about it, then we simply would have acted on this when it
> was first proposed. It would have completely gone unnoticed except by
> some users. There's no acceptable way (without sacrificing security -
> which let's be clear, is entirely unacceptable) that we can maintain a
> backwards compatibility shim and Glance v2 already has loads of
> interoperability problems. We're working on fixing them, but we're
> also working on fixing the user experience, which is a big part of
> this patch.

I think Glance team has spent time and considering for moving to this
direction and I believe the team will take responsibility if facing
issues on the direction.
Then I also am going to take this way.

Thanks
Ken Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance][tempest][api] community images, tempest tests, and API stability

[Ken';ichi Ohmichi]

2017-01-12 5:47 GMT-08:00 Brian Rosmaita :
> On 1/11/17 10:35 PM, GHANSHYAM MANN wrote:
>
>> But from meeting logs, it looks like impression was(if am not wrong) that
>> Tempest test[1] is not doing the right thing and should be ok to change.
>> I do not think this is the case, Tempest test is doing what API
>> tells/behave. Below is what test does:
>>  1. Tenant A creates image with explicitly visibility as private.
>>  2. Tenant A add Tenant B as member of created image to allow Tenant B to
>> use that.
>>
>> API [2] or Image sharing workflow [3] does not say/recommend anywhere that
>> Image should not be created with private visibility as explicitly.
>>
>> For me this change breaks people "Creating Image with private visibility as
>> *explicitly* and adding member to that" which will be 409 after glance
>> proposal.
>>
>>
>> Also changing tempest tests does not solve the problem, backward
>> incompatible is still will be introduced in API.
>
> The issue is that we are proposing to introduce an incompatible change
> in order to address an incoherence with image visibility semantics.  We
> have acknowledged that this is a breaking change, but the impact of the
> change is mitigated by the way that the default visibility value is
> assigned in Ocata.
>
> As I've documented earlier in the thread, we have discussed this change
> with the wider community and the API Working Group, and they are OK with it.
>
> The current tempest test has done its duty and identified an
> incompatibility in the Ocata code.  We acknowledge that and salute you.
> On balance, however, this change will be better for users (and as I've
> documented earlier in the thread, we've minimized the impact of the
> change), and we want to make it anyway.

It is difficult to expect the impact of API change is small by us as developers.
For example, if there could be some APPs which list images of both
private and shared by depending on
https://bugs.launchpad.net/glance/+bug/1394299 , the APPs will be
broken after fixing it.
Nova team faced such situation we expected the impact of the change
was small but horizon was broken, then we reverted the change in the
same dev cycle.
Then Nova has now API microversions mechanism to avoid impacting to
the existing APPs.

This is on very difficult balance, and we don't want to block the
glance team development.
We have some procedure for this situation like
https://github.com/openstack/tempest/blob/master/HACKING.rst#2-bug-fix-on-core-project-needing-tempest-changes
I did put some comments on https://review.openstack.org/#/c/414261 .
Could you check that?

Thanks
Ken Ohmichi

---

> So the situation isn't that we are claiming that your current code is
> flawed.  Rather, it is that we are asking the QA team to approve a
> change to that test in order to address a change we are making in Ocata,
> a change that has the support of the OpenStack community.
>
> thanks,
> brian
>
>>
>> .. 1
>> http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/image/v2/test_images.py#n338
>>
>> .. 2 http://developer.openstack.org/api-ref/image/v2/#create-an-image
>> .. 3
>> http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html
>>
>>
>> Regards
>> Ghanshyam Mann
>> +818011120698
>>
>>
>> On Mon, Jan 9, 2017 at 10:30 PM, Brian Rosmaita 
>> wrote:
>>
>>> On 1/5/17 10:19 AM, Brian Rosmaita wrote:
 To anyone interested in this discussion: I put it on the agenda for
 today's API-WG meeting (16:00 UTC):

 https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
>>>
>>> As you probably noticed in the API-WG newsletter [A], this issue was
>>> discussed at last week's API-WG meeting.  The complete discussion is in
>>> the meeting log [B], but the tldr; is that the proposed change is
>>> acceptable.  I'll address specific points inline for those who are
>>> interested, but the key request from the Glance team right now is that
>>> the QA team approve this patch:
>>>
>>> https://review.openstack.org/#/c/414261/
>>>
>>>
>>> [A]
>>> http://lists.openstack.org/pipermail/openstack-dev/2017-
>>> January/109698.html
>>> [B]
>>> http://eavesdrop.openstack.org/meetings/api_wg/2017/api_
>>> wg.2017-01-05-16.00.log.html
>>>
 On 12/25/16 12:04 PM, GHANSHYAM MANN wrote:
> Thanks Brian for bringing this up, same we been discussing last week on
>>> QA
> channel and this patch[1] but I completely agree with Matthew opinion
>>> here.
> There is no doubt that this change(4-valued) are much better and clear
>>> than
> old one. This makes much defined and clear way of defining the image
> visibility by/for operator/user.
>>>
>>> Yes, we think that the change clarifies the visibility semantics of
>>> images and, in particular, fixes the problem of there being "private"
>>> images that aren't actually private.
>>>
>>> The current situation is easily misunderstood by end users, as evidenced
>>> by bugs that have been filed, for example,
>>> https://bugs.launchpad.net/glance/

[openstack-dev] [qa][ptg] session idea for Pike cycle

[Ken';ichi Ohmichi]

Hi QA-team,

We will have the first PTG[1] next Feb and it is nice to get session ideas now.
I am looking forward to seeing new ideas and discussing them together
as the community.
The etherpad is https://etherpad.openstack.org/p/qa-ptg-pike
Please write your ideas down on that if you have.
Thanks for your contributions and see you in Atlanta.


Thanks
Ken Ohmichi

---
[1]: https://www.openstack.org/ptg/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Infra][heat][QA] Tempest layer4 job failure due to heat devstack plugin switch.

[Ken';ichi Ohmichi]

2016-12-06 19:42 GMT-08:00 GHANSHYAM MANN :
> Hi All,
>
> Recently all gate heat gate jobs were switched to use heat devstack plugin
> and heat code was removed from devstack tree.
>
> During that tempest layer 4 job is missed and blocked the tempest gate[1].
> Also another heat job had issue for enabling plugin [2].
>
> Fixes are up for both job fix, hope infra team can merge those ASAP.
>
> - Tempest layer4 job fix - https://review.openstack.org/#/c/407807/
> - Heat job fix - https://review.openstack.org/#/c/407817/
>
> ..1
> http://logs.openstack.org/68/407768/1/check/gate-tempest-dsvm-layer4-ubuntu-xenial/9499d2a/logs/testr_results.html.gz
> ..2
> http://logs.openstack.org/14/406514/1/check/gate-tempest-dsvm-heat-identity-v3-only-nv/0e51c2b/logs/testr_results.html.gz

Thank you very much for your help, anyways.

Thanks
Ken Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] [openstack-health] Avoid showing non-official projects failure ratios

[Ken';ichi Ohmichi]

2016-12-02 5:39 GMT-08:00 Masayuki Igawa :
> Hi,
>
> On Fri, Dec 2, 2016 at 6:29 PM, Andreas Jaeger  wrote:
>> On 12/02/2016 10:03 AM, Thierry Carrez wrote:
>>> Ken'ichi Ohmichi wrote:
>>>> Hi QA-team,
>>>>
>>>> In the big-tent policy, we continue creating new projects.
>>>> On the other hand, some projects became non-active.
>>>> That seems natural thing.
>>>>
>>>> Now openstack-health[1] shows non-active project as 100% failure ratio
>>>> on "Project Status".
>>>> The project has became non-official since
>>>> https://review.openstack.org/#/c/324412/
>>>> So I feel it is nice to have black-list or something to make it
>>>> disappear from the dashboard for concentrating on active projects'
>>>> failures.
>>>>
>>>> Any thoughts?
>>>
>>> Yes, I totally agree we should only list active official projects in
>>> there, otherwise long-dead things like Cue will make the view look bad.
>>> Looks like the system adds new ones but does not remove anything ? It
>>> should probably take its list from [1].
>>>
>>> [1]
>>> http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
>>
>> Is cue completely dead? Should we then retire it completely following
>> http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project ?
>>
>> It still has jobs setup and I see people submitting typo fixes etc.
>
> I'm not sure the cue is dead or not. But I think we should fix the
> failure of the job or remove the periodic jobs. Otherwise, the job
> just waste the resource of the OpenStack infra..

Yeah, that is a nice point.
And this case means openstack-health notifies this wasting resource on
the infra, that is good thing.
The failing job is already removed since
https://review.openstack.org/#/c/404375/
So we will not see the failure on the dashboard soon, thanks for helping that.

> But we should have the filter feature like a 'Project Type' of
> stackalitics, probably. I think it's useful for openstack-health
> users.

Yeah, it might be useful. But it is fine to wait for seeing the above result.
Maybe our motivation of the filter feature will become less after that ;)

Thanks
Ken Ohmichi

---

>>
>>
>> Andreas
>> --
>>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>>HRB 21284 (AG Nürnberg)
>> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Nominating Stephen Finucane for nova-core

[Ken';ichi Ohmichi]

2016-12-02 7:22 GMT-08:00 Matt Riedemann :
> I'm proposing that we add Stephen Finucane to the nova-core team. Stephen
> has been involved with nova for at least around a year now, maybe longer, my
> ability to tell time in nova has gotten fuzzy over the years. Regardless,
> he's always been eager to contribute and over the last several months has
> done a lot of reviews, as can be seen here:
>
> https://review.openstack.org/#/q/reviewer:sfinucan%2540redhat.com
>
> http://stackalytics.com/report/contribution/nova/180
>
> Stephen has been a main contributor and mover for the config option cleanup
> series that last few cycles, and he's a go-to person for a lot of the
> NFV/performance features in Nova like NUMA, CPU pinning, huge pages, etc.
>
> I think Stephen does quality reviews, leaves thoughtful comments, knows when
> to hold a +1 for a patch that needs work, and when to hold a -1 from a patch
> that just has some nits, and helps others in the project move their changes
> forward, which are all qualities I look for in a nova-core member.
>
> I'd like to see Stephen get a bit more vocal / visible, but we all handle
> that differently and I think it's something Stephen can grow into the more
> involved he is.
>
> So with all that said, I need a vote from the core team on this nomination.
> I honestly don't care to look up the rules too much on number of votes or
> timeline, I think it's pretty obvious once the replies roll in which way
> this goes.

+1

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [qa] [openstack-health] Avoid showing non-official projects failure ratios

[Ken';ichi Ohmichi]

Hi QA-team,

In the big-tent policy, we continue creating new projects.
On the other hand, some projects became non-active.
That seems natural thing.

Now openstack-health[1] shows non-active project as 100% failure ratio
on "Project Status".
The project has became non-official since
https://review.openstack.org/#/c/324412/
So I feel it is nice to have black-list or something to make it
disappear from the dashboard for concentrating on active projects'
failures.

Any thoughts?

Thanks
Ken Ohmichi
---

[1]: http://status.openstack.org/openstack-health/#/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [release] New hacking 0.12.0

[Ken';ichi Ohmichi]

Hi,

Today a new hacking 0.12.0 is released.
The release contains a new hacking rule:

[H904] Delay string interpolations at logging calls.

BTW, the hacking repo starts containing reno since this release but it
is not used yet.
Please check the git history (or
https://review.openstack.org/#/c/343824) if wanting to know the
detail.

Thanks
Ken Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [qa] Summary of design summit for Ocata

[Ken';ichi Ohmichi]

Hi QA-team,

Thanks for joining QA sessions on OpenStack Summit Barcelona.
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.

* (Tempest) Add an option for stopping cleanup when test failure happens
  Main assignee / organizer: dpaterson, mkopec
  Milestone: O-3
  Description:
As the design principle, Tempest should clean all created resource
up when finishing.
However the cleanup makes difficult to debug problems sometimes
because the failure situation is deleted.
Nice to add an option into tempest.conf or 'tempest run' command
for disabling the cleanup.

* (Tempest) Add an option for the number of target VMs to test live-migration
  Main assignee / organizer: gmann
  Milestone: O-2
  Description:
On production clouds, it is common to migrate multiple virtual
machines to the other host.
Current Tempest migrates a single virtual machine in each test.
Nice to add an option to control the number of target machines.

* (Tempest) Add and decorator into bug-reproducing tests to know
actual bug number from test failure
  Main assignee / organizer: oomichi, dmellado
  Milestone: O-2
  Description:
When fixing a bug on each project, it is nice to propose Tempest
test to reproduce the bug on the gate.
Such Tempest tests can help detecting latent bugs on production
clouds which are deployed with older OpenStack versions.
By knowing the LP bug number from the test, testers can know which
patch is necessary to be applied to thier own clouds according to the
LP report.
Now they can know it from Tempest git history(Related-Bug tag),
but that is a little hard.
A new test decorator will help to know that easily.

* (Tempest) Reduce deep test class inheritance for easy debugging
  Main assignee / organizer: ekhugen, dmellado, jhakimra andreaf
  Milestone: O-3
  Description:
We are still seeing deep backtrace when some Tempest tests fail.
That makes hard to debug problems because testers need to read
many test modules.
At first, we need to know how deep on current test inheritances
and define the target depth for reducing.
So some tool is necessary to know current test inheritances as first step.

* (Tempest) Bug Triage
  Main assignee / organizer: masayukig, gmann, jhakimra, luzC,
ababich, dmellado
  Milestone: End of Ocata
  Description:
The bug report number of Tempest continues increasing and we need
bug triage.
In this Ocata cycle, many people raise hands for this bug triage.
Thanks so much.
We will do that in weekly rotation and report the progress in
weekly meetings.
https://etherpad.openstack.org/p/ocata-qa-bug-triage is for
managing assignees.

* OpenStack Health
  Main assignee / organizer: masayukig
  Milestone: O-2
  Description:
Submit ideas to launchpad from the session feedback and prioritize them.
The feedback was
- Unit test coverage of each project (Nova, Cinder, etc)
- Test failure ratio ranking by test

* Destructive testing
  Main assignee / organizer: Timur Nurlygayanov
  Milestone: O-2 (qa-spec at least)
  Description:
To clarify the scope, user story and test scenario, qa-spec is
necessary to be proposed.
On the implementation side, it is better to avoid separated repos
of os-faults and stepler for its maintenance.

* Policy testing
  Main assignee / organizer:
  Milestone: O-2 (qa-spec at least)
  Description:
This test will be implemented with tempest-plugin from separated
repo which is different from Tempest.
The qa-spec is already proposed as https://review.openstack.org/#/c/382672/

If having questions, please send mails to me or "Main assignee / organizer".
Thanks for your help.

Reference:
* Ocata Priorities: https://etherpad.openstack.org/p/ocata-qa-priorities
* Etherpads of QA:
https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#QA_.28Quality_Assurance.29

Thanks
Ken Omichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA][Tempest] Check puppet jobs on the gate

[Ken';ichi Ohmichi]

Hi QA team,

There are three gate jobs related to puppet jobs (like
gate-puppet-openstack-integration-4-scenario001-tempest-centos-7-nv)
and they are marked as non-voting now.
If finding these jobs failures during Tempest patch reviews even but
jenkins +1, please notify the failures to the following guys on
#openstack-qa channel if possible.

  EmilienM
  mwhahaha
  dmsimard

It is fine to just notify that without any investigations.
Some projects are still using Tempest internal code without using
stable Tempest library code(aka tempest.lib) and the internal change
of Tempest can affect these projects' gates.
The puppet jobs can detect such effect before merging, and the above
guys will help the quality improvement in such cases.

Thanks
Ken Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA] Request for design session ideas of Barcelona Summit

[Ken';ichi Ohmichi]

Hi QA team,

Thanks for providing ideas for Barcelona summit.
I am trying to fit ideas for each design slots, please see the
following etherpad.

  https://etherpad.openstack.org/p/ocata-qa-summit-topics

Current content is just a prototype and not concrete yet.
I am happy if you give feedback to us on the etherpad or this mail thread :)

Thanks
Ken Ohmichi.

2016-09-27 12:40 GMT-07:00 Ken'ichi Ohmichi :
> Hi,
>
> We have a Design Summit next month, and now we are trying to get ideas
> for QA sessions.
> There is an etherpad for ideas and it is good if writing your ideas on that:
>
> https://etherpad.openstack.org/p/ocata-qa-summit-topics
>
> After getting ideas, we will arrange them into available slots for QA 
> sessions.
> Thanks in advance and see you in Barcelona :-)
>
> Thanks
> Ken Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA] The end-user test suite for OpenStack clusters

[Ken';ichi Ohmichi]

Hi Timur,

I discussed this on irc, and it seems hard to get feedback from many
people because now the scope and implementation of this os-faults are
separated into multiple pieces(like multiple mails, github code,
gerrit etc).
So how about proposing this as qa-spec?
If doing that, We can discuss this on clear document and it is clear
to get a consensus about adding this.

Thanks
Ken Ohmichi

---

.

2016-10-07 12:43 GMT-07:00 Ken'ichi Ohmichi :
> Hi Timur,
>
> 2016-10-06 4:08 GMT-07:00 Timur Nurlygayanov :
>> Ken, it is a good idea!
>>
>> The plan is to develop os-faults as a library which will be able
>> to manage cluster nodes and OpenStack services on these nodes.
>> It is a good idea to add some Tempest tests which will use
>> os-faults library as well for some API tests.
>
> Sorry for my misleading, that is not I wanted to say.
> I am thinking Tempest doesn't use os-faults as library.
> I just wanted to say some destructive tests which will use REST APIs
> can be implemented in Tempest instead of os-faults.
>
> For example, the compute service client contains disable_service which
> disables nova service but Tempest doesn't contain the corresponding
> test cases because Tempest tests need to run in parallel.
> https://github.com/openstack/tempest/blob/master/tempest/lib/services/compute/services_client.py#L54
>
> If some tests use this method, the other tests which run in parallel
> can be failed as unexpected on the gate.
> Such tests also are destructive and I am hoping these tests also will
> be able to run the gate by finding better way.
>
>> The Stepler framework [1] will use os-faults to perform all destructive
>> actions in the clouds (the reboot of nodes, restart of OpenStack services,
>> enable/disable network interfaces or some firewall rules and etc).
>>
>> We need to get +1 from you in [1] to create the repository with
>> advanced end-user scenario tests.
>
> OK, I'd like to summarize my thinking here for adding os-faults under
> QA project:
>
> Under QA project, the first target of most programs(tempest, devstack,
> etc) is for the gate testing.
> Of course, some of them are available on production clouds also as the
> design, but the first is for the gate.
> That means devstack clouds as the first target/purpose.
> At this time, this os-faults doesn't seem the gate as the first
> purpose based on current implementation.
> So I feel os-faults seems different from the existing programs.
>
> os-faults is very young and we will be able to extend it for devstack
> clouds also later, I hope.
> In addition, I heard this kind of tests(destructive, HA, etc) are
> requested from the other users.
> So this os-faults seems very valuable for users.
>
> Just in my opinion, I am find to add this os-faults under QA project.
> But before that, I'd like to get opinions from the other people of QA team.
>
> Thanks
> Ken Ohmichi
>
>
>
>
>
>
>
>
>
>
>
>
>> On Tue, Oct 4, 2016 at 8:53 PM, Yaroslav Lobankov 
>> wrote:
>>>
>>> Hi Ken,
>>>
>>> OS-Faults doesn't have any scenarios in the tree yet (the project is two
>>> months old), but you can find some examples of the use in the
>>> os-faults/examples directory.
>>>
>>> Regards,
>>> Yaroslav Lobankov.
>>>
>>> On Tue, Oct 4, 2016 at 8:02 PM, Ken'ichi Ohmichi 
>>> wrote:
>>>>
>>>> Hi Timur,
>>>>
>>>> Thanks for your explanation.
>>>>
>>>> 2016-09-29 6:22 GMT-07:00 Timur Nurlygayanov
>>>> :
>>>> >
>>>> >> I am guessing the above "restart nodes" is for verifying each
>>>> >> OpenStack service restarts successfully, right?
>>>> >
>>>> > Yes, this is right. And we also will check that HA logic for these
>>>> > services works correctly (for example, rescheduling of L3 Neutron
>>>> > agents for networks).
>>>> >
>>>> >> But these service scripts are provided by distributors, and Devstack
>>>> >> itself doesn't contain service scripts IIUC.
>>>> >> So I'd like to know how to verify it on Devstack clouds.
>>>> >
>>>> > Yes, DevStack doesn't support many scenarios which are actual
>>>> > and should be supported on the production clouds.
>>>> > It will be not possible to run all advanced test scenarios for DevStack
>>>> > clouds,
>>>> > just because DevStack can't deploy OpenStack cloud with 3 controlle

Re: [openstack-dev] [QA][Cinder]Removing Cinder v1 in Tempest

[Ken';ichi Ohmichi]

Thanks for pointing this up, Jordan

Before removing volume v1 API tests, it is nice to make the v2 API the
default of Tempest scenario tests.
Now the v1 and v2 is set as True on the default in the
configuration[1], and the v1 API is used in the scenario like [2].
So it is better to switch using v2 API on the default.

Thanks
Ken Ohmichi

---

[1]: https://github.com/openstack/tempest/blob/master/tempest/config.py#L770
[2]: 
https://github.com/openstack/tempest/blob/master/tempest/scenario/manager.py#L83


2016-10-10 11:37 GMT-07:00 Matt Riedemann :
> On 10/10/2016 7:47 AM, Duncan Thomas wrote:
>>
>> If we can get them running on cinder patches via a different job, then
>> removing them from the common job afterwards seems reasonable.
>>
>> There's no strong will to remove them, several libraries still use them,
>> and given we're now supporting /all/ other API versions indefinitely,
>> keeping them around isn't that much of a burden.
>>
>> On 10 October 2016 at 15:32, Jordan Pittier > > wrote:
>>
>> Hi,
>> I'd like to reduce the duration of a full Tempest run and I noticed
>> that Cinder tests take a good amount of time (cumulative
>> time 2149sec vs 2256sec for Nova, source code [0])
>>
>> So I'd like to not run the Cinder v1 tests anymore, at least on the
>> master branches.
>>
>> I remember that Cinder  v1 is deprecated (it has been for what, 2
>> years ?) Is the removal scheduled ? I don't see/feel a lot of
>> efforts toward that removal but I may be missing something. Any way,
>> that's not really my business but it's not really fair to all the
>> projects that run the "common jobs" that Cinder "slows" everyone down.
>>
>> What do you think ?
>>
>> [0]
>> :
>> https://github.com/JordanP/openstack-snippets/blob/master/tempest-timing/tempest_timing.py
>>
>> 
>>
>>
>> 
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>>
>>
>>
>>
>> --
>> --
>> Duncan Thomas
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> So make it conditional in Tempest via a config option, disable volume v1
> tests by default for the integrated gate, and then add a new job that runs
> only on cinder changes (and maybe only in the experimental queue) that
> enables volume v1 tests. You could run it on cinder in the check/gate and
> skip the job from running unless something in the v1 API path is changed,
> there are examples of that in project-config.
>
> Nova used to have the v2 API in tree and this was kind of the eventual path
> to phasing out the Tempest testing on that code and got us to the point of
> removing the v2 *code*.  The compute v2 API itself is still honored via the
> v2.1 base microversion.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA] Presence at PTG Atlanta in February

[Ken';ichi Ohmichi]

Hi QA team,

As you know, the first PTG(Project Teams Gathering) happens at Atlanta
20th-24th February the next year.
After Barcelona, OpenStack Summit will be separated into two parts
(conferences and design sessions) and PTG is a new format for design
sessions for developers(Please see the detail on [1]).
QA is always important factor of developments, and I am thinking the
presence of QA project is good for the community.

Thanks
Ken Omichi

---
[1]: http://www.openstack.org/ptg

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA] The end-user test suite for OpenStack clusters

[Ken';ichi Ohmichi]

Hi Timur,

2016-10-06 4:08 GMT-07:00 Timur Nurlygayanov :
> Ken, it is a good idea!
>
> The plan is to develop os-faults as a library which will be able
> to manage cluster nodes and OpenStack services on these nodes.
> It is a good idea to add some Tempest tests which will use
> os-faults library as well for some API tests.

Sorry for my misleading, that is not I wanted to say.
I am thinking Tempest doesn't use os-faults as library.
I just wanted to say some destructive tests which will use REST APIs
can be implemented in Tempest instead of os-faults.

For example, the compute service client contains disable_service which
disables nova service but Tempest doesn't contain the corresponding
test cases because Tempest tests need to run in parallel.
https://github.com/openstack/tempest/blob/master/tempest/lib/services/compute/services_client.py#L54

If some tests use this method, the other tests which run in parallel
can be failed as unexpected on the gate.
Such tests also are destructive and I am hoping these tests also will
be able to run the gate by finding better way.

> The Stepler framework [1] will use os-faults to perform all destructive
> actions in the clouds (the reboot of nodes, restart of OpenStack services,
> enable/disable network interfaces or some firewall rules and etc).
>
> We need to get +1 from you in [1] to create the repository with
> advanced end-user scenario tests.

OK, I'd like to summarize my thinking here for adding os-faults under
QA project:

Under QA project, the first target of most programs(tempest, devstack,
etc) is for the gate testing.
Of course, some of them are available on production clouds also as the
design, but the first is for the gate.
That means devstack clouds as the first target/purpose.
At this time, this os-faults doesn't seem the gate as the first
purpose based on current implementation.
So I feel os-faults seems different from the existing programs.

os-faults is very young and we will be able to extend it for devstack
clouds also later, I hope.
In addition, I heard this kind of tests(destructive, HA, etc) are
requested from the other users.
So this os-faults seems very valuable for users.

Just in my opinion, I am find to add this os-faults under QA project.
But before that, I'd like to get opinions from the other people of QA team.

Thanks
Ken Ohmichi












> On Tue, Oct 4, 2016 at 8:53 PM, Yaroslav Lobankov 
> wrote:
>>
>> Hi Ken,
>>
>> OS-Faults doesn't have any scenarios in the tree yet (the project is two
>> months old), but you can find some examples of the use in the
>> os-faults/examples directory.
>>
>> Regards,
>> Yaroslav Lobankov.
>>
>> On Tue, Oct 4, 2016 at 8:02 PM, Ken'ichi Ohmichi 
>> wrote:
>>>
>>> Hi Timur,
>>>
>>> Thanks for your explanation.
>>>
>>> 2016-09-29 6:22 GMT-07:00 Timur Nurlygayanov
>>> :
>>> >
>>> >> I am guessing the above "restart nodes" is for verifying each
>>> >> OpenStack service restarts successfully, right?
>>> >
>>> > Yes, this is right. And we also will check that HA logic for these
>>> > services works correctly (for example, rescheduling of L3 Neutron
>>> > agents for networks).
>>> >
>>> >> But these service scripts are provided by distributors, and Devstack
>>> >> itself doesn't contain service scripts IIUC.
>>> >> So I'd like to know how to verify it on Devstack clouds.
>>> >
>>> > Yes, DevStack doesn't support many scenarios which are actual
>>> > and should be supported on the production clouds.
>>> > It will be not possible to run all advanced test scenarios for DevStack
>>> > clouds,
>>> > just because DevStack can't deploy OpenStack cloud with 3 controllers
>>> > now (so, probably it will be possible in the future).
>>> >
>>> > Of course, some advanced scenarios will support DevStack clouds,
>>> > for example, some test scenarios which are based on customer-found
>>> > issues from the real production clouds, like upload of the large images
>>> > (100+ Gb)
>>> > to Glance with Swift backend. Such cases are important for verification
>>> > of
>>> > pre-production environments, but not very important for CI gate jobs.
>>> >
>>> > It is also important to note that in these advanced cases we are
>>> > targeting
>>> > to check not only the logic of Python code, but also the correct
>>> > configuration
>>

Re: [openstack-dev] [QA] The end-user test suite for OpenStack clusters

[Ken';ichi Ohmichi]

Hi Timur,

Thanks for your explanation.

2016-09-29 6:22 GMT-07:00 Timur Nurlygayanov :
>
>> I am guessing the above "restart nodes" is for verifying each
>> OpenStack service restarts successfully, right?
>
> Yes, this is right. And we also will check that HA logic for these
> services works correctly (for example, rescheduling of L3 Neutron
> agents for networks).
>
>> But these service scripts are provided by distributors, and Devstack
>> itself doesn't contain service scripts IIUC.
>> So I'd like to know how to verify it on Devstack clouds.
>
> Yes, DevStack doesn't support many scenarios which are actual
> and should be supported on the production clouds.
> It will be not possible to run all advanced test scenarios for DevStack
> clouds,
> just because DevStack can't deploy OpenStack cloud with 3 controllers
> now (so, probably it will be possible in the future).
>
> Of course, some advanced scenarios will support DevStack clouds,
> for example, some test scenarios which are based on customer-found
> issues from the real production clouds, like upload of the large images
> (100+ Gb)
> to Glance with Swift backend. Such cases are important for verification of
> pre-production environments, but not very important for CI gate jobs.
>
> It is also important to note that in these advanced cases we are targeting
> to check not only the logic of Python code, but also the correct
> configuration
> of all OpenStack components on some pre-production OpenStack clusters.

I guessed some part of os-faults can be moved to Tempest if os-faults
contains API tests for enabling/disabling OpenStack services.
Then, os-faults would be able to concentrate on more destructive tests
like rebooting physical nodes, etc.
However, I could not find any actual scenarios on current os-faults
(https://github.com/openstack/os-faults).
That seems to just contain some abstraction layers and unit tests. Can
we see actual test scenarios of os-faults ?
Maybe I missed something.

Thanks
Ken Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA] The end-user test suite for OpenStack clusters

[Ken';ichi Ohmichi]

Hi Timur,

Thanks for picking this up, that is interesting for me.

2016-09-22 5:58 GMT-07:00 Timur Nurlygayanov :
>
> we have an idea to create the test suite with destructive/HA and advanced
> end-user scenarios for the OpenStack clusters. This test suite will contains
> advanced scenario integration tests for OpenStack clusters to make sure that
> the cluster is ready for the production.
>
> The test cases which we want to cover in this test suite:
> 1) All simple and advanced destructive actions, like a reboot of the nodes,
> restart OpenStack services and etc. (we can probably use of-faults library
> [1], which we already use in Rally)
> 2) All advanced test scenarios like a migration of the bunch of VMs between
> nodes and booting of the VMs with large images (10+ Gb), send traffic
> between VMs and in parallel restart Neutron l3 agents and etc.
>
> The key requirements:
> 1) The framework should know the details of the deployments (how many nodes
> we have, how to ssh to OpenStack nodes, how to restart the nodes and etc.).
> This is why we don't want to add such "advanced" and HA-focused test
> scenarios to Tempest.

Yeah, this point is right. This "advanced" way is different from the
design principle of Tempest[1].
I am guessing the above "restart nodes" is for verifying each
OpenStack service restarts successfully, right?
For productions(or distributions), this verifying point seems
important because service scripts need to restart OpenStack services
automatically.
But these service scripts are provided by distributors, and Devstack
itself doesn't contain service scripts IIUC.
So I'd like to know how to verify it on Devstack clouds.

Thanks
Ken Ohmichi
---

[1]: https://github.com/openstack/tempest#design-principles

> 2) We should be ready to run these tests for any clouds: DevStack clouds (we
> can skip HA cases for DevStack), Fuel clouds, clouds which were deployed by
> Ansible or Puppet tools.
> 3) This framework should allow reproduce the issue in a repeatable manner,
> this is why we can't just cover all the tests with Rally load tests +
> destructive plugins (we are working on this right now too to have an ability
> to test HA-related scenarios under the load).
>
> As we discussed on the OpenStack summit a year ago it is better to move such
> test suite in a separate repository and this framework can became a part of
> the QA (or at least BigTent) program in OpenStack.
>
> I've created the commit to OpenStack project-config repository:
> https://review.openstack.org/#/c/374667/
>
> Could you please take a look?
>
> We understand that it will be hard to add such test suite to the gates for
> every commit in OpenStack because we will need a lot of hardware. We don't
> want to add these tests to the per-commit gates for now, it is ok to run
> them just once a day, for example. And we definitely need to have such test
> suite to validate our own pre-production clouds.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA] Request for design session ideas of Barcelona Summit

[Ken';ichi Ohmichi]

Hi,

We have a Design Summit next month, and now we are trying to get ideas
for QA sessions.
There is an etherpad for ideas and it is good if writing your ideas on that:

https://etherpad.openstack.org/p/ocata-qa-summit-topics

After getting ideas, we will arrange them into available slots for QA sessions.
Thanks in advance and see you in Barcelona :-)

Thanks
Ken Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] tempest-cores update

[Ken';ichi Ohmichi]

Hi Hugh,


2016-09-25 22:50 GMT-07:00 Hugh Blemings :
> Hi Ohmichi-san,
>
> Firstly congratulations on becoming PTL for Quality Assurance!

Thanks

>> As previous mail, Marc has resigned from tempest-cores.
>> In addition, David also has done from tempest-cores to concentrate on new
>> work.
>> Thank you two for many contributions to the project and I wish your
>> continuous successes.
>
>
> I'm including a link for your email about tempest-cores in this week's
> Lwood.  Could you please tell David's surname so I can include that in the
> item ?

Oh, sorry about that.
He is David Kranz.

Thanks
Ken Ohmichi

---

> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] tempest tests in Horizon GUI

[Ken';ichi Ohmichi]

Hi Ofer,

The scenario test of Horizon has been removed from Tempest since
https://review.openstack.org/#/c/313713/
And now the test[1] exists in openstack/tempest-horizon.
The test is very simple like
 * checks that the login page is available
 * logs in as a regular user
 * checks that the user home page loads without error

> When I run a tempest test/scenario-test, should I see the components 
> (network, subnet, router etc.) in the horizon GUI ?

The test doesn't create any resources(network, subnet, etc), so any
changes would not happen during the test.

Thanks
Ken Ohmichi

---
[1]: 
https://github.com/openstack/tempest-horizon/blob/master/tempest_horizon/tests/scenario/test_dashboard_basic_ops.py

2016-09-21 15:01 GMT+02:00 Barber, Ofer :
> I have a basic question about tempest.
>
>
>
> When I run a tempest test/scenario-test, should I see the components
> (network, subnet, router etc.) in the horizon GUI ?
>
>
>
> If yes, for what username or what project those are created ?
>
>
>
> Thank you,
>
> Ofer
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [qa] tempest-cores update

[Ken';ichi Ohmichi]

Hi,

As previous mail, Marc has resigned from tempest-cores.
In addition, David also has done from tempest-cores to concentrate on new work.
Thank you two for many contributions to the project and I wish your
continuous successes.

Thanks
Ken Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] resigning from Tempest core

[Ken';ichi Ohmichi]

Hi Marc,

Thanks for hosting a QA/Infra code sprint.
All attendees have been satisfied with rooms, coffee, food and weather.

And thanks for your work on QA project in long term.
You have brought a lot of value to us.

Thanks
Ken Ohmichi



2016-09-19 11:51 GMT+02:00 Koderer, Marc :
> Hi folks,
>
> as already mentioned during the current code sprint:
> I am currently lacking time for reviews and code contributions.
>
> I think it better to step back and let other’s in that are more active.
>
> Thanks for all the support and it was really fun the past 3 years working with
> you!
>
> Regards
> Marc
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cue][qa] Status of OpenStack CI jobs

[Ken';ichi Ohmichi]

Hi Graham,

Thanks for your response :-)
Yeah, you are right.
That seems the same as a designate bug report:
https://bugs.launchpad.net/designate/+bug/1603036
Hope this helps the gate jobs.

Thanks
Ken Ohmichi

---


2016-09-15 6:21 GMT-07:00 Hayes, Graham :
> On 15/09/2016 00:12, Ken'ichi Ohmichi wrote:
>> Hi Cue-team,
>>
>> As http://status.openstack.org/openstack-health/#/ , the cue gate jobs
>> continues failing 100%.
>> What is current status of the development?
>> Hopefully the  job will become stable for smooth development.
>>
>> Thanks
>> Ken Ohmichi
>
> I am not sure what the status of development is, but it looks like they
> hit the same issue some of us did with olso.context 2.6.0 (when the
> output of to_dict() changed).
>
>
>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [qa] Cancelled: IRC meeting 0900UTC Sep. 22 2016

[Ken';ichi Ohmichi]

Hi,

We have QA/Infra mid-cycle meetup next week, then it is hard to attend
the next meeting for most people.
So let's cancel the next week meeting.
The next irc meeting of QA will be Sep. 29th 2016 (1700 UTC).

Thanks
Ken Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cue][qa] Status of OpenStack CI jobs

[Ken';ichi Ohmichi]

Hi Cue-team,

As http://status.openstack.org/openstack-health/#/ , the cue gate jobs
continues failing 100%.
What is current status of the development?
Hopefully the  job will become stable for smooth development.

Thanks
Ken Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder]tempest test case for force detach volume

[Ken';ichi Ohmichi]

Hi Chaoyi,

That is a nice point.
Now Tempest have tests for some volume v2 action APIs which doesn't
contain os-force_detach.
The available APIs of tempest are two: os-set_image_metadata and
os-unset_image_metadata like
https://github.com/openstack/tempest/blob/master/tempest/services/volume/v2/json/volumes_client.py#L27
That is less than I expected by comparing the API reference.

The corresponding API tests' patches are welcome if interested in :-)

Thanks
Ken Ohmichi

---


2016-09-13 17:58 GMT-07:00 joehuang :
> Hello,
>
> Is there ant tempest test case for "os-force_detach" action to force detach
> a volume? I didn't find such a test case both in the repository
> https://github.com/openstack/cinder/tree/master/cinder/tests/tempest
> and https://github.com/openstack/tempest
>
> The API link is:
> http://developer.openstack.org/api-ref-blockstorage-v2.html#forcedetachVolume
>
> Best Regards
> Chaoyi Huang(joehuang)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Infra] bugdaystats for different time ranges

[Ken';ichi Ohmichi]

Hi Infra-team,

(We told this a little bit on IRC, but it is happy to get more feedback widely)

Recently, we are triaging bugs of Tempest on the launchpad and that
work was fine to clean up old bugs and fixed bugs with different
patches.
There is bugdaystats[1] for showing a progress on bag days, that is
good for motivate us.
Current bugdaystats shows it in last several days statically, can we
add/implement more time ranges like daily in 30 days, or in releases?
The bugs are reported randomly and bugs triage also happens every day,
so I guess different time range would be good to know bug situation in
a development cycle.

Thanks
Ken Ohmichi

---
[1]: http://status.openstack.org/bugday/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Possible REST API design change for get-me-a-network (2.37)

[Ken';ichi Ohmichi]

2016-08-11 14:53 GMT-07:00 Matt Riedemann :
> I wanted to bring this up for awareness since we're getting close to feature
> freeze and want consensus before it gets too late.
>
> Ken'ichi brought up a good question on my REST API change for the 2.37
> microversion:
>
> https://review.openstack.org/#/c/316398/
>
> The way I had written this was to just add special auto/none values for the
> networks 'uuid' field in the server create request schema.
>
> The catch with using auto/none is that they can't be specified with any
> other values, like other networks, or a port, or really anything else. It's
> just a list with a single entry and that's either uuid=auto or uuid=none.
>
> Ken'ichi's point was, why not just make "networks" in this case map to
> 'auto' or 'none' or the list that exists today.
>
> I like the idea, it's cleaner and it probably allows moving some of the
> validation from the REST API code into the json schema (I think, not totally
> sure about that yet).

Yeah, that also is a nice point.
Current json-schema [1] shows "uuid" parameter accepts not only
uuid-format string but also 'auto' and 'none'.
That seems fair from the naming.

> It is a change for how networks are requested today so there would be some
> conditional logic change pushed on the client - my tempest test change and
> novaclient changes would have to be updated for sure.

You have already work so much for this feature and client
implementation including Tempest.
Sorry for pointing this out lately, but after implementing, it is more
harder to change.
It is nice to avoid more microversions if we can.

Thanks
Ken Omichi

---
[1]: 
https://review.openstack.org/#/c/316398/35/nova/api/openstack/compute/schemas/servers.py


> So I'm looking for input on that idea before we get too late, is that
> difference worth the work and syntax change in how the client requests a
> network when creating a server?
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Does this api modification need Microversion?

[Ken';ichi Ohmichi]

2016-08-03 9:53 GMT-07:00 Andrew Laski :

> I think the discussion about whether or not this needs a microversion is
> missing the bigger question of whether or not this should be in the API to
> begin with. If it's safe to rollback from this error state why not just do
> that automatically in Nova? If it's proposed for the API because it's not
> considered safe I don't agree it should be in the API. This is not an API
> that's restricted to admins by default.
>
> However if this is going to be exposed in the API I lean towards this not
> needing a microversion. It's a new policy in the usage of the API, not a
> change to the API. To me it seems like adding a microversion because a
> policy rule was changed. I know we should have some sort of signal here for
> users, but I think we need to look at different ways to signal this type of
> change.
>

Yeah, I feel a new microversion in this case seems a little overkill.
This is a negative case and rollback could be operated in all versions.
We have implemented rollback thing in years, and I guess we don't have any
negative feedback related to rollback from users.

Thanks
Ken Omichi

---


>
> -Andrew
>
>
> On Tue, Aug 2, 2016, at 02:11 AM, han.ro...@zte.com.cn wrote:
>
> patchset url: https://review.openstack.org/#/c/334747/
>
>
>
>
> Allow "revert_resize" to recover error instance after resize/migrate.
>
> When resize/migrate instance, if error occurs on source compute node,
> instance state can rollback to active currently. But if error occurs in
> "finish_resize" function on destination compute node, the instance state
> would not rollback to active.
>
> This patch is to rollback instance state from error to active when resize
> or migrate action failed on destination compute node..
>
>
>
>
> Best,
> Rong Han
>
> *__*
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] os-virtual-interfaces isn't deprecated in 2.36

[Ken';ichi Ohmichi]

2016-07-29 10:32 GMT-07:00 Sean Dague :
> On 07/28/2016 05:38 PM, Matt Riedemann wrote:
>> On 7/28/2016 3:55 PM, Matt Riedemann wrote:
>>> For os-attach-interfaces, we need that to attach/detach interfaces to a
>>> server, so those actions don't go away with 2.36. We can also list and
>>> show interfaces (ports) which is a proxy to neutron, but in this case it
>>> seems a tad bit necessary, else to list ports for a given server you
>>> have to know to list ports via neutron CLI and filter on
>>> device_id=server.uuid.
>>
>> On second thought, we could drop the proxy APIs to list/show ports for a
>> given server. python-openstackclient could have a convenience CLI for
>> listing ports for a server. And the show in os-attach-interfaces takes a
>> server id but it's not used, so it's basically pointless and should just
>> be replaced with neutron.
>>
>> The question is, as these are proxies and the 2.36 microversion was for
>> proxy API deprecation, can we still do those in 2.36 even though it's
>> already merged? Or do they need to be 2.37? That seems like the more
>> accurate thing to do, but then we really have some weird "which is the
>> REAL proxy API microversion?" logic going on.
>>
>> I think we could move forward with deprecation in novaclient either way.
>
> We should definitely move forward with novaclient CLI deprecations.
>
> We've said that microversions are idempotent, so fixing one in this case
> isn't really what we want to do, it should just be another bump, with
> things we apparently missed. I'm not sure it's super important that
> there is a REAL proxy API microversion. We got most of it in one go, and
> as long as we catch the stragglers in 2.39 (let's make that the last
> merged one before the release so that we can figure out anything else we
> missed, and keep get me a network as 2.37).

Yeah, I agree with another bump.
We miss something like this and microversion mechanism can provide us
with another chance.

Thanks
Ken Omichi

---


> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA] Cancel QA meeting today

[Ken';ichi Ohmichi]

Hi

Sorry for notifying this too lately.
We don't have enough attendees of QA meeting today and it is difficult
to run that.
So we cancel this week QA meeting.

Thanks
Ken Omichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][qa] When do we need tests for microversions in Tempest?

[Ken';ichi Ohmichi]

Hi Matt,


2016-07-14 11:55 GMT+09:00 Matt Riedemann :
> There are several changes in Tempest right now trying to add response schema
> validation for the 2.26 microversion which added server tags to the server
> GET response. This is needed for anything testing a microversion >=2.26,
> which several people are trying to add.
>
> We have a similar issue with the 2.3 microversion which is really a bug, but
> only exposed in jobs that have run_validation=True which is only in a
> non-voting job right now.
>
> I've mostly been debating this in this change:
>
> https://review.openstack.org/#/c/233176/
>
> I've added an item to the nova midcycle meetup agenda to talk about the plan
> for handling microversion testing in tempest for nova changes, specifically
> around API response validation.
>
> I agree that nova doesn't test response schema validation in tree, so doing
> it in tempest is good.
>
> But I'm not sure that we need a new set of tempest tests for every
> microversion change in nova, e.g. if it's only touching the API and
> database, like server tags, we can test that in nova.

I think it is nice to implement every microversion tests in Tempest
for preparing the base/minimum microversion bump in the future.
On API microversions mechanism, we have defined the minimum
microversion(now version 2.1) can be increased.
Every microversion test will provide an option when we want to bump it
to verify a new minimum microversion is stable by Tempest as an
integrated test.

> It's also not great having several changes in flight at the same time to
> tempest trying to add the same 2.26 response schema because it wasn't added
> the at the same time the 2.26 API merged.
>
> I also wonder what it means if someone configures max_microversion in
> tempest.conf to something we don't test, like say 2.11, what blows up? For
> example, we know that we don't have response validation for 2.3 so some
> tests are broken when you run with ssh validation and microversion>=2.3.

Ideally, the response schema also should be implemented on Tempest.
but it is difficult to catch up because the microversion bumping is
fast on Nova side.
The max_microversion option is useful to operate the same Tempest to
master/stable branches which are different microversions.

Thanks
Ken Ohmichi

---

> So I'm thinking we should:
>
> 1. Always add a schema change to Tempest if a microversion changes a
> response.
>
> 2. Only add tests to Tempest for a microversion change if it can't be tested
> within nova, e.g. you actually need to create a server, or use other
> services like glance/cinder/neutron.
>
> mtreinish and sdague will be at the nova midcycle so hopefully they can
> represent for the QA team.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

[Ken';ichi Ohmichi]

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 DefCore Guideline typically covers three OpenStack
>> releases".
>> That means the latest guideline needs to cover Mitaka, Liberty and Kilo,
>> right?
>>
>> In the Kilo development, we(nova team) have already considered
>> additional properties are not good for the interoperability.
>> And the stable_api.rst of [2] which is contained in Kilo says we need
>> to implement new features without extensions.
>> However, there are Kilo+ clouds which are extended with vendors' own
>> extensions, right?
>>
>> My concern of allowing additional properties on interoperability tests is
>> that
>>  - users can move from pure OpenStack clouds to non-pure OpenStack
>> clouds which implement vender specific properties
>>  - but users cannot move from non-pure OpenStack clouds if users
>> depend on the properties
>> even if these clouds are certificated on the same interoperability tests.
>>
>
> The end goal is 100% to get everyone consistent with no "extra" data being
> passed out of the APIs and certified on the same tests.

Yeah, I am appreciated that everyone agree with the non-extra data as
the final goal.

> However, right now we have an issue where vendors/operators are lagging on
> getting this cleaned up. Since this is the first round of certifications
> (among other things), the proposal is to support/manage this in a way that
> gives a bit more of a grace period while the deployers/operators finish
> moving away from custom properties (as i understand it the ones affected
> have communicated that they are working on meeting this goal; Chris, please
> correct me if I am wrong).
>
> Your concerns are spot on, and at the end of this "greylist" window ( at the
> " 2017.01" defcore guideline ), this grace period will expire and everyone
> will be expected to be compatible without the "Extra" data. Part of the
> process of doing these programs is working to refine the process (and
> sometimes make exceptions in the early stages) until the workflow is
> established and understood. It is not expected to continue nor extend the
> period beyond the firm end point Chris highlighted. I would not support this
> proposal if it was open ended.

The greylist seems a good idea, and I am not so strongly against the idea.
However, I have still some questions about this direction.

I am thinking most important API of Nova is "create a server" API for
the interoperability, because most users want to use servers on
OpenStack clouds.
However, I am guessing most venders which cannot be passed through
current strict Tempest are customizing this API.
So if this API on the greylist on most venders' tests, the
interoperability seems a little meaningless.
Is that expected now?

One more question is that how many venders cannot pass through current Tempest?
100%? or 20%?
If 5% venders cannot pass, I guess we can say "the certification is
failed" to the venders.
I'd like to know current situation for expecting our future so that we
will need to mark this "greylist" as deprecated soon and need to know
how progress at some steps/cycles of venders.

Thanks
Ken Omichi

---
>> ---
>> [1]:
>> http://lists.openstack.org/pipermail/defcore-committee/2015-June/000849.html
>> [2]: https://review.openstack.org/#/c/162912
>>
>> 2016-06-14 16:37 GMT-07:00 Chris Hoge :
>> > Top posting one note and direct comments inline, I’m proposing
>> > this as a member of the DefCore working group, but this
>> > proposal itself has not been accepted as the forward course of
>> > action by the working group. These are my own views as the
>> > administrator of the program and not that of the working group
>> > itself, which may independently reject the idea outside of the
>> > response from the upstream devs.
>> >
>> > I posted a link to this thread to the DefCore mailing list to make
>> > that working group aware of the outstanding issues.
>> >
>> > On Jun 14, 2016, at 3:50 PM, Matthew Treinish 
>> > wrote:
>> >
>> > On Tue, Jun 14, 2016 at 05:42:16PM -0400, Doug Hellmann wrote:
>> >
>> > Excerpts from Matthew Treinish's message of 2016-06-14 15:12:45 -0400:
>> >
>> > On Tue, Jun 14, 2016 at 02:41:10PM -0400, Doug Hellmann wrote:
>> >
>> > Excerpts from Matthew Treinish's message of 2016-06-14 14

Re: [openstack-dev] [qa] Tempest pre-provisioned credentials in the gate

[Ken';ichi Ohmichi]

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 credentials and pre-provisioned ones.
>
> The current check and gate jobs only use the dynamic credentials provider.
>
> The pre-provisioned credentials provider has been introduced to support
> running test in parallel without the need of having access to admin
> credentials in tempest configuration file - which is a valid use case
> especially when testing public clouds or in general a deployment that is not
> own by who runs the test.
>
> As a small extra, since pre-provisioned credentials are re-used to run many
> tests during a CI test run, they give an opportunity to discover issues
> related to cleanup of test resources.

This is a significant merit for Tempest development.
So +1 for enabling the credential on the gate.

> Pre-provisioned credentials is currently used in periodic jobs [1][2] - as
> well as an experimental job defined for tempest changes. This means that
> even if we are careful, there is a good chance for it to be inadvertently
> broken by a change.
>
> Until recently the periodic job suffered a racy failure on object-storage
> tests. A recent refactor [3] of the tool that pre-proprovisioned the
> accounts has fixed the issue: the past 8 runs of the periodic jobs have not
> encountered that race anymore [4][5].
>
> Specifically I'd like to propose changing to start changing of the neutron
> jobs [6].

I am not sure why don't we add another simple job(non neutron job)
which just enables this.
But maybe it is better to discuss which job is nice for enabling
pre-provisioned cred on the review.

Thanks
Ken Ohmichi

---

> [0]
> http://docs.openstack.org/developer/tempest/configuration.html#credential-provider-mechanisms
> [1]
> http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/devstack-gate.yaml#n220
> [2]
> http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/devstack-gate.yaml#n253
> [3] https://review.openstack.org/#/c/317105/
> [4]
> http://status.openstack.org/openstack-health/#/job/periodic-tempest-dsvm-full-test-accounts-master
> [5]
> http://status.openstack.org/openstack-health/#/job/periodic-tempest-dsvm-neutron-full-test-accounts-master
> [6] https://review.openstack.org/329723
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA][Infra] Newton Code Sprint

[Ken';ichi Ohmichi]

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 Infra team.

Many people say the first code sprint which was held in Germany was
great and want to do it again.
So the next sprint will take place in Germany on 19th - 21th
September, SAP has offered to sponsor the event and it'll be held at
SAP HQ, Walldorf, Germany.
Thank you so much to host this event, SAP and Marc Koderer who
arranges this event.

More details can be found on the following wiki page, and if you're planning on
attending please sign up using the wiki page:

https://wiki.openstack.org/wiki/Sprints/QAInfraNewtonSprint

Thanks
Ken Omichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

[Ken';ichi Ohmichi]

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, we(nova team) have already considered
additional properties are not good for the interoperability.
And the stable_api.rst of [2] which is contained in Kilo says we need
to implement new features without extensions.
However, there are Kilo+ clouds which are extended with vendors' own
extensions, right?

My concern of allowing additional properties on interoperability tests is that
 - users can move from pure OpenStack clouds to non-pure OpenStack
clouds which implement vender specific properties
 - but users cannot move from non-pure OpenStack clouds if users
depend on the properties
even if these clouds are certificated on the same interoperability tests.

Thanks
Ken Ohmichi

---
[1]: 
http://lists.openstack.org/pipermail/defcore-committee/2015-June/000849.html
[2]: https://review.openstack.org/#/c/162912

2016-06-14 16:37 GMT-07:00 Chris Hoge :
> Top posting one note and direct comments inline, I’m proposing
> this as a member of the DefCore working group, but this
> proposal itself has not been accepted as the forward course of
> action by the working group. These are my own views as the
> administrator of the program and not that of the working group
> itself, which may independently reject the idea outside of the
> response from the upstream devs.
>
> I posted a link to this thread to the DefCore mailing list to make
> that working group aware of the outstanding issues.
>
> On Jun 14, 2016, at 3:50 PM, Matthew Treinish  wrote:
>
> On Tue, Jun 14, 2016 at 05:42:16PM -0400, Doug Hellmann wrote:
>
> Excerpts from Matthew Treinish's message of 2016-06-14 15:12:45 -0400:
>
> On Tue, Jun 14, 2016 at 02:41:10PM -0400, Doug Hellmann wrote:
>
> Excerpts from Matthew Treinish's message of 2016-06-14 14:21:27 -0400:
>
> On Tue, Jun 14, 2016 at 10:57:05AM -0700, Chris Hoge wrote:
>
> Last year, in response to Nova micro-versioning and extension updates[1],
> the QA team added strict API schema checking to Tempest to ensure that
> no additional properties were added to Nova API responses[2][3]. In the
> last year, at least three vendors participating the the OpenStack Powered
> Trademark program have been impacted by this change, two of which
> reported this to the DefCore Working Group mailing list earlier this
> year[4].
>
> The DefCore Working Group determines guidelines for the OpenStack Powered
> program, which includes capabilities with associated functional tests
> from Tempest that must be passed, and designated sections with associated
> upstream code [5][6]. In determining these guidelines, the working group
> attempts to balance the future direction of development with lagging
> indicators of deployments and user adoption.
>
> After a tremendous amount of consideration, I believe that the DefCore
> Working Group needs to implement a temporary waiver for the strict API
> checking requirements that were introduced last year, to give downstream
> deployers more time to catch up with the strict micro-versioning
> requirements determined by the Nova/Compute team and enforced by the
> Tempest/QA team.
>
>
> I'm very much opposed to this being done. If we're actually concerned with
> interoperability and verify that things behave in the same manner between
> multiple
> clouds then doing this would be a big step backwards. The fundamental
> disconnect
> here is that the vendors who have implemented out of band extensions or were
> taking advantage of previously available places to inject extra attributes
> believe that doing so means they're interoperable, which is quite far from
> reality. **The API is not a place for vendor differentiation.**
>
>
> This is a temporary measure to address the fact that a large number
> of existing tests changed their behavior, rather than having new
> tests added to enforce this new requirement. The result is deployments
> that previously passed these tests may no longer pass, and in fact
> we have several cases where that's true with deployers who are
> trying to maintain their own standard of backwards-compatibility
> for their end users.
>
>
> That's not what happened though. The API hasn't changed and the tests
> haven't
> really changed either. We made our enforcement on Nova's APIs a bit stricter
> to
> ensure nothing unexpected appeared. For the most these tests work on any
> version
> of OpenStack. (we only test it in the gate on supported stable releases, but
> I
> don't expect things to have drastically shifted on older releases) It also
> doesn't matter which version of the API you run, v2.0 or v2.1. Literally,
> the
> only case it ever fails is when you run something extra, not from the
> community,
> either as an extension (which themselves are going away [1]) or another
> 

Re: [openstack-dev] [qa] Tempest unstable interfaces in plugins

[Ken';ichi Ohmichi]

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 work inevitably involves changing the current client manager (unstable)
>> interface.
>> Several tempest plugins in OpenStack already consume that interface (namely
>> the manager.Manager class) [1], so my work is likely to break them.
>>
>> I would ask the people maintaining the plugins to be careful about using
>> unstable interfaces, as they are likely to change, especially since we're
>> working on converting them to stable.
>>
>> If you maintain a plugin (in OpenStack or outside of OpenStack) that is
>> likely to be affected by my work, please keep an eye on my gerrit review
>> [0], leave a comment there or ping me on IRC (andreaf), I would very much
>> like to make sure the transition is as painless as possible for everyone.
>
> FWIW this doesn't seem to break Neutron:
> https://review.openstack.org/#/c/328398/.
>
> I would appreciate it if changes are made in a backwards compatible
> manner (Similar to this:
> https://review.openstack.org/#/c/322492/13/tempest/common/waiters.py)
> so that projects with Tempest plugins may adapt and not break voting
> jobs. The reason projects are using interfaces outside of tempest.lib
> is that that's all there is, and the alternative of copy/pasting in to
> the repo isn't amazing.

Yeah, copy/pasting of tempest code which is outside of tempest.lib is
not amazing.
However, that is a possible option to continue gate testing on each project.
We did that to pass Ceilometer gate as a workaround[1], then
we(QA-team) knew what lib code is necessary and are concentrating on
making the code as tempest.lib.
After finishing, we can remove the copy/pasting code from Ceilometer
by using new tempest.lib code.

During this work, I feel it is nice to add a new hacking rule to block
importing the local tempest code from other projects.
>From viewpoints of outside of QA team, it would be difficult to know
the stability of tempest code I guess.
Then by adding a rule, most projects know that and it is nice to
ignore it by understanding the stability.

The hacking rule patch is https://review.openstack.org/#/c/328651/
And tempest itself needs to ignore that if merging the rule ;-) [2]

Thanks
Ken Ohmichi
---
[1]: https://review.openstack.org/#/c/325727/
[2]: https://review.openstack.org/#/c/328652/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] [Tempest] Abondoned old code reviews

[Ken';ichi Ohmichi]

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 Ohmichi, 
>> wrote:
>>>
>>> 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
> I think 5 months is enough to abandon :)
>
> Best Regards,
> -- Masayuki
>
>
>>
>>
>> I don't mind either way, if you prefer abandoning them it's ok with me.
>> I rely on gerrit dashboards and IRC communication to decide which patches I
>> should review; but I understand it would be nice to remove some clutter.
>>
>> Andrea
>>
>>>
>>> [1]:
>>> http://lists.openstack.org/pipermail/openstack-dev/2016-May/096112.html
>>>
>>> Thanks
>>> Ken Ohmichi
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [qa] [Tempest] Abondoned old code reviews

[Ken';ichi Ohmichi]

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]: http://lists.openstack.org/pipermail/openstack-dev/2016-May/096112.html

Thanks
Ken Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] API changes on limit / marker / sort in Newton

[Ken';ichi Ohmichi]

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/8d16fc11ee6d01b5a9fe1b8b7ab7fa6dff460e2a/specs/newton/approved/keypairs-pagination.rst#L2
>> * os-instances-actions - https://review.openstack.org/#/c/240401/
>> * hypervisors - https://review.openstack.org/#/c/240401/
>> * os-migrations - https://review.openstack.org/#/c/239869/
>>
>> I think that limit / marker is always a legit thing to add, and I almost
>> wish we just had a single spec which is "add limit / marker to the
>> following APIs in Newton"
>>
>
> Are you looking for code sharing or one microversion? For code sharing, it
> sounds ok if people have some co-work. Probably we need a common pagination
> supported model_query function for all of those. For one microversion, i'm a
> little hesitate, we should keep one small change, or enable all in one
> microversion. But if we have some base code for pagination support, we
> probably can make the pagination as default thing support for all list
> method?

It is nice to share some common code for this, that would be nice for
writing the api doc also to know what APIs support them.
And also nice to do it with a single microversion for the above
resources, because we can avoid microversion bumping conflict and all
of them don't seem a big change.

Thanks

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA][RFC] Skip this week meeting

[Ken';ichi Ohmichi]

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 topics on that if anyone have.

Thanks
Ken Ohmichi

---

2016-05-02 7:03 GMT-07:00 Masayuki Igawa :
> Hi QA guys,
>
> We have very few topic this week to discuss. So I think we should skip
> this week meeting.
> Any thoughts?
>
> Best Regards,
> -- Masayuki Igawa
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][qa] devstack plugin

[Ken';ichi Ohmichi]

Hi dixiaoli

Thanks for raising your hand for this work.
I put your name on https://etherpad.openstack.org/p/newton-qa-newton-priorities

Thanks
---

2016-05-05 2:13 GMT-07:00 dixiaoli <13051592...@163.com>:
> Hi,  Ken Omichi
>
> Thanks for point out this.
> I would like to help 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 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-devstack-plugin
>>The way is like:
>>1. (heat) Add devstack plugin by copying the code from devstack
>>2. (project-config) Switch to use devstack plugin
>>3. (devstack) Remove lib/heat, ...
>>
>>The related doc is
>> http://docs.openstack.org/developer/devstack/plugins.html
>>I am happy to get helps to move forward.
>>
>>Thanks
>>Ken Omichi
>>
>>__
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat][qa] devstack plugin

[Ken';ichi Ohmichi]

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-devstack-plugin
The way is like:
1. (heat) Add devstack plugin by copying the code from devstack
2. (project-config) Switch to use devstack plugin
3. (devstack) Remove lib/heat, ...

The related doc is http://docs.openstack.org/developer/devstack/plugins.html
I am happy to get helps to move forward.

Thanks
Ken Omichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [qa] Summary of design summit for Newton

[Ken';ichi Ohmichi]

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/p/newton-qa-cruft-busters
  Main assignee / organizer: andreaf
  Action items:
  * Test resources as fixtures (jswarren, mtreinish, dwalleck)
  * Remote client debuggability (andreaf)
  * Test class hierarchy (dmellado)
  * Neutron OO wrappers (jlwhite, hockeynut)
  * Documentation review and cleanup (andreaf)
  * Test audit (Revital)
  * Cleanup client and manager aliases
  * Refactor test base class setup and teardown steps

2. Devstack
  https://etherpad.openstack.org/p/newton-qa-devstack-roadmap
  Action items:
  * Neutron cleanup (sc68cal)
  * Add tempest config hook to devstack plugin interface (call it
test-config) (mtreinish)
  * Talk to remove heat from devstack (oomichi)

3. openstack-health
  https://etherpad.openstack.org/p/newton-qa-openstack-health
  Main assignee / organizer: mtreinish, masayukig
  Action items:
  * Elastic recheck integration
  * Figure out check data solution
  * Add a bug link to the page (- low-hanging-fruit)

4. Tempest: Remaining CLI work
  https://etherpad.openstack.org/p/newton-qa-tempest-cli
  Main assignee / organizer: mtreinish
  Action items:
  * Run (dpaterson, dmellado)
- spec
- impl

5. Tempest: Negative Test
  https://etherpad.openstack.org/p/newton-qa-negative-testing
  Main assignee / organizer: oomichi
  Action items:
  * Doc update: Remove negative tests framework from Doc (luzC)
  * Write guideline of negative tests (hogepodge, dwalleck, and oomichi)
  * Will consider removing/keeping negative test framework after the guideline
refstack doesn't use the framework.

6.Tempest: tempest-lib/plugin
  https://etherpad.openstack.org/p/newton-qa-tempest-lib-and-tempest-plugin
  Main assignee / organizer: gmann
  Action items:
  * Remove client manager use from credential providers and move to
lib (andreaf)
  * Need to push reno on pip site: Talk with doughellmann
  * Extending plugin for CLI Tools(cleanup) - spec - (gmann)
  * Migrate pending interfaces to /lib
create new etherpad and ML for volunteers (gmann)

7. Tempest: Client Manager Refactor
  Main assignee / organizer: andreaf
  https://review.openstack.org/#/c/92804/

8. Tempest: Test resource management
  Main assignee / organizer: oomichi, jswarren?
  https://review.openstack.org/#/c/173334/

9. Tempest: Microversion tests
  Main assignee / organizer: gmann
  Action items:
  * compute microversion tests - gmann (Low priority)

NOTE: Helpful ways to join into QA-team for new volunteers
  * Join into #openstack-qa
  * Triage bugs on LP

If having questions, please send mails to me or "Main assignee / organizer".
Thanks for your help.

Ken Omichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA] Meeting Thursday April 14th at 17:00 UTC

[Ken';ichi Ohmichi]

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 welcome to add items to the agenda.

To help people figure out what time 17:00 UTC is in other timezones the
next meeting will be at:

12:00 EST
02:00 JST
02:30 ACST
07:00 CEST
12:00 CDT
10:00 PDT

Thanks
Ken Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Proposing Andrey Kurilin for python-novaclient core

[Ken';ichi Ohmichi]

+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 major issue, does a lot of the
> microversion work, and is also working on cleaning up docs and helping me
> with planning releases.
>
> His work is here [1].
>
> Review stats for the last 4 months (although he's been involved in the
> project longer than that) [2].
>
> Unless there is disagreement I plan to make Andrey core by the end of the
> week.
>
> [1]
> https://review.openstack.org/#/q/owner:akurilin%2540mirantis.com+project:openstack/python-novaclient
> [2] http://stackalytics.com/report/contribution/python-novaclient/120
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

[Ken';ichi Ohmichi]

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 a simple +1 counter, such as +1'ing changes
>> that already have at least 1x +2, or which already approved, or which need
>> rechecking...

Can we merge this kind of patches without reviews?
When seeing this kind of patches, I check all jobs are succeeded. Sometimes 
some job failed, I check the reason and +2 if that is unrelated.

This workflow seems possible to be implemented automatically.
Or bad idea?

Thanks








>> 
>> 
>>> 
>>> 
>>> It's pretty clear what's happening if you look here:
>>> 
>>> https://review.openstack.org/#/q/owner:openstack-infra%2540lists.openstack.org+status:open
>>> 
>>> Here's the drastic step (i'd like to avoid):
>>> https://review.openstack.org/#/c/303545/
>>> 
>>> What do you think?
>> 
>> One more possible (though also imperfect) mitigation is to make exception
>> from the usual 2x +2 rule for requirements updates passing gates and use
>> only 1x +2. Then requirements reviews will take substantially less time to
>> land, reducing need/possibility of having such +1's.
> 
> Proposal bot patches merge in many cases with 1 +2 already.
> 
> Have you looked at the timing of the bot patches generated and the first
> +1's? If not, take a look at that.
> 
> I don't think we should be expecting core reviewers to schedule
> approving bot proposals to prevent extraneous +1s.
> 
> Thanks,
> Anita.
> 
>> 
>>> 
>>> Thanks,
>>> Dims
>>> 
>>> --
>>> Davanum Srinivas :: https://twitter.com/dims
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> 
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][api] Recently accepted API-WG guidelines

[Ken';ichi Ohmichi]

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.openstack.org/243414
>> 
>> 3. versioning guideline for API microversions
>> https://review.openstack.org/243041
> 
> As you can see several of these address microversions. To help make
> processing microversion headers consistent and reliable, with the
> help of sdague and elmiko I've created a library that does one thing
> and one thing only: It looks in request headers and extracts a
> microversion for a given service type from the default (modern)
> header or from a provided (legacy) header.
> 
>https://github.com/openstack/microversion-parse
>https://pypi.python.org/pypi/microversion_parse
> 
> I've started a WIP for integrating it into Nova, just to see how it
> might work and demonstrate how it could be used:
> 
>https://review.openstack.org/#/c/300076/
>https://review.openstack.org/#/c/300077/
> 
> If you look you'll see the library does very little. This is a)
> intentional, b) good. Let's have more of that.
> 
> -- 
> Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
> freenode: cdent tw: @anticdent
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] API priorities in Newton

[Ken';ichi Ohmichi]

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 working for this now. That is pretty good work.
Current coverage is just v2.2 only on Tempest side.
Nova v2.10 test patch is being reviewed now:
https://review.openstack.org/#/c/277763/

The difference between Tempest tests and novaclient tests is blocking
additional properties.
Tempest implements *response* body validation with JSON-Schema like
nova side, and additionalProperties is false for blocking unexpected
additional properties.
As microversion rule of nova, we need to add properties in a response
body with bumping a microversion.
So as the test, Tempest needs to block unexpected properties on the
existing microversions tests.

Thanks

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] API priorities in Newton

[Ken';ichi Ohmichi]

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 would slice our bread and julien
> our fries, and solve all this. But it's a big thing to get right, and
> JSON Home has an unclear future. And, we could server our users pretty
> well with a much simpler take on capabilities. For instance
>
>  GET /servers/{id}/capabilities
>
> {
> "capabilities" : {
> "resize": True,
> "live-resize": True,
> "live-migrate": False
> ...
>  }
> }

Yeah, JSOM-Home is not an option for this kind of capabilities discovery.
Swagger is that instead. Clients can know available capabilities by
getting swagger definition via REST API.

Ex:

GET /swaggers
{
...
"/action": {
   "parameters": [
   {"name": "resize", "in": "body", ...},
   {"name": "os-start", "in": "body", ...},
   {"name": "os-stop", "in": "body", ...},
   ...
   }
}
}

Thanks

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA] Request for design session ideas of Austin Summit

[Ken';ichi Ohmichi]

Hi

We have a Design Summit next month, and now we are trying to get ideas
for QA sessions.
There is an etherpad for ideas and it is great if writing your ideas
on the etherpad:

https://etherpad.openstack.org/p/newton-qa-summit-topics

After getting ideas, we will arrange them into available slots for QA sessions.

Thanks in advance and see you in Austin :-)
Ken Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA][all] Propose to remove negative tests from Tempest

[Ken';ichi Ohmichi]

2016-03-16 20:27 GMT-07:00 Assaf Muller :
> On Wed, Mar 16, 2016 at 10:41 PM, Jim Rollenhagen
>  wrote:
>> On Wed, Mar 16, 2016 at 06:20:11PM -0700, Ken'ichi Ohmichi wrote:
>>> Hi
>>>
>>> I have one proposal[1] related to negative tests in Tempest, and
>>> hoping opinions before doing that.
>>>
>>> Now Tempest contains negative tests and sometimes patches are being
>>> posted for adding more negative tests, but I'd like to propose
>>> removing them from Tempest instead.
>>>
>>> Negative tests verify surfaces of REST APIs for each component without
>>> any integrations between components. That doesn't seem integration
>>> tests which are scope of Tempest.
>>> In addition, we need to spend the test operating time on different
>>> component's gate if adding negative tests into Tempest. For example,
>>> we are operating negative tests of Keystone and more
>>> components on the gate of Nova. That is meaningless, so we need to
>>> avoid more negative tests into Tempest now.
>>>
>>> If wanting to add negative tests, it is a nice option to implement
>>> these tests on each component repo with Tempest plugin interface. We
>>> can avoid operating negative tests on different component gates and
>>> each component team can decide what negative tests are valuable on the
>>> gate.
>>>
>>> In long term, all negative tests will be migrated into each component
>>> repo with Tempest plugin interface. We will be able to operate
>>> valuable negative tests only on each gate.
>>
>> So, positive tests in tempest, negative tests as a plugin.
>>
>> Is there any longer term goal to have all tests for all projects in a
>> plugin for that project? Seems odd to separate them.
>
> I'd love to see this idea explored further. What happens if Tempest
> ends up without tests, as a library for shared code as well as a
> centralized place to run tests from via plugins?

Now Tempest contains library code and the other projects can use them
as library.
We are trying to increase the library code for more usability.
The qa-spac https://review.openstack.org/#/c/275966/ is nice to be understood.

Thanks
Ken Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA][all] Propose to remove negative tests from Tempest

[Ken';ichi Ohmichi]

2016-03-17 5:32 GMT-07:00 Adam Young :
> On 03/16/2016 11:01 PM, Ken'ichi Ohmichi wrote:
>>
>> 2016-03-16 19:29 GMT-07:00 Adam Young :
>>>
>>> On 03/16/2016 09:20 PM, Ken'ichi Ohmichi wrote:
>>>>
>>>> Hi
>>>>
>>>> I have one proposal[1] related to negative tests in Tempest, and
>>>> hoping opinions before doing that.
>>>>
>>>> Now Tempest contains negative tests and sometimes patches are being
>>>> posted for adding more negative tests, but I'd like to propose
>>>> removing them from Tempest instead.
>>>>
>>>> Negative tests verify surfaces of REST APIs for each component without
>>>> any integrations between components. That doesn't seem integration
>>>> tests which are scope of Tempest.
>>>> In addition, we need to spend the test operating time on different
>>>> component's gate if adding negative tests into Tempest. For example,
>>>> we are operating negative tests of Keystone and more
>>>> components on the gate of Nova. That is meaningless, so we need to
>>>> avoid more negative tests into Tempest now.
>>>>
>>>> If wanting to add negative tests, it is a nice option to implement
>>>> these tests on each component repo with Tempest plugin interface. We
>>>> can avoid operating negative tests on different component gates and
>>>> each component team can decide what negative tests are valuable on the
>>>> gate.
>>>
>>>
>>> Hear hear!  For Keystone, please put them in the Keystone Client
>>> Functional
>>> tests.
>>
>> They are negative tests of Keystone API, not keystoneclient tests.
>> These tests are implemented with Tempest original rest clients without
>> official clients because it is nice to test variable cases in Tempest.
>> So it is nice to keep them in Keystone repo, I feel.
>
>
> That works, too, and there is a Functional test section in Keystone Proper.
>
> Most of the Keystone APIs are fairly well covered by the Unit tests, which
> make a full HTTP call through a liteish server, so the functional tests are
> really to cover the live database (soon to include LDAP, hopefully)
> integrations.

Nice point.
Yeah, most these cases(without DB) are covered by unit tests of each
project, I guess.
At least, Nova also covers these cases with unit tests.

Thanks

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA][all] Propose to remove negative tests from Tempest

[Ken';ichi Ohmichi]

2016-03-17 3:22 GMT-07:00 Jordan Pittier :
>>
>> If wanting to add negative tests, it is a nice option to implement
>> these tests on each component repo with Tempest plugin interface. We
>> can avoid operating negative tests on different component gates and
>> each component team can decide what negative tests are valuable on the
>> gate.
>>
>> In long term, all negative tests will be migrated into each component
>> repo with Tempest plugin interface. We will be able to operate
>> valuable negative tests only on each gate.
>>
>> Any thoughts?
>
>
> I am not sure we should remove negative tests from Tempest. Agreed that we
> should reject most new negative tests, but some negative
> tests do test useful things imo. Also I ran all the negative tests today:
> "Ran: 452 tests in 144. sec." They just account for 2 minutes and 20sec
> in the gate. That's very little, removing them won't bring a lot. And the
> code for negative tests is quite contain, not a big maintenance burden.

This is a nice point. The merit of removal is less from the operation time.

My concern was the existing negative tests attract new ones like "ah,
current Tempest doesn't cover these (corner) cases. We should add
them".
I agree with keeping the existing negative tests if we reject new
corner negative tests.

Thanks
Ken Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA][all] Propose to remove negative tests from Tempest

[Ken';ichi Ohmichi]

2016-03-17 15:05 GMT-07:00 Rochelle Grober :
> (Sorry for the top post.  It was this or bottom post because of company
> choice of email systems)

(no problem :)

> Integration tests, corner cases, negative tests.  Lots of names that don't
> have clear definitions in this discussion.  But, it seems like the
> collection of "negative tests" include both functional and integrated tests.
> Maybe we should analyze the tests to see where they belong. So, perhaps we
> can ask an important question here:
>
> · Does the test provoke a change of behavior outside the designated
> project, depending on the output(s) from the test action?  In other words,
> if the test is attempting to generate a 4xx response, does it cause another
> project or client to act differently than if it returns a 2xx or different
> 4xx response?  An example of this would be the project the response is
> returned to attempts a retry.
>
> This should qualify as a tempest test because it drives actions from
> multiple projects.  Yes, it is a "negative" api test, but run in an
> integrated system, it is also a normal integration test that demonstrates
> the integrated system behaves appropriately on expected error conditions
> from other projects.  Or it throws an exception or an error message and we
> know we have a problem with either the api or the misbehaving project.
>
> Andrea aptly pointed out that these tests may very well be interoperability
> tests that should be in a gate somewhere.  After all, what are APIs, but
> defined interfaces between two components.  Sometimes it's between human and
> software, but most often in OpenStack, it's between two pieces of software
> written by different groups of developers.  Hence, the API *is* the
> integration point and ideally, all request/response options should be
> validated, whether happy path or not so happy.
>
> And, oh by the way, "negative" responses are crucial interoperability points
> for DefCore.

Thanks for your comment from the DefCore viewpoint.
That is very appreciated for me.

I understand the *success* status code should be stable for OpenStack
interoperability, but I don't yet for the *error* status code for
that.

I saw some *error* status code changes with valid implementations.
For example, if a client passes invalid format id as the URI to the
corresponding server, we can imagine two error status codes:
HTTP400(BadRequest) or HTTP404(NotFound).
From the implementation viewpoint, HTTP404 can be acceptable because
such resource must not exist in its database and we can keep the
implementation simple without a format check code. However, sometimes
we want to add the format check to avoid querying its database. In
this case, the error status code is changed from HTTP404 to HTTP400.
Now Tempest is checking such error status codes as negative tests, and
the above changes would be blocked.

Maybe the above cases would be corner, but I'd like to know what is
actual merit of error status code check from the interoperability
thing.

Thanks

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA][all] Propose to remove negative tests from Tempest

[Ken';ichi Ohmichi]

2016-03-17 4:05 GMT-07:00 Andrea Frittoli :
> On Thu, Mar 17, 2016 at 2:57 AM Ken'ichi Ohmichi 
> wrote:
>>
>> 2016-03-16 19:41 GMT-07:00 Jim Rollenhagen :
>> > On Wed, Mar 16, 2016 at 06:20:11PM -0700, Ken'ichi Ohmichi wrote:
>> >> Hi
>> >>
>> >> I have one proposal[1] related to negative tests in Tempest, and
>> >> hoping opinions before doing that.
>> >>
>> >> Now Tempest contains negative tests and sometimes patches are being
>> >> posted for adding more negative tests, but I'd like to propose
>> >> removing them from Tempest instead.
>> >>
>> >> Negative tests verify surfaces of REST APIs for each component without
>> >> any integrations between components. That doesn't seem integration
>> >> tests which are scope of Tempest.
>> >> In addition, we need to spend the test operating time on different
>> >> component's gate if adding negative tests into Tempest. For example,
>> >> we are operating negative tests of Keystone and more
>> >> components on the gate of Nova. That is meaningless, so we need to
>> >> avoid more negative tests into Tempest now.
>> >>
>> >> If wanting to add negative tests, it is a nice option to implement
>> >> these tests on each component repo with Tempest plugin interface. We
>> >> can avoid operating negative tests on different component gates and
>> >> each component team can decide what negative tests are valuable on the
>> >> gate.
>> >>
>> >> In long term, all negative tests will be migrated into each component
>> >> repo with Tempest plugin interface. We will be able to operate
>> >> valuable negative tests only on each gate.
>> >
>> > So, positive tests in tempest, negative tests as a plugin.
>> >
>> > Is there any longer term goal to have all tests for all projects in a
>> > plugin for that project? Seems odd to separate them.
>>
>> Yeah, from implementation viewpoint, that seems a little odd.
>> but from the main scope of Tempest and to avoid unnecessary gate
>> operation time, that can be acceptable, I feel.
>> Negative tests can be corner cases in most cases, they don't seem
>> integration tests.
>
> I think it's difficult to define a single black and white criteria for
> negative tests, as they encompass a wide range of types of tests.
>
> I agree that things that only testing the API level of a service (not even a
> DB behind) do not necessarily belong in tempest - i.e. testing of input
> validation done by an API.  We could have a guideline for such tests to be
> implemented as unit/functional tests in tree of the service.

Yeah, it is difficult to distinguish corner cases or not on negative
tests as the criteria.
If necessary to do that, we(QA team) need to read the implementation
code of the core six services deeply during Tempest reviews. Then I
rushed to remove all of them. My first proposal is not good according
to feedback, but I'm happy to get feedback to see our direction :-)

The guideline is a nice idea.
If necessary to add more negative tests into Tempest, how about
requiring to write the reason which explains new tests are not corner
cases in the commit message?
We can know the merit of new negative ones when reviewing.

> However Tempest is also interoperability, so we should keep at least a few
> negative API checks in tempest (for the core six services) to enforce that
> return codes do not change inadvertently in negative cases, which could
> break existing clients and applications.

This also is a nice point.
How to change error return codes is unclear to me at this time.
In Nova, there are some exceptions for changing error return code
without microversion bumping as [1]. This kind of guideline will be
discussed later.

Now I am fine to keep the existing negative tests in Tempest, anyway.

Thanks
Ken Ohmichi

---
[1]: 
https://github.com/openstack/nova/blob/master/doc/source/api_microversion_dev.rst#f2

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA][all] Propose to remove negative tests from Tempest

[Ken';ichi Ohmichi]

2016-03-18 1:50 GMT-07:00 Masayuki Igawa :
> From: GHANSHYAM MANN 
> Subject: Re: [openstack-dev] [QA][all] Propose to remove negative tests from 
> Tempest
> Date: Fri, 18 Mar 2016 10:05:39 +0900
>
>> On Fri, Mar 18, 2016 at 9:06 AM, Ken'ichi Ohmichi  
>> wrote:
>>> 2016-03-17 4:05 GMT-07:00 Andrea Frittoli :
>>>> On Thu, Mar 17, 2016 at 2:57 AM Ken'ichi Ohmichi 
>>>> wrote:
>>>>>
>>>>> 2016-03-16 19:41 GMT-07:00 Jim Rollenhagen :
>>>>> > On Wed, Mar 16, 2016 at 06:20:11PM -0700, Ken'ichi Ohmichi wrote:
>>>>> >> Hi
>>>>> >>
>>>>> >> I have one proposal[1] related to negative tests in Tempest, and
>>>>> >> hoping opinions before doing that.
>>>>> >>
>>>>> >> Now Tempest contains negative tests and sometimes patches are being
>>>>> >> posted for adding more negative tests, but I'd like to propose
>>>>> >> removing them from Tempest instead.
>>>>> >>
>>>>> >> Negative tests verify surfaces of REST APIs for each component without
>>>>> >> any integrations between components. That doesn't seem integration
>>>>> >> tests which are scope of Tempest.
>>>>> >> In addition, we need to spend the test operating time on different
>>>>> >> component's gate if adding negative tests into Tempest. For example,
>>>>> >> we are operating negative tests of Keystone and more
>>>>> >> components on the gate of Nova. That is meaningless, so we need to
>>>>> >> avoid more negative tests into Tempest now.
>>>>> >>
>>>>> >> If wanting to add negative tests, it is a nice option to implement
>>>>> >> these tests on each component repo with Tempest plugin interface. We
>>>>> >> can avoid operating negative tests on different component gates and
>>>>> >> each component team can decide what negative tests are valuable on the
>>>>> >> gate.
>>>>> >>
>>>>> >> In long term, all negative tests will be migrated into each component
>>>>> >> repo with Tempest plugin interface. We will be able to operate
>>>>> >> valuable negative tests only on each gate.
>>>>> >
>>>>> > So, positive tests in tempest, negative tests as a plugin.
>>>>> >
>>>>> > Is there any longer term goal to have all tests for all projects in a
>>>>> > plugin for that project? Seems odd to separate them.
>>>>>
>>>>> Yeah, from implementation viewpoint, that seems a little odd.
>>>>> but from the main scope of Tempest and to avoid unnecessary gate
>>>>> operation time, that can be acceptable, I feel.
>>>>> Negative tests can be corner cases in most cases, they don't seem
>>>>> integration tests.
>>>>
>>>> I think it's difficult to define a single black and white criteria for
>>>> negative tests, as they encompass a wide range of types of tests.
>>>>
>>>> I agree that things that only testing the API level of a service (not even 
>>>> a
>>>> DB behind) do not necessarily belong in tempest - i.e. testing of input
>>>> validation done by an API.  We could have a guideline for such tests to be
>>>> implemented as unit/functional tests in tree of the service.
>>
>> Yes, this is key point here. If we see ~70% of the negative tests are
>> just checking API surface level (wrong input validation), which
>> defiantly
>> not belong to Tempest scope. Those should be in respective projects
>> repo either by functional/unit/plugin.
>> But in that case we have to define a very clear criteria about what
>> level of negative testing should be in scope of Tempest.
>>
>> Also another key point is that, as we have lot of surface level
>> negative testing in Tempest, should we reject the new one?
>> For me sometime it makes difficult to reject those as we already have
>> some in tempest.
>>
>> My vote here is we reject the new surface level negative tests and try
>> to move all existing negative tests(surface level) out of Tempest
>> ASAP.
>> And those can be just moved to projects functional/unit tests.
>>
>>>
>>> Yeah, it is difficult to distinguish corner cases or not on

Re: [openstack-dev] [QA][all] Propose to remove negative tests from Tempest

[Ken';ichi Ohmichi]

2016-03-16 19:29 GMT-07:00 Adam Young :
> On 03/16/2016 09:20 PM, Ken'ichi Ohmichi wrote:
>>
>> Hi
>>
>> I have one proposal[1] related to negative tests in Tempest, and
>> hoping opinions before doing that.
>>
>> Now Tempest contains negative tests and sometimes patches are being
>> posted for adding more negative tests, but I'd like to propose
>> removing them from Tempest instead.
>>
>> Negative tests verify surfaces of REST APIs for each component without
>> any integrations between components. That doesn't seem integration
>> tests which are scope of Tempest.
>> In addition, we need to spend the test operating time on different
>> component's gate if adding negative tests into Tempest. For example,
>> we are operating negative tests of Keystone and more
>> components on the gate of Nova. That is meaningless, so we need to
>> avoid more negative tests into Tempest now.
>>
>> If wanting to add negative tests, it is a nice option to implement
>> these tests on each component repo with Tempest plugin interface. We
>> can avoid operating negative tests on different component gates and
>> each component team can decide what negative tests are valuable on the
>> gate.
>
>
> Hear hear!  For Keystone, please put them in the Keystone Client Functional
> tests.

They are negative tests of Keystone API, not keystoneclient tests.
These tests are implemented with Tempest original rest clients without
official clients because it is nice to test variable cases in Tempest.
So it is nice to keep them in Keystone repo, I feel.

Thanks
Ken Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA][all] Propose to remove negative tests from Tempest

[Ken';ichi Ohmichi]

2016-03-16 19:41 GMT-07:00 Jim Rollenhagen :
> On Wed, Mar 16, 2016 at 06:20:11PM -0700, Ken'ichi Ohmichi wrote:
>> Hi
>>
>> I have one proposal[1] related to negative tests in Tempest, and
>> hoping opinions before doing that.
>>
>> Now Tempest contains negative tests and sometimes patches are being
>> posted for adding more negative tests, but I'd like to propose
>> removing them from Tempest instead.
>>
>> Negative tests verify surfaces of REST APIs for each component without
>> any integrations between components. That doesn't seem integration
>> tests which are scope of Tempest.
>> In addition, we need to spend the test operating time on different
>> component's gate if adding negative tests into Tempest. For example,
>> we are operating negative tests of Keystone and more
>> components on the gate of Nova. That is meaningless, so we need to
>> avoid more negative tests into Tempest now.
>>
>> If wanting to add negative tests, it is a nice option to implement
>> these tests on each component repo with Tempest plugin interface. We
>> can avoid operating negative tests on different component gates and
>> each component team can decide what negative tests are valuable on the
>> gate.
>>
>> In long term, all negative tests will be migrated into each component
>> repo with Tempest plugin interface. We will be able to operate
>> valuable negative tests only on each gate.
>
> So, positive tests in tempest, negative tests as a plugin.
>
> Is there any longer term goal to have all tests for all projects in a
> plugin for that project? Seems odd to separate them.

Yeah, from implementation viewpoint, that seems a little odd.
but from the main scope of Tempest and to avoid unnecessary gate
operation time, that can be acceptable, I feel.
Negative tests can be corner cases in most cases, they don't seem
integration tests.

Thanks
Ken Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA][all] Propose to remove negative tests from Tempest

[Ken';ichi Ohmichi]

Hi

I have one proposal[1] related to negative tests in Tempest, and
hoping opinions before doing that.

Now Tempest contains negative tests and sometimes patches are being
posted for adding more negative tests, but I'd like to propose
removing them from Tempest instead.

Negative tests verify surfaces of REST APIs for each component without
any integrations between components. That doesn't seem integration
tests which are scope of Tempest.
In addition, we need to spend the test operating time on different
component's gate if adding negative tests into Tempest. For example,
we are operating negative tests of Keystone and more
components on the gate of Nova. That is meaningless, so we need to
avoid more negative tests into Tempest now.

If wanting to add negative tests, it is a nice option to implement
these tests on each component repo with Tempest plugin interface. We
can avoid operating negative tests on different component gates and
each component team can decide what negative tests are valuable on the
gate.

In long term, all negative tests will be migrated into each component
repo with Tempest plugin interface. We will be able to operate
valuable negative tests only on each gate.

Any thoughts?

Thanks
Ken Ohmichi

---
[1]: https://review.openstack.org/#/c/293197/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Nova PTL for Newton

[Ken';ichi Ohmichi]

Thank you so much, John.

Nova PTL is always a hard position, and you have accelerated our
collaboration with your leadership.

Thanks

2016-03-11 11:22 GMT-08:00 John Garbutt :
> Hi,
>
> It has been greatly rewarding serving you all as Nova PTL over the
> Liberty and Mitaka cycles. I thank you all for the support,
> encouragement and advice I have been given over the last year. I
> really appreciate that. (That's british speak for "I love you all", or
> something like that).
>
> I don't plan on standing for the Newton cycle. I think its a good time
> for someone to bring fresh energy, ideas, and drive to help keep Nova
> driving forward. I have enjoyed my time as PTL, as such, I would
> consider standing again. We have a good number of folks stepping up to
> lead different parts of the project. I hope we can grow that effort,
> and I hope to continue to be part of that.
>
> I aim to continue contributing to Nova (I hope to be in Austin, and I
> hope to write some code again soon). I will certainly make time to
> ensure a smooth transition to the next PTL.
>
> Many thanks,
> johnthetubaguy
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA] Not running for PTL

[Ken';ichi Ohmichi]

2016-03-11 11:34 GMT-08:00 Matthew Treinish :
> Hi everyone,
>
> I'm writing this to announce that I am not running for QA PTL this cycle. I've
> been the QA PTL for the past 4 cycles and I think it's time for another person
> to take over the role. I think during the past 4 cycles the QA community has
> grown greatly and become a much larger and stronger community compared to when
> I first took on the position in the Juno cycle.
>
> I strongly believe in the diversity of leadership and ideas, and I don't want
> the community to grow stagnant because it becomes synonymous with just my 
> voice.
> Being a PTL is not the same as being an autocrat and I think it's time for
> another person to step up and take over the QA PTL spot.

Thank you very much for your great works in long term, Matthew.
You have worked with a lot of people between many projects/timezones
as QA PTL, the work seems hard for me.

> That being said, I'm not planning on going anywhere or leaving the project. I
> fully intend to continue working and being heavily involved with the QA 
> program,
> as I have for been the past 2 years. (although maybe with a bit more free time
> now)

Yeah, we still need  you :-)

Thanks
Ken Ohmichi

---
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Do we need a microversion to return a 501 from GET os-virtual-interfaces?

[Ken';ichi Ohmichi]

2016-03-06 15:41 GMT-08:00 Jay Pipes :
> On 03/06/2016 02:21 PM, Matt Riedemann wrote:
>>
>> Thanks, good point. I think 400 would be best here. And according to our
>> handy-dandy docs [1] it should be OK to do this without a microversion.
>
>
> Yup, 400 is correct and yes, you should not need a new microversion addition
> to the API.

+1 for unnecessary microversion bumping.

Thanks
Ken Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev