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

[GHANSHYAM MANN]

On Sun, Aug 17, 2014 at 1:27 AM, Marc Koderer  wrote:

> Hi all,
>
> Am 15.08.2014 um 23:31 schrieb Jay Pipes :
> >
> > I suggest that "tempest" should be the name of the import'able library,
> and that the integration tests themselves should be what is pulled out of
> the current Tempest repository, into their own repo called
> "openstack-integration-tests" or "os-integration-tests“.
>
> why not keeping it simple:
>
> tempest: importable test library
> tempest-tests: all the test cases
>
> Simple, obvious and clear ;)
>

++. And for more clarity- importable test library could name
as "tempest-lib"


>
> Regards
> Marc
>
> > Best,
> > -jay
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks & Regards
Ghanshyam Mann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] Lack of consistency in returning response from tempest clients

[GHANSHYAM MANN]

+1. That will also help full for API coming up with microversion like Nova.

On Fri, Aug 29, 2014 at 11:56 PM, Sean Dague  wrote:

> On 08/29/2014 10:19 AM, David Kranz wrote:
> > While reviewing patches for moving response checking to the clients, I
> > noticed that there are places where client methods do not return any
> value.
> > This is usually, but not always, a delete method. IMO, every rest client
> > method should return at least the response. Some services return just
> > the response for delete methods and others return (resp, body). Does any
> > one object to cleaning this up by just making all client methods return
> > resp, body? This is mostly a change to the clients. There were only a
> > few places where a non-delete  method was returning just a body that was
> > used in test code.
>
> Yair and I were discussing this yesterday. As the response correctness
> checking is happening deeper in the code (and you are seeing more and
> more people assigning the response object to _ ) my feeling is Tempest
> clients should probably return a body obj that's basically.
>
> class ResponseBody(dict):
> def __init__(self, body={}, resp=None):
> self.update(body)
> self.resp = resp
>
> Then all the clients would have single return values, the body would be
> the default thing you were accessing (which is usually what you want),
> and the response object is accessible if needed to examine headers.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks & Regards
Ghanshyam Mann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] 2019 summit during May holidays?

[Ghanshyam Mann]

  On Tue, 06 Nov 2018 05:50:03 +0900 Dmitry Tantsur  
wrote  
 > 
 > 
 > On Mon, Nov 5, 2018, 20:07 Julia Kreger  *removes all of the hats*
 > *removes years of dust from unrelated event planning hat, and puts it on for 
 > a moment*
 > 
 > In my experience, events of any nature where convention venue space is 
 > involved, are essentially set in stone before being publicly advertised as 
 > contracts are put in place for hotel room booking blocks as well as the 
 > convention venue space. These spaces are also typically in a relatively high 
 > demand limiting the access and available times to schedule. Often venues 
 > also give preference (and sometimes even better group discounts) to repeat 
 > events as they are typically a known entity and will have somewhat known 
 > needs so the venue and hotel(s) can staff appropriately. 
 > 
 > tl;dr, I personally wouldn't expect any changes to be possible at this point.
 > 
 > *removes event planning hat of past life, puts personal scheduling hat on*
 > I imagine that as a community, it is near impossible to schedule something 
 > avoiding holidays for everyone in the community.
 > 
 > I'm not taking about everyone. And I'm mostly fine with my holiday, but the 
 > conflicts with Russia and Japan seem huge. This certainly does not help our 
 > effort to engage people outside of NA/EU.
 > Quick googling suggests that the week of May 13th would have much fewer 
 > conflicts.
 > 
 > I personally have lost count of the number of holidays and special days that 
 > I've spent on business trips over the past four years. While I may be an 
 > out-lier in my feelings on this subject, I'm not upset, annoyed, or even 
 > bitter about lost times. This community is part of my family.
 > 
 > Sure :)
 > But outside of our small nice circle there is a huge world of people who may 
 > not share our feeling and the level of commitment to openstack. These 
 > occasional contributors we talked about when discussing the cycle length. I 
 > don't think asking them to abandon 3-5 days of holidays is a productive way 
 > to engage them.
 > And again, as much as I love meeting you all, I think we're outgrowing the 
 > format of these meetings..
 > Dmitry

Yeah, in case of Japan it is full week holiday starting from April 29th. I 
remember most of the May summits did not conflict with Golden week but this is. 
I am not sure if any solution to this now but we should consider such things in 
future. 

-gmann

 > 
 > -Julia
 > 
 > On Mon, Nov 5, 2018 at 8:19 AM Dmitry Tantsur  wrote:
 > Hi all,
 >  
 >  Not sure how official the information about the next summit is, but it's on 
 > the 
 >  web site [1], so I guess worth asking..
 >  
 >  Are we planning for the summit to overlap with the May holidays? The 1st of 
 > May 
 >  is a holiday in big part of the world. We ask people to skip it in addition 
 > to 
 >  3+ weekend days they'll have to spend working and traveling.
 >  
 >  To make it worse, 1-3 May are holidays in Russia this time. To make it even 
 >  worse than worse, the week of 29th is the Golden Week in Japan [2]. Was it 
 >  considered? Is it possible to move the days to less conflicting time 
 > (mid-May 
 >  maybe)?
 >  
 >  Dmitry
 >  
 >  [1] https://www.openstack.org/summit/denver-2019/
 >  [2] https://en.wikipedia.org/wiki/Golden_Week_(Japan)
 >  
 >  __
 >  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] [tc][all] TC office hours is started now on #openstack-tc

[Ghanshyam Mann]

Hi All, 

TC office hour is started on #openstack-tc channel. Feel free to reach to us 
for anything you want discuss/input/feedback/help from TC. 

-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

Re: [openstack-dev] [all][qa] Migrating devstack jobs to Bionic (Ubuntu LTS 18.04)

[Ghanshyam Mann]

Thanks Jens.

As most of the base jobs are in QA repo, QA team will coordinate this migration 
based on either of the approach mentioned below. 

Another point to note - This migration will only target the zuulv3 jobs not the 
legacy jobs. legacy jobs owner should migrate them to bionic when they will be 
moved to zuulv3 native. Any risk of keeping the legacy on xenial till zullv3 ?

Tempest testing patch found that stable queens/pike jobs failing for bionic due 
to not supported distro in devstack[1]. Fixing in  
https://review.openstack.org/#/c/616017/ and will backport to pike too.

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

http://logs.openstack.org/72/611572/1/check/tempest-full-queens/7cd3f21/job-output.txt.gz#_2018-11-01_09_57_07_551538
 


-gmann
  On Tue, 06 Nov 2018 21:12:55 +0900 Dr. Jens Harbott (frickler) 
 wrote  
 > Dear OpenStackers,
 > 
 > earlier this year Ubuntu released their current LTS version 18.04
 > codenamed "Bionic Beaver" and we are now facing the task to migrate
 > our devstack-based jobs to run on Bionic instead of the previous LTS
 > version 16.04 "Xenial Xerus".
 > 
 > The last time this has happened two years ago (migration from 14.04 to
 > 16.04) and at that time it seems the migration was mostly driven by
 > the Infra team (see [1]), mostly because all of the job configuration
 > was still centrally hosted in a single repository
 > (openstack-infra/project-config). In the meantime, however, our CI
 > setup has been updated to use Zuul v3 and one of the new features that
 > come with this development is the introduction of per-project job
 > definitions.
 > 
 > So this new flexibility requires us to make a choice between the two
 > possible options we have for migrating jobs now:
 > 
 > 1) Change the "devstack" base job to run on Bionic instances
 > instead of Xenial instances
 > 2) Create new "devstack-bionic" and "tempest-full-bionic" base
 > jobs and migrate projects piecewise
 > 
 > Choosing option 1) would cause all projects that base their own jobs
 > on this job (possibly indirectly by e.g. being based on the
 > "tempest-full" job) switch automatically. So there would be the
 > possibility that some jobs would break and require to be fixed before
 > patches could be merged again in the affected project(s). To
 > accomodate those risks, QA team can give some time to projects to test
 > their jobs on Bionic with WIP patches (QA can provide Bionic base job
 > as WIP patch). This option does not require any pre/post migration
 > changes on project's jobs.
 > 
 > Choosing option 2) would avoid this by letting projects switch at
 > their own pace, but create the risk that some projects would never
 > migrate. It would also make further migrations, like the one expected
 > to happen when 20.04 is released, either having to follow the same
 > scheme or re-introduce the unversioned base job. Other point to note
 > down with this option is,
 >- project job definitions need to change their parent job from
 > "devstack" -> "devstack-bionic" or "tempest-full" ->
 > "tempest-full-bionic"
 >  - QA needs to maintain existing jobs ("devstack", "tempest-full") and
 > bionic version jobs ("devstack-bionic", "tempest-full-bionic")
 > 
 > In order to prepare the decision, we have created a set of patches
 > that test the Bionic
 > jobs, you can find them under the common topic "devstack-bionic" [2].
 > There is also an
 > etherpad to give a summarized view of the results of these tests [3].
 > 
 > Please respond to this mail if you want to promote either of the above
 > options or
 > maybe want to propose an even better solution. You can also find us
 > for discussion
 > in the #openstack-qa IRC channel on freenode.
 > 
 > Infra team has tried both approaches during precise->trusty &
 > trusty->xenial migration[4].
 > 
 > Note that this mailing-list itself will soon be migrated, too, so if
 > you haven't subscribed
 > to the new list yet, this is a good time to act and avoid missing the
 > best parts [5].
 > 
 > Yours,
 > Jens (frickler@IRC)
 > 
 > 
 > [1] 
 > http://lists.openstack.org/pipermail/openstack-dev/2016-November/106906.html
 > [2] https://review.openstack.org/#/q/topic:devstack-bionic
 > [3] https://etherpad.openstack.org/p/devstack-bionic
 > [4] 
 > http://eavesdrop.openstack.org/irclogs/%23openstack-qa/%23openstack-qa.2018-11-01.log.html#t2018-11-01T12:40:22
 > [5] 
 > http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html
 > 
 > __
 > 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:unsubs

Re: [openstack-dev] [all][qa] Migrating devstack jobs to Bionic (Ubuntu LTS 18.04)

[Ghanshyam Mann]

  On Wed, 07 Nov 2018 06:51:32 +0900 Slawomir Kaplonski 
 wrote  
 > Hi,
 > 
 > > Wiadomość napisana przez Jeremy Stanley  w dniu 
 > > 06.11.2018, o godz. 22:25:
 > > 
 > > On 2018-11-06 22:05:49 +0100 (+0100), Slawek Kaplonski wrote:
 > > [...]
 > >> also add jobs like "devstack-xenial" and "tempest-full-xenial"
 > >> which projects can use still for some time if their job on Bionic
 > >> would be broken now?
 > > [...]
 > > 
 > > That opens the door to piecemeal migration, which (as we similarly
 > > saw during the Trusty to Xenial switch) will inevitably lead to
 > > projects who no longer gate on Xenial being unable to integration
 > > test against projects who don't yet support Bionic. At the same
 > > time, projects which have switched to Bionic will start merging
 > > changes which only work on Bionic without realizing it, so that
 > > projects which test on Xenial can't use them. In short, you'll be
 > > broken either way. On top of that, you can end up with projects that
 > > don't get around to switching completely before release comes, and
 > > then they're stuck having to manage a test platform transition on a
 > > stable branch.
 > 
 > I understand Your point here but will option 2) from first email lead to the 
 > same issues then?

seems so. approach 1 is less risky for such integrated testing issues and 
requires less work. In approach 1, we can coordinate the base job migration 
with project side testing with bionic.

-gmann

 > 
 > > -- 
 > > 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
 > 
 > — 
 > Slawek Kaplonski
 > Senior software engineer
 > Red Hat
 > 
 > 
 > __
 > 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][qa] Migrating devstack jobs to Bionic (Ubuntu LTS 18.04)

[Ghanshyam Mann]

  On Wed, 07 Nov 2018 07:07:33 +0900 Clark Boylan  
wrote  
 > On Tue, Nov 6, 2018, at 2:02 PM, Ghanshyam Mann wrote:
 > > Thanks Jens.
 > > 
 > > As most of the base jobs are in QA repo, QA team will coordinate this 
 > > migration based on either of the approach mentioned below. 
 > > 
 > > Another point to note - This migration will only target the zuulv3 jobs 
 > > not the legacy jobs. legacy jobs owner should migrate them to bionic 
 > > when they will be moved to zuulv3 native. Any risk of keeping the legacy 
 > > on xenial till zullv3 ?
 > > 
 > > Tempest testing patch found that stable queens/pike jobs failing for 
 > > bionic due to not supported distro in devstack[1]. Fixing in  
 > > https://review.openstack.org/#/c/616017/ and will backport to pike too.
 > 
 > The existing stable branches should continue to test on xenial as that is 
 > what they were built on. We aren't asking that everything be ported forward 
 > to bionic. Instead the idea is that current development (aka master) switch 
 > to bionic and roll forward from that point.

Make sense. Thanks. We can keep stable branch jobs running on Tempest master on 
xenial only. 

-gmann

 > 
 > This applies to tempest jobs, functional jobs, and unittests, etc. Xenial 
 > isn't going away. It is there for the stable branches.
 > 
 > > 
 > > [1]  https://review.openstack.org/#/c/611572/
 > > 
 > > http://logs.openstack.org/72/611572/1/check/tempest-full-queens/7cd3f21/job-output.txt.gz#_2018-11-01_09_57_07_551538
 > >  
 > > 
 > > 
 > > -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

[openstack-dev] [tc][all] TC office hours is started now on #openstack-tc

[Ghanshyam Mann]

Hi All, 

TC office hour is started on #openstack-tc channel. Feel free to reach to us 
for anything you want discuss/input/feedback/help from TC. 

- TC 





__
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] [openstack-operators] [qa] [berlin] QA Team & related sessions at berlin summit

[Ghanshyam Mann]

Hello everyone,

Along with project updates & onboarding sessions, QA team will host QA feedback 
sessions in berlin summit.  Feel free to catch us next week for any QA related 
questions or if you need help to contribute in QA (we are really looking 
forward to onbaord new contributor in QA). 

Below are the QA related sessions, feel free to append the list if i missed 
anything. I am working on onboarding/forum sessions etherpad and will send the 
link tomorrow. 

Tuesday:
  1. OpenStack QA - Project Update.   [1]
  2. OpenStack QA - Project Onboarding.   [2]
  3. OpenStack Patrole – Foolproofing your OpenStack Deployment [3]

Wednesday:
  4. Forum: Users / Operators adoption of QA tools / plugins.  [4]

Thursday:
  5. Using Rally/Tempest for change validation (OPS session) [5]

[1] 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22763/openstack-qa-project-update
 
[2] 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22762/openstack-qa-project-onboarding
[3] 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22148/openstack-patrole-foolproofing-your-openstack-deployment
[4] 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22788/users-operators-adoption-of-qa-tools-plugins
 
[5] 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22837/using-rallytempest-for-change-validation-ops-session
 

-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

Re: [openstack-dev] [openstack-operators] [qa] [berlin] QA Team & related sessions at berlin summit

[Ghanshyam Mann]

Hello Everyone,

I have created the below etherpads to use during QA Forum sessions:

- Users / Operators adoption of QA tools:  
https://etherpad.openstack.org/p/BER-qa-ops-user-feedback 
- QA Onboarding: https://etherpad.openstack.org/p/BER-qa-onboarding-vancouver

-gmann

  On Fri, 09 Nov 2018 11:02:54 +0900 Ghanshyam Mann 
 wrote  
 > Hello everyone, 
 >  
 > Along with project updates & onboarding sessions, QA team will host QA 
 > feedback sessions in berlin summit.  Feel free to catch us next week for any 
 > QA related questions or if you need help to contribute in QA (we are really 
 > looking forward to onbaord new contributor in QA).  
 >  
 > Below are the QA related sessions, feel free to append the list if i missed 
 > anything. I am working on onboarding/forum sessions etherpad and will send 
 > the link tomorrow.  
 >  
 > Tuesday: 
 >   1. OpenStack QA - Project Update.   [1] 
 >   2. OpenStack QA - Project Onboarding.   [2] 
 >   3. OpenStack Patrole – Foolproofing your OpenStack Deployment [3] 
 >  
 > Wednesday: 
 >   4. Forum: Users / Operators adoption of QA tools / plugins.  [4] 
 >  
 > Thursday: 
 >   5. Using Rally/Tempest for change validation (OPS session) [5] 
 >  
 > [1] 
 > https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22763/openstack-qa-project-update
 >   
 > [2] 
 > https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22762/openstack-qa-project-onboarding
 >  
 > [3] 
 > https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22148/openstack-patrole-foolproofing-your-openstack-deployment
 >  
 > [4] 
 > https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22788/users-operators-adoption-of-qa-tools-plugins
 >   
 > [5] 
 > https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22837/using-rallytempest-for-change-validation-ops-session
 >   
 >  
 > -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

Re: [openstack-dev] [QA][Tempest] Proposing Ghanshyam Mann for Tempest Core

[GHANSHYAM MANN]

Thank you very much all of you. It's a honor to be part of Tempest core
team. I will give my best for the team.

On Thu, Nov 27, 2014 at 12:06 AM, Matthew Treinish 
wrote:

>
> So all of the current core team members have voted unanimously in favor of
> adding Ghanshyam to the team.
>
> Welcome to the team Ghanshyam.
>
> -Matt Treinish
>
>
> On Wed, Nov 26, 2014 at 09:57:10AM -0500, Attila Fazekas wrote:
> > +1
> >
> > - Original Message -
> > From: "Marc Koderer" 
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> > Sent: Wednesday, November 26, 2014 7:58:06 AM
> > Subject: Re: [openstack-dev] [QA][Tempest] Proposing Ghanshyam Mann for
>  Tempest Core
> >
> > +1
> >
> > Am 22.11.2014 um 15:51 schrieb Andrea Frittoli <
> andrea.fritt...@gmail.com >:
> >
> >
> >
> >
> >
> > +1
> > On 21 Nov 2014 18:25, "Ken1 Ohmichi" < ken1ohmi...@gmail.com > wrote:
> >
> >
> > +1 :-)
> >
> > Sent from my iPod
> >
> > On 2014/11/22, at 7:56, Christopher Yeoh < cbky...@gmail.com > wrote:
> >
> > > +1
> > >
> > > Sent from my iPad
> > >
> > >> On 22 Nov 2014, at 4:56 am, Matthew Treinish < mtrein...@kortar.org
> > wrote:
> > >>
> > >>
> > >> Hi Everyone,
> > >>
> > >> I'd like to propose we add Ghanshyam Mann (gmann) to the tempest core
> team. Over
> > >> the past couple of cycles Ghanshyam has been actively engaged in the
> Tempest
> > >> community. Ghanshyam has had one of the highest review counts on
> Tempest for
> > >> the past cycle, and he has consistently been providing reviews that
> have been
> > >> of consistently high quality that show insight into both the project
> internals
> > >> and it's future direction. I feel that Ghanshyam will make an
> excellent addition
> > >> to the core 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.
> > >>
> > >> Thanks,
> > >>
> > >> Matt Treinish
> > >>
> > >> References:
> > >>
> > >>
> https://review.openstack.org/#/q/reviewer:%22Ghanshyam+Mann+%253Cghanshyam.mann%2540nectechnologies.in%253E%22,n,z
> > >>
> > >> http://stackalytics.com/?user_id=ghanshyammann&metric=marks
> > >>
> > >> ___
> > >> OpenStack-dev mailing list
> > >> OpenStack-dev@lists.openstack.org
> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > > ___
> > > OpenStack-dev mailing list
> > > OpenStack-dev@lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks & Regards
Ghanshyam Mann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tempest] How to run tempest tests

[GHANSHYAM MANN]

gt;> > Angelo
>>>> >
>>>> > [1]
>>>> http://docs.openstack.org/developer/tempest/overview.html#quickstart
>>>> >
>>>>
>>>> -Matt Treinish
>>>>
>>>>  ___
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev@lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> ___
>> OpenStack-dev mailing 
>> listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks & Regards
Ghanshyam Mann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] Tempest Bug triage

[GHANSHYAM MANN]

All,
As we all know bug triage rotation is working well in QA and we keep new
bug count low.

Thanks everyone for signing up in bug triage rotation.

To continue the same strategy and keeping good progress on bugs, we need
more volunteers to sign-up for coming weeks.

People who want to help in bug triage, feel free to put your name in
https://etherpad.openstack.org/p/qa-bug-triage-rotation

Thanks
gmann

On Fri, Sep 12, 2014 at 4:52 AM, David Kranz  wrote:

> So we had a Bug Day this week and the results were a bit disappointing due
> to lack of participation. We went from 124 New bugs to 75. There were also
> many cases where bugs referred to logs that no longer existed. This
> suggests that we really need to keep up with bug triage in real time. Since
> bug triage should involve the Core review team, we propose to rotate the
> responsibility of triaging bugs weekly. I put up an etherpad here
> https://etherpad.openstack.org/p/qa-bug-triage-rotation and I hope the
> tempest core review team will sign up. Given our size, this should involve
> signing up once every two months or so. I took next week.
>
>  -David
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks & Regards
Ghanshyam Mann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA] Meeting Thursday Jan 22nd at 22:00 UTC

[GHANSHYAM MANN]

Hi everyone,

Just a quick reminder that the weekly OpenStack QA team IRC meeting will be
tomorrow Thursday, Jan 22nd at 22:00 UTC in the #openstack-meeting channel.

The agenda for tomorrow's meeting can be found here:

https://wiki.openstack.org/wiki/Meetings/QATeamMeeting

Anyone is welcome to add an item to the agenda.

To help people figure out what time 22:00 UTC is in other timezones
tomorrow's meeting will be at:

18:00 EDT

07:00 JST

07:30 ACST

0:00 CEST

17:00 CDT

15:00 PDT


-- 
Thanks & Regards
Ghanshyam Mann
__
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] Do we now require schema response validation in tempest clients?

[Ghanshyam Mann]

Hi David, Ken'ichi,

Thursday, May 1, 2014 1:02 PM Ken'ichi Ohmichi : 
>Hi David,

>2014-05-01 5:44 GMT+09:00 David Kranz :
>> There have been a lot of patches that add the validation of response dicts.
>> We need a policy on whether this is required or not. For example, this 
>> patch
>>
>> https://review.openstack.org/#/c/87438/5
>>
>> is for the equivalent of 'cinder service-list' and is a basically a 
>> copy of the nova test which now does the validation. So two questions:
>>
>> Is cinder going to do this kind of checking?
>> If so, should new tests be required to do it on submission?

>I'm not sure someone will add the similar validation, which we are adding to 
>Nova API tests, to Cinder API tests also. but it would be nice for Cinder and 
>Tempest. The validation can be applied to the other >projects(Cinder, etc) 
>easily because the base framework is implemented in common rest client of 
>Tempest.

Yes, that will be nice if we start implementing the validation part for other 
component's APIs test also. I can take this and start implementing the 
validation for existing tests of cinder. Those can be continue whenever new 
test cases are going to be added.

>When adding new tests like https://review.openstack.org/#/c/87438 , I don't 
>have strong opinion for including the validation also. These schemas will be 
>large sometimes and the combination in the same patch >would make reviews 
>difficult. In current Nova API test implementations, we are separating them 
>into different patches.

Me too agree.

Thanks
Ghanshyam Mann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



DISCLAIMER:
---
The contents of this e-mail and any attachment(s) are confidential and
intended
for the named recipient(s) only. 
It shall not attach any liability on the originator or NEC or its
affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the
opinions of NEC or its affiliates. 
Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of 
this message without the prior written consent of the author of this e-mail is
strictly prohibited. If you have 
received this email in error please delete it and notify the sender
immediately. .
---

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] Checking for return codes in tempest client calls

[Ghanshyam Mann]

Hi All,

>>2014-05-07 22:53 GMT+09:00 David Kranz :
>> I just looked at a patch https://review.openstack.org/#/c/90310/3 
>> which was given a -1 due to not checking that every call to list_hosts 
>> returns 200. I realized that we don't have a shared understanding or 
>> policy about this. We need to make sure that each api is tested to 
>> return the right response, but many tests need to call multiple apis 
>> in support of the one they are actually testing. It seems silly to 
>> have the caller check the response of every api call. Currently there 
>> are many, if not the majority of, cases where api calls are made 
>> without checking the response code. I see a few
>> possibilities:
>>
>> 1. Move all response code checking to the tempest clients. They are 
>> already checking for failure codes and are now doing validation of 
>> json response and headers as well. Callers would only do an explicit 
>> check if there were multiple success codes possible.
>>
>> 2. Have a clear policy of when callers should check response codes and 
>> apply it.
>>
>> I think the first approach has a lot of advantages. Thoughts?

>Thanks for proposing this, I also prefer the first approach.
>We will be able to remove a lot of status code checks if going on this 
>direction.
>It is necessary for bp/nova-api-test-inheritance tasks also.
>Current https://review.openstack.org/#/c/92536/ removes status code checks 
>because some Nova v2/v3 APIs return different codes and the codes are already 
>checked in client side.

>but it is necessary to create a lot of patch for covering all API tests.
>So for now, I feel it is OK to skip status code checks in API tests only if 
>client side checks are already implemented.
>After implementing all client validations, we can remove them of API tests.

I also like the first approach, where any missing of return code checking can 
be avoided.
Even we can have multiple return code check at client side in JSON schema. 
Currently we do not have any schema validation of any such API which return 
multiple success code.
For example server external events API returns multiple success code (200, 
207), https://review.openstack.org/#/c/90655/ implement the test for that and 
Schema for this API response validation should have multiple return code check.

Thanks
Ghanshyam Mann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



DISCLAIMER:
---
The contents of this e-mail and any attachment(s) are confidential and
intended
for the named recipient(s) only. 
It shall not attach any liability on the originator or NEC or its
affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the
opinions of NEC or its affiliates. 
Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of 
this message without the prior written consent of the author of this e-mail is
strictly prohibited. If you have 
received this email in error please delete it and notify the sender
immediately. .
---

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Branchless Tempest QA Spec - final draft

[Ghanshyam Mann]

Hi Sean,

> -Original Message-
> From: Sean Dague [mailto:s...@dague.net]
> Sent: Monday, April 14, 2014 10:22 PM
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [all] Branchless Tempest QA Spec - final draft
> 
> As we're coming up on the stable/icehouse release the QA team is looking
> pretty positive at no longer branching Tempest. The QA Spec draft for this is
> here - http://docs-draft.openstack.org/77/86577/2/check/gate-qa-specs-
> docs/3f84796/doc/build/html/specs/branchless-tempest.html
> and hopefully address a lot of the questions we've seen so far.
> 
> Additional comments are welcome on the review -
> https://review.openstack.org/#/c/86577/
> or as responses on this ML thread.
> 
>   -Sean
> 
> --
> Sean Dague
> Samsung Research America
> s...@dague.net / sean.da...@samsung.com
> http://dague.net

There is one more scenario where interface of the existing APIs gets changed
may be only for experimental APIs (Nova V3 APIs). I have following question
regarding those.
1. How we are going to tag those in Branchless Tempest? Should we keep 
two versions of tests for old and new API interface.
2. Till Branchless Tempest is not Implemented, tempest test
 has to be skipped for those as they get failed on 
Ice-House gate tests.
So for tempest part of those changes should we wait for 
implementation of  
Branchless tempest to complete?

For example,
 'os-instance_actions' v3 API changed to 'os-server-actions' 
(https://review.openstack.org/#/c/57614/)
 after Ice-house release and its respective tests are skipped in tempest.
Now https://review.openstack.org/#/c/85666/  adds the response validation for 
this API in tempest.
As API tempest tests are skipped (cannot unskip as ice-house gate test fails), 
response validation code
will be untested on gate. 
My question is how I should go on these-
1. Should I wait for implementation of Branchless tempest to complete?
2. OK to merge even this is going to be untested on gate.


Thanks
Ghanshyam Mann



DISCLAIMER:
---
The contents of this e-mail and any attachment(s) are confidential and
intended
for the named recipient(s) only. 
It shall not attach any liability on the originator or NEC or its
affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the
opinions of NEC or its affiliates. 
Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of 
this message without the prior written consent of the author of this e-mail is
strictly prohibited. If you have 
received this email in error please delete it and notify the sender
immediately. .
---
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] Checking for return codes in tempest client calls

[GHANSHYAM MANN]

[200])

> > >

> > >

> > >Thanks

> > >Ken'ichi Ohmichi

> > >

> > >___

> > >OpenStack-dev mailing list

> > >OpenStack-dev@lists.openstack.org

> > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

> > Note that there are currently two different methods on RestClient that

> > do this sort of thing. Your stacktrace shows "validate_response" which

> > expects to be passed a schema. The other is "expected_success" which

> > takes the expected response code and is only used by the image

> > clients.

> > Both of these will need to stay around since not all APIs have defined

> > schemas but the expected_success method should probably be changed to

> > accept a list of valid success responses rather than just one as it

> > does at present.

>

> So expected_success() is just a better way of doing something like:

>

> assert.Equals(resp.status, 200)

>

> There isn't anything specific about the images clients with it.

> validate_response() should just call expected_success(), which I pushed
out

> here:

> https://review.openstack.org/93035



There can be possibility to have multiple success return code (Nova Server
Ext events API return 200 & 207 as success code). Currently there is no
such API schema but we need to consider this case. In validate_response(),
it was handled and we should expand the expected_success() also for the
same. I have put this in review comment also.



>

>

> >

> > I hope we can get agreement to move response checking to the client.

> > There was no opposition when we started doing this in nova to check

> > schema. Does any one see a reason to not do this? It would both

> > simplify the code and make sure responses are checked in all cases.

> >

> > Sean, do you have a concrete example of what you are concerned about

> > here? Moving the check from the value returned by a client call to

> > inside the client code should not have any visible effect unless the

> > value was actually wrong but not checked by the caller. But this would

> > be a bug that was just found if a test started failing.

> >

>

> Please draft a spec/bp for doing this, we can sort out the implementation

> details in the spec review. There is definitely some overlap with the

> jsonschema work though so we need to think about how to best integrate

> the 2 efforts. For example, for projects that don't use jsonschema yet
does it

> make sense to start using jsonschema files like we do for nova tests to
veriy

> the status codes. Just so we can have a common path for doing this. I
think

> there may be value in doing it that way. We can discuss it more during the

> jsonschema summit session.

>

>

> -Matt Treinish



-- 
Thanks & Regards
Ghanshyam Mann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] custom gerrit dashboard - per project review inbox zero

[GHANSHYAM MANN]

Hi Sean,

That’s pretty cool and helpful. Thanks for providing this.

> > -Original Message-
> > From: Sean Dague [mailto:s...@dague.net]
> > Sent: Friday, May 9, 2014 9:21 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: [openstack-dev] [all] custom gerrit dashboard - per project
> review
> > inbox zero
> >
> > Based on some of my blog posts on gerrit queries, I've built and gotten
> > integrated a custom inbox zero dashboard which is per project in gerrit.
> >
> > ex:
> > https://review.openstack.org/#/projects/openstack/nova,dashboards/impo
>
> <https://review.openstack.org/#/projects/openstack/nova,dashboards/important-changes:review-inbox-dashboard>>
> rtant-changes:review-inbox-dashboard
>
> <https://review.openstack.org/#/projects/openstack/nova,dashboards/important-changes:review-inbox-dashboard>
> >
> > (replace openstack/nova with the project of your choice).
> >
> > This provides 3 sections.
> >
> > = Needs Final +2 =
> >
> > This is code that has an existing +2, no negative code review feedback,
> and
> > positive jenkins score. So it's mergable if you provide the final +2.
> >
> > (Gerrit Query: status:open NOT label:Code-Review>=0,self
> > label:Verified>=1,jenkins NOT label:Code-Review<=-1 label:Code-Review>=2
> > NOT label:Workflow<=-1 limit:50 )
> >
> > = No negative feedback =
> >
> > Changes that have no negative code review feedback, and positive jenkins
> > score.
> >
> > (Gerrit Query: status:open NOT label:Code-Review>=0,self
> > label:Verified>=1,jenkins NOT label:Code-Review<=-1 NOT
> > label:Workflow<=-1 limit:50 )
> >
> > = Wayward changes =
> >
> > Changes that have no code review feedback at all (no one has looked at
> it), a
> > positive jenkins score, and are older than 2 days.
> >
> > (Gerrit Query: status:open label:Verified>=1,jenkins NOT
> > label:Workflow<=-1 NOT label:Code-Review<=2 age:2d)
> >
> >
> > In all cases it filters out patches that you've commented on in the most
> > recently revision. So as you vote on these things they will disappear
> from
> > your list.
> >
> > Hopefully people will find this dashboard also useful.
> >
> > -Sean
> >
> > --
> > Sean Dague
> > http://dague.net


-- 
Thanks & Regards
Ghanshyam Mann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa][nova] Status of v3 tests in tempest

[GHANSHYAM MANN]

I also agree that instead of removing the old test, we keep changing those
as microversion gets changed.
One suggestion (may be same as what Chris is thinking)-
-Tempest can keep the common test directory containing tests which are
going to be same as microversion bump up. Initially all test can go to
common directory and keep filtering the variant tests as microversion
progress.
-As microversion gets changed, tempest will override the tests for those
API which are being changed and will run the other common tests also for
this Test version.
For example-
[image: Inline image 1]



-- 
Thanks
Ghanshyam Mann

On Mon, May 19, 2014 at 9:39 PM, Christopher Yeoh  wrote:

> On Mon, May 19, 2014 at 9:12 PM, David Kranz  wrote:
>
>>  On 05/19/2014 01:24 PM, Frittoli, Andrea (HP Cloud) wrote:
>>
>> Thanks for bringing this up.
>>
>> We won't be testing v3 in Juno, but we'll need coverage for v2.1.
>>
>> In my understanding will be a v2 compatible API - so including proxy to
>> glance cinder and neutron - but with micro-versions to bring in v3 features
>> such as CamelCase and Tasks.
>> So we should be able to reuse a good chunk of the v3 test code for testing
>> v2.1. Adding some config options for the v2.1 to v3 differences we could try
>> and use the same tests for icehouse v3 and juno v2.1.
>>
>>  While it is true that we may reuse some of the actual test code
>> currently in v3, the overall code structure for micro-versions will be
>> much different than for a parallel v2/v3. I wanted to make sure every
>> one  on the qa list knows that v3 is being scrapped and that we should stop
>> making changes that are intended only to enhance the maintainability of an
>> active v2/v3 scenario.
>>
>
>
> So I think we need to distinguish between "v3 being scrapped" and "v3
> features being scrapped". I think its likely that most of the v3
> cleanups/features will end up being exposed via client microversions (its
> what I sort of asked about near the end of the session). And by removing
> the tests we will inevitably end up with regressions which we don't want to
> happen.
>
> I think its pretty important we sort out the microversion design on the
> Nova side pretty quickly and we could adapt the existing v3 tempest tests
> to instead respond with a very high version microversion number. As we roll
> out new features or accept v3 changes in Nova with microversions,
> individual tests can then be changed to respond to the lower microversion
> numbers. That way we keep existing regression tests so we don't regress on
> the Nova side and don't need to rewrite them at a later date for tempest.
> Depending on how the client microversion design works this might make code
> duplication issues on the tempest side easier to handle - though we're
> going to need a pretty generic solution to support API testing of
> potentially quite a few versions of individual APIs as depending on the
> microversion.  Every time we bump the microversion we essentially just add
> a new version to be tested, we don't replace the old one.
>
> There is one big implication for tempest regarding micoversions for Nova -
> scenario testing. With microversions we need to support testing for quite a
> few versions of slightly different APIs rather than just say 2. And there's
> some potential for quite a few different combinations especially if other
> projects go the microversion route as well.
>
>
>
>> With regard to icehouse, my understanding is that we are basically
>> deprecating v3 as an api before it was ever declared stable. Should we
>> continue to carry technical debt in tempest to support testing the unstable
>> v3 in icehouse? Another alternative, if we really want to continue testing
>> v3 on icehouse but want to remove v3 from tempest, would be to create a
>> stable/icehouse branch in tempest and run that against changes to
>> stable/icehouse in projects in addition to running tempest master.
>>
>>  -David
>>
>>  We may have to implement support for micro-versions in tempests own rest
>> client as well.
>>
>> andrea
>>
>>
>> -Original Message-
>> From: David Kranz [mailto:dkr...@redhat.com ]
>> Sent: 19 May 2014 10:49
>> To: OpenStack Development Mailing List
>> Subject: [openstack-dev] [qa][nova] Status of v3 tests in tempest
>>
>> It seems the nova team decided in Atlanta that "v3" as currently understood
>> is never going to exist:https://etherpad.openstack.org/p/juno-nova-v3-api.
>>
>> There are a number of patches in flight that tweak how we handle supporti

Re: [openstack-dev] [qa][nova] Status of v3 tests in tempest

[GHANSHYAM MANN]

I agree to continue work on  bp/ nova-api-test-inheritance. As its reduce
the duplication code and later will help to remove the V2 tests easily.
V2.1 tests can be written on same design of inheritance.

-- 
Thanks
Ghanshyam Mann

On Mon, May 19, 2014 at 9:32 PM, Kenichi Oomichi
wrote:

> Hi David,
>
> > -Original Message-
> > From: David Kranz [mailto:dkr...@redhat.com]
> > Sent: Monday, May 19, 2014 6:49 PM
> > To: OpenStack Development Mailing List
> > Subject: [openstack-dev] [qa][nova] Status of v3 tests in tempest
> >
> > It seems the nova team decided in Atlanta that "v3" as currently
> > understood is never going to exist:
> > https://etherpad.openstack.org/p/juno-nova-v3-api.
> >
> > There are a number of patches in flight that tweak how we handle
> > supporting both v2/v3 in tempest to reduce duplication.
> > We need to decide what to do about this. At a minimum, I think we should
> > stop any work that is inspired by any v3-related activity
> > except to revert any v2/v3 integration that was already done. We should
> > really rip out the v3 stuff that was recently added. I know Matt had
> > some concern about that regarding testing v3 in stable/icehouse but
> > perhaps he can say more.
>
> I agree to stop new Nova v3 tests and disable Nova v3 tests in
> the gate for icehouse.
> and I hope we continue working for reducing duplication between
> Nova v2/v3 tests on bp/ nova-api-test-inheritance. Because it
> would be nice for v2.1 API tests also for avoiding duplication
> between v2/v2.1 tests also.
>
>
> Thanks
> Ken'ichi Ohmichi
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [qa] Issue in Tempest API's tests when running with nosetest command?

[GHANSHYAM MANN]

Tempest API’s XML test will run with 1 test failure when run with Nosetest.
When we run the tempest with nosetest command (ex -nosetest –v
./tempest/api/compute/test_xyz.py), it run *BaseComputeTest
::create_test_server & create_test_server_group *functions also as test
with any of the API tests. Because nose looks for tests in directories and
modules whose names start with *test* and *Test*, or contain a '_', '.',
or '-' followed by test or Test.



So for each API XML test, failure will happen in  create_test_server_group
function as  it’s XML client is not implemented (as expected).



To fix/stop these kind of issue, one solution is to have some policy for
Tempest not to name non test function with test_, Test_ etc so that nose
would not consider those as test case.



Looking forward to have more opinions on this.


-- 
Thanks
Ghanshyam Mann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] Issue in Tempest API's tests when running with nosetest command?

[GHANSHYAM MANN]

Yes, Issue is in nose. I do not like nose due to these kind of assumption
for test running :). There is no reason of using nose, I just ran that and
counter this issue.

I totally agree on your point not to spent time to fix these kind of issue.
As you mentioned. may be blocking nose would be good idea.

On Fri, May 23, 2014 at 11:12 AM, Matthew Treinish wrote:

> On Fri, May 23, 2014 at 09:34:35AM +0900, GHANSHYAM MANN wrote:
> > Tempest API’s XML test will run with 1 test failure when run with
> Nosetest.
> > When we run the tempest with nosetest command (ex -nosetest –v
> > ./tempest/api/compute/test_xyz.py), it run *BaseComputeTest
> > ::create_test_server & create_test_server_group *functions also as test
> > with any of the API tests. Because nose looks for tests in directories
> and
> > modules whose names start with *test* and *Test*, or contain a '_', '.',
> > or '-' followed by test or Test.
>
> So this is part of the many reasons we don't support or advise running
> tempest
> with nosetests. I brought this up a few months ago when I tried to be a bit
> more aggressive about this and block nose from being run at all. [1] Is
> there
> any particular reason you are still trying to run Tempest with nosetests?
>
> >
> >
> >
> > So for each API XML test, failure will happen in
>  create_test_server_group
> > function as  it’s XML client is not implemented (as expected).
> >
> >
> >
> > To fix/stop these kind of issue, one solution is to have some policy for
> > Tempest not to name non test function with test_, Test_ etc so that nose
> > would not consider those as test case.
>
> So trying to accommodate nose especially on this isn't going to happen. The
> python docs clearly state test_* named methods are what should be used so
> that
> the test driver recognizes them as tests. Nose is what is being overzealous
> and causing issues; the bug is in nose not tempest. I think this suggested
> patch
> or something similar has been pushed at least twice already. The problem
> is even
> after making this change large chunks of tempest still won't work because
> of
> other things with nose. (like testscenarios) It's really not worth the
> review
> effort to merge a change like this. We've been actually moving in the other
> direction too and removed all the in tree references and workarounds
> related to
> nose during Icehouse.
>
> For a project of tempest's size and growth rate trying to workaround all
> the
> quirks of every test runner isn't really feasible especially because we're
> not
> running with anything but testr in the gate. That being said I think nose
> might
> be a slightly special case in that I know it doesn't work for several
> reasons.
> (only because it used to be the default) Other test runners probably
> wouldn't
> have nearly as many issues, if any at all.
>
> >
> >
> >
> > Looking forward to have more opinions on this.
> >
> >
>
>
> -Matt Treinish
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2014-January/024673.html
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks & Regards
Ghanshyam Mann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] Meaning of 204 from DELETE apis

[GHANSHYAM MANN]

On Fri, Jun 13, 2014 at 8:42 AM, Christopher Yeoh  wrote:

> On Fri, Jun 13, 2014 at 7:05 AM, David Kranz  wrote:
>
>> On 06/12/2014 05:27 PM, Jay Pipes wrote:
>>
>>> On 06/12/2014 05:17 PM, David Kranz wrote:
>>>
>>>> Tempest has a number of tests in various services for deleting objects
>>>> that mostly return 204. Many, but not all, of these tests go on to check
>>>> that the resource was actually deleted but do so in different ways.
>>>> Sometimes they go into a timeout loop waiting for a GET on the object to
>>>> fail. Sometimes they immediately call DELETE again or GET and assert
>>>> that it fails. According to what I can see about the HTTP "spec", 204
>>>> should mean that the object was deleted. So is waiting for something to
>>>> disappear unnecessary? Is immediate assertion wrong? Does this behavior
>>>> vary service to service? We should be as consistent about this as
>>>> possible but I am not sure what the expected behavior of all services
>>>> actually is.
>>>>
>>>
>>> The main problem I've seen is that while the resource is deleted, it
>>> stays in a deleting state for some time, and quotas don't get adjusted
>>> until the server is finally set to a terminated status.
>>>
>> So you are talking about nova here. In tempest I think we need to more
>> clearly distinguish when delete is being called to test the delete api vs.
>> as part of some cleanup. There was an irc discussion related to this
>> recently.  The question is, if I do a delete and get a 204, can I expect
>> that immediately doing another delete or get will fail? And that question
>> needs an answer for each api that has delete in order to have proper tests
>> for delete.
>>
>
> So if the deletion does not occur before the call returns the API should
> be returning 202 rather than 204. The tasks API should help clarify things
> here as a task handle will be returned for long running things and you can
> query progress rather than polling by listing objects etc.
>
> Chris
>
> I was also going through the testing of delete operation in tempest and
there is not much consistency.
If *strictly* testing, we should not have any wait for 204 response. If any
operation still in progress and return 204 then its a false return  and
tempest should be able to catch those as it can break user app also.
Tempest should report fail so that specific project can fix that operation
or return code (exception in case of backward compatibility).

Ghanhsyam Mann

> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks & Regards
Ghanshyam Mann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] [All] API standards working group

[GHANSHYAM MANN]

I am very much interested to be part of this group and participate in
RESTful API design and architecture.

On Wed, Sep 24, 2014 at 7:18 AM, Jay Pipes  wrote:

> On 09/23/2014 05:03 PM, Rochelle.RochelleGrober wrote:
>
>> jaypi...@gmail.com <mailto:jaypi...@gmail.com> on Tuesday, September 23,
>> 2014 9:09 AM wrote:
>>
>> _Snip
>>
>> I'd like to say finally that I think there should be an OpenStack API
>>
>> working group whose job it is to both pull together a set of OpenStack
>>
>> API practices as well as evaluate new REST APIs proposed in the
>>
>> OpenStack ecosystem to provide guidance to new projects or new
>>
>> subprojects wishing to add resources to an existing REST API.
>>
>> Best,
>>
>> -jay
>>
>> */[Rocky Grober] /*++
>>
>> */Jay, are you volunteering to head up the working group? Or at least be
>> an active member?  I’ll certainly follow with interest, but I think I
>> have my hands full with the log rationalization working group./*
>>
>
> Yes, I'd be willing to head up the working group... or at least
> participate in it.
>
> Best,
> -jay
>
> _______
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks & Regards
Ghanshyam Mann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[GHANSHYAM MANN]

gt;>
>> But when i am running individual tests in "test_volumes_snapshots",all
>> tests are getting passed.
>>
>> 2)
>> ./run_tempest.sh
>> tempest.api.volume.test_volumes_actions.VolumesV2ActionsTest.test_volume_upload:
>> This is also getting failed.
>>
>>
>>
>> Regards
>> Nikesh
>>
>> On Mon, Sep 22, 2014 at 4:12 PM, Ken'ichi Ohmichi 
>> wrote:
>>
>>> Hi Nikesh,
>>>
>>> > -Original Message-
>>> > From: Nikesh Kumar Mahalka [mailto:nikeshmaha...@vedams.com]
>>> > Sent: Saturday, September 20, 2014 9:49 PM
>>> > To: openst...@lists.openstack.org; OpenStack Development Mailing List
>>> (not for usage questions)
>>> > Subject: Re: [Openstack] No one replying on tempest issue?Please share
>>> your experience
>>> >
>>> > Still i didnot get any reply.
>>>
>>> Jay has already replied to this mail, please check the nova-compute
>>> and cinder-volume log as he said[1].
>>>
>>> [1]:
>>> http://lists.openstack.org/pipermail/openstack-dev/2014-September/046147.html
>>>
>>> > Now i ran below command:
>>> > ./run_tempest.sh
>>> tempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_volume_from_snapshot
>>> >
>>> > and i am getting test failed.
>>> >
>>> >
>>> > Actually,after analyzing tempest.log,i found that:
>>> > during creation of a volume from snapshot,tearDownClass is called and
>>> it is deleting snapshot bfore creation of volume
>>> > and my test is getting failed.
>>>
>>> I guess the failure you mentioned at the above is:
>>>
>>> 2014-09-20 00:42:12.519 10684 INFO tempest.common.rest_client
>>> [req-d4dccdcd-bbfa-4ddf-acd8-5a7dcd5b15db None] Request
>>> (VolumesSnapshotTest:tearDownClass): 404 GET
>>>
>>> http://192.168.2.153:8776/v1/ff110b66c98d455092c6f2a2577b4c80/snapshots/71d3cad4-440d-4fbb-8758-76da17b6ace6
>>> 0.029s
>>>
>>> and
>>>
>>> 2014-09-20 00:42:22.511 10684 INFO tempest.common.rest_client
>>> [req-520a54ad-7e0a-44ba-95c0-17f4657bc3b0 None] Request
>>> (VolumesSnapshotTest:tearDownClass): 404 GET
>>>
>>> http://192.168.2.153:8776/v1/ff110b66c98d455092c6f2a2577b4c80/volumes/7469271a-d2a7-4ee6-b54a-cd0bf767be6b
>>> 0.034s
>>>
>>> right?
>>> If so, that is not a problem.
>>> VolumesSnapshotTest creates two volumes, and the tearDownClass checks
>>> these
>>> volumes deletions by getting volume status until 404(NotFound) [2].
>>>
>>> [2]:
>>> https://github.com/openstack/tempest/blob/master/tempest/api/volume/base.py#L128
>>>
>>> > I deployed a juno devstack setup for a cinder volume driver.
>>> > I changed cinder.conf file and tempest.conf file for single backend
>>> and restarted cinder services.
>>> > Now i ran tempest test as below:
>>> > /opt/stack/tempest/run_tempest.sh
>>> tempest.api.volume.test_volumes_snapshots
>>> >
>>> > I am getting below output:
>>> >  Traceback (most recent call last):
>>> >   File
>>> "/opt/stack/tempest/tempest/api/volume/test_volumes_snapshots.py", line
>>> 176, in test_volume_from_snapshot
>>> > snapshot = self.create_snapshot(self.volume_origin['id'])
>>> >   File "/opt/stack/tempest/tempest/api/volume/base.py", line 112, in
>>> create_snapshot
>>> > 'available')
>>> >   File
>>> "/opt/stack/tempest/tempest/services/volume/json/snapshots_client.py", line
>>> 126, in wait_for_snapshot_status
>>> > value = self._get_snapshot_status(snapshot_id)
>>> >   File
>>> "/opt/stack/tempest/tempest/services/volume/json/snapshots_client.py", line
>>> 99, in _get_snapshot_status
>>> > snapshot_id=snapshot_id)
>>> > SnapshotBuildErrorException: Snapshot
>>> 6b1eb319-33ef-4357-987a-58eb15549520 failed to build and is in
>>> > ERROR status
>>>
>>> What happens if running the same operation as Tempest by hands on your
>>> environment like the following ?
>>>
>>> [1] $ cinder create 1
>>> [2] $ cinder snapshot-create 
>>> [3] $ cinder create --snapshot-id  1
>>> [4] $ cinder show 
>>>
>>> Please check whether the status of created volume at [3] is "available"
>>> or not.
>>>
>>> Thanks
>>> Ken'ichi Ohmichi
>>>
>>> ___
>>> Mailing list:
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>> Post to : openst...@lists.openstack.org
>>> Unsubscribe :
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks & Regards
Ghanshyam Mann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[GHANSHYAM MANN]

On Wed, Oct 15, 2014 at 7:44 AM, Christopher Yeoh  wrote:

> On Tue, 14 Oct 2014 09:45:44 -0400
> Jay Pipes  wrote:
>
> > On 10/14/2014 12:52 AM, Christopher Yeoh wrote:
> > > On Mon, 13 Oct 2014 22:20:32 -0400
> > > Jay Pipes  wrote:
> > >
> > >> On 10/13/2014 07:11 PM, Christopher Yeoh wrote:
> > >>> On Mon, 13 Oct 2014 10:52:26 -0400
> > > And whilst I don't have a problem with having some guidelines which
> > > suggest a future standard for APIs, I don't think we should be
> > > requiring any type of feature which has not yet been implemented in
> > > at least one, preferably two openstack projects and released and
> > > tested for a cycle. Eg standards should be lagging rather than
> > > leading.
> >
> > What about "features" in some of our APIs that are *not* preferable?
> > For instance: API extensions.
> >
> > I think we've seen where API extensions leads us. And it isn't
> > pretty. Would you suggest we document what a Nova API extension or a
> > Neutron API extension looks like and then propose, for instance, not
> > to ever do it again in future APIs and instead use schema
> > discoverability?
>
> So if we had standards leading development rather than lagging in the
> past then API extensions would have ended up in the standard because we
> once thought they were a good idea.
>
> Perhaps we should distinguish in the documentation between
> recommendations (future looking) and standards (proven it works well
> for us). The latter would be potentially enforced a lot more strictly
> than the former.
>

That will be great to have classification in guidelines (Strict
, recommended etc ) and step by step those can be moved to higher
classification as project start consuming those.


> In the case of extensions I think we should have a section documenting
> why we think they're a bad idea and new projects certainly shouldn't
> use them. But also give some advice around if they are used what
> features they should have (eg version numbers!). Given the time that it
> takes to make major API infrastructure changes it is inevitable that
> there will be api extensions added in the short to medium term. Because
> API development will not just stop while API infrastructure is improved.
>
> > > I think it will be better in git (but we also need it in gerrit)
> > > when it comes to resolving conflicts and after we've established a
> > > decent document (eg when we have more content). I'm just looking to
> > > make it as easy as possible for anyone to add any guidelines now.
> > > Once we've actually got something to discuss then we use git/gerrit
> > > with patches proposed to resolve conflicts within the document.
> >
> > Of course it would be in Gerrit. I just put it up on GitHub first
> > because I can't just add a repo into the openstack/ code
> > namespace... :)
>
> I've submitted a patch to add an api-wg project using your repository
> as the initial content for the git repository.
>
> https://review.openstack.org/#/c/128466/
>
> Regards,
>
> Chris
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks & Regards
Ghanshyam Mann
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[GHANSHYAM MANN]

I am not core but Big +1 for Alex. It will be great to have him in nova core.

Thanks
ghanshyam

On Sat, Nov 7, 2015 at 12:32 AM, John Garbutt  wrote:
> Hi,
>
> I propose we add Alex Xu[1] to nova-core.
>
> Over the last few cycles he has consistently been doing great work,
> including some quality reviews, particularly around the API.
>
> Please respond with comments, +1s, or objections within one week.
>
> Many thanks,
> John
>
> [1]http://stackalytics.com/?module=nova-group&user_id=xuhj&release=all
>
> __
> 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



-- 
Regards
Ghanshyam Mann
+81-8084200646

__
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] [ironic][tempest]Tempest test plugin and microversions

[GHANSHYAM MANN]

Hi,

Yea, IMO also we can merge Ironic patch in Tempest first but do not
have much strong opinion. Ironic patch can be updated on top of
microversion testing framework base patch [1] and we can test that
while residing in Tempest which avoid updates in Ironic repo (if move
Ironic tests first) if anything needs to be updated.

For testing or sample we are going to implement Nova 2.2 version
tests[2]. On the same line Ironic one can be updated.

[1] https://review.openstack.org/#/c/242296/
[2] https://review.openstack.org/#/c/244996/

Thanks
Ghanshyam

On Thu, Nov 19, 2015 at 8:48 AM, Ken'ichi Ohmichi  wrote:
> Hi,
>
> Nice description for our situation.
> Yes, qa-spec of microversions testing is already approved.
> But as you said, we need time for the implementation.
>
> Your migration patch for ironic doesn't seem hard to be merged, I feel. So
> it is also nice option to merge the migration patch first.
> Technically, the microversions testing framework will be merged into
> tempest-lib at early stage, and we can share it on many projects.
>
> Thanks
>
>
> 2015年11月18日(水) 午後6:54 Yuiko Takada :
>>
>> Hi Ironic folks,
>>
>> As we discussed in Design Summit, we will move forward with tempest test
>> tasks.
>> I've posted a patch for tempest test plugin interface [1]
>> (Now it fails because of flake8-ignore-difference, anyway).
>>
>> Then, I'd like to discuss about our tests migration procedure.
>> As you know, we are also working for Tempest microversions, so
>> our tests in Tempest need to be fixed for working with microversions.
>> Its spec has been approved and now microversion testing frame work has
>> been posted [2].
>> IMO, tests in Tempest should be fixed before moving into Ironic tree,
>> but maybe [2] will take long time to be merged.
>> What do you think?
>>
>> [1] https://review.openstack.org/#/c/246161/
>> [2] https://review.openstack.org/#/c/242346/
>>
>>
>> Best Regards,
>> Yuiko Takada
>> __
>> 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
>



-- 
Regards
Ghanshyam Mann
+81-8084200646

__
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] Fwd: [QA] Meeting Thursday December 10th at 9:00 UTC

[GHANSHYAM MANN]

Hi everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, November 26th at 9:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_December_10th_2015_.280900_UTC.29

 Anyone is welcome to add an item to the agenda.

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

04:00 EST

18:00 JST

18:30 ACST

11:00 CEST

04:00 CDT

02:00 PDT


-- 
Regards
Ghanshyam Mann
+81-8084200646

__
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 pre-provisioned credentials in the gate

[Ghanshyam Mann]

Big +1 for that which makes pre-provisioned cred testing more thoroughly.

And at the end we should divide the existing jobs among dynamic and 
pre-provisioned account so that we would not leave any of them less tested.

Thanks
gmann
From: Andrea Frittoli [mailto:andrea.fritt...@gmail.com]
Sent: 15 June 2016 09:01
To: OpenStack Development Mailing List (not for usage questions) 

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

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.

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].

Andrea Frittoli

[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

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

[GHANSHYAM MANN]

On Wed, Jun 15, 2016 at 6:12 AM, Matthew Treinish  wrote:
> On Tue, Jun 14, 2016 at 12:19:54PM -0700, Chris Hoge wrote:
>>
>> > On Jun 14, 2016, at 11:21 AM, Matthew Treinish  
>> > wrote:
>> >
>> > 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.**
>>
>> Yes, it’s bad practice, but it’s also a reality, and I honestly believe that
>> vendors have received the message and are working on changing.
>
> They might be working on this, but this change was coming for quite some
> time it shouldn't be a surprise to anyone at this point. I mean seriously, 
> it's
> been in tempest for 1 year, and it took 6months to land. Also, lets say we set
> a hard deadline on this new option to disable the enforcement and enforce it.
> Then we implement a similar change on keystone are we gonna have to do the 
> same
> thing again when vendors who have custom things running there fail.
>
>>
>> > As a user of several clouds myself I can say that having random gorp in a
>> > response makes it much more difficult to use my code against multiple 
>> > clouds. I
>> > have to determine which properties being returned are specific to that 
>> > vendor's
>> > cloud and if I actually need to depend on them for anything it makes 
>> > whatever
>> > code I'm writing incompatible for using against any other cloud. (unless I
>> > special case that block for each cloud) Sean Dague wrote a good post where 
>> > a lot
>> > of this was covered a year ago when microversions was starting to pick up 
>> > steam:
>> >
>> > https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2 
>> > 
>> >
>> > I'd recommend giving it a read, he explains the user first perspective more
>> > clearly there.
>> >
>> > I believe Tempest in this case is doing the right thing from an 
>> > interoperability
>> > perspective and ensuring that the API is actually the API. Not an API with 
>> > extra
>> > bits a vendor decided to add.
>>
>> A few points on this, though. Right now, Nova is the only API that is
>> enforcing this, and the clients. While this may change in the
>> future, I don’t think it accurately represents the reality of what’s
>> happening in the ecosystem.
>
> This in itself doesn't make a difference. There is a disparity in the level of
> testing across all the projects. Nova happens to be further along in regards
> to api stability and testing things compared to a lot of projects, it's not
> really a surprise that they're the first for this to come up on. It's only a
> matter of time for other projects to follow nova's example and implement 
> similar
> enforcement.
>
>>
>> As mentioned before, we also need to balance the lagging nature of
>> DefCore as an interoperability guideline with the needs of testing
>> upstream changes. I’m not asking for a permanent change that
>> undermines the goals of Tempest for QA, rather a temporary
>> upstream modification that recognizes the challenges faced by
>> vendors in the market right now, and gives them room to continue
>> to align themselves with ups

[openstack-dev] [QA] Meeting Thursday June 16th at 9:00 UTC

[GHANSHYAM MANN]

Hello everyone,


Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, June 16th at 9:00 UTC in the #openstack-meeting channel.


The agenda for the meeting can be found here:

https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_June_16th_2016_.280900_UTC.29

Anyone is welcome to add an item to the agenda.

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

04:00 EST
18:00 JST
18:30 ACST
11:00 CEST
04:00 CDT
02:00 PDT


Regards
Ghanshyam Mann

__
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] Question about redundant API samples tests for microversions

[Ghanshyam Mann]

> -Original Message-
> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> Sent: 18 June 2016 05:16
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [nova] Question about redundant API samples
> tests for microversions
> 
> I was reviewing this today:
> 
> https://review.openstack.org/#/c/326940/
> 
> And I said to myself, 'self, do we really need to subclass the API samples
> functional tests for this microversion given this change doesn't modify the
> request/response body, it's only adding paging support?'.
> 
> https://review.openstack.org/#/c/326940/6/nova/tests/functional/api_sam
> ple_tests/test_hypervisors.py
> 
> The only change here is listing hypervisors, and being able to page on those 
> if
> the microversion is high enough. So the API samples don't change at all, they
> are just running against a different microversion.
> 
> The same goes for the REST API unit tests really:
> 
> https://review.openstack.org/#/c/326940/6/nova/tests/unit/api/openstack/
> compute/test_hypervisors.py
> 
> I'm not sure if the test subclassing is just done like this for new 
> microversions
> because it's convenient or if it's because of regression testing - knowing 
> that
> we aren't changing a bunch of other REST methods in the process, so the
> subclassed tests aren't testing anything different from the microversion that
> came before them.
> 
> The thing I don't like about the test subclassing is all of the redundant 
> testing
> that goes on, and people might add tests to the parent class not realizing 
> it's
> subclassed and thus duplicating test cases with no functional change.
> 
> Am I just having some Friday crazies? Ultimately this doesn't hurt anything
> really but thought I'd ask.

Yes, we should not run redundant test case till we are trying to test the 
regression in previous microversion or really testing the changes does not 
reflect in previous version or something.
In this case, we should not run the normal hypervisor tests(present in 
HypervisorsSampleJsonTests) for this new microversion tests (as those does not 
give real benefit), if we want to tests the pagination in functional tests then 
it should be separate specific tests. But if we want to tests paging in 
functional tests, I wonder we end up with having duplicate sample template and 
sample files. 
Otherwise I too like to tests those bits in unit tests and then in Tempest 
(volume pagination tests are well implemented [1]).

Tempest has taken care the redundant tests run by mentioning the 
max_microversion in existing parent test class [2] which make sure tests gets 
executed once in case of subclass too. Or other way is not to subclass 
microversion tests class and let is implement and run its own specific tests 
[3]. Those can be implemented case by case. 

1 .. 
https://github.com/openstack/tempest/blob/master/tempest/api/volume/v2/test_volumes_list.py#L184-L193
 

2 .. 
https://github.com/openstack/tempest/blob/master/tempest/api/compute/keypairs/test_keypairs.py#L22
 

3 .. 
https://github.com/openstack/tempest/blob/master/tempest/api/compute/admin/test_keypairs_v210.py
 

> 
> --
> 
> 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

Thanks
Ghanshyam Mann

__
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 June 30th at 9:00 UTC

[Ghanshyam Mann]

Hello everyone,



Please reminder that the weekly OpenStack QA team IRC meeting will be Thursday, 
June 30th at 9:00 UTC in the #openstack-meeting channel.



The agenda for the meeting can be found here:

https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_June_30th_2016_.280900_UTC.29

Anyone is welcome to add an item to the agenda.



Sorry for delay in mail.



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



04:00 EST

18:00 JST

18:30 ACST

11:00 CEST

04:00 CDT

02:00 PDT


Thanks & Regards,
Ghanshyam Mann

__
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][cinder] Fix nova swap volume (updating an attached volume) function

[GHANSHYAM MANN]

On Thu, Mar 31, 2016 at 10:39 AM, Matt Riedemann
 wrote:
>
>
> On 3/30/2016 8:20 PM, Matt Riedemann wrote:
>>
>>
>>
>> On 3/30/2016 7:56 PM, Matt Riedemann wrote:
>>>
>>>
>>>
>>> On 3/30/2016 7:38 PM, Matt Riedemann wrote:



 On 2/25/2016 5:31 AM, Takashi Natsume wrote:
>
> Hi Nova and Cinder developers.
>
> As I reported in a bug report [1], nova swap volume
> (updating an attached volume) fuction does not work
> in the case of non admin users by default.
> (Volumes are stuck.)
>
> Before I was working for fixing another swap volume bug [2][3].
> But Ryan fixed it on the Cinder side [4].
> As a result, admin users can execute swap volume function,
> but it was not fixed in the case of non admin users.
> So I reported the bug report [1].
>
> In the patch[5], I tried to change the default cinder's policy
> to allow non admin users to execute migrate_volume_completion API.
> But it was rejected by the cinder project ('-2' was voted).
>
> In the patch[5], it was suggested to make the swap volume API admin
> only
> on the Nova side.
> But IMO, the swap volume function should be allowed to non admin users
> because attaching a volume and detaching a volume can be performed
> by non admin users.


 I agree with this. DuncanT said in IRC that he didn't think non-admin
 users should be using the swap-volume API in nova because it can be
 problematic, but I'm not sure why, is there more history or detail
 there? I'd think it shouldn't be any worse than doing a detach/attach in
 quick succession (like in a CI test for example).

>
> If migrate_volume_completion is only allowed to admin users
> by default on the Cinder side, attaching a new volume and
> detaching an old volume should be performed on the Nova side
> when swapping volumes.


 My understanding of the problem is as follows:

 1. Admin-initiated volume migration in Cinder calls off to Nova to
 perform the swap-volume, and then Nova calls back to Cinder's
 migrate_volume_completion API. This is fine since it's an admin that
 initiated this series of operations on the Cinder side (that's by
 default, however, this is broken if the policy file for Cinder is change
 to allow non-admins to migrate volumes).

 2. A non-admin swap-volume API call in Nova fails because Nova blindly
 makes the migrate_volume_completion call to Cinder which fails with a
 403 because the Cinder API policy has that as an admin action by
 default.

 I don't know the history around when the swap-volume API was added to
 Nova, was it specifically for this volume migration scenario in Cinder?
   Are there other use cases?  Knowing those would be good to determine
 if Nova should change it's default policy for swap-volume, although,
 again, that's only a default and can be changed per deployment so we
 probably shouldn't rely on it.

 Ideally we would have implemented this like the nova/neutron server
 events callback API in Nova during vif plugging (nova does the vif plug
 on the host then waits for neutron to update it's database for the port
 status and sends an event (API call) to nova to continue booting the
 server). That server events API in nova is admin-only by default and
 neutron is configured with admin credentials for nova to use it.

 Another option would be for Nova to handle a 403 response when calling
 Cinder's migrate_volume_completion API and ignore it if we don't have an
 admin context. This is pretty hacky though. It assumes that it's a
 non-admin user initiating the swap-volume operation. It wouldn't be a
 problem for the volume migration operation initiated in Cinder since by
 default that's admin-only, so nova shouldn't get a 403 when calling
 migrate_volume_completion. The trap would be if the cinder policy for
 volume migration was changed to allow non-admins, but if someone did
 that, they should also change the policy for migrate_volume_completion
 to allow non-admin too.

>
> If you have a good idea, please let me know it.
>
> [1] Cinder volumes are stuck when non admin user executes nova swap
> volume API
>  https://bugs.launchpad.net/cinder/+bug/1522705
>
> [2] Cinder volume stuck in swap_volume
>  https://bugs.launchpad.net/nova/+bug/1471098
>
> [3] Fix cinder volume stuck in swap_volume
>  https://review.openstack.org/#/c/207385/
>
> [4] Fix swap_volume for case without migration
>  https://review.openstack.org/#/c/247767/
>
> [5] Enable volume owners to execute migrate_volume_completion
>  https://review.openstack.org/#/c/253363/
>
> Regards,
> Takashi Natsume
> NTT Software Innovation Center
> E-mail: natsume.taka...@lab.

Re: [openstack-dev] [nova][cinder] Fix nova swap volume (updating an attached volume) function

[GHANSHYAM MANN]

This [1] adds tests for swap volume with admin and non-admin case. I
want to check behaviour with current code so not adding Depends-On on
your fix.
Once we have gate results then feel free to add Depends-On or I will add.

I think virt driver does not do attach/detach but we can re-verify
that on tempest patch.

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


On Thu, Mar 31, 2016 at 11:29 AM, Matt Riedemann
 wrote:
>
>
> On 3/30/2016 9:14 PM, GHANSHYAM MANN wrote:
>>
>> On Thu, Mar 31, 2016 at 10:39 AM, Matt Riedemann
>>  wrote:
>>>
>>>
>>>
>>> On 3/30/2016 8:20 PM, Matt Riedemann wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On 3/30/2016 7:56 PM, Matt Riedemann wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 3/30/2016 7:38 PM, Matt Riedemann wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2/25/2016 5:31 AM, Takashi Natsume wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi Nova and Cinder developers.
>>>>>>>
>>>>>>> As I reported in a bug report [1], nova swap volume
>>>>>>> (updating an attached volume) fuction does not work
>>>>>>> in the case of non admin users by default.
>>>>>>> (Volumes are stuck.)
>>>>>>>
>>>>>>> Before I was working for fixing another swap volume bug [2][3].
>>>>>>> But Ryan fixed it on the Cinder side [4].
>>>>>>> As a result, admin users can execute swap volume function,
>>>>>>> but it was not fixed in the case of non admin users.
>>>>>>> So I reported the bug report [1].
>>>>>>>
>>>>>>> In the patch[5], I tried to change the default cinder's policy
>>>>>>> to allow non admin users to execute migrate_volume_completion API.
>>>>>>> But it was rejected by the cinder project ('-2' was voted).
>>>>>>>
>>>>>>> In the patch[5], it was suggested to make the swap volume API admin
>>>>>>> only
>>>>>>> on the Nova side.
>>>>>>> But IMO, the swap volume function should be allowed to non admin
>>>>>>> users
>>>>>>> because attaching a volume and detaching a volume can be performed
>>>>>>> by non admin users.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I agree with this. DuncanT said in IRC that he didn't think non-admin
>>>>>> users should be using the swap-volume API in nova because it can be
>>>>>> problematic, but I'm not sure why, is there more history or detail
>>>>>> there? I'd think it shouldn't be any worse than doing a detach/attach
>>>>>> in
>>>>>> quick succession (like in a CI test for example).
>>>>>>
>>>>>>>
>>>>>>> If migrate_volume_completion is only allowed to admin users
>>>>>>> by default on the Cinder side, attaching a new volume and
>>>>>>> detaching an old volume should be performed on the Nova side
>>>>>>> when swapping volumes.
>>>>>>
>>>>>>
>>>>>>
>>>>>> My understanding of the problem is as follows:
>>>>>>
>>>>>> 1. Admin-initiated volume migration in Cinder calls off to Nova to
>>>>>> perform the swap-volume, and then Nova calls back to Cinder's
>>>>>> migrate_volume_completion API. This is fine since it's an admin that
>>>>>> initiated this series of operations on the Cinder side (that's by
>>>>>> default, however, this is broken if the policy file for Cinder is
>>>>>> change
>>>>>> to allow non-admins to migrate volumes).
>>>>>>
>>>>>> 2. A non-admin swap-volume API call in Nova fails because Nova blindly
>>>>>> makes the migrate_volume_completion call to Cinder which fails with a
>>>>>> 403 because the Cinder API policy has that as an admin action by
>>>>>> default.
>>>>>>
>>>>>> I don't know the history around when the swap-volume API was added to
>>>>>> Nova, was it specifically for this volume m

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

[GHANSHYAM MANN]

On Thu, Mar 31, 2016 at 4:47 AM, Matthew Treinish  wrote:
> On Wed, Mar 30, 2016 at 03:26:13PM -0400, Sean Dague wrote:
>> During the Nova API meeting we had some conversations about priorities,
>> but this feels like the thing where a mailing list conversation is more
>> inclusive to get agreement on things. I think we need to remain focused
>> on what API related work will have the highest impact on our users.
>> (some brain storming was here -
>> https://etherpad.openstack.org/p/newton-nova-api-ideas). Here is a
>> completely straw man proposal on priorities for the Newton cycle.
>>
>> * Top Priority Items *
>>
>> 1. API Reference docs in RST which include microversions (drivers: me,
>> auggy, annegentle) -
>> https://blueprints.launchpad.net/nova/+spec/api-ref-in-rst
>> 2. Discoverable Policy (drivers: laski, claudio) -
>> https://review.openstack.org/#/c/289405/
>> 3. ?? (TBD)
>>
>> I think realistically 3 priority items is about what we can sustain, and
>> I'd like to keep it there. Item #3 has a couple of options.
>>
>> * Lower Priority Background Work *
>>
>> - POC of Gabbi for additional API validation
>> - Microversion Testing in Tempest (underway)
>
> FWIW, the  framework for using microversions in tempest is done (and is part 
> of
> tempest.lib too) and the BP for that has been marked as implemented:
>
> http://specs.openstack.org/openstack/qa-specs/specs/tempest/implemented/api-microversions-testing-support.html
>
> All that's needed now is to actually start to leverage it by adding tests with
> microversions. IIRC there is only 1 right now, just a pro forma test for v2.2.
> The docs for using it are here:
>
> http://docs.openstack.org/developer/tempest/microversion_testing.html

Yea, now those tests can be implemented along with scenario tests with
other project microversion if available.

Along with version 2.2 tests running in gate, We have 2.10, 2.20 and
2.25 are up for review.

Plan is to cover as much as possible in N which should version most of
schema changes also and
makes tests implementation easy.

Nova functional tests will mostly cover Top, Bottom, change layer of
each microversion
https://blueprints.launchpad.net/nova/+spec/nova-microversion-functional-tests

>
>> - Some of the API WG recommendations
>>
>> * Things we shouldn't do this cycle *
>>
>> - Tasks API - not because it's not a good idea, but because I think
>> until we get ~ 3 core team members agreed that it's their number #1 item
>> for the cycle, it's just not going to get enough energy to go somewhere
>> useful. There are some other things on deck that we just need to clear
>> first.
>> - API wg changes for error codes - we should fix that eventually, but
>> that should come as a single microversion to minimize churn. That's
>> coordination we don't really have the bandwidth for this cycle.
>>
>> * Things we need to decide this cycle *
>>
>> - When are we deleting the legacy v2 code base in tree?
>
> I can get behind doing this. I think we've been running the 2.1 base compat
> as the default for long enough that there aren't gonna be any surprises if
> we drop the old v2 code in Newton.
>
>>
>> * Final priority item *
>>
>> For the #3 priority item one of the things that came up today was the
>> structured errors spec by the API working group. That would be really
>> nice... but in some ways really does need the entire new API reference
>> docs in place. And maybe is better in O.
>>
>> 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
>> ...
>>  }
>> }
>>
>> Effectively an actions map for servers. Lots of details would have to be
>> sorted out on this one, clearly needs a spec, however I think that this
>> would help unstick some other things people would like in Nova, without
>> making our interop story terrible. This would need a driver for this effort.
>>
>> Every thing here is up for discussion. This is a summary of some of what
>> was in the meeting, plus some of my own thoughts. Please chime in on any
>> of this. It would be good to be of general agreement pre summit, so we
>> could focus conversation there more on the hows for getting things done.
>>
>>   -Sean
>>
>> --
>> Sean Dague
>> http://dague.net
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openst

Re: [openstack-dev] FW: Regarding code debug information

[GHANSHYAM MANN]

There are developers doc which can help you to understand particular
component framework and codes.

http://docs.openstack.org/developer/openstack-projects.html

Depends on project you want to deep dive you can check their doc. For
example Nova nova one can be found here -
http://docs.openstack.org/developer/nova/

Regards
Ghanshyam Mann


On Tue, Apr 5, 2016 at 6:49 PM, Shashi Kant
 wrote:
> Dear All,
>
>
>
> I am newbie for openstack development and trying to understand the flow
> using code base.
>
> As the code base is very huge need your support to understand it.
>
> Please let me know if there are any such way to debug the code or analyse
> it.
>
>
>
> Any kind of help will be appreciated.
>
>
>
> Thanks & Regards,
>
> Shashi(シャッシー)
>
>
>
> DISCLAIMER:
> ---
> The contents of this e-mail and any attachment(s) are confidential and
> intended
> for the named recipient(s) only.
> It shall not attach any liability on the originator or NEC or its
> affiliates. Any views or opinions presented in
> this email are solely those of the author and may not necessarily reflect
> the
> opinions of NEC or its affiliates.
> Any form of reproduction, dissemination, copying, disclosure, modification,
> distribution and / or publication of
> this message without the prior written consent of the author of this e-mail
> is
> strictly prohibited. If you have
> received this email in error please delete it and notify the sender
> immediately. .
> ---
>
>
> __
> 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] Meeting Thursday April 7th at 9:00 UTC

[GHANSHYAM MANN]

Hello everyone,


Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, April 7th at 9:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_April_7th_2016_.280900_UTC.29

 Anyone is welcome to add an item to the agenda.

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

18:00 JST

18:30 ACST

11:00 CEST

04:00 CDT

02:00 PDT

Regards
Ghanshyam Mann

__
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] [Congress] Issues with Tox testing

[GHANSHYAM MANN]

Yea that's right. Tempest will be able to run all tests(tempest one or
plugin) as long as plugin is discoverable and all services tests
interact with are reachable from Tempest installed node.

In that case, you need to configure services (keystone, congress etc)
endpoints correctly. Please refer configuration in detail-
http://docs.openstack.org/developer/tempest/configuration.html

Regards
Ghanshyam Mann


On Tue, Apr 12, 2016 at 2:46 PM, Anusha Ramineni  wrote:
> Hi Bryan,
>
> Yes, tempest can be run outside devstack deployments. Please check the
> README in https://github.com/openstack/tempest on configuring tempest.
>
> As in liberty, you need to copy the tests to tempest, I guess installing
> tempest on diff server also should work as long as congress service is
> discoverable (never tried though) . But just to let you know, congress
> Liberty version has minimal tempest coverage, In Mitaka we have enabled all
> the tempest tests.
>
> Best Regards,
> Anusha
>
> On 12 April 2016 at 10:43, Bryan Sullivan  wrote:
>>
>> Hi Anusha,
>>
>> That helps. Just one more question: in Liberty (which I'm currently based
>> upon) have the tempest tests been run outside of devstack deployments, i.e.
>> in an actual OpenStack deployment? The guide you reference mentions devstack
>> but it's not clear that the same process applies outside devstack:
>>
>> e.g. "To list all Congress test cases, run command in /opt/stack/tempest:"
>> references the "/opt/stack" folder which is not created outside of devstack
>> environments. Thus to run them in a full OpenStack deployment, do I need to
>> install  tempest and create an "opt/stack/tempest" folder to which the tests
>> are copied, on the same server where Congress is installed?
>>
>> I'll try Mitaka soon but I expect to have the same question there:
>> basically, are the tempest tests expected to be usable outside a devstack
>> deploy?
>>
>> I guess I could just try it, but I don't want to waste time if this is not
>> designed to be used outside devstack environments.
>>
>> Thanks,
>> Bryan Sullivan
>>
>> 
>> Date: Fri, 8 Apr 2016 09:01:29 +0530
>> From: anusha.ii...@gmail.com
>>
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [Congress] Issues with Tox testing
>>
>> Hi Bryan,
>>
>> tox -epy27 doesn't run tempest tests , that is tests mentioned in
>> https://github.com/openstack/congress/tree/stable/liberty/contrib/tempest ,
>> it runs only unit tests , tests present in
>> https://github.com/openstack/congress/tree/stable/liberty/congress/tests .
>>
>> To run tempest tests, you need to manually copy the files to tempest and
>> run the tests as mentioned in following readme
>> https://github.com/openstack/congress/blob/stable/liberty/contrib/tempest/README.rst
>>
>> Mitaka supports tempest plugin, so manually copying tests to tempest can
>> be avoided if you are using mitaka.
>>
>> Hope I clarified your question.
>>
>>
>> Best Regards,
>> Anusha
>>
>> On 8 April 2016 at 08:51, Bryan Sullivan  wrote:
>>
>> OK, somehow I did not pick up on that, or dropped it along the way of
>> developing the script. Thanks for the clarification, also that Tempest is
>> not required. I should have clarified that I'm using stable/liberty as the
>> base. I will be moving to stable/mitaka soon, as part of the OPNFV Colorado
>> release development.
>>
>> One additional question then - are the tests run by "tox -epy27" the same
>> as the tests in the folder
>> https://github.com/openstack/congress/tree/stable/liberty/contrib/tempest?
>> If not, how are those tests supposed to be run for a non-devstack deploy (I
>> see reference to devstack in the readme)?
>>
>> I see that the folders have been reorganized for mitaka. My question is
>> per the goal to include as much of the Congress tests as possible in the
>> OPNFV CI/CD process. Not that I expect any to fail, I just want OPNFV to
>> leverage the full test suite. If for liberty that's best left as the tests
>> run by the tox command, then that's OK.
>>
>> Thanks,
>> Bryan Sullivan
>>
>> 
>> Date: Thu, 7 Apr 2016 17:11:36 -0700
>> From: ekcs.openst...@gmail.com
>> To: openstack-dev@lists.openstack.org
>>
>> Subject: Re: [openstack-dev] [Congress] Issues with Tox testing
>>
>> Thanks for the feedback, Bryan. Glad you got things working!
>>
&

Re: [openstack-dev] [ceilometer][tempest] disabling 'full' tempest tests for ceilometer changes in CI

[GHANSHYAM MANN]

+1, That make sense.

Also as Ceilometer and Aodh will be running tests from plugin, I have
initiated patch to remove those from Tempest.

- https://review.openstack.org/#/c/304992/
Regards
Ghanshyam Mann
+818011120698


On Tue, Apr 12, 2016 at 9:47 PM, Chris Dent  wrote:
> On Tue, 12 Apr 2016, gordon chung wrote:
>
>> i'd be in favour of dropping the full cases -- never really understood
>> why we ran all the tests everywhere. ceilometer/aodh are present at the
>> end of the workflow so i don't think we need to be concerned with any of
>> the other tests, only the ones explicitly related to ceilometer/aodh.
>
>
> +1
> --
> 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

[openstack-dev] [QA] Meeting Thursday April 21st at 9:00 UTC

[GHANSHYAM MANN]

Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, April 21st at 9:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_April_21st_2016_.280900_UTC.29

Anyone is welcome to add an item to the agenda.

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

04:00 EST
18:00 JST
18:30 ACST
11:00 CEST
04:00 CDT
02:00 PDT

Regards
Ghanshyam Mann

__
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] Drop javelin off tempest

[GHANSHYAM MANN]

Hi,

Yes, That's very valid point about there might be some real users or in future.

So Instead of deleting it, how about maintaining it. Only issue here
was gate did not
capture the issues when introduced in his tool.
But we can cover that using Unit tests and if really necessary we can
add experimental job for that.

2 thing we need
- Modify current unit tests to mock clients methods at deeper level
instead of complete service clients class.
- If really needed add experimental job for testing on gate.

Same issue we have for cleanup tool also, I need to check where we can
cover their testing(UT or gate job etc)

I vote it to keep that (which can be useful for some users (may be
future) who want to quickly tests their Cloud's resource
creation/deletion etc )

On Fri, Dec 11, 2015 at 1:17 AM, Matthew Treinish  wrote:
> On Thu, Dec 10, 2015 at 11:15:06AM +0100, Daniel Mellado wrote:
>> Hi All,
>>
>> In today's QA meeting we were discussing about dropping Javelin off
>> tempest if it's not being used anymore in grenade, as sdague pointed
>> out. We were thinking about this as a part of the work for [1], where we
>> hit issue on Javelin script testing where gate did not detect the
>> service clients changes in this script.
>
> So the reason we didn't remove this from tempest when we stopped using it as
> part of grenade is at the time there were external users. They still wanted to
> keep the tooling around. This is why the unit tests were grown in an effort to
> maintain some semblance of testing after the grenade removal. (for a long time
> it was mostly self testing through the grenade job)
>
>>
>> Our intention it's to drop the following files off tempest:
>>
>>   * tempest/cmd/javelin.py
>> <https://review.openstack.org/#/c/254274/3/tempest/cmd/javelin.py>
>>   * tempest/cmd/resources.yaml
>> <https://review.openstack.org/#/c/254274/3/tempest/cmd/resources.yaml>
>>   * tempest/tests/cmd/test_javelin.py
>> 
>> <https://review.openstack.org/#/c/254274/3/tempest/tests/cmd/test_javelin.py>
>>
>> Before doing so, we'd like to get some feedback about out planned move,
>> so if you have any questions, comments or feedback, please reply to this
>> thread.
>
> You should not just delete these files, there were real users of it in the 
> past
> and there might still be. If you're saying that javelin isn't something we can
> realistically maintain anymore (which I'm not sure I buy, but whatever) we
> should first mark it for deprecation and have a warning print saying it will 
> be
> removed in the future. This gives people a chance to stop using it and migrate
> to something else. (using ansible would be a good alternative)
>
>
> -Matt Treinish
>
>>
>> ---
>> [1]
>> https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:bp/consistent-service-method-names,n,z
>>
>
> ______
> 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
>



-- 
Regards
Ghanshyam Mann
+81-8084200646

__
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] clients/manager in plugins

[GHANSHYAM MANN]

Hi Ryota,

That is the one way as you mentioned.

On Fri, Dec 11, 2015 at 8:15 PM, Ryota Mibu  wrote:
> Hi,
>
>
> This is a question regarding design of clients and managers in a tempest 
> plugin.
>
>
> I'm not familiar with tempest, but it seems that there are the following 
> terms:
>
> Client: client of service or feature (part of service)
>
> ClientManager: having clients which are needed for particular test 
> scenario

Yes, clients called service clients are those which place request on
services and Manager to load those clients and make them available for
tests cases.

> According to [1], we are encouraged to have own client in each project 
> repository instead of tempest tree. That means we may have to gather clients 
> from other repositories to create a test scenario when it use other services. 
> For example, when  and  are out of tempest scope/tree, 
> we have to load client of  from its repository in order to create 
> a test scenario under .

Yes, Tempest will maintain the service client for 6 core projects (as
per Big tent Architecture) and those will be available in Tempest-lib
as stable interfaces (many of the compute clients are available [4]
and other in progress).
Plugins or any functional tests can use those from Tempest-lib and
about other project(other than those 6 which Tempest own) clients, yes
plugin needs to use from that project repo.

>
> If so, I'd like to use tempest.test.BaseTestCase() with my ClientManager 
> which is customized to load clients from other repositories out of tempest 
> and my own repository. So, I proposed [2]. But, if there is a better approach 
> to do the similar thing, please let me know.

So existing plugins like Manila etc, instantiate their Manager  in
their base test class which is inherited from
tempest.test.BaseTestCase() Along with that way, your idea of adding
option in Tempest base class itelf to give flexibility to users to
provide Manager class looks good to me as a short term solution.
Tempest long term solution/goal is to provide the plugin ability for
Manager class also and make that available from lib. But that is plan
and might take time.

>
>
> [1] http://docs.openstack.org/developer/tempest/plugin.html
> [2] https://review.openstack.org/#/c/255161/

[3] - https://github.com/openstack/tempest-lib/tree/master/tempest_lib/services

>
>
> Thanks,
> Ryota
>
> ---
> "Ryota Mibu" 
> NEC Corporation
>
>
> __
> 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



-- 
Regards
Ghanshyam Mann
+81-8084200646

__
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] clients/manager in plugins

[GHANSHYAM MANN]

Yes, 'common/service_client' was used temporary to migrate the clients to lib.
Anyways instead of ML, it will be fast to discuss on IRC :)

If you face any issue,feel free to ping me(gmann) or any QA member on
#openstack-qa channel.

On Wed, Dec 16, 2015 at 8:06 PM, Ryota Mibu  wrote:
> Hi Ghanshyam,
>
>
>
> Thanks for your response.
>
> It seems that I'm headed in the right direction.
>
> One more question. - Should we migrate from 'service_client' to 'rest_client' 
> in tempest-lib?
>
>
>
> Best regards,
> Ryota
>
>> -Original Message-
>> From: GHANSHYAM MANN [mailto:ghanshyamm...@gmail.com]
>> Sent: Saturday, December 12, 2015 11:32 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [tempest] clients/manager in plugins
>>
>> Hi Ryota,
>>
>> That is the one way as you mentioned.
>>
>> On Fri, Dec 11, 2015 at 8:15 PM, Ryota Mibu  wrote:
>> > Hi,
>> >
>> >
>> > This is a question regarding design of clients and managers in a tempest 
>> > plugin.
>> >
>> >
>> > I'm not familiar with tempest, but it seems that there are the following 
>> > terms:
>> >
>> > Client: client of service or feature (part of service)
>> >
>> > ClientManager: having clients which are needed for particular test
>> > scenario
>>
>> Yes, clients called service clients are those which place request on 
>> services and Manager to load those clients and
>> make them available for tests cases.
>>
>> > According to [1], we are encouraged to have own client in each project 
>> > repository instead of tempest tree. That
>> means we may have to gather clients from other repositories to create a test 
>> scenario when it use other services.
>> For example, when  and  are out of tempest scope/tree, 
>> we have to load client of 
>> from its repository in order to create a test scenario under .
>>
>> Yes, Tempest will maintain the service client for 6 core projects (as per 
>> Big tent Architecture) and those will be
>> available in Tempest-lib as stable interfaces (many of the compute clients 
>> are available [4] and other in progress).
>> Plugins or any functional tests can use those from Tempest-lib and about 
>> other project(other than those 6 which Tempest
>> own) clients, yes plugin needs to use from that project repo.
>>
>> >
>> > If so, I'd like to use tempest.test.BaseTestCase() with my ClientManager 
>> > which is customized to load clients from
>> other repositories out of tempest and my own repository. So, I proposed [2]. 
>> But, if there is a better approach to
>> do the similar thing, please let me know.
>>
>> So existing plugins like Manila etc, instantiate their Manager  in their 
>> base test class which is inherited from
>> tempest.test.BaseTestCase() Along with that way, your idea of adding option 
>> in Tempest base class itelf to give
>> flexibility to users to provide Manager class looks good to me as a short 
>> term solution.
>> Tempest long term solution/goal is to provide the plugin ability for Manager 
>> class also and make that available from
>> lib. But that is plan and might take time.
>>
>> >
>> >
>> > [1] http://docs.openstack.org/developer/tempest/plugin.html
>> > [2] https://review.openstack.org/#/c/255161/
>>
>> [3] - 
>> https://github.com/openstack/tempest-lib/tree/master/tempest_lib/services
>>
>> >
>> >
>> > Thanks,
>> > Ryota
>> >
>> > ---
>> > "Ryota Mibu" 
>> > NEC Corporation
>> >
>> >
>> > __
>> >  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
>>
>>
>>
>> --
>> Regards
>> Ghanshyam Mann
>> +81-8084200646
>>
>> __
>> 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



-- 
Regards
Ghanshyam Mann
+81-8084200646

__
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] does validation bug-fix require microversion bump?

[GHANSHYAM MANN]

On Mon, Dec 21, 2015 at 4:25 PM, Ken'ichi Ohmichi  wrote:
> Hi nova-api team,
>
> I'd like to get a feedback about the way to bump a microversion.
>
> Short version:
>   We found a validation bug on Nova v2.1 API.
>   To fix the bug, do we need to bump a new microversion?
>
> Long version:
> As LP bug report[1], nova v2.0 API allows a list of server-IDs on
> scheduler_hint "different_host" like
>
> "os:scheduler_hints": {
> "different_host": [
> "099b8bee-9264-48fe-a745-45b22f7ff79f",
> "99644acc-8893-4656-9481-0114efdbc9b6"
> ]
> }
>
> on "create a server" API.
> However, nova v2.1 API is handling this request as invalid because the
> validation implementation way is wrong now.
> Nova v2.1 API should allow the list of server-IDs for backwards compatibility.
>
> We are trying to fix this bug on
> https://review.openstack.org/#/c/259247/ , and we have a question to
> fix it.
> This fix is API change even if fixing the bug, so do we need to bump a
> microversion?
>
> The one usage of microversions is notification of API change.
> If bumping it, nova can notify the fixing with a microversion.
>
> This fix should be applied to stable branches also because of helping
> the existing users.
> So if bumping a microversion on stable branch also, the microversion
> number meanings become different between clouds which are deployed
> with different nova releases.
> So we(John, Alex, me) are guessing we should not bump a microversion
> on stable branches. but if doing that, nova cannot notify the fixing
> on stable branches.
>
> Now I am feeling this fixing will be applied without a microversion
> bump because it is nice to avoid different microversion meanings of
> master/stable branches.
> Is it fine for us?

+1, IMO too it is fine to fix it as bug as long as it does not break
any existing v2.1 users (it still allow UUID only as valid one).
And we have to fix it for V2.1 comp mode too so microversion does not
fit here in my opinion too.
I am +1 to fix it as bug and backport to stable/branches also.


>
> Thanks
> Ken Ohmichi
>
> ---
> [1]: https://launchpad.net/bugs/1521928
>
> __
> 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



-- 
Regards
Ghanshyam Mann
+81-8084200646

__
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 January 14th at 9:00 UTC

[GHANSHYAM MANN]

Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, Jan 14th at 9:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:

https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_January_14th_2016_.280900_UTC.29

Anyone is welcome to add an item to the agenda.

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

04:00 EST
18:00 JST
18:30 ACST
11:00 CEST
04:00 CDT
02:00 PDT

Regards
Ghanshyam Mann

__
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 January 28th at 9:00 UTC

[GHANSHYAM MANN]

Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, Jan 28th at 9:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_January_28st_2016_.280900_UTC.29

Anyone is welcome to add an item to the agenda.

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

04:00 EST

18:00 JST

18:30 ACST

11:00 CEST

04:00 CDT

02:00 PDT



Regards

Ghanshyam Mann

__
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] "kwargs" of service clients for POST/PUT methods

[GHANSHYAM MANN]

On Wed, Jul 8, 2015 at 12:27 PM, Ken'ichi Ohmichi  wrote:
> Hi tempest team,
>
> We are working for refactoring service clients in tempest for
> preparing to migrate them to tempest-lib, and I found an inconsistency
> between them.
> So I'd like to ask opinions for considering which is the best as
> library methods.
>
> On some methods, a caller can specify whole body for sending a request
> to http POST/PUT methods.
> But on the others a caller can specify only part of body.
>
> For example, a caller can specify any parameters to
> update_quota_class_set() like:
>
> tempest/services/compute/json/quota_classes_client.py
>  34 def update_quota_class_set(self, quota_class_id, **kwargs):
>  35 """
>  36 Updates the quota class's limits for one or more resources.
>  37 """
>  38 post_body = json.dumps({'quota_class_set': kwargs})
>  39
>  40 resp, body = self.put('os-quota-class-sets/%s' % quota_class_id,
>  41   post_body)
>
> but update_quota_set method has each argument and a caller cannot
> specify the other parameters like:
>
> tempest/services/compute/json/quotas_client.py
>  44 def update_quota_set(self, tenant_id, user_id=None,
>  45  force=None, injected_file_content_bytes=None,
>  46  metadata_items=None, ram=None, floating_ips=None,
>  47  fixed_ips=None, key_pairs=None, instances=None,
>  48  security_group_rules=None, injected_files=None,
>  49  cores=None, injected_file_path_bytes=None,
>  50  security_groups=None):
>  51 """
>  52 Updates the tenant's quota limits for one or more resources
>  53 """
>  54 post_body = {}
>  55
>  56 if force is not None:
>  57 post_body['force'] = force
>  58
>  59 if injected_file_content_bytes is not None:
>  60 post_body['injected_file_content_bytes'] = \
>  61 injected_file_content_bytes
>  [..]
>  96 post_body = json.dumps({'quota_set': post_body})
>  97
>  98 if user_id:
>  99 resp, body = self.put('os-quota-sets/%s?user_id=%s' %
> 100   (tenant_id, user_id), post_body)
> 101 else:
> 102 resp, body = self.put('os-quota-sets/%s' % tenant_id,
> 103   post_body)
>
> By defining all parameters on each method like update_quota_set(), it
> is easy to know what parameters are available from caller/programer
> viewpoint.

I think this can be achieved with former approach also by defining all
expected param in doc string properly.

> So I feel the later seems easy to use them as library methods.
> But as the demerit, a caller cannot specify *undefined" parameters for
> fuzzing tests.
> Nova v2.1 API should deny a request which includes undefined
> parameters, and Tempest will be able to test the behavior if the
> former style.
> So this is my concern point now.
>
> I tend to prefer the later(all parameters need to be defined on each
> method) because that will be useful for callers as the above.
> In addition, tempest-lib should be a library for implementing
> integration tests, then fuzzing tests can be out of scope.
> If fuzzing tests are necessary, we will be able to implement them with
> RestClient of tempest-lib without service clients.

Second approach also looks good but I prefer the first one. As you
mentioned that fuzzy testing will not be possible with second
approach, we should not restrict our lib functions for the same. Any
project/test suits should be able to do API/Fuzzy testing with
tempest-lib.
Good example is nova v2.1 as you mentioned. Using service clients of
lib, project (Nova) or test suits (Tempest) should be able to perform
fuzzy testing.

IMO, lib's service clients should not have any restriction on param
list (type or number etc) to be passed from its users. Whatever
(random param etc) is being passed that should be passed to
corresponding projects APIs and let APIs through error or success.

This can be useful when project adds new request attributes (with
current API change guidelines like with microversion), in that case we
do not need to change service clients. But microversion testing is not
yet decided so this should/may not be considered aa strong point?

>
> I am on between both now, and I'd like to get feedback about this
> before changing them.

Thanks a lot for driving service clients towards goo

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

[GHANSHYAM MANN]

On Thu, Jul 9, 2015 at 9:39 AM, Ken'ichi Ohmichi  wrote:
> 2015-07-08 16:42 GMT+09:00 Ken'ichi Ohmichi :
>> 2015-07-08 14:07 GMT+09:00 GHANSHYAM MANN :
>>> On Wed, Jul 8, 2015 at 12:27 PM, Ken'ichi Ohmichi  
>>> wrote:
>>>>
>>>> By defining all parameters on each method like update_quota_set(), it
>>>> is easy to know what parameters are available from caller/programer
>>>> viewpoint.
>>>
>>> I think this can be achieved with former approach also by defining all
>>> expected param in doc string properly.
>>
>> You are exactly right.
>> But current service clients contain 187 methods *only for Nova* and
>> most methods don't contain enough doc string.
>> So my previous hope which was implied was we could avoid writing doc
>> string with later approach.
>
> I am thinking it is very difficult to maintain doc string of REST APIs
> in tempest-lib because APIs continue changing.
> So instead of doing it, how about putting the link of official API
> document[1] in tempest-lib and concentrating on maintaining official
> API document?
> OpenStack APIs are huge now and It doesn't seem smart to maintain
> these docs at different places.
>

++, this will be great. Even API links can be provided in both class
doc string as well as each method doc string (link to specific API).
This will improve API ref docs quality and maintainability.

> Thanks
> Ken Ohmichi
>
> ---
> [1]: http://developer.openstack.org/api-ref.html
>
> __
> 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



-- 
Thanks & Regards
Ghanshyam Mann

__
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] Why is osapi_v3.enabled = False by default?

[GHANSHYAM MANN]

On Thu, Jul 16, 2015 at 3:03 AM, Sean Dague  wrote:
> On 07/15/2015 01:44 PM, Matt Riedemann wrote:
>> The osapi_v3.enabled option is False by default [1] even though it's
>> marked as the CURRENT API and the v2 API is marked as SUPPORTED (and
>> we've frozen it for new feature development).
>>
>> I got looking at this because osapi_v3.enabled is True in nova.conf in
>> both the check-tempest-dsvm-nova-v21-full job and non-v21
>> check-tempest-dsvm-full job, but only in the v21 job is
>> "x-openstack-nova-api-version: '2.1'" used.
>>
>> Shouldn't the v2.1 API be enabled by default now?
>>
>> [1]
>> http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/__init__.py#n44
>
> Honestly, we should probably deprecate out osapi_v3.enabled make it
> osapi_v21 (or osapi_v2_microversions) so as to not confuse people further.
>

Nice Catch. We might have just forgot to make it default to True.

How about just deprecating it and remove in N and makes v21 enable all
the time (irrespective of osapi_v3.enabled) as they are current now.

> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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



-- 
Thanks & Regards
Ghanshyam Mann

__
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] change of day for API subteam meeting?

[GHANSHYAM MANN]

Sorry for late reply. Monday or Tuesday works fine for me

On Sat, Aug 8, 2015 at 1:48 AM, Sean Dague  wrote:
> Friday's have been kind of a rough day for the Nova API subteam. It's
> already basically the weekend for folks in AP, and the weekend is right
> around the corner for everyone else.
>
> I'd like to suggest we shift the meeting to Monday or Tuesday in the
> same timeslot (currently 12:00 UTC). Either works for me. Having this
> earlier in the week I also hope keeps the attention on the items we need
> to be looking at over the course of the week.
>
> If current regular attendees could speak up about day preference, please
> do. We'll make a change if this is going to work for folks.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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



-- 
Thanks & Regards
Ghanshyam Mann

__
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: Question on 'Retry-After': 0 in HTTPForbidden

[GHANSHYAM MANN]

That is nice point. IMO also Retry-After does not looks good for Quota
error (in all three mentioned case) and actually we are trying to tell
user in case of Quota error, retry this request after 0 sec.

Thanks
Ghanshyam

On Wed, Aug 19, 2015 at 12:34 AM, Chen CH Ji  wrote:
> When doing patch[1] Ken'ichi raise a good suggestion on not raise
> Retry-After according to [2]
>
> seems nova also when doing create[3] and resize[4] a server nova may raise
> those, too
> is this a bug or something made on purpose? Thanks
>
> [1]https://review.openstack.org/#/c/180469/5/nova/api/openstack/compute/tenant_networks.py
> [2]http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
> [3]https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L591
> [4]https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L846
>
> Best Regards!
>
> Kevin (Chen) Ji 纪 晨
>
> Engineer, zVM Development, CSTL
> Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
> Phone: +86-10-82454158
> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
> Beijing 100193, PRC
>
>
> __
> 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
>



-- 
Thanks & Regards
Ghanshyam Mann

__
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] should we combine a set of minor microversion bump needed fix into one microversoin bump?

[GHANSHYAM MANN]

nge, just return 400.  In the service_get change where you
> want to return a 400 but it's only returning a 404 today, then I guess
> according to the doc you'd need a microversion bump. But what do we do about
> fixing that bug in the v2 API?  Do we not fix it?  Do we return 404 but v2.1
> would return 400 with a microversion bump?  That's equally inconsistent and
> gross IMO.
>
> --
>
> 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
>



-- 
Thanks & Regards
Ghanshyam Mann

__
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] should we combine a set of minor microversion bump needed fix into one microversoin bump?

[GHANSHYAM MANN]

On Thu, Aug 20, 2015 at 3:33 AM, Matt Riedemann
 wrote:
>
>
> On 8/19/2015 12:18 PM, Chen CH Ji wrote:
>>
>> In doing [1] [2], some suggestions raised that those kind of change need
>> microversion bump which is fine
>> however, another concern raised on whether we need combine a set of
>> those kind of changes (which may only change some error code) into one
>> bump ?
>>
>> apparently there are pros and cons for doing so, combine makes API
>> version bump not that frequent for minor changes
>> but makes it hard to review and backport ... so any suggestions on how
>> to handle ? Thanks
>>
>>
>> [1]https://review.openstack.org/#/c/198753/
>> [2]https://review.openstack.org/#/c/173985/
>>
>> Best Regards!
>>
>> Kevin (Chen) Ji 纪 晨
>>
>> Engineer, zVM Development, CSTL
>> Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
>> Phone: +86-10-82454158
>> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
>> District, Beijing 100193, PRC
>>
>>
>> __
>> 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
>>
>
> I don't see why https://review.openstack.org/#/c/198753/ would require a
> microversion bump.  We've always allowed handling 500s and turning them into
> more appropriate error codes, like a 400 in this case.
>
> As noted:
>
> http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html
>
> "Changing an error response code to be more accurate." is generally
> acceptable.

humm, actually m confused now whether we should consider changing
error code as backward incompatible or not. or its more broken in 2
part? 1 introduced new error code (500-> new error code) 2. changing
to existing error code and which one is backward incompatible?

IMO (considering most users/app checking existing/published error code
range) 1 one should be considered as backward incompatible.

>
> --
>
> 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



-- 
Thanks & Regards
Ghanshyam Mann

__
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] [docs] Generating API samples

[GHANSHYAM MANN]

;:
>> "http://127.0.0.1:8774/c2ab3e6ac69e43bb925a4895075e47d7/servers/19f98a6f-26d2-4491-93a8-8e894f19034c";,
>> "rel": "bookmark"}], "adminPass": "2iEDo2EP5wRM"}} _log_request_full
>> /opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/rest_client.py:411
>>
>> I feel it is difficult to implement the similar sample test way of
>> Nova on each project.
>> The above Tempest log is written on tempest-lib side and that is
>> common way between projects.
>> So we can use this way for all projects as a common/consistent way, I
>> imagine now.
>>
>> I will make/write the detail of this idea later.
>>
>> Thanks
>> Ken Ohmichi
>>
>> ---
>>
>>> 1.
>>> https://github.com/openstack/nova/blob/master/nova/tests/functional/api_sample_tests/api_sample_base.py
>>>
>>> --
>>> Anne Gentle
>>> Rackspace
>>> Principal Engineer
>>> www.justwriteclick.com
>>>
>>> __
>>> 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



-- 
Thanks & Regards
Ghanshyam Mann

__
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] Should v2 compatibility mode (v2.0 on v2.1) fixes be applicable for v2.1 too?

[GHANSHYAM MANN]

Hi All,

As we all knows, api-paste.ini default setting for /v2 was changed to
run those on v2.1 (v2.0 on v2.1) which is really great think for easy
code maintenance in future (removal of v2 code).

To keep "v2.0 on v2.1" fully compatible with "v2.0 on v2.0", some bugs
were found[1] and fixed. But I think we should fix those only for v2
compatible mode not for v2.1.

For example bug#1491325, 'device' on volume attachment Request is
optional param[2] (which does not mean 'null-able' is allowed) and
v2.1 used to detect and error on usage of 'device' as "None". But as
it was used as 'None' by many /v2 users and not to break those, we
should allow 'None' on v2 compatible mode also. But we should not
allow the same for v2.1.

IMO v2.1 strong input validation feature (which helps to make API
usage in correct manner) should not be changed, and for v2 compatible
mode we should have another solution without affecting v2.1 behavior
may be having different schema for v2 compatible mode and do the
necessary fixes there.

Trying to know other's opinion on this or something I missed during
any discussion.

[1]: https://bugs.launchpad.net/python-novaclient/+bug/1491325
  https://bugs.launchpad.net/nova/+bug/1491511

[2]: http://developer.openstack.org/api-ref-compute-v2.1.html#attachVolume

-- 
Thanks & Regards
Ghanshyam Mann

__
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 September 17th at 9:00 UTC

[GHANSHYAM MANN]

Hi everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, September 17th at 9:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting
Anyone is welcome to add an item to the agenda.

To help people figure out what time 9:00 UTC is in other timezones,
meeting will be at:

04:00 EDT
18:00 JST
18:30 ACST
11:00 CEST
04:00 CDT
02:00 PDT


-- 
Thanks & Regards
Ghanshyam Mann

__
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] Proposing Jordan Pittier for Tempest Core

[GHANSHYAM MANN]

+1 :)

On Tue, Jun 23, 2015 at 5:23 AM, Matthew Treinish 
wrote:

>
>
> Hi Everyone,
>
> I'd like to propose we add Jordan Pittier (jordanP) to the tempest core
> team.
> Jordan has been a steady contributor and reviewer on tempest over the past
> few
> cycles and he's been actively engaged in the Tempest community. Jordan has
> had
> one of the higher review counts on Tempest for the past cycle, and he has
> consistently been providing reviews that show insight into both the project
> internals and it's future direction. I feel that Jordan will make an
> excellent
> addition to the core 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.
>
> Thanks,
>
> Matt Treinish
>
> References:
>
>
> https://review.openstack.org/#/q/reviewer:jordan.pittier%2540scality.com+project:openstack/tempest+OR+project:openstack/tempest-lib,n,z
>
> http://stackalytics.com/?metric=marks&user_id=jordan-pittier
>
> __
> 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
>
>


-- 
Thanks & Regards
Ghanshyam Mann
__
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] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

[GHANSHYAM MANN]

you think type these in every
>> > time? Solution is simple: add IRONIC_API_VERSION to whatever exports the
>> > other environment variables.
>>
>> It's not that bad, especially if devstack/tripleo will provide some
>> reasonable default for you.
>>
>> I remember, however, Devananda didn't like the idea.
>>
>> And it definitely makes a quick start guide a bit harder to follow. I
>> already imagine how many people will forget about this pinning (either
>> to do it, or do update when they need new features).
>>
>> >
>> > The version depends on the environment you are running against - why not
>> > treat it as such?
>> >
>> >> d.1) you start to break people \o/ that's not a theoretical concern:
>> >> our
>> >> downstream tooling did get broken by updating to newer ironicclient
>> >> from git
>> >>
>> >
>> > As I said before, we need to encourage folks to pin client versions if
>> > they don't want to break. I'm probably alone here, but I would even
>> > propose making the version *required*. Force people to think about what
>> > they are doing. If folks are okay with being broken, they can pass
>> > "latest".
>>
>> Could be a good default for devstack btw
>>
>> >
>> >> d.2) you require complex version negotiations on the client side.
>> >> Otherwise
>> >> imaging CLI tool defaulting to 1.6 will issue `node-create` to Ironic
>> >> supporting only 1.5. Guess what? It will fail despite node-create being
>> >> very
>> >> old feature. Again, that's not something theoretical: that's how we
>> >> broke
>> >> TripleO CI.
>> >>
>> >
>> > Again, pin it.
>> >
>> >> e) Every microversion should be fully tested separately. Which ended up
>> >> in
>> >> Ironic having 4 versions 1.2-1.5 that were never ever gate tested. Even
>> >> worse, initially, our gate tested only the oldest version 1.1, but we
>> >> solved
>> >> it (though it took time to realize). The only good thing here is that
>> >> these
>> >> versions 1.2-1.5 were probably never used by anyone.
>> >>
>> >
>> > Hi. I've used some of these. :)
>>
>> You didn't tell me last time we talked :) note, that you didn't use
>> them, unless you explicitly requested, because IIRC we never defaulted
>> our client to any of these. So for most people, even deploying from
>> master, it was 1.1 -> 1.6.
>>
>> >
>> > // jim
>> >
>> > [0]
>> > https://github.com/openstack/ironic/blob/master/ironic/api/controllers/v1/__init__.py#L59-63
>> > [1]
>> > https://review.openstack.org/#/c/188873/1/ironic/api/controllers/v1/node.py
>> >>
>> >> To sum this long post up, I'm seeing that hiding new features based on
>> >> microversions brings much more problems, than it solves (I'm not aware
>> >> of
>> >> the latter at all). I'm very opposed to continuing doing it in Ironic,
>> >> and
>> >> I'm going to propose patch stopping gating Kilo changes (non-breaking
>> >> obviously).
>> >>
>> >> Hope that helps,
>> >> Dmitry
>> >>
>> >>>
>
>
> __
> 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
>



-- 
Thanks & Regards
Ghanshyam Mann

__
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] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

[GHANSHYAM MANN]

eds to consider interoperability between clouds so well
> because Nova API is one of general external interfaces for end users.
>
> On the other hand, Ironic API is for administrators, not for end users.
> I am imaging that:
> * Some administrator wrote his application for using Ironic API.
> * From the viewpoint of administrator, the switching destination cloud
> in newer in most cases.
> * The application can continue working on newer clouds even after
> switching many times.
>
> So I feel the above interoperable issue example would not happen on
> Ironic in most cases unless hiding backwards compatible changes on
> lower microversion.
> I guess this is the difference between Nova and Ironic on
> interoperability discussion.
>
> I cannot/don't want to enforce Ironic way at all, and it's fine to
> find the best way on each project as OSS projects.
> But only my concern here is that we cannot use "Microversions" as a
> perfect keyword for OpenStack interoperability on whole OpenStack
> projects if Ironic goes to the other way.
>
> Thanks
> Ken Ohmichi
>
> ---
> [1]: https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/
>
> __
> 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



-- 
Thanks & Regards
Ghanshyam Mann

__
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] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

[GHANSHYAM MANN]

On Fri, Jun 26, 2015 at 3:46 PM, Dmitry Tantsur  wrote:
>
> 26 июня 2015 г. 2:48 пользователь "GHANSHYAM MANN" 
> написал:
>>
>> On Thu, Jun 25, 2015 at 5:18 PM, Ken'ichi Ohmichi 
>> wrote:
>> > Sorry for late response here,
>> >
>> > 2015-06-20 9:14 GMT+09:00 Devananda van der Veen
>> > :
>> >>
>> >> Long version...
>> >> Every HTTP response from Ironic today includes three headers: min, max,
>> >> and
>> >> version. The service can present an older API version, as long as it is
>> >> greater-than-or-equal-to the minimum supported version, even if that
>> >> version
>> >> is incompatible with the maximum supported version.  It does this by
>> >> rewriting responses to match what was expected in the requested (older)
>> >> version.
>> >>
>> >> When the newer version is identical *for all interfaces present* in the
>> >> older version, this can be called compatible. Dmitry's point is that we
>> >> don't need to hide newer interfaces from users who request an older API
>> >> version, because the client won't know or care about things that
>> >> weren't in
>> >> the version it requested.
>> >>
>> >> However, we *do* need to signal their presence, and we don't have a
>> >> good
>> >> means for that right now. We also need to signal to the client that the
>> >> response given is "compatible with" a certain "age" of API, even if
>> >> it's not
>> >> exactly the same. And we don't have any means for that, either.
>> >>
>> >> Time for an example
>> >>
>> >> Let's say that an incompatible change was made in v1.3. Let's also say
>> >> that
>> >> a change was made in v1.5 that added a new endpoint. Today, this is
>> >> what the
>> >> response headers would look like when calling a server running v1.5.
>> >>
>> >> a) client requests v1.2, receives headers (min: 1.1, max: 1.5, current:
>> >> 1.2)
>> >> b) client requests v1.4, receives headers (min: 1.1, max: 1.5, current
>> >> 1.4)
>> >> c) client requests v1.5, receives headers (min: 1.1, max: 1.5, current:
>> >> 1.5)
>> >>
>> >> What we have implemented today is that in case (b), the service will
>> >> *hide*
>> >> any changes that we introduced in v1.5. But those changes did not
>> >> affect any
>> >> functionality of the v1.4 API, so Dmitry objects to this. So do I.
>> >>
>> >> The issue at hand is the response in case (b) ... though after spending
>> >> the
>> >> last several months working on api versioning, I actually think all of
>> >> those
>> >> are poor responses.
>> >>
>> >> What I believe we should have:
>> >> a) client requests v1.2, receives headers (min: 1.1, max: 1.5,
>> >> compatible-with: 1.1)
>> >> b) client requests v1.4, receives headers  (min: 1.1, max: 1.5,
>> >> compatible-with: 1.3)
>> >> b) client requests v1.5, receives headers  (min: 1.1, max: 1.5,
>> >> compatible-with: 1.3)
>> >>
>> >> Yes -- (b) and (c) are identical responses.
>> >>
>> >> Discuss.
>> >
>> > I think it is good that backwards compatible changes(new features) are
>> > available on older microversion also *only* if the clouds which are
>> > used by users continue upgrading.
>> >
>> > I think Sophia's role on "The Backwards Compatibility Fallacy" of
>> > Sean's blog[1] has answered to this question, but I'd like to try
>> > explaining it here for considering Ironic situation.
>> > As the example, there are multiple public clouds which provide
>> > different max microversions like:
>> >
>> > Cloud A: Max microversion: v1.5
>> > Cloud B: Max microversion: v1.1
>> >
>> > A user wrote his own application for running on cloud A and specifying
>> > v1.1 on the first application implementation.
>> > The first application used small number of APIs, and he wanted to
>> > extend the application.
>> > If all backwards compatible changes(v1.2 - v1.5) appear on lower
>> > microversion(in this case v1.1), he can use all new features even if
>> > specifying v1.1.
>> > That seem

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

[GHANSHYAM MANN]

On Fri, Jun 26, 2015 at 3:43 PM, Dmitry Tantsur  wrote:
>
> 26 июня 2015 г. 2:47 пользователь "GHANSHYAM MANN" 
> написал:
>>
>> On Sat, Jun 20, 2015 at 9:14 AM, Devananda van der Veen
>>  wrote:
>> > Almost all of our discussions so far on this topic have left something
>> > out,
>> > which Monty pointed out to me last week. I'm following up now because
>> > E_TRAVEL...
>> >
>> > tldr;
>> > What we're versioning here are API's, not packages. It's not a question
>> > of
>> > numbering and dependency ordering, but of communicating support[ed|able]
>> > interfaces between running services. Libtool is more relevant than
>> > semver.
>> >
>> >
>> > http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
>> >
>> > Right now we lack a means to express that the API response is
>> > "compatible-with" a particular previously-released version of the API.
>> > If we
>> > had that, instead of "current-version", I believe we would have much
>> > happier
>> > users (and a happier Dmitry and jroll).
>> >
>> >
>> > Long version...
>> > Every HTTP response from Ironic today includes three headers: min, max,
>> > and
>> > version. The service can present an older API version, as long as it is
>> > greater-than-or-equal-to the minimum supported version, even if that
>> > version
>> > is incompatible with the maximum supported version.  It does this by
>> > rewriting responses to match what was expected in the requested (older)
>> > version.
>> >
>> > When the newer version is identical *for all interfaces present* in the
>> > older version, this can be called compatible. Dmitry's point is that we
>> > don't need to hide newer interfaces from users who request an older API
>> > version, because the client won't know or care about things that weren't
>> > in
>> > the version it requested.
>> >
>> > However, we *do* need to signal their presence, and we don't have a good
>> > means for that right now. We also need to signal to the client that the
>> > response given is "compatible with" a certain "age" of API, even if it's
>> > not
>> > exactly the same. And we don't have any means for that, either.
>> >
>> > Time for an example
>> >
>> > Let's say that an incompatible change was made in v1.3. Let's also say
>> > that
>> > a change was made in v1.5 that added a new endpoint. Today, this is what
>> > the
>> > response headers would look like when calling a server running v1.5.
>> >
>> > a) client requests v1.2, receives headers (min: 1.1, max: 1.5, current:
>> > 1.2)
>> > b) client requests v1.4, receives headers (min: 1.1, max: 1.5, current
>> > 1.4)
>> > c) client requests v1.5, receives headers (min: 1.1, max: 1.5, current:
>> > 1.5)
>> >
>> > What we have implemented today is that in case (b), the service will
>> > *hide*
>> > any changes that we introduced in v1.5. But those changes did not affect
>> > any
>> > functionality of the v1.4 API, so Dmitry objects to this. So do I.
>> >
>> > The issue at hand is the response in case (b) ... though after spending
>> > the
>> > last several months working on api versioning, I actually think all of
>> > those
>> > are poor responses.
>> >
>> > What I believe we should have:
>> > a) client requests v1.2, receives headers (min: 1.1, max: 1.5,
>> > compatible-with: 1.1)
>> > b) client requests v1.4, receives headers  (min: 1.1, max: 1.5,
>> > compatible-with: 1.3)
>> > b) client requests v1.5, receives headers  (min: 1.1, max: 1.5,
>> > compatible-with: 1.3)
>> >
>>
>> This is nice idea to return "compatible-with" information. But I feel
>> each microversion either backward compatible or not should have their
>> unique output only for what they had been introduced (not include new
>> version changes).
>
> Sigh. Please provide some justification.

I am considering the case of interoperatibility for Apps based on
OpenStack cloud.
where they are going to break when upgrade happens.

Returning "compatible-with" information makes them encourage and well instance
information about versions whether they are backward compatible or not.

Even we have w

Re: [openstack-dev] [Nova] Should we signal backwards incompatible changes in microversions?

[GHANSHYAM MANN]

Regards
Ghanshyam Mann


On Mon, Feb 15, 2016 at 12:07 PM, Alex Xu  wrote:
> If we support 2.x.y, when we bump 'x' is a problem. We didn't order the API
> changes for now, the version of API change is just based on the order of
> patch merge. For support 2.x.y, we need bump 'y' first for back-compatible
> changes I guess.
>
> As I remember, we said before, the new feature is the motivation of user
> upgrade their client to support new version API, whatever the new version is
> backward compatible or incompatible. So I guess the initial thinking we hope
> user always upgrade their code than always stop at old version? If we bump
> 'x' after a lot of 'y', will that lead to user always stop at 'x' version?
> And the evolution of api will slow down.
>
> Or we limit to each release cycle. In each release, we bump 'y' first, and
> then bump 'x'. Even there isn't any back-incompatible change in the release.
> We still bump 'x' when released. Then we can encourage user upgrade their
> code. But I still think the back-incompatible API change will be slow down
> in development, as it need always merged after back-compatible API change
> patches.

Yea that true and will be more complicated from development
perspective which leads to slow down the evolution of API changes.
But if we support x.y then still we can change x at any time back
in-comp changes happens(i mean before y also)? Or I may not be getting
the issue you mentioned about always bump y before x.

I like the idea of distinguish the backward comp and in-comp changes
with x and y which always gives clear perspective about changes.
But it should not lead users to ignore y. I mean some backward comp
changes which are really good gets ignored by users as they start look
at the x only.
For example- "adding attribute in resource representation" is back
comp change (if so) and if that is added as y then, it might get
ignored by users.

Another way to clearly distinguish backward comp and in-comp changes
is through documentation which was initially discussed during
microversion specs. Currently doc has good description about each
changes but not much clear way about backward comp or not.
Which we can do by adding a clear flag [Backward Compatible/
Incompatible] for each version in doc [1]-

>
>
>
> 2016-02-13 4:55 GMT+08:00 Andrew Laski :
>>
>> Starting a new thread to continue a thought that came up in
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2016-February/086457.html.
>> The Nova API microversion framework allows for backwards compatible and
>> backwards incompatible changes but there is no way to programmatically
>> distinguish the two. This means that as a user of the API I need to
>> understand every change between the version I'm using now and a new
>> version I would like to move to in case an intermediate version changes
>> default behaviors or removes something I'm currently using.
>>
>> I would suggest that a more user friendly approach would be to
>> distinguish the two types of changes. Perhaps something like 2.x.y where
>> x is bumped for a backwards incompatible change and y is still
>> monotonically increasing regardless of bumps to x. So if the current
>> version is 2.2.7 a new backwards compatible change would bump to 2.2.8
>> or a new backwards incompatible change would bump to 2.3.8. As a user
>> this would allow me to fairly freely bump the version I'm consuming
>> until x changes at which point I need to take more care in moving to a
>> new version.
>>
>> Just wanted to throw the idea out to get some feedback. Or perhaps this
>> was already discussed and dismissed when microversions were added and I
>> just missed it.
>>
>> __
>> 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
>

[1] 
https://github.com/openstack/nova/blob/master/nova/api/openstack/rest_api_version_history.rst

__
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] Does nova API allow the server_id parem as DB index?

[GHANSHYAM MANN]

Yes, currently Nova support that for show/update/delete server APIs etc
(both v2 and v2.1) and python-novaclient too. But I think that was old
behaviour and for ec2 API mainly?

I searched on ec2 repo [1] and they get the instance from nova using UUID,
i did not find any place they are fetching using id. Hut not sure if
external interface directly fetch that on nova by 'id'.

But apart from that, may be some users using 'id' instead of 'uuid' but
that was not recommended or documented anywhere So in that case can we
remove this old behaviour without version bump?


[1].. https://github.com/openstack/ec2-api

Regards
Ghanshyam Mann

On Tue, Feb 16, 2016 at 11:24 AM, Anne Gentle  wrote:

>
>
> On Mon, Feb 15, 2016 at 6:03 PM, 少合冯  wrote:
>
>> I guess others may ask the same questions.
>>
>> I read the nova API doc:
>> such as this API:
>> http://developer.openstack.org/api-ref-compute-v2.1.html#showServer
>>
>> GET /v2.1/​{tenant_id}​/servers/​{server_id}​
>> *Show server details*
>>
>>
>> *Request parameters*
>> ParameterStyleTypeDescription
>> tenant_id URI csapi:UUID
>>
>> The UUID of the tenant in a multi-tenancy cloud.
>> server_id URI csapi:UUID
>>
>> The UUID of the server.
>>
>> But I can get the server by DB index:
>>
>> curl -s -H X-Auth-Token:6b8968eb38df47c6a09ac9aee81ea0c6
>> http://192.168.2.103:8774/v2.1/f5a8829cc14c4825a2728b273aa91aa1/servers/2
>> {
>> "server": {
>> "OS-DCF:diskConfig": "MANUAL",
>> "OS-EXT-AZ:availability_zone": "nova",
>> "OS-EXT-SRV-ATTR:host": "shaohe1",
>> "OS-EXT-SRV-ATTR:hypervisor_hostname": "shaohe1",
>> "OS-EXT-SRV-ATTR:instance_name": "instance-0002",
>> "OS-EXT-STS:power_state": 1,
>> "OS-EXT-STS:task_state": "migrating",
>> "OS-EXT-STS:vm_state": "error",
>> "OS-SRV-USG:launched_at": "2015-12-18T07:41:00.00",
>> "OS-SRV-USG:terminated_at": null,
>> ..
>> }
>> }
>>
>> and the code really allow it use  DB index
>> https://github.com/openstack/nova/blob/master/nova/compute/api.py#L1939
>>
>>
> Nice find. Can you log this as an API bug and we'll triage it -- can even
> help you fix it on the site if you like.
>
> https://bugs.launchpad.net/openstack-api-site/+filebug
>
> Basically, click that link, write a short summary, then copy and paste in
> this email's contents, it has lots of good info.
>
> Let me know if you'd also like to fix the bug on the site.
>
> And hey nova team, if you think it's actually an API bug, we'll move it
> over to you.
>
> Thanks for reporting it!
> Anne
>
>
>
>> __
>> 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
>>
>>
>
>
> --
> Anne Gentle
> Rackspace
> Principal Engineer
> www.justwriteclick.com
>
> __
> 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] deprecating Tempest stress framework

[GHANSHYAM MANN]

+1 Sounds good to separate those to different repo.


Regards
Ghanshyam Mann


On Wed, Feb 17, 2016 at 4:55 AM, Matthew Treinish  wrote:
> On Fri, Feb 12, 2016 at 10:21:53AM +0100, Koderer, Marc wrote:
>> I know that there are folks around that are using it.
>> +1 to move it to a separate repo.
>
> That sounds fine to me, let's mark the stress runner as deprecated and before
> we remove it someone can spin up a separate repo that owns the stress runner
> moving forward. But, I don't think we should hold up marking the deprecation
> until that exists. Let's move forward on the deprecation to give users enough
> time to prepare that the in-tree version is going away.
>
> -Matt Treinish
>
>>
>> Regards
>> Marc
>>
>> > On 11 Feb 2016, at 13:59, Daniel Mellado  
>> > wrote:
>> >
>> > +1 to that, it was my 2nd to-be-deprecated after javelin ;)
>> >
>> > El 11/02/16 a las 12:47, Sean Dague escribió:
>> >> In order to keep Tempest healthy I feel like it's time to prune things
>> >> that are outside of the core mission, especially when there are other
>> >> options out there.
>> >>
>> >> The stress test framework in tempest is one of those. It builds on other
>> >> things in Tempest, but isn't core to it.
>> >>
>> >> I'd propose that becomes deprecated now, and removed in Newton. If there
>> >> are folks that would like to carry it on from there, I think we should
>> >> spin it into a dedicated repository and just have it require tempest.
>> >>
>> >>-Sean
>> >>
>
> __
> 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] Meeting Thursday March 10th at 9:00 UTC

[GHANSHYAM MANN]

Hello everyone,


Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, March 10th at 9:00 UTC in the #openstack-meeting channel.


The agenda for the meeting can be found here:

https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_March_10th_2016_.280900_UTC.29


Anyone is welcome to add an item to the agenda.

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

04:00 EST

18:00 JST

18:30 ACST

11:00 CEST

04:00 CDT


02:00 PDT

Regards
Ghanshyam Mann

__
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

[GHANSHYAM MANN]

Thanks Matt for your great leadership and hardwork around QA world.

It has been great working in your leadership and provided a smooth &
cool environment during
those period.

There lot of key things we achieved and with diversity of ideas. You
have been always very active
and present to help all. Your great skill and versatile knowledge
helped QA to achieve a lot and going
on good direction.

And yes best thing is how you cover your work time for all different
different timeznoes. From JST too, almost
everyday we can contact you.

Yea, we need you not only as team member also to help smooth
transition to new PTL.

Congratulation for being as successful PTL for 2 years.

Thanks
gmann

On Sat, Mar 12, 2016 at 4:34 AM, Matthew Treinish  wrote:
> 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.
>
> 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)
>
> -Matt Treinish
>
> __
> 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] Nova PTL for Newton

[GHANSHYAM MANN]

Thanks a lot John for great leadership and all achievements. You have
been very encouraging and helpful always.
Regards
Ghanshyam Mann


On Sat, Mar 12, 2016 at 4:22 AM, John Garbutt  wrote:
> 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][all] Propose to remove negative tests from Tempest

[GHANSHYAM MANN]

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

This makes Tempest scope little bit unclear again. If we want to
verify all error codes in Tempest then it leads to have all surface
level negative testing also in Tempest. There are lot of scenario
where error codes can be verified and will be difficult to cover all
in Tempest.

Current negative tests does not cover all error codes for all APIs. If
we try to implement all then it will be huge tests n

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

[GHANSHYAM MANN]

On Thu, Mar 17, 2016 at 3:24 PM, Kairat Kushaev  wrote:
> 
> Also curious about this. It seems weird to separate the 'positive' and
> the 'negative' ones, assuming those patches are mostly contributed by
> the same group of developers.
> 
>
> Yeah, agree. This approach leads to situation when I need to look at two
> places to observe test coverage for each component.
> Also when I would like to add some tests I need to contribute to two places
> which is not convenient for reviewers for contributors IMO.

But currently also it is same situation where some negative tests are
in tempest and some are in project repo either as functional tests or
unit  [1].
Whenever we review new negative test patch, we have to check whether
that already exist in respective project or not if not then we can
consider it to add in tempest.

This could have valid if projects does not have any negative testing
in their tree and all reply on tempest tests for that.

Note- I am considering the surface level negative tests here, but yea
if that negative tests covers larger scope than just negative input
testing then, yes it should be in one place always.

[1]: 
https://github.com/openstack/keystone/blob/master/keystone/tests/unit/test_v3_identity.py

>
>
> Best regards,
> Kairat Kushaev
>
> On Thu, Mar 17, 2016 at 8:31 AM, Qiming Teng 
> wrote:
>>
>> >
>> > 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?
>> >
>>
>> Also curious about this. It seems weird to separate the 'positive' and
>> the 'negative' ones, assuming those patches are mostly contributed by
>> the same group of developers.
>>
>> Qiming
>>
>>
>> __
>> 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] [jacket] Introduction to jacket, a new project

[GHANSHYAM MANN]

Hi Kevin,

Its always nice idea as jacket has but not sure how feasible and
valuable it would be. For doing API translation and gateway, there are
many available and one I remember is Aviator (based on ruby gem) [1],
not sure how active it is now.

As your idea is more about consuming all differences between different
cloud, few query-

 1. Different clouds have very much different API model and feature
they provides, how  worth it is to provide missing/different features
at jacket layer? its then kind of another layer of cloud layer you
will end up.

 2. To support that idea through OpenStack standard API, you need to
inserting jacket driver all over the components which end up having
another layer gets inserted there. Maintainability of that is another
issue for each OpenStack components.

IMO, outside layer (from OpenStack ) which can do all these would be
nice something which can redirect API services at top level top and do
what all conversion, consume difference etc.

[1] https://github.com/aviator/aviator

Regards
Ghanshyam Mann


On Wed, Mar 16, 2016 at 9:58 PM, zs  wrote:
> Hi Gordon,
>
> Thank you for your suggestion.
>
> I think jacket is different from tricircle. Because tricircle focuses on
> OpenStack deployment across multiple sites, but jacket focuses on how to
> manage the different clouds just like one cloud.  There are some
> differences:
> 1. Account management and API model: Tricircle faces multiply OpenStack
> instances which can share one Keystone and have the same API model, but
> jacket will face the different clouds which have the respective service and
> different API model. For example, VMware vCloud Director has no volume
> management like OpenStack and AWS, jacket will offer a fake volume
> management for this kind of cloud.
> 2. Image management: One image just can run in one cloud, jacket need
> consider how to solve this problem.
> 3. Flavor management: Different clouds have different flavors which can not
> be operated by users. Jacket will face this problem but there will be no
> this problem in tricircle.
> 4. Legacy resources adoption: Because of the different API modles, it will
> be a huge challenge for jacket.
>
> I think it is maybe a good solution that jacket works to unify the API model
> for different clouds, and then using tricircle to offer the management of  a
> large scale VMs.
>
> Best Regards,
> Kevin (Sen Zhang)
>
>
> At 2016-03-16 19:51:33, "gordon chung"  wrote:
>>
>>
>>On 16/03/2016 4:03 AM, zs wrote:
>>> Hi all,
>>>
>>> There is a new project "jacket" to manage multiply clouds. The jacket
>>> wiki is: https://wiki.openstack.org/wiki/Jacket
>>>   Please review it and give your comments. Thanks.
>>>
>>> Best Regards,
>>>
>>> Kevin (Sen Zhang)
>>>
>>>
>>
>>i don't know exact details of either project, but i suggest you
>>collaborate with tricircle project[1] because it seems you are
>>addressing the same user story (and in a very similar fashion). not sure
>>if it's a user story for OpenStack itself, but no point duplicating
>> efforts.
>>
>>[1] https://wiki.openstack.org/wiki/Tricircle
>>
>>cheers,
>>
>>--
>>gord
>>
>>__
>>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] Meeting Thursday March 24th at 9:00 UTC

[GHANSHYAM MANN]

Hello everyone,


Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, March 24th at 9:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:

https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_March_24th_2016_.280900_UTC.29

 Anyone is welcome to add an item to the agenda.


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

04:00 EST
18:00 JST
18:30 ACST
11:00 CEST
04:00 CDT
02:00 PDT

Regards
Ghanshyam Mann

__
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 Bug triage

[GHANSHYAM MANN]

All,
As we all know, bug triage rotation really helps us to respond Tempest bugs
as quick as possible and keep bug count low.

Thanks for signing up in bug triage rotation.

To continue the same strategy and keeping good progress on bugs, we need
more volunteers to sign-up for coming weeks.

People who want to help in bug triage, feel free to put your name in
https://etherpad.openstack.org/p/qa-bug-triage-rotation


Thanks & Regards
Ghanshyam Mann
__
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] removal of v3 in tree testing

[GHANSHYAM MANN]

Hi Sean,

Yes having V3 directory/file names is very confusing now.

But current v3 sample tests cases tests v2.1 plugins. As /v3 url is
redirected to v21 plugins, v3 sample tests make call through v3 url and
test v2.1 plugins.

I think we can start cleaning up the *v3* from everywhere and change it to
v2.1 or much appropriate name.

To cleanup the same from sample files, I was planning to rearrange sample
files structure. Please check if that direction looks good (still need to
release patch for directory restructure)

https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:sample_files_structure,n,z



On Wed, Mar 4, 2015 at 11:06 PM, Sean Dague  wrote:

> I have proposed the following patch series to remove the API v3 direct

testing in tree -

https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:rm_v3_paste,n,z


> This also removes the /v3 entry from the paste.ini that we ship. I think

it's important that we remove that before kilo releases as I believe it

continues to confuse people.


> This also drops the functional test runs by about 50% in time.


> I couldn't think of a reason why we still needed this, but if someone

does, please speak up.


> -Sean


> --

Sean Dague

http://dague.net


> __

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




-- 
Thanks & Regards
Ghanshyam Mann
__
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] removal of v3 in tree testing

[GHANSHYAM MANN]

Hi Sean,

That is very nice idea to keep only 1 set of tests and run those twice via
tox.

Actually my main goal was-
- 1. Create clean sample file structure for V2. V2.1 and micro-versions
   Something like below-
 api_samples/
 extensions/
 v2.0/ - v2 sample files
 v2.1/- v2.1 sample files
 v2.2/- v2.2 sample files
 and so on

- 2.  Merge sample files between v2 and v2.1.

But your idea is much better which almost covers mine (except dir structure
for microversion which can/should be work after that).

As there are many extensions merged/split from v2 -> v2.1, we need to twist
tests to work for both v2 and v2.1.
For exmple, v2 flavor-swap, flavor-disable, flavor-extraData has been
merged to single flavor plugin in v2.1.

So running v2.1 flavor tests for v2 needs above extensions to be enabled in
that tests. It looks something like -
https://review.openstack.org/#/c/162016/

-- 
Thanks & Regards
Ghanshyam Mann


On Fri, Mar 6, 2015 at 7:00 AM, Sean Dague  wrote:
On 03/04/2015 07:48 PM, GHANSHYAM MANN wrote:
> Hi Sean,
>
> Yes having V3 directory/file names is very confusing now.
>
> But current v3 sample tests cases tests v2.1 plugins. As /v3 url is
> redirected to v21 plugins, v3 sample tests make call through v3 url and
> test v2.1 plugins.
>
> I think we can start cleaning up the *v3* from everywhere and change it
> to v2.1 or much appropriate name.
>
> To cleanup the same from sample files, I was planning to rearrange
> sample files structure. Please check if that direction looks good (still
> need to release patch for directory restructure)
>
>
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:sample_files_structure,n,z

I had another chat with Alex this morning on IRC. I think my confusion
is that I don't feel like I understand how we get down to 1 set of API
samples in the tree based on that set of posted patches.

It seems like there should only be 1 set of samples in docs/ and one set
of templates. I would also argue that we should only have 1 set of tests
(though that I'm mid term flexible on).

It seems that if our concern is that both the v2 and v21 endpoints need
to have the same results, we could change the functional tox target to
run twice, once with v2 and once with v21 set as the v2 endpoint.
Eventually we'll be able to drop v2 on v2.

Anyway, in order to both assist my own work unwinding the test tree, and
to help review your work there, can you lay out your vision for cleaning
this up with all the steps involved? Hopefully that will cut down the
confusion and make all this work move faster.

-Sean

--
Sean Dague
http://dague.net

__
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] what is our shipped paste.ini going to be for Kilo

[GHANSHYAM MANN]

us a little
> better. Especially with robust release notes that explain to people
> how to move their endpoints forward.
>
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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
>



-- 
Thanks & Regards
Ghanshyam Mann
__
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][QA] Use case of Nova to boot VM from volume only

[GHANSHYAM MANN]

Hi,

This is regarding bug - https://bugs.launchpad.net/tempest/+bug/1436314

When Nova is configured to boot VM from volume only, current Tempest
integration tests will fails. We are not sure how feasible and valid this
configuration is for Nova and what are the use cases of this.

Before starting support this in Tempest, we would like to get some feedback
and use cases about such configuration on Nova side.

I am trying it by setting "max_local_block_device" to 0 and tests fails
with 400 error[1]. Is that the right configuration to make boot from volume
only or something else there on Nova config.

1- ERROR (BadRequest): Block Device Mapping is Invalid: You specified more
local devices than the limit allows (HTTP 400) (Request-ID: req-3ef100c7-
b5c5-4a2d-a5da-8344726336e2)

-- 
Thanks & Regards
Ghanshyam Mann
__
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] In loving memory of Chris Yeoh

[GHANSHYAM MANN]

:( I am shocked to my core. He was so humble and helpful always. It would
be very hard to believe that he is no more.

God rest his soul in peace.


On Wed, Apr 8, 2015 at 1:49 PM, Michael Still  wrote:

> It is my sad duty to inform the community that Chris Yeoh passed away this
> morning. Chris leaves behind a daughter Alyssa, aged 6, who I hope will
> remember Chris as the clever and caring person that I will remember him as.
> I haven't had a chance to confirm with the family if they want flowers or a
> donation to a charity. As soon as I know those details I will reply to this
> email.
>
> Chris worked on open source for a very long time, with OpenStack being
> just the most recent in a long chain of contributions. He worked tirelessly
> on his contributions to Nova, including mentoring other developers. He was
> dedicated to the cause, with a strong vision of what OpenStack could
> become. He even named his cat after the project.
>
> Chris might be the only person to have ever sent an email to his coworkers
> explaining what his code review strategy would be after brain surgery. It
> takes phenomenal strength to carry on in the face of that kind of
> adversity, but somehow he did. Frankly, I think I would have just sat on
> the beach.
>
> Chris was also a contributor to the Linux Standards Base (LSB), where he
> helped improve the consistency and interoperability between Linux
> distributions. He ran the 'Hackfest' programming contests for a number of
> years at Australia's open source conference -- linux.conf.au. He
> supported local Linux user groups in South Australia and Canberra,
> including involvement at installfests and speaking at local meetups. He
> competed in a programming challenge called Loki Hack, and beat out the
> world to win the event[1].
>
> Alyssa's memories of her dad need to last her a long time, so we've
> decided to try and collect some fond memories of Chris to help her along
> the way. If you feel comfortable doing so, please contribute a memory or
> two at
> https://docs.google.com/forms/d/1kX-ePqAO7Cuudppwqz1cqgBXAsJx27GkdM-eCZ0c1V8/viewform
>
> Chris was humble, helpful and honest. The OpenStack and broader Open
> Source communities are poorer for his passing.
>
> Michael
>
> [1] http://www.lokigames.com/hack/
>
> __
> 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
>
>


-- 
Thanks & Regards
Ghanshyam Mann
__
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] Call to sign QA Bug Triage Rotation

[GHANSHYAM MANN]

All,

We started QA bug triage rotation last year and it helped us to respond to
bugs as quick as possible and keep bug count low.

To continue the same strategy and keeping good progress on bugs, we need
more volunteers to sign-up bug triage rotation.

People who want to help in bug triage, feel free to put your name in
https://etherpad.openstack.org/p/qa-bug-triage-rotation

-- 
Thanks & Regards
Ghanshyam Mann
__
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

[Ghanshyam Mann]

Yea, agree with dims.

Sampath ,

Thanks for taking over this, it is really great help. Please update the
current spec with approaches you have. Timur help will be great if he show
up sometime.

Also we will add destructive testing as one of weekly meeting agenda and
make sure you will get all help & required attention from QA team.

-gmann

On Fri, Feb 24, 2017 at 7:26 AM, Davanum Srinivas  wrote:

> Sampath,
>
> I am not sure if you will hear back from Timur soon as he may not be
> working on this stuff anymore (in Mirantis). So i'd recommend picking
> up the work if you don't hear from him soon.
>
> Thanks,
> Dims
>
> On Thu, Feb 23, 2017 at 3:41 PM, Sam P  wrote:
> > Hi Timur,
> >
> >  The current status of this work is,
> > 1) The QA user story for destructive testing of OpenStack cloud [1] is
> merged .
> > 2) The spec for a new framework which will focus on HA/failover and
> > destructive testing  [2] has no update since Nov 30 2016.
> > 3) The commit for the new repository [3]  has abandoned due to no
> > update after Nov 29 2016.
> >
> > Currently, I am working on 3rd party destructive/HA testing CI for
> > Masakari[4] and very much interested in this work.
> > I will keep working on [1] with PWG.
> > Please let me know your plans for [2], and [3].
> > If it is difficult for you to continue, I would love to continue your
> > work on [2], and [3].
> >
> > [1] https://review.openstack.org/#/c/396142
> > [2] https://review.openstack.org/#/c/399618
> > [3] https://review.openstack.org/#/c/374667
> > [4] https://wiki.openstack.org/wiki/Masakari
> > --- Regards,
> > Sampath
> >
> >
> >
> > On Mon, Nov 28, 2016 at 6:37 AM, Timur Nurlygayanov
> >  wrote:
> >> Hi team,
> >>
> >> here is a short update:
> >>
> >> 1) The QA user story for destructive testing of OpenStack cloud is on
> review
> >> [1].
> >> 2) The spec for a new framework which will focus on HA/failover and
> >> destructive testing is no review [2].
> >> 3) The commit for the new repository is on review [3] as well.
> >>
> >> [1] https://review.openstack.org/#/c/396142
> >> [2] https://review.openstack.org/#/c/399618
> >> [3] https://review.openstack.org/#/c/374667
> >>
> >>
> >> On Fri, Oct 14, 2016 at 3:47 AM, Ghanshyam Mann
> >>  wrote:
> >>>
> >>> I like os-faults library which can provide the abstraction over
> different
> >>> destructive actions like reboot/poweroff node etc.
> >>>
> >>>
> >>>
> >>> But not much clear about Stepler that what all tests it will contain.
> >>> Tempest do have scenario tests which can hit the production env with
> >>> significant way of testing scenario.
> >>>
> >>> It can cover the end user scenario also which involves the interaction
> of
> >>> public OpenStack APIs and always in enhancement state by adding more
> and
> >>> more scenario tests.
> >>>
> >>>
> >>>
> >>> Few query over Stepler as separate project:
> >>>
> >>> 1.   Is Stepler will cover only tests which hits the node level
> >>> action(reboot, HA etc)?
> >>>
> >>> 2.   This should not mix the scenario tests which are in Tempest
> scope
> >>> because that can make confusion for developers (where to add scenario
> tests)
> >>> as well as for tester(from where to run what scenario tests).
> >>>
> >>> 3.   How we make sure those tests run fine or at least run while
> >>> adding.
> >>>
> >>> a.   I think devstack enhancement for multi-node etc can do this as
> >>> mentioned by you also.
> >>>
> >>> b.  If so then why not adding those tests in Tempest only using
> >>> os-faults lib ?
> >>>
> >>>
> >>>
> >>> Overall I feel os-faults  as lib is really nice idea but tests scope
> can
> >>> go in Tempest under HW_scenario  (or something else) till it does not
> break
> >>> basic principle of Tempest.
> >>>
> >>>
> >>>
> >>> Thanks
> >>>
> >>> gmann
> >>>
> >>>
> >>>
> >>> From: Timur Nurlygayanov [mailto:tnurlygaya...@mirantis.com]
> >>> Sent: 06 October 2016 20:09
> >>> To: OpenStack Development Mailing List (not for usage questions)
> >>> 

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

[Ghanshyam Mann]

Yea, there is no doubt we should refactor scenario tests but even those are
internal interface it breaks plugins. We can argue that plugins should not
be using those but before that tempest should have all required
interface/class/helper as stable interface for plugins. which is what
scenario tests refactoring is trying to do.

​​I agree with the process Andrea defined and we should follow the same. If
we can put a deadline for projects to fix, we can speed up our work of
refactoring. I propose to keep refactoring patch for 2 week (including
comments fixes etc) and give time to plugins to fix and yes we will help
them. ​
After 2 week of time, we do not guarantee about any plugin failure (with
very rare exception if interface is being used very widely)

Let's not break plugins (what we doing as max as possible) but we really
need each plugins helps on those. QA team fix plugins since starting and we
have submitted lot of patches for many plugins to fix them and many of them
never got attention or reviewed.
For such cases (which falls under 2 week of deadlines), yes plugins needs
to take full responsibility if any of the tempest interface break them.

-gmann

On Mon, Feb 27, 2017 at 3:13 AM, Andrea Frittoli 
wrote:

>
> On Sun, Feb 26, 2017 at 12:49 AM Masayuki Igawa  wrote:
>
>> Hi,
>>
>> Thank you for bringing this up.
>>
>> Yeah, I understand your frustration. We already have the document about
>> our stable interface[1]. It says
>> --
>> Stability
>> Any code that lives in tempest/lib will be treated as a stable interface.
>> This means that any public interface under the tempest/lib directory is
>> expected to be a stable interface suitable for public consumption. However,
>> for any interfaces outside of tempest/lib in the tempest tree (unless
>> otherwise noted) or any private interfaces the same stability guarantees
>> don't apply.
>> --
>>
>> So we can change private interfaces basically. However, I also assume
>> that this document is not well known(or people just ignore it, though,
>> maybe). So I'd like to advertise this policy here, and discuss it (if the
>> discussion is needed.)
>>
>> [1] https://docs.openstack.org/developer/tempest/library.html#stability
>>
>> On Sat, Feb 25, 2017 at 22:39 Jordan Pittier 
>> wrote:
>>
>> Hi guys,
>> So I have a problem with these 2 patches here [1] and here [2]. You
>> basically are blocking any attempt of refactoring manager.py. Refactoring
>> that file has been our number one priority for 2 cycles, and so far hardly
>> no one stepped up really to do the work, except me with these 2 patches.
>> Let me remind you that that file is a gigantic mess, an so are our network
>> scenarios.
>>
>> The manager.py file in the scenarios directory has no stable interface,
>> and it was never "advertised" so. That some plugins decided to use some
>> private methods (such as this _get_network_by_name) is unfortunate but that
>> should not block us from moving.
>>
>>
> I agree this should not block us from moving, and as you mentioned we
> definitely need to move and I appreciate the fact that you started the work!
>
>
>>
>> So just to be clear, if we really want to refactor our scenarios (and we
>> must in my opinion), things will break for projects that are importing
>> Tempest and using it outside of its stable interface. I am not interested
>> in being the good Samaritan for the whole OpenStack galaxy, I have enough
>> with the 6 core projects and the Tempest stable interface. So guys, if you
>> are and don't want to go forward with [1] and [2], be sure I'll never touch
>> those scenarios again. I am not upset, but we have to make clear decisions,
>> sometimes difficult.
>>
>>
> We have no way to know exactly who's using unstable interfaces in Tempest,
> so it's likely someone will have to change their code as a consequence of
> the refactor.
> But I think it's important that we are good citizens and advertise well
> what's going to change, even if it's about an interface which is not
> declared as stable.
>
>
>> [1] : https://review.openstack.org/#/c/436555/
>> [2] : https://review.openstack.org/#/c/438097/
>> 
>> __
>> 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
>>
>> --
>> 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
>
>
> 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.sc

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

[Ghanshyam Mann]

Doing gradual refactoring and fixing plugins time to time needs lot of wait
and sync.

That needs:
1. Plugins to switch from current method usage. Plugins to have some other
function or same copy paste code what current scenario base class has.
2. Tempest patch to wait for plugin fix.
3. Plugins to switch back to stable interface once Tempest going to provide
those.

This needs lot of sync between tempest and plugins and we have to wait for
tempest refactoring patch for long.

To make it more efficient, how about this:
1. Keep the scenario manger copy in tempest as it is. for plugins usage
only.
2. Start refactoring the scenario framework by adding more and more helper
function under /common or lib.
3. Once we feel all needed by scenario tests are available as stable
helper, then ask each plugins to switch to stable interface.
4. After all helpers are available, with deprecation period of 1 cycle
remove the scenario base class.

​Other way can be have copy of scenario manager or used interfaces in each
plugins (as mentioned by Andrea) but that needs changes in almost all
plugins and slow down Tempest work.​

​Have a look in this patch- https://review.openstack.org/#/c/439291/


-gmann

On Tue, Feb 28, 2017 at 3:28 AM, Ken'ichi Ohmichi 
wrote:

> 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 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][gate][all] dsvm gate stability and scenario tests

[Ghanshyam Mann]

Thanks. +1. i added my list in ethercalc.

Left put scenario tests can be run on periodic and experimental job. IMO on
both ( periodic and experimental) to monitor their status periodically as
well as on particular patch if we need to.

-gmann

On Fri, Mar 3, 2017 at 4:28 PM, Andrea Frittoli 
wrote:

> Hello folks,
>
> we discussed a lot since the PTG about issues with gate stability; we need
> a stable and reliable gate to ensure smooth progress in Pike.
>
> One of the issues that stands out is that most of the times during test
> runs our test VMs are under heavy load.
> This can be the common cause behind several failures we've seen in the
> gate, so we agreed during the QA meeting yesterday [0] that we're going to
> try reducing the load and see whether that improves stability.
>
> Next steps are:
> - select a subset of scenario tests to be executed in the gate, based on
> [1], and run them serially only
> - the patch for this is [2] and we will approve this by the end of the day
> - we will monitor stability for a week - if needed we may reduce
> concurrency a bit on API tests as well, and identify "heavy" tests
> candidate for removal / refactor
> - the QA team won't approve any new test (scenario or heavy resource
> consuming api) until gate stability is ensured
>
> Thanks for your patience and collaboration!
>
> Andrea
>
> ---
> irc: andreaf
>
> [0] http://eavesdrop.openstack.org/meetings/qa/
> 2017/qa.2017-03-02-17.00.txt
> [1] https://ethercalc.openstack.org/nu56u2wrfb2b
> [2] https://review.openstack.org/#/c/439698/
>
> __
> 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] Disabling glance v1 by default in devstack

[Ghanshyam Mann]

On Sat, Mar 4, 2017 at 6:01 AM, Andrea Frittoli 
wrote:

>
>
> On Fri, Mar 3, 2017 at 7:38 PM Matt Riedemann  wrote:
>
>> I've got a change proposed to disable glance v1 by default in devstack
>> for Pike [1].
>>
>> The glance v1 API has been deprecated for awhile now. Nova started
>> supporting glance v2 in Newton and removed the ability to use nova with
>> glance v1 in Ocata.
>>
>> It also turns out that Tempest will do things with glance v1 over v2
>> during test setup of glance v1 is available, so we're missing out on
>> some v2 coverage.
>>
> +1. We should really test v2 as opposed to v1.
>

​+1, we have lot of if else and coverage issue by having both version in
tempest.
First step with deprecation on config options. -
https://review.openstack.org/#/c/442939/1




>
>
>>
>> The time has come to change the default. If you have a project or CI
>> jobs that require glance v1, first, you should probably start moving to
>> v2, and second, you can re-enable this by setting GLANCE_V1_ENABLED=True
>> in the settings/localrc for your devstack plugin.
>>
>> [1] https://review.openstack.org/#/c/343129/
>>
>> --
>>
>> 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 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 Mar 9th at 9:00 UTC

[Ghanshyam Mann]

Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, Mar 9th at 9:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:

https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_March_9th_2017_.280900_UTC.29


Anyone is welcome to add an item to the agenda.
-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

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

[Ghanshyam Mann]

Thanks Luz,

We will discuss the same in today meeting. Saw your report on etherpad too.

-gmann

On Thu, Mar 9, 2017 at 7:22 AM, Cazares, Luz  wrote:

> Hey gmann
>
>
>
> I did bug triage last weeks (27th Feb – 3rd March).
>
>
>
> So far 7 new bugs arrived:
>
> 3 confirmed (2 low, 1 medium)
>
> #1669455 tempest run --regex '\[.*\bsmoke\b.*\]' 
> --blacklist-file=/home/jenkins/tempest/skip.txt
> not able to run smoke tests
> <https://bugs.launchpad.net/tempest/+bug/1669455>
>
> #1668690 Tempest test_server_actions missing evacuate server test (and
> client) <https://bugs.launchpad.net/tempest/+bug/1668690>
>
> #1668407 os-assisted-volume-snapshots client is not available
> <https://bugs.launchpad.net/tempest/+bug/1668407>
>
> 1 in-progress
>
> #1667354 Volume v2 capabilities & scheduler-stats service clients makes
> v1 APIs call <https://bugs.launchpad.net/tempest/+bug/1667354>
>
> 2 incomplete
>
> #1667443 API endpoints become
> inaccessible after tempest run
> <https://bugs.launchpad.net/tempest/+bug/1667443>
>
> #1671256 test_get_volume_absolute_limits
> fails with no admin credentials
> <https://bugs.launchpad.net/tempest/+bug/1671256>
>
> 1 reviewing – not sure if it is a valid bug or working as
> designed – Related to resource_cleanup vs teardown (clean after each test
> case).
>
> #1670693 Tests in
> tempest.api.network.test_routers.RoutersTest don't clean up network
> resources <https://bugs.launchpad.net/tempest/+bug/1670693>
>
>
>
> Please let me know if comments or questions
>
>
>
>
>
> *From: *Ghanshyam Mann 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Wednesday, March 8, 2017 at 1:09 AM
> *To: *"openstack-dev@lists.openstack.org"  openstack.org>
> *Subject: *[openstack-dev] [QA] Meeting Thursday Mar 9th at 9:00 UTC
>
>
>
> Hello everyone,
>
> Please reminder that the weekly OpenStack QA team IRC meeting will be
> Thursday, Mar 9th at 9:00 UTC in the #openstack-meeting channel.
>
> The agenda for the meeting can be found here:
>
> https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#
> Agenda_for_March_9th_2017_.280900_UTC.29
>
> Anyone is welcome to add an item to the agenda.
>
> -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] [api][qa][tc][glance][keystone][cinder] Testing of deprecated API versions

[Ghanshyam Mann]

On Fri, Mar 10, 2017 at 7:23 AM, Lance Bragstad  wrote:

>
>
> On Thu, Mar 9, 2017 at 3:46 PM, Doug Hellmann 
> wrote:
>
>> Excerpts from Andrea Frittoli's message of 2017-03-09 20:53:54 +:
>> > Hi folks,
>> >
>> > I'm trying to figure out what's the best approach to fade out testing of
>> > deprecated API versions.
>> > We currently host in Tempest API tests for Glance API v1, Keystone API
>> v2
>> > and Cinder API v1.
>> >
>> > According to the guidelines for the "follow-standard-deprecation" tag
>> [0],
>> > when projects that have that tag deprecate a feature:
>> >
>> > "Code will be frozen and only receive minimal maintenance (just so that
>> it
>> > continues to work as-is)."
>> >
>> > I interpret this so that projects should maintain some level of testing
>> of
>> > the deprecated feature, including a deprecated API version.
>> > The QA team does not see value in testing deprecated API versions in the
>> > common gate jobs, so my question is what do to with those tests.
>> >
>> > One option is to maintain them in Tempest until the API version is
>> removed,
>> > and run them in dedicated project jobs.
>> > This means that tempest would have to run those jobs as well, so three
>> > extra jobs, until the API version is removed.
>> >
>> > The other option is to move those tests out of Tempest, into the
>> projects.
>> > This would imply back porting them to all relevant branches as well,
>> but it
>> > would have the advantage of decoupling them from Tempest. It should be
>> no
>> > concern from an API stability POV since the code for that API will be
>> > frozen.
>> > Tests for deprecated APIs in cinder, keystone and glance are all - as
>> far
>> > as I can tell - removed or deprecated from interoperability guidelines,
>> so
>> > moving the tests out of Tempest would not be an issue in that sense.
>> >
>> > The 2nd option involves a bit more initial overhead for the removal of
>> > tests, but I think it would works for the best on the long term.
>> >
>> > There is a 3rd option as well, which is to stop running integration
>> testing
>> > on deprecated API versions before they are actually removed, but I feel
>> > that would not meet the criteria defined by the
>> follow-standard-deprecation
>> > tag.
>> >
>> > Thoughts?
>> >
>> > andrea
>>
>> Are any of those tests used by the interoperability working group
>> (formerly DefCore)?
>>
>>
> That's a good question. I was very curious about this because last I
> checked keystone had v2.0 calls required for defcore. Looks like that might
> not be the case anymore [0]? I started a similar thread to this after the
> PTG since that was something our group talked about extensively during the
> deprecation session [1].
>
> ​Yes, it seems no Volume v1 and Keystone v2 tests usage in defcore
2017.01.json [0]​. But there are some compute tests which internally use
glance v1 API call [2]. But on mentioned flagged action- Nova already moved
to v2 APIs and tempest part is pending which can be fixed to make call on
v2 APIs only (which can be part of this work and quick).

​From options about deprecated APIs testing, I am with options 2 which
really take out the load of Tempest tests maintenance and gate.   ​

​But another question is about stable branch testing of those API, like
glance v1 and identity v2 APIs are supported (not deprecated) in Mitaka.
​As Tempest is responsible of testing all stable branch behavior too, Should
 we keep testing them till all Mitaka EOL (till APIs are in deprecated
state in all stable branch) ?​




>
> [0] https://github.com/openstack/defcore/blob/master/2017.01.json
> [1] http://lists.openstack.org/pipermail/openstack-dev/
> 2017-March/113166.html
>
> ​[2]
https://git.openstack.org/cgit/openstack/defcore/tree/2017.01.json#n294  ​

>
>
>> Doug
>>
>> >
>> > [0]
>> > https://governance.openstack.org/tc/reference/tags/assert_fo
>> llows-standard-deprecation.html
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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] [api][qa][tc][nova][cinder] Testing of a microversioned world

[Ghanshyam Mann]

On Sun, Mar 12, 2017 at 7:40 AM, Matt Riedemann  wrote:

> On 3/10/2017 3:02 PM, Andrea Frittoli wrote:
>
>>
>> We had a couple of sessions related to this topic at the PTG [0][1].
>>
>> We agreed that we want to still maintain integration tests only in
>> Tempest, which means that API micro versions that have no integration
>> impact can be tested via functional tests.
>>
>
> To be clear, "integration" here means tests that span operations across
> multiple services, correct? Like a compute test that first creates a port
> in the networking service and a volume in the block storage service and
> then uses those to create a server and maybe take a snapshot of it which is
> then verified was uploaded to the image service.
>
> The non-integration things are self-contained in a single service, like if
> all you need to do is create an aggregate, show it's details and validate
> the response, at a particular microversion, we can just do that in nova
> functional tests, and it's not necessary in Tempest.
>
> It might be worth having a definition of this policy in the Tempest docs
> so when people ask this question again you can just point at the docs.
>
>
​Yes, that will be helpful to have those agreement in doc​. I am adding
those in existing microversion testing doc [0] and later will be
refactoring to give them better and more visible shape.

Tempest maintain the info about what microversion tests are is implemented
on Tempest side which will be helpful for projects to check the coverage
[1]. Cinder one was missed which I added in [2].

​As summary:
Tempest Scope:
- Only Integration tests for microversion is allowed in Tempest
- Exception for non integration tests to fill the schema gap if exists.

Project Scope:
- Remaining tests coverage of microversion​ should be on Projects side.
  - Project can cover those as functional tests etc.
  - Nova currently have at least one functional tests per each
microversion and plan to extend coverage like [3]
  - IMO, only running tests with 'latest' microversion is not enough,
each microversion should be tested with positive and negative testing
(w.r.t at least immediate previous microversion).



>
>> In terms of which versions we test in the gate, for nova we always run
>> with min_microversion = None and max_microversion = latest, which means
>> that all tests will be executed.
>> Since micro versions are incremental, and each micro version usually
>> involves no or one test on Tempest side, I think it will be a while
>> before this becomes an issue for the common gate.
>>
>
> We test max_microversion=latest only on master. On the devstack stable
> branch we cap the max_microversion, e.g.:
>
> https://github.com/openstack-dev/devstack/blob/stable/newton
> /lib/tempest#L339
>
> --
>
> Thanks,
>
> Matt
>
>


..0 https://review.openstack.org/#/c/444727/1
..1
https://docs.openstack.org/developer/tempest/microversion_testing.html#microversion-tests-implemented-in-tempest

..2 https://review.openstack.org/#/c/444711/ ​
​..3
https://blueprints.launchpad.net/nova/+spec/nova-microversion-functional-tests
 ​

​​Thanks
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] [api][qa][tc][glance][keystone][cinder] Testing of deprecated API versions

[Ghanshyam Mann]

On Sat, Mar 11, 2017 at 12:10 AM, Andrea Frittoli  wrote:

>
>
> On Fri, Mar 10, 2017 at 2:49 PM Andrea Frittoli 
> wrote:
>
>> On Fri, Mar 10, 2017 at 2:24 PM Doug Hellmann 
>> wrote:
>>
>> Excerpts from Ghanshyam Mann's message of 2017-03-10 10:55:25 +0900:
>> > On Fri, Mar 10, 2017 at 7:23 AM, Lance Bragstad 
>> wrote:
>> >
>> > >
>> > >
>> > > On Thu, Mar 9, 2017 at 3:46 PM, Doug Hellmann 
>> > > wrote:
>> > >
>> > >> Excerpts from Andrea Frittoli's message of 2017-03-09 20:53:54 +:
>> > >> > Hi folks,
>> > >> >
>> > >> > I'm trying to figure out what's the best approach to fade out
>> testing of
>> > >> > deprecated API versions.
>> > >> > We currently host in Tempest API tests for Glance API v1, Keystone
>> API
>> > >> v2
>> > >> > and Cinder API v1.
>> > >> >
>> > >> > According to the guidelines for the "follow-standard-deprecation"
>> tag
>> > >> [0],
>> > >> > when projects that have that tag deprecate a feature:
>> > >> >
>> > >> > "Code will be frozen and only receive minimal maintenance (just so
>> that
>> > >> it
>> > >> > continues to work as-is)."
>> > >> >
>> > >> > I interpret this so that projects should maintain some level of
>> testing
>> > >> of
>> > >> > the deprecated feature, including a deprecated API version.
>> > >> > The QA team does not see value in testing deprecated API versions
>> in the
>> > >> > common gate jobs, so my question is what do to with those tests.
>> > >> >
>> > >> > One option is to maintain them in Tempest until the API version is
>> > >> removed,
>> > >> > and run them in dedicated project jobs.
>> > >> > This means that tempest would have to run those jobs as well, so
>> three
>> > >> > extra jobs, until the API version is removed.
>> > >> >
>> > >> > The other option is to move those tests out of Tempest, into the
>> > >> projects.
>> > >> > This would imply back porting them to all relevant branches as
>> well,
>> > >> but it
>> > >> > would have the advantage of decoupling them from Tempest. It
>> should be
>> > >> no
>> > >> > concern from an API stability POV since the code for that API will
>> be
>> > >> > frozen.
>> > >> > Tests for deprecated APIs in cinder, keystone and glance are all -
>> as
>> > >> far
>> > >> > as I can tell - removed or deprecated from interoperability
>> guidelines,
>> > >> so
>> > >> > moving the tests out of Tempest would not be an issue in that
>> sense.
>> > >> >
>> > >> > The 2nd option involves a bit more initial overhead for the
>> removal of
>> > >> > tests, but I think it would works for the best on the long term.
>> > >> >
>> > >> > There is a 3rd option as well, which is to stop running integration
>> > >> testing
>> > >> > on deprecated API versions before they are actually removed, but I
>> feel
>> > >> > that would not meet the criteria defined by the
>> > >> follow-standard-deprecation
>> > >> > tag.
>> > >> >
>> > >> > Thoughts?
>> > >> >
>> > >> > andrea
>> > >>
>> > >> Are any of those tests used by the interoperability working group
>> > >> (formerly DefCore)?
>> > >>
>> > >>
>> > > That's a good question. I was very curious about this because last I
>> > > checked keystone had v2.0 calls required for defcore. Looks like that
>> might
>> > > not be the case anymore [0]? I started a similar thread to this after
>> the
>> > > PTG since that was something our group talked about extensively
>> during the
>> > > deprecation session [1].
>> > >
>> > > ​Yes, it seems no Volume v1 and Keystone v2 tests usage in defcore
>> > 2017.01.json [0]​. But there are some compute tests which internally use
>> > glance v1 API call [2]. But on mentioned flagged action- Nova already
>> moved
>> > to v2 APIs and tempest part is pending which can be fixed to make call
>> on
>> > v2 APIs only (which can be part of this work and quick).
>> >
>> > ​From options about deprecated APIs testing, I am with options 2 which
>> > really take out the load of Tempest tests maintenance and gate.   ​
>> >
>> > ​But another question is about stable branch testing of those API, like
>> > glance v1 and identity v2 APIs are supported (not deprecated) in Mitaka.
>> > ​As Tempest is responsible of testing all stable branch behavior too,
>> Should
>> >  we keep testing them till all Mitaka EOL (till APIs are in deprecated
>> > state in all stable branch) ?​
>>
>> Excellent point.
>>
>>
>> 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
>>
>
> Of course Glance v1 still has to run on the stable/newton gate jobs, until
> Newton EOL (TBD), so tests will stay in Tempest for a cycle more at least.
> I guess I shouldn't be sending emails on a Friday afternoon?
>

​humm, Till Mitaka right? Newton version of glance is with v1 API as
deprecated. And Mitaka is v1 as supported APIs so we only need to care
about Mitaka where v1 APIs were supported and keep tests till Mitaka EOL.

Re: [openstack-dev] [QA] Meeting Thursday Mar 9th at 9:00 UTC (about bug: test_get_volume_absolute_limits fails with no admin credentials)

[Ghanshyam Mann]

This should be moved to admin dir with clear note like - [0].

force_tenant_isolation is right thing in that tests to avoid the test fails
due to other tenants volumes etc. We have similar case for quota tests too.


..0
https://github.com/openstack/tempest/blob/fe1a8e289c2d79df29beaa6b3603afe5feb60fb3/tempest/api/compute/admin/test_auto_allocate_network.py#L31


-gmann

On Mon, Mar 13, 2017 at 3:29 PM,  wrote:

> hello qa team,
>
>
> As to #1671256 test_get_volume_absolute_limits fails with no admin
> credentials <https://bugs.launchpad.net/tempest/+bug/1671256>
>
>
> This testcase will fail when admin credenticals are not present, because
> it uses force_tenant_isolation = True and is not in admin dirs(if it was,
> it would be skipped instead of fail)
>
>
> so, there are 3 possible solutions:
>
> 1) to move this testcase into admin dirs
>
> 2) to make Tempest skip testcases when
> ​​
> force_tenant_isolation = True and admin credenticals are not present
>
> 3) to fetch the existsing resources in the system, which will let the
> testcase run without admin credenticals, but may cause the code look a bit
> longer.
>
>
> so, I'd like you to give me some advice, which do you perfer,  thanks:)
>
>
> BR
>
> zhufl
>
>
> Original Mail
> *Sender: * ＜luz.caza...@intel.com＞;
> *To: * ＜openstack-dev@lists.openstack.org＞;
> *Date: *2017/03/09 06:28
> *Subject: **Re: [openstack-dev] [QA] Meeting Thursday Mar 9th at 9:00 UTC*
>
>
> Hey gmann
>
>
>
> I did bug triage last weeks (27th Feb – 3rd March).
>
>
>
> So far 7 new bugs arrived:
>
> 3 confirmed (2 low, 1 medium)
>
> #1669455 tempest run --regex '\[.*\bsmoke\b.*\]' 
> --blacklist-file=/home/jenkins/tempest/skip.txt
>  not able to run smoke tests
> <https://bugs.launchpad.net/tempest/+bug/1669455>
>
> #1668690 Tempest test_server_actions missing evacuate server test (and
> client) <https://bugs.launchpad.net/tempest/+bug/1668690>
>
> #1668407 os-assisted-volume-snapshots client is not available
> <https://bugs.launchpad.net/tempest/+bug/1668407>
>
> 1 in-progress
>
> #1667354 Volume v2 capabilities & scheduler-stats service clients makes
> v1 APIs call <https://bugs.launchpad.net/tempest/+bug/1667354>
>
> 2 incomplete
>
> #1667443 API endpoints become
> inaccessible after tempest run
> <https://bugs.launchpad.net/tempest/+bug/1667443>
>
> #1671256 test_get_volume_absolute_limits
> fails with no admin credentials
> <https://bugs.launchpad.net/tempest/+bug/1671256>
>
> 1 reviewing – not sure if it is a valid bug or working as
> designed – Related to resource_cleanup vs teardown (clean after each test
> case).
>
> #1670693 Tests in
> tempest.api.network.test_routers.RoutersTest don't clean up network
> resources <https://bugs.launchpad.net/tempest/+bug/1670693>
>
>
>
> Please let me know if comments or questions
>
>
>
>
>
> *From: *Ghanshyam Mann ＜ghanshyamm...@gmail.com＞
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" ＜openstack-dev@lists.openstack.org＞
> *Date: *Wednesday, March 8, 2017 at 1:09 AM
> *To: *"openstack-dev@lists.openstack.org" ＜openstack-dev@lists.
> openstack.org＞
> *Subject: *[openstack-dev] [QA] Meeting Thursday Mar 9th at 9:00 UTC
>
>
>
> Hello everyone,
>
> Please reminder that the weekly OpenStack QA team IRC meeting will be
> Thursday, Mar 9th at 9:00 UTC in the #openstack-meeting channel.
>
> The agenda for the meeting can be found here:
>
> https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#
> Agenda_for_March_9th_2017_.280900_UTC.29
>
> Anyone is welcome to add an item to the agenda.
>
> -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] [api][qa][tc][nova][cinder] Testing of a microversioned world

[Ghanshyam Mann]

On Mon, Mar 13, 2017 at 7:37 PM, Andrea Frittoli 
wrote:

> On Sat, Mar 11, 2017 at 10:45 PM Matt Riedemann 
> wrote:
>
> On 3/10/2017 3:02 PM, Andrea Frittoli wrote:
> >
> > We had a couple of sessions related to this topic at the PTG [0][1].
> >
> > We agreed that we want to still maintain integration tests only in
> > Tempest, which means that API micro versions that have no integration
> > impact can be tested via functional tests.
>
> To be clear, "integration" here means tests that span operations across
> multiple services, correct? Like a compute test that first creates a
> port in the networking service and a volume in the block storage service
> and then uses those to create a server and maybe take a snapshot of it
> which is then verified was uploaded to the image service.
>
> Yes, indeed.
>
>
>
> The non-integration things are self-contained in a single service, like
> if all you need to do is create an aggregate, show it's details and
> validate the response, at a particular microversion, we can just do that
> in nova functional tests, and it's not necessary in Tempest.
>
> It might be worth having a definition of this policy in the Tempest docs
> so when people ask this question again you can just point at the docs.
>
>
> I agree, we need to go a better job at documenting this.
> I just want to avoid having a black and white rule that would not work.
>
> To me tests that should be in Tempest are tests that make sense to run
> against any change in any repo, and the reasons for that can be many:
> - the test involves multiple services (more that "it uses a token though")
> - the test covers a feature which is key for interoperability
> - the test must be reliable and not take too long
>
> ​+1. I added those in https://review.openstack.org/#/c/444727/​



> Based on this I don't it's possible to completely avoid the discussion
> about
> which test should in Tempest and which not, it's something to be considered
> on a test by test basis, based on a set of guidelines.
>
> We have an initial definition of scope in [0], but it's probably worth to
> elaborate
> more on it. I'll put up a patch so that the discussion on it can continue
> in
> gerrit.
>
> [0] https://docs.openstack.org/developer/tempest/test-
> removal.html#tempest-scope
>
>
> >
> > In terms of which versions we test in the gate, for nova we always run
> > with min_microversion = None and max_microversion = latest, which means
> > that all tests will be executed.
> > Since micro versions are incremental, and each micro version usually
> > involves no or one test on Tempest side, I think it will be a while
> > before this becomes an issue for the common gate.
>
> We test max_microversion=latest only on master. On the devstack stable
> branch we cap the max_microversion, e.g.:
>
> Thanks, good point.
>
>
>
> https://github.com/openstack-dev/devstack/blob/stable/
> newton/lib/tempest#L339
>
> --
>
> 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
>
>
__
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] [Patrole] Nominating Felipe Monteiro for patrole core

[Ghanshyam Mann]

+1.
Yea, Felipe is doing great work.

-gmann

On Fri, Mar 17, 2017 at 3:28 AM, BARTRA, RICK  wrote:

> Felipe has done a tremendous amount of work stabilizing, enabling gates,
> contributing new tests, and extensively reviewing code in the Patrole
> project. In fact, he is the number one contributor to Patrole in terms of
> lines of code. He is also driving direction in the project and genuinely
> cares about the success of Patrole. As core spots are limited, I am
> recommending that Felipe replace Sangeet Gupta (sg7...@att.com) as core
> due to Sangeet’s inactivity on the project.
>
>
>
> -Rick Bartra
>
> rb5...@att.com
>
> __
> 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] [os-university] [os-upstream-institute] NAME CHANGE

[Ghanshyam Mann]

Noted.

Also added redirect link on old wiki
https://wiki.openstack.org/wiki/OpenStack_University

-gmann

On Fri, Mar 17, 2017 at 6:47 AM, Ildiko Vancsa 
wrote:

> Hi All,
>
> Due to some issues around the name OpenStack University we unfortunately
> had to pick a new one.
>
> The new name of the program is OpenStack Upstream Institute.
>
> We renamed the corresponding assets as well, so please join or move to the
> #openstack-upstream-institute IRC channel. The new ML tag is
> os-upstream-institute.
>
> You can find the wiki page for the team and activities here:
> https://wiki.openstack.org/wiki/OpenStack_Upstream_Institute
>
> Sorry for the inconvenience.
>
> Thanks and Best Regards,
> Ildikó
> IRC: ildikov
> __
> 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][cinder] RFC: Cinder test on Tempest

[Ghanshyam Mann]

On Thu, Mar 23, 2017 at 7:02 AM, Ken'ichi Ohmichi 
wrote:

> 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
>

​+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.



>
> > 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.
>
>
​Yes, so devstack does set different catalog for v2 and v3 [0]​. Based on
those catalog_type configured on tempest config(we already have that for
volume API config) auth can select the right endpoints to make the API call.

All existing tests can be run for both API without any extra class or
change. This way we can get rid of 'api_version' in all volumes clients and
have them as single copy for v2 and v3 base.
Further v3 microversion tests can be implemented as accordingly by sending
the microversion header on API request. and devstack can tell Temepst not
to set microversion if catalog_type volume_v2 is being asked to run the
tests.

As you mentioned it can be same way we handle compute v2, v2.1 and +
microversion tests.



> > 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
>


​.. 0
http://git.openstack.org/cgit/opensta

[openstack-dev] [QA] Meeting Thursday Mar 23rd at 9:00 UTC

[Ghanshyam Mann]

Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, Mar 23rd at 9:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:

https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_March_23rd_2017_.280900_UTC.29


Anyone is welcome to add an item to the agenda.
-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-dev] [neutron][networking-odl][qa] What's the recommended behavior for SG Rules with ethertype='IPv6' and protocol='icmp' ?

[Ghanshyam Mann]

Hi All,

Tempest is testing SG rule creation and pinging scenario tests with
ethertype='IPv6' and protocol='icmp' [0].
In case of ethertype='IPv6', currently neutron accept protocol type
as 'icmp', 'icmpv6' and 'ipv6-icmp' which again seems like duplication of
SG rules bug on neutron side but not sure [1]

But it seems like some driver does not work with 'icmp' on IPv6, at least
ODL as mentioned in bug [2]. Where few others like ML2/OVS iptables driver
convert 'icmp' to 'icmpv6' when ethertype='IPv6' and had no issue with
'icmp'.

IMO neutron should keep accepting 'icmp' for IPv6 for backward
compatibility and legacy usage and tempest should test 'icmp' also along
with other protocol type.
But we need more feedback on that what is right way (as per backward
compatibility pov) and recommended way for having best behaviour for SG
rules on IPv6. What best can work for all plugins also?

.. 0

https://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/network/test_security_groups.py

https://git.openstack.org/cgit/openstack/tempest/tree/tempest/scenario/manager.py#n1116

.. 1 https://bugs.launchpad.net/neutron/+bug/1582500

.. 2 https://bugs.launchpad.net/tempest/+bug/1671366

.. 3
https://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/linux/iptables_firewall.py#n378


-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

Re: [openstack-dev] [neutron][networking-odl][qa] What's the recommended behavior for SG Rules with ethertype='IPv6' and protocol='icmp' ?

[Ghanshyam Mann]

On Sun, Mar 26, 2017 at 9:31 PM, Sridhar Gaddam  wrote:

>
>
> On Fri, Mar 24, 2017 at 7:27 PM, Brian Haley  wrote:
>
>> On 03/24/2017 06:41 AM, Ghanshyam Mann wrote:
>>
>>> Hi All,
>>>
>>> Tempest is testing SG rule creation and pinging scenario tests with
>>> ethertype='IPv6' and protocol='icmp' [0].
>>> In case of ethertype='IPv6', currently neutron accept protocol type
>>> as 'icmp', 'icmpv6' and 'ipv6-icmp' which again seems like duplication
>>> of SG rules bug on neutron side but not sure [1]
>>>
>>> But it seems like some driver does not work with 'icmp' on IPv6, at
>>> least ODL as mentioned in bug [2]. Where few others like ML2/OVS
>>> iptables driver convert 'icmp' to 'icmpv6' when ethertype='IPv6' and had
>>> no issue with 'icmp'.
>>>
>>> IMO neutron should keep accepting 'icmp' for IPv6 for backward
>>> compatibility and legacy usage and tempest should test 'icmp' also along
>>> with other protocol type.
>>> But we need more feedback on that what is right way (as per backward
>>> compatibility pov) and recommended way for having best behaviour for SG
>>> rules on IPv6. What best can work for all plugins also?
>>>
>>
>> Thanks for raising this issue.  Let me just restate it a little so it's
>> clear.
>>
>> 1. One can create an IPv6 rule using protocol value "icmp" today, and the
>> base security group code does the right thing changing the rule to be
>> correct for the underlying implementation, for example, "ipv6-icmp" for
>> iptables.  It doesn't look like all other drivers handle this properly.
>>
>> ​Well, let the Neutron API accept multiple values like
> "icmp/icmpv6/ipv6-icmp", but IMO it should store a single Security Group
> rule in the DB and raise "Duplicate error when similar rule is configured
> once again".
> Currently, Neutron treats each of them as a different Security Group rule
> and stores them as separate entries in the DB.
> However, IPtables Firewall driver in Neutron is converting[1] the
> "ethertype=IPv6 and protocol=icmp" as a request to ICMPv6 and applying the
> necessary ip-table rule.
> https://github.com/openstack/neutron/blob/stable/newton/
> neutron/agent/linux/iptables_firewall.py#L373
>
> Since this is not a documented behavior, other firewall drivers (which I
> guess could be an issue even with OVS firewall driver) may be missing this
> info.​
>

​++ for this, documentation could have helped this better way. ​



>
>
>> 2. The neutron API will accept multiple values - "icmp", "ipv6-icmp" and
>> "icmpv6" for an IPv6 rule, but it will create unique database entries for
>> each (I just verified that).  While that shouldn't create multiple entries
>> in the base iptables code, it will probably generate a warning in the logs
>> about a duplicate being suppressed.
>>
>>
>> So there are a few things that could be done:
>>
>> 1. Drivers need to accept "icmp" in order to be backwards-compatible with
>> the current code.
>>
>> 2. Duplicates should be detected and generate 409 (?) errors.
>>
>> 3. We should add a migration (IMO) where any duplicates are squashed.
>>
>> ​Agree with your points.
>


​Yes, 409 on same type again make sense. And it can be documented properly
that 'icmp'​ will be treated same as other protocol type for
​
Ethertype=IPv6 and user will get 409 if they try to create and expect 2
different SG rules with those different protocol_type.
This is something change in current behavior where both requests('icmp' and
'icmpv6') are treated as 2 separate rules. And so this new Tempest tests
will fail [1] which can be modified later.

With those points and current situation, I feel Tempest should tests the
current behavior proposed in [1] which will discover the drivers for point
1. Later based on bug [2] consensus we can change the tests accordingly.
I want to merge Tempest changes so that while changing anything on neutron
side, we know exactly what behavior we are going to change and its impact
etc.
Please leave comment on patch if any more feedback.



> ​
>
>> The open question is, do we want to change the DB to have a different
>> value here, like "icmpv6" ?  We could obviously add a migration where we
>> update the value.  The problem is that flag day could pose a problem if
&g

[openstack-dev] [nova] Nova API sub-team meeting

[Ghanshyam Mann]

Hi All,



We have weekly Nova API meeting tomorrow. The meeting is being held
Wednesday UTC1300 and irc channel is #openstack-meeting-4.



The proposed agenda and meeting details are here:



https://wiki.openstack.org/wiki/Meetings/NovaAPI



Please feel free to add items to the agenda.


-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