You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cloudstack.apache.org by Ryan Dietrich <ry...@betterservers.com> on 2013/10/23 23:24:12 UTC

Review Request 14889: Expose as much type information to commands.xml as well as to the generated python clasesss for Marvin

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14889/
-----------------------------------------------------------

Review request for cloudstack, Marcus Sorensen and Prasanna Santhanam.

Repository: cloudstack-git

Description
-------

I have a requirement for some work I am doing to "fail early". The existing marvin cloudstackAPI classes give me both the "legal" and "required" elements for each API call as well as the response attributes. However, they do not tell me the types of each value. I've gone ahead and exposed that type information to python and to commands.xml as well. I decided to try and expose things so we're being as descriptive as possible. It's a little deflating how the Request/Response annotations aren't equal (Requests can expose "strings" as "uuid's", allowing me to auto generate regex's for validation). Responses however, simply fall back to the specific java type, (Integer, Long, String, Boolean).

I believe cloudmonkey could take advantage of this, by stopping invalid parameters from being sent to Cloudstack in the first place (client side validation is good, right?)
I also think the UI could use this as part of their validation routines, if they're using commands.xml as part of their build process.

Diffs
-----

server/src/com/cloud/api/doc/ApiXmlDocWriter.java c3c0cab
server/src/com/cloud/api/doc/Argument.java 29c361e
tools/marvin/marvin/codegenerator.py 96729f6

Diff: https://reviews.apache.org/r/14889/diff/

Testing
-------

mvn clean
mvn
cd tools/apidoc
mvn
inspect target/commands.xml
cd ../tools/marvin
mvn
inspect python classes

Thanks,

Ryan Dietrich

Re: Review Request 14889: Expose as much type information to commands.xml as well as to the generated python clasesss for Marvin

Posted by Ryan Dietrich <ry...@betterservers.com>.


> On Oct. 28, 2013, 6:06 a.m., Prasanna Santhanam wrote:
> > One last thing - if you change the ApiXmlDocWriter to include type information, you might want to include that in the API discovery plugin as well. Many of the downstream tools (cloudmonkey/marvin) use the listApis call to sync against the management server's exposed API set.

Ok, I'll make that change as well then.


- Ryan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14889/#review27593
-----------------------------------------------------------


On Oct. 23, 2013, 9:38 p.m., Ryan Dietrich wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14889/
> -----------------------------------------------------------
> 
> (Updated Oct. 23, 2013, 9:38 p.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen and Prasanna Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> -------
> 
> I have a requirement for some work I am doing to "fail early".  The existing marvin cloudstackAPI classes give me both the "legal" and "required" elements for each API call as well as the response attributes.  However, they do not tell me the types of each value.  I've gone ahead and exposed that type information to python and to commands.xml as well.  I decided to try and expose things so we're being as descriptive as possible.  It's a little deflating how the Request/Response annotations aren't equal (Requests can expose "strings" as "uuid's", allowing me to auto generate regex's for validation).  Responses however, simply fall back to the specific java type, (Integer, Long, String, Boolean).
> 
> I believe cloudmonkey could take advantage of this, by stopping invalid parameters from being sent to Cloudstack in the first place (client side validation is good, right?)
> I also think the UI could use this as part of their validation routines, if they're using commands.xml as part of their build process.
> 
> 
> Diffs
> -----
> 
>   server/src/com/cloud/api/doc/ApiXmlDocWriter.java c3c0cab 
>   server/src/com/cloud/api/doc/Argument.java 29c361e 
>   tools/marvin/marvin/codegenerator.py 96729f6 
> 
> Diff: https://reviews.apache.org/r/14889/diff/
> 
> 
> Testing
> -------
> 
> mvn clean
> mvn
> cd tools/apidoc
> mvn
> inspect target/commands.xml
> cd ../tools/marvin
> mvn
> inspect python classes
> 
> 
> Thanks,
> 
> Ryan Dietrich
> 
>

Re: Review Request 14889: Expose as much type information to commands.xml as well as to the generated python clasesss for Marvin

Posted by Prasanna Santhanam <ts...@apache.org>.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14889/#review27593
-----------------------------------------------------------


One last thing - if you change the ApiXmlDocWriter to include type information, you might want to include that in the API discovery plugin as well. Many of the downstream tools (cloudmonkey/marvin) use the listApis call to sync against the management server's exposed API set.

- Prasanna Santhanam


On Oct. 23, 2013, 9:38 p.m., Ryan Dietrich wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14889/
> -----------------------------------------------------------
> 
> (Updated Oct. 23, 2013, 9:38 p.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen and Prasanna Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> -------
> 
> I have a requirement for some work I am doing to "fail early".  The existing marvin cloudstackAPI classes give me both the "legal" and "required" elements for each API call as well as the response attributes.  However, they do not tell me the types of each value.  I've gone ahead and exposed that type information to python and to commands.xml as well.  I decided to try and expose things so we're being as descriptive as possible.  It's a little deflating how the Request/Response annotations aren't equal (Requests can expose "strings" as "uuid's", allowing me to auto generate regex's for validation).  Responses however, simply fall back to the specific java type, (Integer, Long, String, Boolean).
> 
> I believe cloudmonkey could take advantage of this, by stopping invalid parameters from being sent to Cloudstack in the first place (client side validation is good, right?)
> I also think the UI could use this as part of their validation routines, if they're using commands.xml as part of their build process.
> 
> 
> Diffs
> -----
> 
>   server/src/com/cloud/api/doc/ApiXmlDocWriter.java c3c0cab 
>   server/src/com/cloud/api/doc/Argument.java 29c361e 
>   tools/marvin/marvin/codegenerator.py 96729f6 
> 
> Diff: https://reviews.apache.org/r/14889/diff/
> 
> 
> Testing
> -------
> 
> mvn clean
> mvn
> cd tools/apidoc
> mvn
> inspect target/commands.xml
> cd ../tools/marvin
> mvn
> inspect python classes
> 
> 
> Thanks,
> 
> Ryan Dietrich
> 
>

Re: Review Request 14889: Expose as much type information to commands.xml as well as to the generated python clasesss for Marvin

Posted by Marcus Sorensen <sh...@gmail.com>.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14889/#review27461
-----------------------------------------------------------

Ship it!


Looks cool to me, will give Prasanna time to respond.


- Marcus Sorensen


On Oct. 23, 2013, 9:38 p.m., Ryan Dietrich wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14889/
> -----------------------------------------------------------
> 
> (Updated Oct. 23, 2013, 9:38 p.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen and Prasanna Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> -------
> 
> I have a requirement for some work I am doing to "fail early".  The existing marvin cloudstackAPI classes give me both the "legal" and "required" elements for each API call as well as the response attributes.  However, they do not tell me the types of each value.  I've gone ahead and exposed that type information to python and to commands.xml as well.  I decided to try and expose things so we're being as descriptive as possible.  It's a little deflating how the Request/Response annotations aren't equal (Requests can expose "strings" as "uuid's", allowing me to auto generate regex's for validation).  Responses however, simply fall back to the specific java type, (Integer, Long, String, Boolean).
> 
> I believe cloudmonkey could take advantage of this, by stopping invalid parameters from being sent to Cloudstack in the first place (client side validation is good, right?)
> I also think the UI could use this as part of their validation routines, if they're using commands.xml as part of their build process.
> 
> 
> Diffs
> -----
> 
>   server/src/com/cloud/api/doc/ApiXmlDocWriter.java c3c0cab 
>   server/src/com/cloud/api/doc/Argument.java 29c361e 
>   tools/marvin/marvin/codegenerator.py 96729f6 
> 
> Diff: https://reviews.apache.org/r/14889/diff/
> 
> 
> Testing
> -------
> 
> mvn clean
> mvn
> cd tools/apidoc
> mvn
> inspect target/commands.xml
> cd ../tools/marvin
> mvn
> inspect python classes
> 
> 
> Thanks,
> 
> Ryan Dietrich
> 
>

Re: Review Request 14889: Expose as much type information to commands.xml as well as to the generated python clasesss for Marvin

Posted by Ryan Dietrich <ry...@betterservers.com>.


> On Oct. 25, 2013, 6:10 a.m., Prasanna Santhanam wrote:
> > I actually don't quite see how marvin uses the typeInfo. Will it only act as a carrier for this information? 
> > 
> > How would a test case author use this? It would've been nice if we could use the type info to deserialize the response returned by the server so each field gets its appropriate type. But in most tests we don't use the type information afaik.
> 
> Ryan Dietrich wrote:
>     Yes, a carrier.  The main goal was to get the type into commands.xml, so other "things" could take advantage of this extra meta-data.
> 
> Prasanna Santhanam wrote:
>     I'm okay with it going to the 'commands.xml'. But may be we could wait on including it in cloudstackAPI stubs since you're not using this information directly from marvin?

If I added it for use with Marvin would that be acceptable?


- Ryan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14889/#review27513
-----------------------------------------------------------


On Oct. 23, 2013, 9:38 p.m., Ryan Dietrich wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14889/
> -----------------------------------------------------------
> 
> (Updated Oct. 23, 2013, 9:38 p.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen and Prasanna Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> -------
> 
> I have a requirement for some work I am doing to "fail early".  The existing marvin cloudstackAPI classes give me both the "legal" and "required" elements for each API call as well as the response attributes.  However, they do not tell me the types of each value.  I've gone ahead and exposed that type information to python and to commands.xml as well.  I decided to try and expose things so we're being as descriptive as possible.  It's a little deflating how the Request/Response annotations aren't equal (Requests can expose "strings" as "uuid's", allowing me to auto generate regex's for validation).  Responses however, simply fall back to the specific java type, (Integer, Long, String, Boolean).
> 
> I believe cloudmonkey could take advantage of this, by stopping invalid parameters from being sent to Cloudstack in the first place (client side validation is good, right?)
> I also think the UI could use this as part of their validation routines, if they're using commands.xml as part of their build process.
> 
> 
> Diffs
> -----
> 
>   server/src/com/cloud/api/doc/ApiXmlDocWriter.java c3c0cab 
>   server/src/com/cloud/api/doc/Argument.java 29c361e 
>   tools/marvin/marvin/codegenerator.py 96729f6 
> 
> Diff: https://reviews.apache.org/r/14889/diff/
> 
> 
> Testing
> -------
> 
> mvn clean
> mvn
> cd tools/apidoc
> mvn
> inspect target/commands.xml
> cd ../tools/marvin
> mvn
> inspect python classes
> 
> 
> Thanks,
> 
> Ryan Dietrich
> 
>

Re: Review Request 14889: Expose as much type information to commands.xml as well as to the generated python clasesss for Marvin

Posted by Ryan Dietrich <ry...@betterservers.com>.


> On Oct. 25, 2013, 6:10 a.m., Prasanna Santhanam wrote:
> > I actually don't quite see how marvin uses the typeInfo. Will it only act as a carrier for this information? 
> > 
> > How would a test case author use this? It would've been nice if we could use the type info to deserialize the response returned by the server so each field gets its appropriate type. But in most tests we don't use the type information afaik.

Yes, a carrier.  The main goal was to get the type into commands.xml, so other "things" could take advantage of this extra meta-data.


- Ryan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14889/#review27513
-----------------------------------------------------------


On Oct. 23, 2013, 9:38 p.m., Ryan Dietrich wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14889/
> -----------------------------------------------------------
> 
> (Updated Oct. 23, 2013, 9:38 p.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen and Prasanna Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> -------
> 
> I have a requirement for some work I am doing to "fail early".  The existing marvin cloudstackAPI classes give me both the "legal" and "required" elements for each API call as well as the response attributes.  However, they do not tell me the types of each value.  I've gone ahead and exposed that type information to python and to commands.xml as well.  I decided to try and expose things so we're being as descriptive as possible.  It's a little deflating how the Request/Response annotations aren't equal (Requests can expose "strings" as "uuid's", allowing me to auto generate regex's for validation).  Responses however, simply fall back to the specific java type, (Integer, Long, String, Boolean).
> 
> I believe cloudmonkey could take advantage of this, by stopping invalid parameters from being sent to Cloudstack in the first place (client side validation is good, right?)
> I also think the UI could use this as part of their validation routines, if they're using commands.xml as part of their build process.
> 
> 
> Diffs
> -----
> 
>   server/src/com/cloud/api/doc/ApiXmlDocWriter.java c3c0cab 
>   server/src/com/cloud/api/doc/Argument.java 29c361e 
>   tools/marvin/marvin/codegenerator.py 96729f6 
> 
> Diff: https://reviews.apache.org/r/14889/diff/
> 
> 
> Testing
> -------
> 
> mvn clean
> mvn
> cd tools/apidoc
> mvn
> inspect target/commands.xml
> cd ../tools/marvin
> mvn
> inspect python classes
> 
> 
> Thanks,
> 
> Ryan Dietrich
> 
>

Re: Review Request 14889: Expose as much type information to commands.xml as well as to the generated python clasesss for Marvin

Posted by Prasanna Santhanam <ts...@apache.org>.


> On Oct. 25, 2013, 6:10 a.m., Prasanna Santhanam wrote:
> > I actually don't quite see how marvin uses the typeInfo. Will it only act as a carrier for this information? 
> > 
> > How would a test case author use this? It would've been nice if we could use the type info to deserialize the response returned by the server so each field gets its appropriate type. But in most tests we don't use the type information afaik.
> 
> Ryan Dietrich wrote:
>     Yes, a carrier.  The main goal was to get the type into commands.xml, so other "things" could take advantage of this extra meta-data.

I'm okay with it going to the 'commands.xml'. But may be we could wait on including it in cloudstackAPI stubs since you're not using this information directly from marvin? 


- Prasanna


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14889/#review27513
-----------------------------------------------------------


On Oct. 23, 2013, 9:38 p.m., Ryan Dietrich wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14889/
> -----------------------------------------------------------
> 
> (Updated Oct. 23, 2013, 9:38 p.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen and Prasanna Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> -------
> 
> I have a requirement for some work I am doing to "fail early".  The existing marvin cloudstackAPI classes give me both the "legal" and "required" elements for each API call as well as the response attributes.  However, they do not tell me the types of each value.  I've gone ahead and exposed that type information to python and to commands.xml as well.  I decided to try and expose things so we're being as descriptive as possible.  It's a little deflating how the Request/Response annotations aren't equal (Requests can expose "strings" as "uuid's", allowing me to auto generate regex's for validation).  Responses however, simply fall back to the specific java type, (Integer, Long, String, Boolean).
> 
> I believe cloudmonkey could take advantage of this, by stopping invalid parameters from being sent to Cloudstack in the first place (client side validation is good, right?)
> I also think the UI could use this as part of their validation routines, if they're using commands.xml as part of their build process.
> 
> 
> Diffs
> -----
> 
>   server/src/com/cloud/api/doc/ApiXmlDocWriter.java c3c0cab 
>   server/src/com/cloud/api/doc/Argument.java 29c361e 
>   tools/marvin/marvin/codegenerator.py 96729f6 
> 
> Diff: https://reviews.apache.org/r/14889/diff/
> 
> 
> Testing
> -------
> 
> mvn clean
> mvn
> cd tools/apidoc
> mvn
> inspect target/commands.xml
> cd ../tools/marvin
> mvn
> inspect python classes
> 
> 
> Thanks,
> 
> Ryan Dietrich
> 
>

Re: Review Request 14889: Expose as much type information to commands.xml as well as to the generated python clasesss for Marvin

Posted by Prasanna Santhanam <ts...@apache.org>.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14889/#review27513
-----------------------------------------------------------


I actually don't quite see how marvin uses the typeInfo. Will it only act as a carrier for this information? 

How would a test case author use this? It would've been nice if we could use the type info to deserialize the response returned by the server so each field gets its appropriate type. But in most tests we don't use the type information afaik.

- Prasanna Santhanam


On Oct. 23, 2013, 9:38 p.m., Ryan Dietrich wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14889/
> -----------------------------------------------------------
> 
> (Updated Oct. 23, 2013, 9:38 p.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen and Prasanna Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> -------
> 
> I have a requirement for some work I am doing to "fail early".  The existing marvin cloudstackAPI classes give me both the "legal" and "required" elements for each API call as well as the response attributes.  However, they do not tell me the types of each value.  I've gone ahead and exposed that type information to python and to commands.xml as well.  I decided to try and expose things so we're being as descriptive as possible.  It's a little deflating how the Request/Response annotations aren't equal (Requests can expose "strings" as "uuid's", allowing me to auto generate regex's for validation).  Responses however, simply fall back to the specific java type, (Integer, Long, String, Boolean).
> 
> I believe cloudmonkey could take advantage of this, by stopping invalid parameters from being sent to Cloudstack in the first place (client side validation is good, right?)
> I also think the UI could use this as part of their validation routines, if they're using commands.xml as part of their build process.
> 
> 
> Diffs
> -----
> 
>   server/src/com/cloud/api/doc/ApiXmlDocWriter.java c3c0cab 
>   server/src/com/cloud/api/doc/Argument.java 29c361e 
>   tools/marvin/marvin/codegenerator.py 96729f6 
> 
> Diff: https://reviews.apache.org/r/14889/diff/
> 
> 
> Testing
> -------
> 
> mvn clean
> mvn
> cd tools/apidoc
> mvn
> inspect target/commands.xml
> cd ../tools/marvin
> mvn
> inspect python classes
> 
> 
> Thanks,
> 
> Ryan Dietrich
> 
>

Re: Review Request 14889: Expose as much type information to commands.xml as well as to the generated python clasesss for Marvin

Posted by Ryan Dietrich <ry...@betterservers.com>.

(Updated Oct. 23, 2013, 9:38 p.m.)

Review request for cloudstack, Marcus Sorensen and Prasanna Santhanam.

Changes
-------

Small bug fixed.

Repository: cloudstack-git

Description
-------

Diffs (updated)
-----

server/src/com/cloud/api/doc/ApiXmlDocWriter.java c3c0cab
server/src/com/cloud/api/doc/Argument.java 29c361e
tools/marvin/marvin/codegenerator.py 96729f6

Diff: https://reviews.apache.org/r/14889/diff/

Testing
-------

mvn clean
mvn
cd tools/apidoc
mvn
inspect target/commands.xml
cd ../tools/marvin
mvn
inspect python classes

Thanks,

Ryan Dietrich