Open Stack

I'm replying to this version of John's mail to expand on his "use case" point.

What John calls a use case is, in this instance, the same as a high level "Test Case".  Essentially, this is the documentation/comments that define what the test(s) for this case are doing.  DefCore (or others) could create these high level test cases and use them as the framework into which new tests, specific for the capability, could be written.  This, I think, would be an ideal way to start documenting missing capabilities tests.  For some capabilities, there could be multiple use cases (or test cases) that define the capability.

This could also be used for existing tests, but instead of including code for each case or step in a case, the git repo link to the existing test could be included.  This process could also be used with new tests being linked into the test case document as they are merged into the trunk.

This process provides the higher level test "specs" that developers implement into tests.  It provides both a way to track what tests exist and what don't, and a description of the capability that is understandable by end users and other interested parties not concerned with the "guts," but just the behavior of the capability.

For the case of multiple ways of performing an action, the tests would need to implement all methods that meet DefCore criteria.  If any of the methods result in the appropriate end result, then for DefCore purposes, the test has passed.

Does this make sense for DefCore?  As OpenStack matures and acts more like a collection of products rather than a collection of code bases, the processes and collateral of software process that exist to turn code into product come more into play. Hence, the QA as not just verification gate, but a measurement and metrics repository. 

Sorry!  Had to get this thought out.  You don't need the QA that most SW companies have until you have product.  We are getting close to one and so are now in need of expanding OpenStack QA to encompass the other.

--Rocky



-----Original Message-----
From: John Garbutt [mailto:john at johngarbutt.com] 
Sent: Wednesday, June 17, 2015 09:57
To: defcore-commit.
Cc: Nikhil Komawar
Subject: [OpenStack-DefCore] Image APIs in Glance and Nova

Hi,

So this was raised in the cross project meeting, and thank you for that.

I keep mentioning use cases, so here we go...
* create from cloud base image for ubuntu 12.04
* above but with boot from volume
* create a snapshot
* download snapshot
* upload image into another openstack cloud
* boot server from uploaded image

Now, at a higher level:
* user does above using custom script for Cloud A and Cloud B
* user keeps to just the APIs that are defcore tested
* user gets access to Cloud C and Cloud D
* user wants to point script at new clouds, and everything should just work

So I think thats where we want to be. Now lets dig in...

To list images, the user could:
* use nova to list images (stable, but project wants to delete it)
* use glance v1 (should never be exposed to end users, was designed as
internal only API)
* use glance v2 (only just released, not really deployed anywhere)

For the

_______________________________________________
Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee