1. extend the namespace using execfile for getting cmdlets. Don't expect
existing marvin installations
2. additional entity adjustments for registerUserkeys and template
related APIs
3. optional **kwargs are explained in docstring
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
When comparing json response against the response object disregard the
jobstatus and jobid returned as part of object response. These are some
quirks in the API response added previously that we are unable to
remove.
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
CloudStackEntity : represents the base entity. This is a placeholder for
future use. Right now it only implements version info
CloudStackBaseFactory: overloads AbstractFactory to provide custom hooks
for CloudStackEntity creation. The current creators for cloudstack
entities are any api actions that begin as create, deploy or register
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
legacy: all old integration libraries go here
generate: all the code used to autogenerate marvin libraries
docs: documentation
data: data objects representing what were earlier service dictionaries
cmd.id = self.id expression should be included only when id is in the
required arguments of the entity.
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
Some entities are unrelated to the API. Include the complete API as the
verb to make the relationship to the entitiy clearer
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
All delete APIs have an id field and the entityType the delete is
removing from the system is found here. Include the entity Type for
these in the API discovery service.
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
Also include the entity generation in to the codegenerator so single
module can generate both api command objects and the derived entities.
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
The API discovery service is enhanced to include the entity that an API
will act upon. Also included are the changes for API doc generation.
For APIs that don't provide a direct relationship to their entities we
use the related parameter to derive the entity.
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
eg: dedicatePublicIpRange acts on VlanIpRange entities. So does listVlanIpRanges,
listapisresponse: {
count: 1,
api: [
{
name: "dedicatePublicIpRange",
description: "Dedicates a Public IP range to an account",
isasync: false,
related: "listVlanIpRanges",
params: [],
response: [],
entity: "VlanIpRange"
}
]
}
}
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
adding support for capturing plurals
adding filtering for non-conforming entities
adding more error checking in entity.action {return}
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
Marvin deserializes by matching attributes of the response with the
responseObject expected. In case the object's attributes don't mirror
the response Marvin assumes the response is invalid and can't return a
proper first class entity. This makes it difficult for tests to
reference the object's attributes in a sensible way.
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
createAccountResponse is now an instance of createAccountResponse and
not just a plain dict.
TODO:
1. nested entities don't work yet.
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
Build phase will init the bare minimum object required to make the web
request to the mgmt server
Create phase will make the actual request and fill the attributes of the
entity after recieving the response
This allows for one shot creation of the entity using:
EntityFactory.create(apiclient)
over two steps:
factory = EntityFactory()
entity = Entity.create(apiclient, factory)
TODO:
Figure out howto perform related factory creation.
eg: UserFactory.create() inits AccountFactory.create()
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
Prasanna Santhanam