Few questions:
1. About the "more object-oriented" CloudStack API python binding: Is the
proposed api good enough?
For example,
The current hand written create virtual machine looks like:
class VirtualMachine(object):
....
@classmethod
def create(cls, apiclient, services, templateid=None, accountid=None,
domainid=None, zoneid=None, networkids=None,
serviceofferingid=None,
securitygroupids=None, projectid=None, startvm=None,
diskofferingid=None, affinitygroupnames=None, group=None,
hostid=None, keypair=None, mode='basic', method='GET'):
the proposed api may look like:
class VirtualMachine(object):
def create(self, apiclient, accountId, templateId, **kwargs)
The proposed api will look better than previous one, and it's automatically
generated, so easy to maintain. But as a consumer of the api, how do people
know what kind of parameters should be passed in? Will you have an online
document for your api? Or you assume people will look at the api docs generated
by CloudStack?
Or why not make the api itself as self-contained? For example, add docs before
create method:
class VirtualMachine(object):
'''
Args:
accountId: what ever
templateId: whatever
networkids: whatever
'''
'''
Response:
'''
def create(self, apiclient, accountId, templateId, **kwargs)
All the api documents should be included in api discovery already, so it should
be easy to add them in your api binding.
2. Regarding to data factories. From the proposed factories, in each test case,
does test writer still need to write the code to get data, such as writing code
to get account during the setupclass?
I looked at some of the existing test cases, most of them have the same code
snippet:
class Services:
def __init__(self):
self.services = {
"account": {
"email": "t...@test.com",
"firstname": "Test",
"lastname": "User",
"username": "test",
"password": "password",
},
"virtual_machine": {
"displayname": "Test VM",
"username": "root",
"password": "password",
"ssh_port": 22,
"hypervisor": 'XenServer',
"privateport": 22,
"publicport": 22,
"protocol": 'TCP',
},
With the data factories, the code will look like the following?
Class TestFoo:
Def setupClass():
Account = UserAccount(apiclient)
VM = UserVM(apiClient)
And if I want to customize the default data factories, I should be able to use
something like: UserAccount(apiclient, username='myfoo')?
And the data factories should be able to customized based on test environment,
right?
For example, the current iso test cases are hardcoded to test against
http://people.apache.org/~tsp/dummy.iso, but it won't work for devcloud, or in
an internal network. The ISO data factory should be able to return an url based
on different test environment, thus iso test cases can be reused.
> -----Original Message-----
> From: Santhosh Edukulla [mailto:santhosh.eduku...@citrix.com]
> Sent: Monday, October 07, 2013 7:06 AM
> To: dev@cloudstack.apache.org
> Subject: RE: [DISCUSS] Breaking out Marvin from CloudStack
>
> Team,
>
> Apart\Away from breaking out marvin from cloudstack, please check the
> other new details provided as part of the new proposal for marvin
> refactoring. Your inputs out of experience are invaluable. Any new feature
> tests for CS will be followed with the new approach, provided if we agree to
> all. Pasting the proposal link one more time below.
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Marvin+Refactor
>
> Regards,
> Santhosh
> ________________________________________
> From: Daan Hoogland [daan.hoogl...@gmail.com]
> Sent: Sunday, October 06, 2013 3:05 PM
> To: dev
> Subject: Re: [DISCUSS] Breaking out Marvin from CloudStack
>
> On Sun, Oct 6, 2013 at 8:10 PM, Animesh Chaturvedi <
> animesh.chaturv...@citrix.com> wrote:
>
> > > Yes and we will need to work down a backlog of scenarios before we
> > > ever can rely on guys like me doing that. Not because they won't but
> > > because there is to much to write tests for edging on the new
> > > features they write. Just because those tests aren't there yet. I
> > > think giving Citrix QA a repo to work on is fine but I would like to
> > > see it merged back at some point and a continued possibility to write
> them in the main tree.
> > >
> > [Animesh>] While I don't agree to a separate repo for tests (marvin
> > framework is ok) I do want to call out the proposal is not for giving
> > Citrix QA a repo to work on and I don't think Prasanna meant that way.
> >
>
>
> I have to apologize for the formulations I choose to express my thoughts
> with. I did not mean to talk of a department of a certain company donating
> human effort for testing to the community. I was talking of the frustration of
> the individuals working and how the separate repo would smoothen their
> workflow. The new repo is in the apache domain, no question whether the
> work in their is done by one person or 100 companies.
