from:"GHANSHYAM MANN"

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

2014-08-17 Thread GHANSHYAM MANN

On Sun, Aug 17, 2014 at 1:27 AM, Marc Koderer m...@koderer.com wrote:

 Hi all,

 Am 15.08.2014 um 23:31 schrieb Jay Pipes jaypi...@gmail.com:
 
  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

2014-08-30 Thread 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 s...@dague.net 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] [qa] Meaning of 204 from DELETE apis

2014-06-12 Thread GHANSHYAM MANN

On Fri, Jun 13, 2014 at 8:42 AM, Christopher Yeoh cbky...@gmail.com wrote:

 On Fri, Jun 13, 2014 at 7:05 AM, David Kranz dkr...@redhat.com 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] [qa] [cinder] Do we now require schema response validation in tempest clients?

2014-05-01 Thread Ghanshyam Mann

Hi David, Ken'ichi,

Thursday, May 1, 2014 1:02 PM Ken'ichi Ohmichi ken1ohmi...@gmail.com: 
Hi David,

2014-05-01 5:44 GMT+09:00 David Kranz dkr...@redhat.com:
 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

2014-05-07 Thread Ghanshyam Mann

Hi All,

2014-05-07 22:53 GMT+09:00 David Kranz dkr...@redhat.com:
 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

2014-05-09 Thread 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

2014-05-09 Thread GHANSHYAM MANN

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

2014-05-09 Thread 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

2014-05-20 Thread 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 cbky...@gmail.com wrote:

 On Mon, May 19, 2014 at 9:12 PM, David Kranz dkr...@redhat.com 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 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 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.

   -David

 ___
 OpenStack-dev mailing 
 listOpenStack-dev@lists.openstack.orghttp

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

2014-05-20 Thread 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
oomi...@mxs.nes.nec.co.jpwrote:

 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?

2014-05-22 Thread 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?

2014-05-22 Thread 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 mtrein...@kortar.orgwrote:

 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] [Nova] [All] API standards working group

2014-09-24 Thread 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 jaypi...@gmail.com 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

2014-09-29 Thread GHANSHYAM MANN

]
  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 id of the created volume at [1]
 [3] $ cinder create --snapshot-id id of the created snapshot at [2] 1
 [4] $ cinder show id of the created volume at [3]

 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

2014-10-14 Thread GHANSHYAM MANN

On Wed, Oct 15, 2014 at 7:44 AM, Christopher Yeoh cbky...@gmail.com wrote:

 On Tue, 14 Oct 2014 09:45:44 -0400
 Jay Pipes jaypi...@gmail.com wrote:

  On 10/14/2014 12:52 AM, Christopher Yeoh wrote:
   On Mon, 13 Oct 2014 22:20:32 -0400
   Jay Pipes jaypi...@gmail.com 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] [QA][Tempest] Proposing Ghanshyam Mann for Tempest Core

2014-11-26 Thread 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 mtrein...@kortar.org
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 m...@koderer.com
  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=ghanshyammannmetric=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

2014-11-28 Thread GHANSHYAM MANN

Tests can be skipped based on configuration file options. Its all depend on
what all set of tests you want to skip for your environment.

For example- to skip all sahara tests (as you mentioned)

You can make config option - 'sahara' to false which will skip all sahara
tests.

Particular feature of services can be skipped by same way if those have
specific configuration options (like IPv6) or through extension list
''api_extension of specific service.

On Fri, Nov 28, 2014 at 6:24 PM, om prakash pandey pande...@gmail.com
wrote:

Thanks Sridhar.

I'm aware of using skipException for skipping tests at class level.
However, this involves putting it in every class to skip tests which are
not desired.

I was looking for a way to control the tests I want to run through some
kind of a configuration file, the options to pass to test runner.

Regards
Om

On Fri, Nov 28, 2014 at 2:02 PM, Sridhar Gaddam
sridhar.gad...@enovance.com wrote:

If the deployment does not support IPv6, we use the following convention
to skip the tests at class level.

https://github.com/openstack/tempest/blob/master/tempest/api/network/base.py#L65

Regards,
--Sridhar.

On 11/28/2014 01:50 PM, om prakash pandey wrote:

Hi Folks,

I would like to know about the best practices followed for skipping
tests not applicable for my environment.

I know one of the ways is to use the below decorator over the test
method:
@test.skip_because(bug=BUG_ID)

However, what if my deployment doesn't support VPNAAS and I want to
skip those tests. Similarly, what if I want to skip the entire suite of
sahara(data processing) tests.

Are there any options in testr to customize running of tempest tests as
per my environment/requirements?

Regards,
Om

On Wed, Nov 26, 2014 at 3:13 AM, Vineet Menon mvineetme...@gmail.com
wrote:

Hi,
Thanjs for clearing that up... I had a hard time understanding the
screws before I went with testr.

Regards,
Vineet
On 25 Nov 2014 17:46, Matthew Treinish mtrein...@kortar.org wrote:

On Mon, Nov 24, 2014 at 10:49:27AM +0100, Angelo Matarazzo wrote:
Sorry for my previous message with wrong subject

Hi all,
By reading the tempest documentation page [1] a user can run tempest
tests
by using whether testr or run_tempest.sh or tox.

What is the best practice?
run_tempest.sh has several options (e.g. ./run_tempest.sh -h) and it
is my
preferred way, currently.
Any thought?

So the options are there for different reasons and fit different
purposes. The
run_tempest.sh script exists mostly for legacy reasons as some people
prefer to
use it, and it predates the usage of tox in tempest. It also has some
advantages
like that it can run without a venv and provides some other options.

Tox is what we use for gating, and we keep most of job definitions for
gating in
the tox.ini file. If you're trying to reproduce a gate run locally
using tox is
what is recommended to use. Personally I use it to run everything just
because
I often mix unit tests and tempest runs and I like having separate
venvs for
both being created on demand.

Calling testr directly is just what all of these tools are doing under
the
covers, and it'll always be an option.

One thing we're looking to do this cycle is to add a single entry point
for
running tempest which will hopefully clear up this confusion, and make
the
interface for interacting with tempest a bit nicer. When this work is
done, the
run_tempest.sh script will most likely disappear and tox will probably
just be
used for gating job definitions and just call the new entry-point
instead of
testr directly.

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

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

2015-01-21 Thread 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] Tempest Bug triage

2015-01-08 Thread 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 dkr...@redhat.com 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] Tempest Bug triage

2015-02-19 Thread 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] [nova] what is our shipped paste.ini going to be for Kilo

2015-03-16 Thread GHANSHYAM MANN

Hi Sean-

On Mon, Mar 16, 2015 at 11:15 PM, Sean Dague s...@dague.net wrote:

 Our current top level shipped example paste.ini for Nova includes the
 following set of endpoint definitions:

 [composite:osapi_compute]
 use = call:nova.api.openstack.urlmap:urlmap_factory
 /: oscomputeversions
 /v1.1: openstack_compute_api_v2
 /v2: openstack_compute_api_v2
 /v2.1: openstack_compute_api_v21
 /v3: openstack_compute_api_v3


 The real question I have is what should this look like in the Kilo
 release. And this has a couple of axes.

  Who uses our paste.ini?
 =

 paste.ini is an etc file, so we assume that during upgrade you'll be
 using your existing config. Changes to the default paste.ini will
 really only be effective in new deploys. So this should not impact
 existing users, but instead only new users.

 Cleaning up Cruft
 =

 Drop of /v3
 ---

 v3 is no longer a supported thing. I think v3 in the paste.ini causes
 confusion. It also causes us to keep around untested / unsupported
 code.

 This seems kind of a no brainer.

 Drop of /v1.1 ?
 ---

 Only new deploys are really going to base off of our in tree
 config. I'm not convinced that we want to encourage people setting up
 new /v1.1 endpoint in tree.

 I'm not convinced there is a deprecation path here because the ones I
 could imagine would involve people changing their paste.ini to include
 a deprecation checking piece of code.

 Honestly, I don't care strongly either way on this one. It's cruft,
 but not dangerous cruft (unlike v3).

 +1


 Nova v2
 ===

 This is where things get interesting.

 v2.1 is supposed to be equivalent to v2. The difference is moving the
 validation for datastructures from the database to the wsgi layer. The
 ways in which this doesn't react like the existing APIs should be
 basically not letting you create corrupt data models which will
 explode later in unexpected and hard to determine ways. The reality is
 objects validation has been sneaking this in all along anyway.

 The full monty approach
 ---

 [composite:osapi_compute]
 use = call:nova.api.openstack.urlmap:urlmap_factory
 /: oscomputeversions
 /v1.1: openstack_compute_api_v2
 /v2: openstack_compute_api_v21
 # starting in Kilo the v21 implementation replaces the v2
 # implementation and is suggested that you use it as the default. If
 # this causes issues with your clients you can rollback to the
 # *frozen* v2 api by commenting out the above stanza and using the
 # following instead::
 # /v2: openstack_compute_api_v2
 # if rolling back to v2 fixes your issue please file a critical bug
 # at - https://bugs.launchpad.net/nova/+bugs

 This would make the v2 endpoint the v21 implementation for new
 deploys. It would also make it easy for people to flip back if they
 hit an edge condition we didn't notice.

 +1. I think that will be the way to move forward with better APIs
otherwise it will go in wait state for couple of cycles:).


 In functional testing we'd still test both v2 and v2.1

 Tempest would move to v2.1 by default, and I think we should put an
 old v2 job on nova stable/kilo - master to help us keep track of
 regressions.

 Patches are up to make v2.1 as default one in devstack (for gate jobs) -
https://review.openstack.org/#/c/163731/  Depends-On patches.


 The slow roll approach
 --

 Ship the existing file (minus v3):

 [composite:osapi_compute]
 use = call:nova.api.openstack.urlmap:urlmap_factory
 /: oscomputeversions
 /v1.1: openstack_compute_api_v2
 /v2: openstack_compute_api_v2
 /v2.1: openstack_compute_api_v21

 The advantages here is that out of the box stuff keeps working. The
 dilema here is it's not really clear that we'll get people poking at
 v2.1 because it will be out of the main path. The point of the
 microversioning was to get folks onto that train soon because it falls
 back to existing API. And once we are convinced we're good we can
 deprecate out the old implementation.

 Also, things like out of tree EC2 support requires v2.1, which is
 going to make deploys start relying on a /v2.1 endpoint that want EC2,
 so our options for grafting that back onto /v2 in the future are more
 limitted.

 Decision Time
 =

 Anyway, this is a decision we should make before freeze. The 'no
 decision' case gives us the slow roll. I think from an upstream
 perspective the full monty will probably serve 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

Re: [openstack-dev] removal of v3 in tree testing

2015-03-04 Thread 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 s...@dague.net 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

2015-03-05 Thread 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 s...@dague.net 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

[openstack-dev] [Nova][QA] Use case of Nova to boot VM from volume only

2015-04-03 Thread 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

[openstack-dev] [qa] Call to sign QA Bug Triage Rotation

2015-04-16 Thread 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] In loving memory of Chris Yeoh

2015-04-08 Thread 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 mi...@stillhq.com 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

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

2015-06-22 Thread GHANSHYAM MANN

+1 :)

On Tue, Jun 23, 2015 at 5:23 AM, Matthew Treinish mtrein...@kortar.org
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=marksuser_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

2015-06-25 Thread GHANSHYAM MANN

, this list of states is (AIUI) not part of the API contract;
rather the verbs available to move between states are.

What's the point in contract, if there are things not covered by it that
drastically change the system behavior?

As far as JSON fields, we've never had a contract around what keys are
available. Only the semantics of working with those fields, and which
fields exist.

ditto as above: you can request new features by modifying driver_info.

c) It gives additional push back to making (required) breaking changes.
We
already got suggestions to have ONE MORE feature gating for breaking
changes. Reason: people will need to increase microversions to get
features,
and your breaking change will prevent it.

This is just silly. If 1.10 breaks a user, and the user wants 1.11,
they'll need to fix that breakage.

++ but not everyone agreed on the summit, when I was talking about
ENROLL state

d) It requires a hard compromise on the CLI tool. You either default it
to
1.0 forever, and force all the people to get used to figuring out
version
numbers and using `ironic --ironic-api-version x.y` every time
(terrible
user experience), or you default it to some known good version, bumping
it
from time to time. This, in turn, has 2 more serious problems:

I disagree that pinning a version all the time is a terrible experience.
We already require a number of options for authentication (OS_USERNAME,
OS_PASSWORD, etc etc). How many folks do 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

--
Thanks Regards
Ghanshyam Mann

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

2015-06-25 Thread GHANSHYAM MANN

 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

2015-06-27 Thread GHANSHYAM MANN

On Fri, Jun 26, 2015 at 3:43 PM, Dmitry Tantsur divius.ins...@gmail.com wrote:

26 июня 2015 г. 2:47 пользователь GHANSHYAM MANN ghanshyamm...@gmail.com
написал:

On Sat, Jun 20, 2015 at 9:14 AM, Devananda van der Veen
devananda@gmail.com 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 well written document for each version about what they
are introduced for but still that
information in new version can be useful.

If older version shows what is in newer version(backward comp) then,
there is no meaning
of introducing those compatible changes as microversion. And if so
then it blank out whole
idea of publishing changes/features through microversion even they are
backward compatible.

The main reason for versioning is feature discovery. It had nothing to do
with feature hiding. Please read the whole thread to see why feature hiding
is actually harmful.

I can understand your concern here and somehow i agree on the problems
you mentioned
in initial thread. But we have to trade-off between developers pain vs
breaking Apps ion upgrade.

i also agree feature hiding can be very painful in some cases as you
mentioned ironic node state,
and their testing more, but allow new feature automatically in older
version on upgrade does break the App
as mentioned ijn early mail and Sean blog.

IMO, OpenSatck users/App/its usability takes priority than
developers/testing pain till we have better solution

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

2015-06-27 Thread GHANSHYAM MANN

On Fri, Jun 26, 2015 at 3:46 PM, Dmitry Tantsur divius.ins...@gmail.com wrote:

26 июня 2015 г. 2:48 пользователь GHANSHYAM MANN ghanshyamm...@gmail.com
написал:

On Thu, Jun 25, 2015 at 5:18 PM, Ken'ichi Ohmichi ken1ohmi...@gmail.com
wrote:
Sorry for late response here,

2015-06-20 9:14 GMT+09:00 Devananda van der Veen
devananda@gmail.com:

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.

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.

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 seemed really great for users at this time, and he extended the
application for using all features as possible.
but the specified microversion still is v1.1 because his application
worked fine even if using newer features.

After that, he needed to switch to the other cloud because of cost
merit or something.
The specified microversion was v1.1, so he did think his application
can work fine on cloud B also because of cloud B's max microversion.
But yes, his application could not work because his application had
already used newer features which are implemented on v1.2+.
In the real world, there are a lot of clouds and it is easy to imagine
this situation.

By the way, feature hiding did not change the situation: the application
using new features won't work on older cloud, period.

But application can control the new feature usage with version (with current
design of hiding new features in older versions). With that its going to work
on both new or older cloud.

If older cloud is not upgraded, app knows their max supported version,
and can behave/control new feature usage in their app.

This is really nice point. We should give power to users to decide whether
they
need/want to use/get the new features introduced in new microversion
irrespective
of it is backward compatible or not.

I'm already tried of asking why, but I'll try

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

2015-08-13 Thread GHANSHYAM MANN

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

On Sat, Aug 8, 2015 at 1:48 AM, Sean Dague s...@dague.net 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] should we combine a set of minor microversion bump needed fix into one microversoin bump?

2015-08-20 Thread GHANSHYAM MANN

On Thu, Aug 20, 2015 at 3:33 AM, Matt Riedemann
mrie...@linux.vnet.ibm.com 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] [nova] should we combine a set of minor microversion bump needed fix into one microversoin bump?

2015-08-20 Thread GHANSHYAM MANN

 Development Mailing 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] API: Question on 'Retry-After': 0 in HTTPForbidden

2015-08-18 Thread 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 jiche...@cn.ibm.com 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] Why is osapi_v3.enabled = False by default?

2015-07-15 Thread GHANSHYAM MANN

On Thu, Jul 16, 2015 at 3:03 AM, Sean Dague s...@dague.net 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] Proposal to add Alex Xu to nova-core

2015-11-07 Thread 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 <j...@johngarbutt.com> 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_id=xuhj=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] [api] [docs] Generating API samples

2015-08-25 Thread GHANSHYAM MANN

://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?

2015-09-06 Thread 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

2015-09-16 Thread 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

[openstack-dev] Fwd: [QA] Meeting Thursday December 10th at 9:00 UTC

2015-12-09 Thread 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] [tempest] clients/manager in plugins

2015-12-16 Thread 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 <r-m...@cq.jp.nec.com> 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 <r-m...@cq.jp.nec.com> 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" <r-m...@cq.jp.nec.com>
>> > 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] [tempest] clients/manager in plugins

2015-12-11 Thread GHANSHYAM MANN

Hi Ryota,

That is the one way as you mentioned.

On Fri, Dec 11, 2015 at 8:15 PM, Ryota Mibu <r-m...@cq.jp.nec.com> 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" <r-m...@cq.jp.nec.com>
> 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] [QA][Tempest] Drop javelin off tempest

2015-12-10 Thread 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 <mtrein...@kortar.org> 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] [nova][api] does validation bug-fix require microversion bump?

2015-12-21 Thread GHANSHYAM MANN

On Mon, Dec 21, 2015 at 4:25 PM, Ken'ichi Ohmichi <ken1ohmi...@gmail.com> 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

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

2015-11-18 Thread 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 <ken1ohmi...@gmail.com> 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 <yuikotakada0...@gmail.com>:
>>
>> 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] [QA] Meeting Thursday June 16th at 9:00 UTC

2016-06-16 Thread 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

2016-06-19 Thread 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)
> <openstack-dev@lists.openstack.org>
> 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

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

2016-06-15 Thread 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

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

2016-01-13 Thread 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

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

2016-06-15 Thread 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

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

2016-01-27 Thread 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] [Nova] Should we signal backwards incompatible changes in microversions?

2016-02-15 Thread GHANSHYAM MANN

Regards
Ghanshyam Mann


On Mon, Feb 15, 2016 at 12:07 PM, Alex Xu <sou...@gmail.com> 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 <and...@lascii.com>:
>>
>> 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?

2016-02-15 Thread 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 <annegen...@justwriteclick.com
> wrote:

>
>
> On Mon, Feb 15, 2016 at 6:03 PM, 少合冯 <lvmxhs...@gmail.com> 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

2016-02-16 Thread 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 <mtrein...@kortar.org> 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 <daniel.mellado...@ieee.org> 
>> > 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

2016-03-09 Thread 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

2016-03-12 Thread 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

2016-03-12 Thread 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 <j...@johngarbutt.com> 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] [nova][cinder] Fix nova swap volume (updating an attached volume) function

2016-03-30 Thread 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
>

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

2016-04-06 Thread 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] [ceilometer][tempest] disabling 'full' tempest tests for ceilometer changes in CI

2016-04-13 Thread 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 <cdent...@anticdent.org> 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

Re: [openstack-dev] [Congress] Issues with Tox testing

2016-04-12 Thread 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 <anusha.ii...@gmail.com> 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 <bls...@hotmail.com> 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 <bls...@hotmail.com> 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, B

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

2016-03-19 Thread 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

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

2016-03-20 Thread 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

2016-03-23 Thread 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 <okay22m...@163.com> 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" <g...@live.ca> 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

2016-03-24 Thread 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

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

2016-04-05 Thread 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
<shashi.k...@nectechnologies.in> 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

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

2016-03-31 Thread 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:

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

2016-03-31 Thread 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
<mrie...@linux.vnet.ibm.com> wrote:
>
>
> On 3/30/2016 9:14 PM, GHANSHYAM MANN wrote:
>>
>> On Thu, Mar 31, 2016 at 10:39 AM, Matt Riedemann
>> <mrie...@linux.vnet.ibm.com> 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

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

2016-04-20 Thread 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

[openstack-dev] [QA] Meeting Thursday July 28th at 9:00 UTC

2016-07-28 Thread Ghanshyam Mann

Hello everyone,



Please reminder that the weekly OpenStack QA team IRC meeting will be Thursday, 
July 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#Agenda_for_July_28th_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


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] Next steps for proxy API deprecation

2016-07-28 Thread Ghanshyam Mann


> -Original Message-
> From: Matthew Treinish [mailto:mtrein...@kortar.org]
> Sent: 27 July 2016 02:36
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [nova] Next steps for proxy API deprecation
> 
> On Tue, Jul 26, 2016 at 01:21:53PM -0400, Sean Dague wrote:
> > On 07/26/2016 01:14 PM, Matt Riedemann wrote:
> > > On 7/26/2016 11:59 AM, Matt Riedemann wrote:
> > >> Now that the 2.36 microversion change has merged [1], we can work
> > >> on the python-novaclient changes for this microversion.
> > >>
> > >> At the midcycle we agreed [2] to also return a 404 for network
> > >> APIs, including nova-network (which isn't a proxy), for consistency
> > >> and further signaling that nova-network is going away.
> > >>
> > >> In the client, we agreed to soften the impact for network CLIs by
> > >> determining if the latest microversion supported will fail (so will
> > >> we send >=2.36) and rather than fail, send 2.35 instead (if the
> > >> user didn't specifically specify a different version). However,
> > >> we'd emit a warning saying this is deprecated and will go away in
> > >> the first major client release (in Ocata? after nova-network is
> > >> removed? after Ocata is released?).
> > >>
> > >> We should probably just deprecate any CLIs/APIs in
> > >> python-novaclient today that are part of this server side API
> > >> change, including network CLIs/APIs in novaclient. The baremetal
> > >> and image proxies in the client are already deprecated, and the volume
> proxies were already removed.
> > >> That leaves the network proxies in the client.
> > >>
> > >> From my notes, Dan Smith was going to work on the novaclient
> > >> changes for
> > >> 2.36 to not fail and use 2.35 - unless anyone else wants to
> > >> volunteer to do that work (please speak up).
> > >>
> > >> We can probably do the network CLI/API deprecations in the client
> > >> in parallel to the 2.36 support, but need someone to step up for
> > >> that. I'll try to get it started this week if no one else does.
> > >>
> > >> [1] https://review.openstack.org/#/c/337005/
> > >> [2] https://etherpad.openstack.org/p/nova-newton-midcycle
> > >>
> > >
> > > I forgot to mention Tempest. We're going to have to probably put a
> > > max_microversion cap in several tests in Tempest to cap at 2.35 (or
> > > change those to use Neutron?). There are also going to be some
> > > response schema changes like for quota usage/limits, I'm not sure if
> > > anyone is looking at this yet. We could also get it done after
> > > feature freeze on 9/2, but I still need to land the get-me-a-network
> > > API change which is microversion 2.37 and has it's own Tempest test,
> > > although that test relies on Neutron so I might be OK for the most part.
> >
> > Is that strictly true? We could also just configure all the jobs for
> > Nova network to set max microversion at 2.35. That would probably be
> > more straight forward way of approaching this, and make it a bit more
> > clear how serious we are here.
> >
> 
> Yeah, for the gate that should work. By default tempest sends the minimum
> microversion based on the config and the test requirements. So we should
> never send 2.36 unless the test says it's minimum required microversion is
> >=2.36. Setting the max at 2.35 would mean we skip those tests. My bigger
> concern is for people using tempest outside of the gate. I still think we
> should set a max microversion on any test classes that call nova's network
> apis to make sure they're properly skipped just in case someone sets the min
> microversion in the tempest config at 2.36. (assuming such a test class exists
> at all, I don't actually know) Unless you thinking failing there is the 
> correct
> way to do it?

Yes, I also prefer the approach of capping the tests instead of jobs. But along 
with that we might need to make sure the same tests coverage Tempest provides 
if min_microversion is set >2.35 in config.
For example, if we cap the tests (calls nova-network) with max_microversion = 
2.35 then, we might need to implement/modify those tests to start using neutron 
which can be run if config's min_microversion
is set > 2.35.
There are two type of test cases-
1. Test only tests nova-network APIs - Example: 
https://github.com/openstack/tempest/tree/master/tempest/api/compute/floating_ips
 
2. Test testing other scenario using nova-network - Example: 
https://github.com/openstack/tempest/blob/master/tempest/api/compute/servers/test_server_rescue.py
 

1st case if all ok to cap and leave it skip for >2.35. But for 2nd case, I feel 
we should not leave them skip if config's min_microversion > 2.35 which mean 
leaving those scenario untested(if min_microversion >2.35).
There are 2 options for 2nd case:
  1. Implement  duplicate tests by using the neutron APIs - This will be 
duplicate tests but needed because of testing nova-network till newton EOL.
  2. Or modify those

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

2016-07-14 Thread GHANSHYAM MANN

Thanks Matt for bringing this up.

On Thu, Jul 14, 2016 at 11:55 AM, Matt Riedemann
 wrote:
> There are several changes in Tempest right now trying to add response schema
> validation for the 2.26 microversion which added server tags to the server
> GET response. This is needed for anything testing a microversion >=2.26,
> which several people are trying to add.
>
> We have a similar issue with the 2.3 microversion which is really a bug, but
> only exposed in jobs that have run_validation=True which is only in a
> non-voting job right now.
>
> I've mostly been debating this in this change:
>
> https://review.openstack.org/#/c/233176/
>
> I've added an item to the nova midcycle meetup agenda to talk about the plan
> for handling microversion testing in tempest for nova changes, specifically
> around API response validation.
>
> I agree that nova doesn't test response schema validation in tree, so doing
> it in tempest is good.
>
> But I'm not sure that we need a new set of tempest tests for every
> microversion change in nova, e.g. if it's only touching the API and
> database, like server tags, we can test that in nova.
>
> It's also not great having several changes in flight at the same time to
> tempest trying to add the same 2.26 response schema because it wasn't added
> the at the same time the 2.26 API merged.
>
> I also wonder what it means if someone configures max_microversion in
> tempest.conf to something we don't test, like say 2.11, what blows up? For
> example, we know that we don't have response validation for 2.3 so some
> tests are broken when you run with ssh validation and microversion>=2.3.

you mean if we increase min_microversion? For max_microversion
capping, It should just skip the tests which are going
out of configured boundary.

But yes there will be failure if we increase the min_microversion to
some higher version which schema is missing (as tests is not added).

2.3 schema was missed as this tests was not added yet in tempest. So
we might have same case in future also.

I am trying to add all version schema needed till Mitaka max supported
version which is 2.25 in https://review.openstack.org/#/c/287605/
After that, we should have all lower version schema available for
other version tests(<2.25). This should make things easy for other new
tests.

>
> So I'm thinking we should:
>
> 1. Always add a schema change to Tempest if a microversion changes a
> response.

We should not actually. Schema are more error prone if we add
manually. We have to be very careful on all attributes, their type and
range etc
which can be verified with tests only. Adding schema in Tempest may
end up adding wrong schema in Tempest.

>
> 2. Only add tests to Tempest for a microversion change if it can't be tested
> within nova, e.g. you actually need to create a server, or use other
> services like glance/cinder/neutron.

Almost +1.
Actually This is fine till we do not increase the min_microversion.
Any new version tests coming in Tempest should add lower version
schema also if needed. This is mentioned very clearly in doc [1] also.
But if anytime we increase the minimum version (which is almost
impossible) then yes, we should have tests for all microversion so
that no failure with schema things. Honestly saying, I would like to
ignore this case as of now as very rare to rare that nova will bump
minimum version.

I am agree on this But also want to tests each microversion changes
through schema which does not mean we need to add tests for each
microversion. Higher microversion tests(which are valid for Tempest
like interacting with other services etc) can verify same API's lower
version changes through schema automatically.

Tempest testing which does schema validation are very useful to find
API bugs. We have found many in past and recently also [2].  How about
this:
- Do not add tests for changes which can be tested in Nova as
mentioned by you in 2nd point with below exception:
- Exception- If that version need schema change and those schema
changes are not covered by any higher version tests then add tests in
Tempest.

And this we can done at end of each cycle to make sure each version
changes in this cycle are tested thorough schema validation (is change
in schema) in Tempest.

>
> mtreinish and sdague will be at the nova midcycle so hopefully they can
> represent for the QA team.

..[1] 
http://docs.openstack.org/developer/tempest/microversion_testing.html#notes-about-compute-microversion-tests
..[2]  https://bugs.launchpad.net/nova/+bug/1602044
>
> --
>
> 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

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

2016-07-14 Thread GHANSHYAM MANN

On Thu, Jul 14, 2016 at 12:08 PM, Matthew Treinish  wrote:
> On Wed, Jul 13, 2016 at 09:55:33PM -0500, Matt Riedemann wrote:
>> There are several changes in Tempest right now trying to add response schema
>> validation for the 2.26 microversion which added server tags to the server
>> GET response. This is needed for anything testing a microversion >=2.26,
>> which several people are trying to add.
>>
>> We have a similar issue with the 2.3 microversion which is really a bug, but
>> only exposed in jobs that have run_validation=True which is only in a
>> non-voting job right now.
>>
>> I've mostly been debating this in this change:
>>
>> https://review.openstack.org/#/c/233176/
>>
>> I've added an item to the nova midcycle meetup agenda to talk about the plan
>> for handling microversion testing in tempest for nova changes, specifically
>> around API response validation.
>>
>> I agree that nova doesn't test response schema validation in tree, so doing
>> it in tempest is good.
>>
>> But I'm not sure that we need a new set of tempest tests for every
>> microversion change in nova, e.g. if it's only touching the API and
>> database, like server tags, we can test that in nova.
>
> I largely agree with this, we don't need 100% coverage of every microversion.
> Especially if it's just an API that's just extra metadata in the DB.
>
>>
>> It's also not great having several changes in flight at the same time to
>> tempest trying to add the same 2.26 response schema because it wasn't added
>> the at the same time the 2.26 API merged.
>
> I agree it's not ideal, but it's not like there is a huge burden on rebasing,
> no more than for developers having to bump their microversions because another
> bp landed and took the microversion they were using.
>
>
>>
>> I also wonder what it means if someone configures max_microversion in
>> tempest.conf to something we don't test, like say 2.11, what blows up? For
>> example, we know that we don't have response validation for 2.3 so some
>> tests are broken when you run with ssh validation and microversion>=2.3.
>
> We can easily add a job that changes the min microversion config flag in 
> tempest
> to something higher than 2.1. This will ensure we send a higher microversion
> everywhere and will catch these issues sooner. But, I'm not sure we want to do
> that on a normal check/gate job.

Yes, there will be lot of tests failure not with schema thing only but
we do tests some bit
in tests which might got changed in versions.

But we have plan for that. to detect those tests and modify/cap with
appropriate boundary. But not sure when :)


>
>>
>> So I'm thinking we should:
>>
>> 1. Always add a schema change to Tempest if a microversion changes a
>> response.
>
> The problem with this is we shouldn't land a schema change by itself in 
> tempest.
> Until we have something using the schema we have no verification that they
> actually work. We can and will land incorrect schemas if we did this. That's 
> why
> there is a pretty strong policy of only landing code that is run in CI 
> somewhere
> for Tempest.

+1, yes we should not add those without testing.

>
>>
>> 2. Only add tests to Tempest for a microversion change if it can't be tested
>> within nova, e.g. you actually need to create a server, or use other
>> services like glance/cinder/neutron.
>
> +1
>
> -Matt Treinish
>
>>
>> mtreinish and sdague will be at the nova midcycle so hopefully they can
>> represent for the QA team.
>>
>
> __
> OpenStack Development Mailing 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] Some thoughts on API microversions

2016-08-08 Thread Ghanshyam Mann

> -Original Message-
> From: Andrew Laski [mailto:and...@lascii.com]
> Sent: 04 August 2016 22:18
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Nova] Some thoughts on API microversions
> 
> 
> 
> On Thu, Aug 4, 2016, at 08:20 AM, Sean Dague wrote:
> > On 08/03/2016 08:54 PM, Andrew Laski wrote:
> > > I've brought some of these thoughts up a few times in conversations
> > > where the Nova team is trying to decide if a particular change
> > > warrants a microversion. I'm sure I've annoyed some people by this
> > > point because it wasn't germane to those discussions. So I'll lay
> > > this out in it's own thread.
> > >
> > > I am a fan of microversions. I think they work wonderfully to
> > > express when a resource representation changes, or when different
> > > data is required in a request. This allows clients to make the same
> > > request across multiple clouds and expect the exact same response
> > > format, assuming those clouds support that particular microversion.
> > > I also think they work well to express that a new resource is
> > > available. However I do think think they have some shortcomings in
> > > expressing that a resource has been removed. But in short I think
> > > microversions work great for expressing that there have been changes
> > > to the structure and format of the API.
> > >
> > > I think microversions are being overused as a signal for other types
> > > of changes in the API because they are the only tool we have
> > > available. The most recent example is a proposal to allow the
> > > revert_resize API call to work when a resizing instance ends up in
> > > an error state. I consider microversions to be problematic for
> > > changes like that because we end up in one of two situations:
> > >
> > > 1. The microversion is a signal that the API now supports this
> > > action, but users can perform the action at any microversion. What
> > > this really indicates is that the deployment being queried has
> > > upgraded to a certain point and has a new capability. The structure
> > > and format of the API have not changed so an API microversion is the
> > > wrong tool here. And the expected use of a microversion, in my
> > > opinion, is to demarcate that the API is now different at this particular
> point.
> > >
> > > 2. The microversion is a signal that the API now supports this
> > > action, and users are restricted to using it only on or after that
> microversion.
> > > In many cases this is an artificial constraint placed just to
> > > satisfy the expectation that the API does not change before the
> microversion.
> > > But the reality is that if the API change was exposed to every
> > > microversion it does not affect the ability I lauded above of a
> > > client being able to send the same request and receive the same
> > > response from disparate clouds. In other words exposing the new
> > > action for all microversions does not affect the interoperability
> > > story of Nova which is the real use case for microversions. I do
> > > recognize that the situation may be more nuanced and constraining
> > > the action to specific microversions may be necessary, but that's not
> always true.
> > >
> > > In case 1 above I think we could find a better way to do this. And I
> > > don't think we should do case 2, though there may be special cases
> > > that warrant it.
> > >
> > > As possible alternate signalling methods I would like to propose the
> > > following for consideration:
> > >
> > > Exposing capabilities that a user is allowed to use. This has been
> > > discussed before and there is general agreement that this is
> > > something we would like in Nova. Capabilities will programatically
> > > inform users that a new action has been added or an existing action
> > > can be performed in more cases, like revert_resize. With that in
> > > place we can avoid the ambiguous use of microversions to do that. In
> > > the meantime I would like the team to consider not using
> > > microversions for this case. We have enough of them being added that
> > > I think for now we could just wait for the next microversion after a
> > > capability is added and document the new capability there.
> >
> > The problem with this approach is that the capability add isn't on a
> > microversion boundary, as long as we continue to believe that we want
> > to support CD deployments this means people can deploy code with the
> > behavior change, that's not documented or signaled any way.
> 
> The fact that the capability add isn't on a microversion boundary is exactly 
> my
> point. There's no need for it to be in many cases. But it would only apply for
> capability adds which don't affect the interoperability of multiple
> deployments.
> 
> The signaling would come from the ability to query the capabilities listing. A
> change in what that listing returns indicates a behavior change.
> 
> Another reason I like the above mechanism is that it handles differences in
> policy

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

2016-06-30 Thread 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] [QA] Announcing my candidacy for PTL of the Pike cycle

2017-02-06 Thread Ghanshyam Mann

Hi Jordan,

Thanks for bring it up. I know we had both side of argument on those
changes.

IMO in general, its all QA team responsibility to verify the requirement
very strictly and make sure no changes break existing released version and
so users. Many times QA team does not agree to development team :).

But as we are working as community and one of our key goal is to smooth
development also. But as of now, strong rejection or formal approval from
QA team is something missing in formal guidelines or formal written.

We have api-wg and its guidelines which are a great things in OpenStack and
helped a lot to improve the APIs. But those are just guidelines and no hard
restriction.

Many of us can say if we are changing the APIs in backward incompatible
way, then api-wg and QA agreements are great to consider and then only
proceed but many of us can say if project team want then even disagreement
from QA or api-wg does not matter much.

As we do not have any official statement anywhere about mandatory agreement
of QA team, i do not think we can stop any projects for such changes but we
can always put our strong opinion and try to make project team understand
that how harmful that changes can be.

To make it in more smooth way in future, there is proposal in TC for new
tag "supports-api-compatibility" [1] (thanks matt for that) and cdent is
refactoring the api-wg guidelines accordingly [2].

This is really nice direction and if any projects adopt to have that new
tag, then they have to honor the API compatibility and honor the api-wg, QA
and TC decision.

My opinion on that to have a clear responsibility of QA, api-wg to make
projects considering new tag strictly honor the compatibility guidelines.
So that we as QA team have formal rights to stop any incompatible changes.

I personally feel we have to have a very clear responsibility of QA team
over API incompatible changes which will be helped by TC and all of us to
have consensus on that and keep/make OpenStack APIs as one of the best APIs
for users.

..1 https://review.openstack.org/#/c/418010/3
..2 https://review.openstack.org/#/c/421846/

-gmann

On Mon, Feb 6, 2017 at 8:14 PM, Jordan Pittier <jordan.pitt...@scality.com>
wrote:

> Hi gmann,
> Thanks for your candidacy. Let me ask one question if it's not too
> late. What's the role of the QA team when it comes to API change ? I
> have in mind the recent Glance change related to private vs shared
> image status.
>
> Someone in our community asked :
> * "I need to get an official decision from the QA team on whether
> [such a] patch is acceptable or not"
> * "what's needed is an "official" response from the QA team concerning
> the acceptability of the patch"
>
> But we didn't provide such an answer. There could be a feeling that
> the QA team is acting as a self-appointed activist judiciary.
>
> Now we have another occurrence of a disagreement between the QA team
> and a project team: https://bugs.launchpad.net/glance/+bug/1656183,
> https://review.openstack.org/#/c/420038/,
> https://review.openstack.org/#/c/425487/
>
> I have myself no strong opinion on the matter, that why I need a leader
> here :)
>
> Note, there *is* a question in this email :D
>
> Jordan
>
> On Thu, Jan 19, 2017 at 12:05 PM, Ghanshyam Mann
> <ghanshyam.m...@nectechnologies.in> wrote:
> > Hi All,
> >
> >
> >
> > First and foremost would like to wish you all a successful 2017 ahead and
> > with this I'm announcing my PTL candidacy of the Quality Assurance team
> for
> > the Pike release cycle.
> >
> >
> >
> > I am glad to work in OpenStack community and would like to thank all the
> > contributors who supported me to explore new things which brings out my
> best
> > for the community.
> >
> >
> >
> > Let me introduce myself, briefly. I have joined the OpenStack community
> > development in 2014 during mid of Ice-House release. Currently, I'm
> > contributing in QA projects and Nova as well as a core member in Tempest.
> > Since Barcelona Summit, I volunteered  as mentor in the upstream
> training.
> > It‘s always a great experience to introduce OpenStack upstream workflow
> to
> > new contributors and encourage them.
> >
> >
> >
> > Following are my contribution activities:
> >
> > * Review:
> > http://stackalytics.com/?release=all=marks_id=ghanshyammann
> >
> > * Commit:
> > http://stackalytics.com/?release=all=commits;
> user_id=ghanshyammann
> >
> >
> >
> > I have worked on some key areas on QA like Interfaces migration to lib,
> JSON
> > schema response validation(for compute), API Microversion testing
> framework
> > in Tempest, Improve test c

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

2017-02-08 Thread Ghanshyam Mann

Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, Jan 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_February_9th_2017_.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
-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] [nova] Device tag in the API breaks in the old microversion

2017-01-24 Thread Ghanshyam Mann

Thanks Alex for writing in details.


On Tue, Jan 24, 2017 at 6:05 PM, Alex Xu  wrote:

> Unfortunately the device tag support in the API was broken in the old
> Microversion https://bugs.launchpad.net/nova/+bug/1658571, which thanks
> to Kevin Zheng to find out that.
>
> Actually there are two bugs, just all of them are about device tag. The
> first one [0] is a mistake in the initial introduce of device tag. The new
> schema only available for the version 2.32, when the request version >
> 2.32, the schema fallback to the old one.
>
> The second one [1] is that when we bump the API to 2.37, the network
> device tag was removed accidentally which also added in 2.32 [2].
>
> So the current API behavior is as below:
>
> 2.32: BDM tag and network device tag added.
> 2.33 - 2.36: 'tag' in the BDM disappeared. The network device tag still
> works.
> 2.37: The network device tag disappeared also.
>


I am modifying the tempest tests in (feel free to modify it for more
verification) and running all above cases combination with version, 2.32,
2.33 and >2.37 and we should be able to verify what we broke actually from
tests results.

But from looking at api-ref and db, i am little bit confused. API-ref says
device tag as "An arbitrary tag." [6] and DB also have it as
Column(String(255)) [7]

But our tag validation we mistakenly removed is more strict actually as per
[8] which seems good so we should fix/mention the same in DB and api-ref
clearly.



>
> There are few questions we should think about:
>
> 1. Should we fix that by Microversion?
> Thanks to Chris Dent point that out in the review. I also think we
> need to bump Microversion, which follow the rule of Microversion.
>

Initially i thought it only validation part we loosen and feature still
works but with additionalPropoerties=False, its all disallowed to add tag
:(.



>
> 2. If we need Microversion, is that something we can do before release?
> We are very close to the feature freeze. And in normal, we need spec
> for microversion. Maybe we only can do that in Pike. For now we can update
> the API-ref, and microversion history to notice that, maybe a reno also.
>
> 2. How can we prevent that happened again?
>Both of those patches were reviewed multiple cycles. But we still miss
> that. It is worth to think about how to prevent that happened again.
>

This is very nice point. Actually we planned a BP [9] to cover the (Top,
Bottom & Changed) testing of each microversion, but my bad here as i did
not get time to work on that. May be this BP can be helpful here and add to
verify those tests in review guidelines.



>
>Talk with Sean. He suggests stop passing plain string version to the
> schema extension point. We should always pass APIVersionRequest object
> instead of plain string. Due to "version == APIVersionRequest('2.32')" is
> always wrong, we should remove the '__eq__'. The developer should always
> use the 'APIVersionRequest.matches' [3] method.
>
>That can prevent the first mistake we made. But nothing help for second
> mistake. Currently we only run the test on the specific Microversion for
> the specific interesting point. In the before, the new tests always
> inherits from the previous microversion tests, just like [4]. That can test
> the old API behavior won't be changed in the new microversion. But now, we
> said that is waste, we didn't do that again just like [5]. Should we change
> that back?
>

Another issue we have in functional tests for device tagging is we did not
make "supports_device_tagging" as true in fake driver and it was something
never got worked in
https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L1730

which seems failure on this -
http://logs.openstack.org/52/423952/5/check/gate-nova-tox-db-functional-ubuntu-xenial/ff1c09a/

I will check and fix functional tests bits.



>
> Thanks
> Alex
>
> [0] https://review.openstack.org/#/c/304510/64/nova/api/
> openstack/compute/block_device_mapping.py
> [1] https://review.openstack.org/#/c/316398/37/nova/api/
> openstack/compute/schemas/servers.py@88
> [2] https://review.openstack.org/#/c/316398/37/nova/api/
> openstack/compute/schemas/servers.py@79
> [3] https://github.com/openstack/nova/blob/master/nova/api/openstack/api_
> version_request.py#L219
> [4] https://github.com/openstack/nova/blob/master/
> nova/tests/unit/api/openstack/compute/test_evacuate.py#L415
> [5] https://github.com/openstack/nova/blob/master/
> nova/tests/unit/api/openstack/compute/test_serversV21.py#L3584
>
> [6]
http://developer.openstack.org/api-ref/compute/?expanded=create-server-detail

[7]
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L624

[8]
http://developer.openstack.org/api-ref/compute/#server-tags-servers-tags
[9]
https://blueprints.launchpad.net/nova/+spec/nova-microversion-functional-tests
 



> __
> OpenStack Development

Re: [openstack-dev] [nova] Device tag in the API breaks in the old microversion

2017-01-24 Thread Ghanshyam Mann

Sorry, forgot to mention tempest patch -
https://review.openstack.org/#/c/424572/1 (but broken cases seems clear
without that patch also)

Regards
Ghanshyam Mann
+818011120698

On Tue, Jan 24, 2017 at 7:34 PM, Ghanshyam Mann <ghanshyamm...@gmail.com>
wrote:

> Thanks Alex for writing in details.
>
>
> On Tue, Jan 24, 2017 at 6:05 PM, Alex Xu <sou...@gmail.com> wrote:
>
>> Unfortunately the device tag support in the API was broken in the old
>> Microversion https://bugs.launchpad.net/nova/+bug/1658571, which thanks
>> to Kevin Zheng to find out that.
>>
>> Actually there are two bugs, just all of them are about device tag. The
>> first one [0] is a mistake in the initial introduce of device tag. The new
>> schema only available for the version 2.32, when the request version >
>> 2.32, the schema fallback to the old one.
>>
>> The second one [1] is that when we bump the API to 2.37, the network
>> device tag was removed accidentally which also added in 2.32 [2].
>>
>> So the current API behavior is as below:
>>
>> 2.32: BDM tag and network device tag added.
>> 2.33 - 2.36: 'tag' in the BDM disappeared. The network device tag still
>> works.
>> 2.37: The network device tag disappeared also.
>>
>
>
> I am modifying the tempest tests in (feel free to modify it for more
> verification) and running all above cases combination with version, 2.32,
> 2.33 and >2.37 and we should be able to verify what we broke actually from
> tests results.
>
> But from looking at api-ref and db, i am little bit confused. API-ref says
> device tag as "An arbitrary tag." [6] and DB also have it as
> Column(String(255)) [7]
>
> But our tag validation we mistakenly removed is more strict actually as
> per [8] which seems good so we should fix/mention the same in DB and
> api-ref clearly.
>
>
>
>>
>> There are few questions we should think about:
>>
>> 1. Should we fix that by Microversion?
>> Thanks to Chris Dent point that out in the review. I also think we
>> need to bump Microversion, which follow the rule of Microversion.
>>
>
> Initially i thought it only validation part we loosen and feature still
> works but with additionalPropoerties=False, its all disallowed to add tag
> :(.
>
>
>
>>
>> 2. If we need Microversion, is that something we can do before release?
>> We are very close to the feature freeze. And in normal, we need spec
>> for microversion. Maybe we only can do that in Pike. For now we can update
>> the API-ref, and microversion history to notice that, maybe a reno also.
>>
>> 2. How can we prevent that happened again?
>>Both of those patches were reviewed multiple cycles. But we still miss
>> that. It is worth to think about how to prevent that happened again.
>>
>
> This is very nice point. Actually we planned a BP [9] to cover the (Top,
> Bottom & Changed) testing of each microversion, but my bad here as i did
> not get time to work on that. May be this BP can be helpful here and add to
> verify those tests in review guidelines.
>
>
>
>>
>>Talk with Sean. He suggests stop passing plain string version to the
>> schema extension point. We should always pass APIVersionRequest object
>> instead of plain string. Due to "version == APIVersionRequest('2.32')" is
>> always wrong, we should remove the '__eq__'. The developer should always
>> use the 'APIVersionRequest.matches' [3] method.
>>
>>That can prevent the first mistake we made. But nothing help for
>> second mistake. Currently we only run the test on the specific Microversion
>> for the specific interesting point. In the before, the new tests always
>> inherits from the previous microversion tests, just like [4]. That can test
>> the old API behavior won't be changed in the new microversion. But now, we
>> said that is waste, we didn't do that again just like [5]. Should we change
>> that back?
>>
>
> Another issue we have in functional tests for device tagging is we did
> not make "supports_device_tagging" as true in fake driver and it was
> something never got worked in https://github.com/openstack/
> nova/blob/master/nova/compute/manager.py#L1730
>
> which seems failure on this - http://logs.openstack.org/
> 52/423952/5/check/gate-nova-tox-db-functional-ubuntu-xenial/ff1c09a/
> I will check and fix functional tests bits.
>
>
>
>>
>> Thanks
>> Alex
>>
>> [0] https://review.openstack.org/#/c/304510/64/nova/api/openstac
>> k/compute/block_device_mapping.py
>> [1] https://review.openstack.org/#/c/31639

Re: [openstack-dev] [nova] The status of servers API's filters

2017-01-29 Thread Ghanshyam Mann

On Sun, Jan 29, 2017 at 10:12 AM, Alex Xu  wrote:

>
>
> 2017-01-29 1:31 GMT+08:00 Matt Riedemann :
>
>> On 1/27/2017 3:37 AM, Alex Xu wrote:
>>
>>> The patches about validation the filters and sorts for servers API are
>>> merged [0]. But we still have something left [1].
>>>
>>> The left is about the proposal of introducing the new rule
>>> 'os_compute_api:servers:all_tenants_visible' which is soft enforcement.
>>> The new rule will instead of the old hard enforcement rule
>>> "os_compute_api:servers:index:get_all_tenants".
>>>
>>> In the discussion of nova API meeting, Join pointed out that the change
>>> from hard enforcement to soft enforcement needs Microversion. The API
>>> used to return 403 when user didn't have permission of all_tenants
>>> parameter. But now the API returns 200 with the own instances when no
>>> permission of all_tenants parameter. So the proposal should be separated
>>> to two parts:
>>>
>>> i. rename the policy from "get_all_tenants" to the "all_tenants_visible"
>>> ii. change the enforcement from hard to soft by Microversion.
>>>
>>> In the old microversion, the rule keeps as hard enforcement.
>>>
>>> So in Ocata, "get_all_tenants" will be deprecated. If the deployer have
>>> overriden rule in the policy file, the old rule still will be enforced,
>>> and the warning message will be emit to notice that the user needs to
>>> move their custom rule to the new rule 'all_tenants_visiable'. And if
>>> the API user requests with new microversion, the rule will become soft
>>> enforcement.
>>>
>>> So if that sounds make sense, there also have another question about
>>> whether we have enough time to merge it. I think Matt will make a call
>>> on it.
>>>
>>> And due to holidays in China, both I and Kevin are in vacation.  And
>>> really really appreciate Ghanshyam take care on those patches! The
>>> spec[3] and the patch[1] already updated by him.
>>>
>>> AnywayHappy Chinese New Year to everyone(yea, new year again \o/).
>>>
>>> Thanks
>>> Alex
>>>
>>> [0] https://review.openstack.org/408571
>>> 
>>> and https://review.openstack.org/415142
>>> 
>>> [1] https://review.openstack.org/#/q/status:open+project:opensta
>>> ck/nova+branch:master+topic:bp/add-whitelist-for-server-list
>>> -filter-sort-parameters
>>> >> ack/nova+branch:master+topic:bp/add-whitelist-for-server-lis
>>> t-filter-sort-parameters>
>>> [3] https://review.openstack.org/425533
>>> 
>>>
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> My immediate question is, does this need to happen in Ocata or can we
>> defer the all_tenants_visible policy change to Pike? Is there anything we
>> merged in Ocata that is now broken, or weird, or blocks us from doing
>> something later, etc if we don't get this done now?
>>
>
> I didn't see any broken or blocks without the all_tenants_visiable policy
> change. The policy change is just part of vision of how filters should be
> looks like between admin user and non-admin user.
>
>
>>
>> Honestly I never really understood why the all_tenants policy change was
>> being lumped in with the server sort/filter whitelist blueprint, except
>> maybe just because of convenience?
>>
>
> Emm..I didn't remember any discussion about why we should put all of them
> into one spec or not.
>
>
>> Anyway, this seems like something we can defer to Pike unless I'm missing
>> something.
>
>
> I'm ok with that, due to I didn't have any critical reason. The only thing
> is we need one more cycle to remove a old policy rule. But currently the
> new proposal without more discussion, and we only have 1 week left for spec
> change and patches. It isn't worth to take that risk I guess.
>

Ok, I was thinking if we could get new policy and old policy deprecation
in Ocata and behavior change in Pike but yes that needs spec update and
review which is little bit tight for Ocata.

I am also ok to defer this in Pike.



>
> Anyway, Matt, thanks for your response.
>
>
>>
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>> 
>> __
>> 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
>

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

2017-01-25 Thread Ghanshyam Mann

Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, Jan 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#Agenda_for_January_26th_2017_.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

-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] [nova] Device tag in the API breaks in the old microversion

2017-01-24 Thread Ghanshyam Mann

On Wed, Jan 25, 2017 at 1:18 AM, Matt Riedemann  wrote:

> On 1/24/2017 2:05 AM, Alex Xu wrote:
>
>> Unfortunately the device tag support in the API was broken in the old
>> Microversion https://bugs.launchpad.net/nova/+bug/1658571, which thanks
>> to Kevin Zheng to find out that.
>>
>> Actually there are two bugs, just all of them are about device tag. The
>> first one [0] is a mistake in the initial introduce of device tag. The
>> new schema only available for the version 2.32, when the request version
>>
>>> 2.32, the schema fallback to the old one.
>>>
>>
>> The second one [1] is that when we bump the API to 2.37, the network
>> device tag was removed accidentally which also added in 2.32 [2].
>>
>> So the current API behavior is as below:
>>
>> 2.32: BDM tag and network device tag added.
>> 2.33 - 2.36: 'tag' in the BDM disappeared. The network device tag still
>> works.
>> 2.37: The network device tag disappeared also.
>>
>> There are few questions we should think about:
>>
>> 1. Should we fix that by Microversion?
>> Thanks to Chris Dent point that out in the review. I also think we
>> need to bump Microversion, which follow the rule of Microversion.
>>
>> 2. If we need Microversion, is that something we can do before release?
>> We are very close to the feature freeze. And in normal, we need spec
>> for microversion. Maybe we only can do that in Pike. For now we can
>> update the API-ref, and microversion history to notice that, maybe a
>> reno also.
>>
>> 2. How can we prevent that happened again?
>>Both of those patches were reviewed multiple cycles. But we still
>> miss that. It is worth to think about how to prevent that happened again.
>>
>>Talk with Sean. He suggests stop passing plain string version to the
>> schema extension point. We should always pass APIVersionRequest object
>> instead of plain string. Due to "version == APIVersionRequest('2.32')"
>> is always wrong, we should remove the '__eq__'. The developer should
>> always use the 'APIVersionRequest.matches' [3] method.
>>
>>That can prevent the first mistake we made. But nothing help for
>> second mistake. Currently we only run the test on the specific
>> Microversion for the specific interesting point. In the before, the new
>> tests always inherits from the previous microversion tests, just like
>> [4]. That can test the old API behavior won't be changed in the new
>> microversion. But now, we said that is waste, we didn't do that again
>> just like [5]. Should we change that back?
>>
>> Thanks
>> Alex
>>
>> [0]
>> https://review.openstack.org/#/c/304510/64/nova/api/openstac
>> k/compute/block_device_mapping.py
>> [1] https://review.openstack.org/#/c/316398/37/nova/api/openstac
>> k/compute/schemas/servers.py@88
>> [2] https://review.openstack.org/#/c/316398/37/nova/api/openstac
>> k/compute/schemas/servers.py@79
>> [3] https://github.com/openstack/nova/blob/master/nova/api/opens
>> tack/api_version_request.py#L219
>> [4] https://github.com/openstack/nova/blob/master/nova/tests/uni
>> t/api/openstack/compute/test_evacuate.py#L415
>> [5] https://github.com/openstack/nova/blob/master/nova/tests/uni
>> t/api/openstack/compute/test_serversV21.py#L3584
>>
>>
>>
>> 
>> __
>> 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
>>
>>
> First, thanks to Kevin and Alex for finding this issue and explaining it
> in detail so we can understand the scope.
>
> This is a nasty unfortunate issue which I really wish we could just fix
> without a microversion bump but we have microversions for a reason, which
> is to fix issues in the API. In thinking about if this were the legacy 2.0
> API, we always had a rule that you couldn't fix bugs in the API if they
> changed the behavior, no matter how annoying.
>
> So let's fix this with a microversion. I don't think we need to hold it to
> the feature freeze deadline as it's a microversion only for a bug fix, it's
> not a new feature. So that's a compromise at least and gives us some time
> to get this done correctly and still have it fixed in Ocata. We'll also
> want to document this in the api-ref and REST API version history in
> whatever way makes it clear about the limitations between microversions.
>

+1 for fixing in Ocata itself. We have fix up just need to put that under
new version. I can modify the tests to cover this bug scenario. 



>
> As for testing, I think using a mix of test inheritance and using 2.latest
> is probably a good step to take. I know we've had a mix of that in
> different places in the functional API samples tests, but there was never a
> clear rule about what do to with testing microversions and if you should
> use inheritance to build on existing tests.


Also along with that, I'd like to add

Re: [openstack-dev] [qa] Tempest Stable plugin interface change broke gate

2017-02-22 Thread Ghanshyam Mann

> -Original Message-
> From: Hayes, Graham [mailto:graham.ha...@hpe.com]
> Sent: 23 February 2017 03:25
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [qa] Tempest Stable plugin interface change
> broke gate
> 
> On 21/02/2017 15:25, Andrea Frittoli wrote:
> > Hi Graham,
> >
> > sorry about that, and good catch.
> > You are right, that's a stable interface so that change should not
> > have landed.
> >
> > andrea
> >
> > On Tue, Feb 21, 2017 at 2:51 PM Hayes, Graham  > > wrote:
> >
> > Hi.
> >
> > https://review.openstack.org/#/c/434304/ landed yesterday, which was
> a
> > change to the stable interface for tempest plugins.
> >
> > It also took out the designate gate.
> >
> > Is this interface stable? - If so, there should have been at least some
> > deprecation cycle, notification, or something.
> >
> > Revert has been proposed -
> > https://review.openstack.org/#/c/436612/
> >
> > Can someone clarify what the "stable" in "Stable APIs" listed here [1]
> > means?
> >
> > - Graham
> >
> > 1 -
> >
> > https://docs.openstack.org/developer/tempest/plugin.html#stable-
> tempes
> > t-apis-plugins-may-use
> >
> >
> __
> 
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >  requ...@lists.openstack.org?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> The revert above still hasn't merged.
> 
> The QA team blocked a change that updated HTTP status code, but removed
> a stable interface with no deprecation.
> 
> The revert needs to land, now, and then the QA team can debate
> deprecation / removal.

Sorry about that. We are ok with that patch to merge that and yes we should do 
that with deprecation warning etc.  

> 
> To stop this happening in the future, can we get tempest to gate on some
> tempest plugins?
> 
> Just a gate job that runs when any code in the designated stable sections of
> tempest change would be incredibly useful.

That might be difficult to run lot of plugins tests on job for tempest stable 
interface but yes I agree with idea and we should have some mechanism to block 
the removal of stable interface without deprecation etc.
Let's us think about more on this. 


> 
> Thanks,
> 
> Graham
> 
> __
> 
> OpenStack Development Mailing 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] The end-user test suite for OpenStack clusters

2017-02-24 Thread 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 <dava...@gmail.com> 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 <sam47pr...@gmail.com> 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
> > <tnurlygaya...@mirantis.com> 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
> >> <ghanshyam.m...@nectechnologies.in> 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:

[openstack-dev] [QA] Announcing my candidacy for PTL of the Pike cycle

2017-01-19 Thread Ghanshyam Mann

Hi All,

First and foremost would like to wish you all a successful 2017 ahead and with 
this I'm announcing my PTL candidacy of the Quality Assurance team for the Pike 
release cycle.

I am glad to work in OpenStack community and would like to thank all the 
contributors who supported me to explore new things which brings out my best 
for the community.

Let me introduce myself, briefly. I have joined the OpenStack community 
development in 2014 during mid of Ice-House release. Currently, I'm 
contributing in QA projects and Nova as well as a core member in Tempest. Since 
Barcelona Summit, I volunteered  as mentor in the upstream training. It's 
always a great experience to introduce OpenStack upstream workflow to new 
contributors and encourage them.

Following are my contribution activities:
* Review:  
http://stackalytics.com/?release=all=marks_id=ghanshyammann
* Commit:  
http://stackalytics.com/?release=all=commits_id=ghanshyammann

I have worked on some key areas on QA like Interfaces migration to lib, JSON 
schema response validation(for compute), API Microversion testing framework in 
Tempest, Improve test coverage and Bug Triage etc.

QA program has been immensely improved since it was introduced which increased 
upstream development quality as well as helping production Cloud for their 
testing and stability. We have a lot of ideas from many different contributors 
to keep improving the QA which is phenomenal and I truly appreciate.

Moving forwards, following are my focus areas for Pike Cycle:

* Help the other Projects' developments and Plugin Improvement:
OpenStack projects consider the quality is important and QA team needs to 
provide useful testing framework for them. Projects who all needs to implement 
their tempest tests in plugin, focus will be to help plugin tests improvement 
and so projects quality. Lot of Tempest  interfaces are moving towards stable 
interfaces, existing plugin tests needs to be fixed multiple times. We are 
taking care of those and helping them to migrate smoothly. But there are still 
many  interfaces going to migrate to lib and further to be adopted on plugin 
side. I'd like to have some mechanism/automation to trigger plugins to know 
about change interfaces before it breaks them. Also help them to use the 
framework correctly. This helps the other non-core projects' tests.

* Improve QA projects for Production Cloud:
This will be the main focus area. Having QA projects more useful for Production 
Cloud testing is/will be great achievement for QA team. This area has been 
improved a lot since last couple of cycles and still a lot to do. We have to 
improve Production scenario testing coverage and make all QA projects easy to 
configure and use. During Barcelona summit, 2 new projects are initiated which 
will definitely help to achieve this goal.
  *RBAC Policy -  https://github.com/openstack/patrole
  *HA testing  -  https://review.openstack.org/#/c/374667/
  https://review.openstack.org/#/c/399618/
  *Hoping for more in future
There will be more focus on those projects and new ideas which will help 
production Cloud testing in more powerful way.

* JSON Schema *response* validation for projects:
JSON schema response validation for compute APIs has been very helpful to keep 
the APIs quality and compatibility. Currently many projects support 
microversion which provides a way to introduce the APIs changes in Backward 
compatible way. I'd like to concentrate on response schema validation for those 
projects also. This helps the OpenStack interoperability and the APIs 
compatibility.

* Improve Documentation and UX:
Documentation and UX are the key part for any software. There have been huge 
improvement in UX , documentation side and new Tempest workflow is available.  
Still configuration and usage is the pain point for Users. During summit/ptg or 
other platforms I'd like us to have more feedbacks from users and improve 
accordingly. Making configuration easy for people is one of the area we will be 
focusing on.

* Bring on more contributor and core reviewers:
QA projects have been one of the active projects during last couple of years 
and I'd like the team to mentor new contributors to help QA projects in planned 
goal and get them to a place where they will be ready for core reviewers.

* Migrate required Tempest Interfaces as stable to lib:
We together have done great job in this area which helped plugin tests. In 
Service clients migration, Object Storage service client are left and all 
others have been moved as stable interfaces. Lot of others framework/interface 
also available in lib. But still lot of unstable interfaces are being used in 
Plugins which should be migrated to lib soon. In Pike cycle, we will wind up 
all remaining service client migration and other required interfaces.

* Last but not the least, Openness is great power of Open Source and so does 
OpenStack. All new ideas from anyone

Re: [openstack-dev] [infra][qa][glance] gate-tempest-dsvm-full-ceph-plugin-src-glance_store-ubuntu-xenial failures

2017-01-16 Thread GHANSHYAM MANN

Yea, manage snapshot tests should be skipped on ceph backend.

I disabled those tests for *-ceph-* jobs and glance-store will be unblocked
after that merged.

-  https://review.openstack.org/#/c/421073/


There is discussion going on whether to enable the manage snapshot false by
default on devstack side and improve
tempest tests also but that might take time.

But for ceph jobs it will be disabled in that patch and should not block
gate etc.

Also if any CI failing due to that they can quickly disable that flag and
skip the tests which not meant to be run on their CI.


-gmann

On Tue, Jan 17, 2017 at 11:18 AM, Brian Rosmaita  wrote:

> I need some help troubleshooting a glance_store gate failure that I
> think is due to a recent change in a tempest test and a configuration
> problem (or it could be something else entirely).  I'd appreciate some
> help solving this as it appears to be blocking all merges into
> glance_store, which, as a non-client library, is supposed to be frozen
> later this week.
>
> Here's an example of the failure in a global requirements update patch:
> https://review.openstack.org/#/c/420832/
> (I should mention that the failure is occurring in a volume test in
> tempest.api.volume.admin.v2.test_snapshot_manage.
> SnapshotManageAdminV2Test,
> not a glance_store test.)
>
> The test is being run by this gate:
> gate-tempest-dsvm-full-ceph-plugin-src-glance_store-ubuntu-xenial
>
> The test that's failing, test_unmanage_manage_snapshot was recently
> modified by Change-Id: I77be1cf85a946bf72e852f6378f0d7b43af8023a
> To be more precise, the test itself wasn't changed, rather the criterion
> for skipping the test was changed (from a skipIf based on whether the
> backend was ceph, to a skipUnless based on a boolean config option).
>
> From the comment in the old code on that patch, it seems like the test
> config value should be False when ceph is the backend (and that's its
> default).  But in the config dump of the failing test run,
> http://logs.openstack.org/32/420832/1/check/gate-tempest-
> dsvm-full-ceph-plugin-src-glance_store-ubuntu-xenial/
> dab27eb/logs/tempest_conf.txt.gz
> you can see that manage_snapshot is True.
>
> That's why I think the problem is being caused by a flipped test config
> value, but I'm not sure where the configuration for this particular gate
> lives so I don't know what repo to propose a patch to.
>
> Thanks in advance for any help,
> brian
>
>
> __
> OpenStack Development Mailing 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] [Cinder] Marking Tintri driver as unsupported

2017-01-16 Thread GHANSHYAM MANN

Or how about just disable the flag which will skip snapshot manage tests
for CI where it should not run.

Flag in Devtsack is TEMPEST_VOLUME_MANAGE_SNAPSHOT which can be set to
False on CI.

I added the same on ceph gate jobs [1] and similarly can be added on CI
side if ok?

..1 https://review.openstack.org/#/c/421073/

-gmann

On Tue, Jan 17, 2017 at 4:32 AM, Sean McGinnis 
wrote:

> On Mon, Jan 16, 2017 at 08:52:34AM +0100, Silvan Kaiser wrote:
> > Apoorva, Sean,
> > after some time i managed to bring up Quobyte CI last friday which tested
> > fine [1,2,3] for a short time and then ran into the same issues with
> > manage_snapshot
> > related tempest tests Apoorva describes (Starting chronologically at
> [4]).
> > From here i see two steps:
> > a) look into the reason for the issue with manage_snapshot tests
> > b) a short note on how to proceed for marking drivers with reinstated CIs
>
> Hey Sylvan,
>
> As mentioned, if the CI requirements can be met yet this cycle, we can
> just do a revert for the patch that set the unsupported flag. That
> should be a quick and easy one to get through once we see the CI is
> back and stable.
>
> Thanks!
> Sean
>
> > back as supported is much appreciated
> > Best
> > Silvan
>
> __
> OpenStack Development Mailing 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] Different length limit for tags in object definition and db model definition

2017-01-16 Thread GHANSHYAM MANN

On Tue, Jan 17, 2017 at 2:37 PM, Alex Xu  wrote:

>
>
> 2017-01-17 10:26 GMT+08:00 Matt Riedemann :
>
>> On 1/16/2017 7:12 PM, Zhenyu Zheng wrote:
>>
>>> Hi Nova,
>>>
>>> I just discovered something interesting, the tag has a limited length,
>>> and in the current implementation, it is 60 in the tag object definition:
>>> http://git.openstack.org/cgit/openstack/nova/tree/nova/objec
>>> ts/tag.py#n18
>>>
>>> but 80 in the db model:
>>> http://git.openstack.org/cgit/openstack/nova/tree/nova/db/sq
>>> lalchemy/models.py#n1464
>>>
>>> As asked in the IRC and some of the cores responded(thanks to Matt and
>>> Jay), it seems to be an
>>> oversight and has no particular reason to do it this way.
>>>
>>> Since we have already created a 80 long space in DB and the current
>>> implementation might be confusing,  maybe we should expand the
>>> limitation in tag object definition to 80. Besides, users can enjoy
>>> longer tags.
>>>
>>> And the question could be, does anyone know why it is 60 in object but
>>> 80 in DB model? is it an oversight or we have some particular reason?
>>>
>>> If we could expand it to be the same as DB model (80 for both), it is ok
>>> to do this tiny change without microversion?
>>>
>>> Thanks,
>>>
>>> Kevin Zheng
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> As I said in IRC, the tags feature took a long time to land (several
>> releases) so between the time that the spec was written and then the data
>> model patch and finally the REST API change, we might have just totally
>> missed that the length of the column in the DB was different than what was
>> allowed in the REST API.
>>
>> I'm not aware of any technical reason why they are different. I'm hoping
>> that Sergey Nikitin might remember something about this. But even looking
>> at the spec:
>>
>> https://specs.openstack.org/openstack/nova-specs/specs/liber
>> ty/approved/tag-instances.html
>>
>> The column was meant to be 60 so my guess is someone noticed that in the
>> REST API review but missed it in the data model review.
>>
>
> I can't remember the detail also. Hoping Sergey can remember something
> also.
>
>
>>
>> As for needing a microversion of changing this, I tend to think we don't
>> need a microversion because we're not restricting the schema in the REST
>> API, we're just increasing it to match the length in the data model. But
>> I'd like opinions from the API subteam about that.
>>
>>
> We still need microversion for the user to discover the max length between
> different cloud deployments.
>

I agree that we still need microversion for this. As Alex mentioned,
otherwise it will be issue on interoperability.

Can we just keep it 60 and change DB to match the same?

-gmann

>
>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>> 
>> __
>> 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] [qa] PTL non-candidacy

2017-01-19 Thread Ghanshyam Mann

Thanks Kenichi for all your hardwork and nice leadership.

Its been very good and lot of things we finished under your leadership. You
managed all the activities in a very cool and polite  way (Japanese style
:)).

-gmann

On Fri, Jan 20, 2017 at 4:16 AM, Ken'ichi Ohmichi 
wrote:

> Hi,
>
> I will step down as PTL after this Ocata cycle.
> I was happy to see new ideas and folks who try making ideas true in
> this 2 cycles.
> Now QA project has a lot of components with many people's effort and
> we help each other as a community.
> This experience is very exciting for me, I am proud to being a member
> in this community.
>
> Today, I'd like to concentrate on coding and reviewing again as a
> developer.
> I think we have good candidates for a next PTL, and I will keep active
> under the next PTL's leadership.
>
> Thanks for choosing me anyways, let's make OpenStack quality better
> together :-)
>
> Thanks
> Ken Ohmichi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Do not recheck changes until 422709 is merged

2017-01-19 Thread Ghanshyam Mann

For other failure on "expected_attr" error, we need this to merge - 
https://review.openstack.org/#/c/422323/  on nova side. 

-gmann


> -Original Message-
> From: Matt Riedemann [mailto:mriede...@gmail.com]
> Sent: 20 January 2017 12:17
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [nova] Do not recheck changes until 422709 is
> merged
> 
> On 1/19/2017 5:09 PM, Matt Riedemann wrote:
> > On 1/19/2017 10:56 AM, Matt Riedemann wrote:
> >> The py35 unit test job is broken for Nova until this patch is merged:
> >>
> >> https://review.openstack.org/#/c/422709/
> >>
> >> So please hold off on the rechecks until that happens.
> >>
> >
> > We're good to go again for rechecks.
> >
> 
> Just a heads up that if you still see py35 unit test failures with a 
> TypeError like
> this [1] then you need to rebase you patch.
> 
> [1]
> http://logs.openstack.org/37/410737/5/check/gate-nova-python35-
> db/4fec66c/console.html#_2017-01-20_01_56_21_021702
> 
> --
> 
> Thanks,
> 
> Matt Riedemann
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

2017-02-26 Thread 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

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

2017-02-28 Thread 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

[openstack-dev] [QA] Meeting Thursday Sept 8th at 9:00 UTC

2016-09-08 Thread Ghanshyam Mann

Hello everyone,



Please reminder that the weekly OpenStack QA team IRC meeting will be Thursday, 
Sept 8th 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_September_8th_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


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 Oct 20th at 9:00 UTC

2016-10-19 Thread Ghanshyam Mann

Hello everyone,



Please reminder that the weekly OpenStack QA team IRC meeting will be Thursday, 
Oct 20th 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_October_20th_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

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

Re: [openstack-dev] [Nova] Stepping back

2016-11-23 Thread Ghanshyam Mann

Thanks a lot alaski for your incredible contribution in Nova. You were a great 
learning guide and mentor.
Very best of luck for your new responsibility and hoping to work together in 
community again. 

Thanks & Regards,
gmann


> -Original Message-
> From: Andrew Laski [mailto:and...@lascii.com]
> Sent: 23 November 2016 01:40
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [Nova] Stepping back
> 
> I should have sent this weeks ago but I'm a bad person who forgets common
> courtesy. My employment situation has changed in a way that does not
> afford me the necessary time to remain a regular contributor to Nova, or the
> broader OpenStack community. So it is with regret that I announce that I will
> no longer be actively involved in the project.
> 
> Fortunately, for those of you reading this, the Nova community is full of
> wonderful and talented individuals who have picked up the work that I'm not
> able to continue. Primarily this means parts of the cellsv2 effort, for which 
> I
> am extremely grateful.
> 
> It has been a true pleasure working with you all these past few years and I'm
> thankful to have had the opportunity. As I've told people many times when
> they ask me what it's like to work on an open source project like this: 
> working
> on proprietary software exposes you to smart people but you're limited to
> the small set of people within an organization, working on a project like this
> exposed me to smart people from many companies and many parts of the
> world. I have learned a lot working with you all. Thanks.
> 
> I will continue to lurk in #openstack-nova, and try to stay minimally involved
> as time allows, so feel free to ping me there.
> 
> -Laski
> 
> __
> 
> OpenStack Development Mailing 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 Nov 17th at 9:00 UTC

2016-11-16 Thread Ghanshyam Mann

Hello everyone,



Please reminder that the weekly OpenStack QA team IRC meeting will be Thursday, 
Nov 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#Agenda_for_November_17th_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


Thanks & Regards,
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] The end-user test suite for OpenStack clusters

2016-10-13 Thread Ghanshyam Mann

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) 

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

Ken, it is a good idea!

The plan is to develop os-faults as a library which will be able
to manage cluster nodes and OpenStack services on these nodes.
It is a good idea to add some Tempest tests which will use
os-faults library as well for some API tests.

The Stepler framework [1] will use os-faults to perform all destructive
actions in the clouds (the reboot of nodes, restart of OpenStack services,
enable/disable network interfaces or some firewall rules and etc).

We need to get +1 from you in [1] to create the repository with
advanced end-user scenario tests.

Thank you!

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

On Tue, Oct 4, 2016 at 8:53 PM, Yaroslav Lobankov 
> wrote:
Hi Ken,

OS-Faults doesn't have any scenarios in the tree yet (the project is two months 
old), but you can find some examples of the use in the os-faults/examples 
directory.

Regards,
Yaroslav Lobankov.

On Tue, Oct 4, 2016 at 8:02 PM, Ken'ichi Ohmichi 
> wrote:
Hi Timur,

Thanks for your explanation.

2016-09-29 6:22 GMT-07:00 Timur Nurlygayanov 
>:
>
>> I am guessing the above "restart nodes" is for verifying each
>> OpenStack service restarts successfully, right?
>
> Yes, this is right. And we also will check that HA logic for these
> services works correctly (for example, rescheduling of L3 Neutron
> agents for networks).
>
>> But these service scripts are provided by distributors, and Devstack
>> itself doesn't contain service scripts IIUC.
>> So I'd like to know how to verify it on Devstack clouds.
>
> Yes, DevStack doesn't support many scenarios which are actual
> and should be supported on the production clouds.
> It will be not possible to run all advanced test scenarios for DevStack
> clouds,
> just because DevStack can't deploy OpenStack cloud with 3 controllers
> now (so, probably it will be possible in the future).
>
> Of course, some advanced scenarios will support DevStack clouds,
> for example, some test scenarios which are based on customer-found
> issues from the real production clouds, like upload of the large images
> (100+ Gb)
> to Glance with Swift backend. Such cases are important for verification of
> pre-production environments, but not very important for CI gate jobs.
>
> It is also important to note that in these advanced cases we are targeting
> to check not only the logic of Python code, but also the correct
> configuration
> of all OpenStack components on some pre-production OpenStack clusters.
I guessed some part of os-faults can be moved to Tempest if os-faults
contains API tests for enabling/disabling OpenStack services.
Then, os-faults would be able to concentrate on more destructive tests
like rebooting physical nodes, etc.
However, I could not find any actual scenarios on current os-faults
(https://github.com/openstack/os-faults).
That seems to just contain some abstraction layers and unit tests. Can
we see actual test scenarios of os-faults ?
Maybe I missed something.

Thanks
Ken Ohmichi

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

Re: [openstack-dev] [sahara][qa] Unblocking Sahara gate

2016-10-13 Thread Ghanshyam Mann

I think this is issue more the way plugin was using the config options.

Sahara tests plugin should have used the options in their own way or implement 
same way it was done in Tempest (define self. data-processing etc) instead of 
partially relying on tempest defined variable.

Honestly saying, I do not prefer of adding the automapping in tempest side. 

[1]  will fix the issue and unblock the sahara tests. And I saw sahara plugin 
is also branchless so should be ok with just this patch ?

..1 - https://review.openstack.org/#/c/385701/


Thanks & Regards,
Ghanshyam Mann

> -Original Message-
> From: Luigi Toscano [mailto:ltosc...@redhat.com]
> Sent: 13 October 2016 00:37
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [sahara][qa] Unblocking Sahara gate
> 
> Hi all,
> 
> the removal of the Sahara tests from Tempest [1] broke the tests now in
> sahara-tests, and basically I underestimated the fall-out of the removal.
> Apart from a minor issue due to the wrong exception [2], the key issue
> comes from the option groups in tempest.conf, which are defined as data-
> processing and data-processing-feature-available, while the code tries to
> access CONF.data_processing. Previously this was handled by some magic
> mapping [3], which can't be used, as it is, by plugins.
> I came up with this solution [4] after discussing with Andrea Frittoli. The
> patches only fails with the automation negative tests, which are on the way
> of the Dodo anyway [5].
> The alternative fix for sahara would involve patching the configured
> tempest.conf in few branches, in addition to the fixes to sahara-tests, and 
> I'd
> frankly prefer a more general solution.
> 
> My question is: can you please approve [5] and [4], so that Sahara gates can
> be unlocked?
> 
> 
> [1] https://review.openstack.org/#/c/380082/
> [2] https://review.openstack.org/#/c/385336/
> [3]
> http://git.openstack.org/cgit/openstack/tempest/tree/tempest/config.py?
> h=13.0.0#n1239
> [4] https://review.openstack.org/#/c/385460/
> [5] https://review.openstack.org/#/c/380982/
> 
> Ciao
> --
> Luigi
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

2016-12-06 Thread GHANSHYAM MANN

Hi All,

Recently all gate heat gate jobs were switched to use heat devstack plugin
and heat code was removed from devstack tree.

During that tempest layer 4 job is missed and blocked the tempest gate[1].
Also another heat job had issue for enabling plugin [2].

Fixes are up for both job fix, hope infra team can merge those ASAP.

- Tempest layer4 job fix - https://review.openstack.org/#/c/407807/
- Heat job fix - https://review.openstack.org/#/c/407817/

..1
http://logs.openstack.org/68/407768/1/check/gate-tempest-dsvm-layer4-ubuntu-xenial/9499d2a/logs/testr_results.html.gz

..2
http://logs.openstack.org/14/406514/1/check/gate-tempest-dsvm-heat-identity-v3-only-nv/0e51c2b/logs/testr_results.html.gz


-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

1 2 3 4 >

1 - 100 of 349 matches

Mail list logo