On Sep 25, 2013, at 2:22 AM, Frank Zhang <frank.zh...@citrix.com> wrote:
> Yes it's SOAP.
> But Python is not a good choice for AWS API considering its SOAP library
> quality .
> If we do it, I'd prefer groovy which is just Java but with all awesome
> dynamic language features like weak type, functional style programming,
> meta-data programming. And Grails has provided all means to construct a
> web-server in war(just get rid of model and view , only use controller)
>
> However, for query API, I also think Python is not a good candidate. Reasons
> are below:
> 1. Query API plays with core data model which should be part of CloudStack
> orchestration, split it into a separate project will cause data model
> diverge. For example, currently API response object represents API data model
> which is the target for querying, if we put query in a python project, then
> API writer will be burdened for syncing his new API into Python
> query. I am sure lots of current CloudStack developers don't want to see
> this. A relief way here is using code generation which produces python code
> from API response object automatically, however, once a Response object has
> one-to-many, many-to-many relationship, thing will get complicated.
>
> 2. Python or any dynamic language has no advantage on query API. A big bonus
> of dynamic language is weak type which allows you to write schema-less
> code(in database terms). By
> schema-less I mean you don't have to define a Class for your data structure
> but just add fields on object on demand(unfortunately, Python is half way on
> this, you still need to define a Class
> for object. Though people use map to overcome this, because of lacking
> capability using '.' for field reference, embedded object in map creates ugly
> code). However, query API is the feature that really needs schema. Think
> about querying vm.nic = 'some nic', before firing real query to database, we
> need to validate if 'nic' is a field of object vm. To do this we need
> a schema defining all queryable fields of API response, a Java class plays
> its role in this case. Given the schema nature of query API, dynamic language
> is not shining in this area.
>
> Actually, using Java inspection to create query API is very easy. Because
> current response object class already has an annotation mapping to VO object,
> when a query api comes in, we can
> easily construct sql query by inspecting response object and VO object. For
> example, a API query may look like(in JSON):
>
> {
> QueryUserVm: {
> conditions: [ {
> 'field': 'name',
> 'op': '=',
> 'value': 'AweSomeVM'
> }, {
> 'field': 'state',
> 'op': '=',
> 'value': 'Running'
> }]
> }
> }
>
> Then we inspect UserVmResponse knowing its VO class is UserVmVO. Generating
> a SQL querying user_vm table where name = ''AweSomeVM'' and state = 'Running'
> is very straightforward.
>
> But, to achieve this in current CloudStack there is still lots of works to
> do. The biggest problem is our response object class is not exactly
> representing VO object in database. Actually our response object class is
> compose of multiple DB tables in denormalizing manner. This keeps us from
> writing a lightweight query framework that can generate SQL query for any
> response object, because automatically generating sub query/join is proven as
> a headache problem. Another obstacle is current DAO/SearchBuilder lacks a
> metamodel which allows creating type-safe query in programming way(JPA,
> QueryDSL have such metamodel), so query framework will directly play with
> plain SQL that is not convenient.
>
> Given above, I think before our API refactor defines a clear data model, it's
> hard to create a lightweight query framework which resolves query forever.
>
>
Thanks to all and Darren S for testing.
I have not looked at the AWS query api in a long time and Frank's comments are
beyond my understanding of it however if we wanted to do this, we could
technically use the same framework has this GCE app. mapping the cloudstack api
response object to the ec2 response can be a headache but not unsurmountable.
-Sebastien
>> -----Original Message-----
>> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
>> Sent: Tuesday, September 24, 2013 7:38 PM
>> To: dev@cloudstack.apache.org
>> Cc: dev@cloudstack.apache.org; Ian Duffy; Darren Brogan
>> Subject: Re: [ANNOUNCE] A GCE interface to CloudStack
>>
>> I got this running earlier today and was really impressed with it, good job!
>>
>> Our current AWS is just SOAP right? How about when we do the query api we
>> do it as a separate python project just like this.
>>
>> Darren
>>
>>> On Sep 24, 2013, at 11:40 AM, Frank Zhang <frank.zh...@citrix.com> wrote:
>>>
>>> Take a look at source. Clean and lightweight implementation. Awesome.
>>> I hope our AWS someday can go this way someday, a separate web server
>>> in separate repo and using some dynamically language which makes
>>> smaller code
>>>
>>>
>>>> -----Original Message-----
>>>> From: Musayev, Ilya [mailto:imusa...@webmd.net]
>>>> Sent: Tuesday, September 24, 2013 11:23 AM
>>>> To: dev@cloudstack.apache.org
>>>> Cc: Ian Duffy; Darren Brogan
>>>> Subject: RE: [ANNOUNCE] A GCE interface to CloudStack
>>>>
>>>> This looks awesome :)
>>>>
>>>>> -----Original Message-----
>>>>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>>>>> Sent: Tuesday, September 24, 2013 12:59 PM
>>>>> To: dev@cloudstack.apache.org
>>>>> Cc: Ian Duffy; Darren Brogan
>>>>> Subject: Re: [ANNOUNCE] A GCE interface to CloudStack
>>>>>
>>>>> Wow. Nice!
>>>>>
>>>>>> On 9/24/13 6:04 AM, "sebgoa" <run...@gmail.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am quite pumped to announce a Google Compute Engine (GCE)
>>>>>> interface to CloudStack.
>>>>>>
>>>>>> Ian Duffy, Darren Brogan and myself worked on this on github over
>>>>>> the last month. Our latest branch:
>>>>>>
>>>>>> https://github.com/NOPping/cloudstack-gce/tree/refactor
>>>>>>
>>>>>> Has been uploaded to pypi:
>>>>>>
>>>>>> https://pypi.python.org/pypi/gcloud
>>>>>>
>>>>>> A little virtualenv and a pip install gcloud will give you a Flask
>>>>>> application, with OAuth2 provider and REST routes that map to the
>>>>>> CloudStack API.
>>>>>> The routes are compliant with GCE API, which allows you to use the
>>>>>> Google gcutil cli to talk to your CloudStack cloud.
>>>>>>
>>>>>> Of course there are a few caveats that I will not mention, this is
>>>>>> release 0.0.1, feedback and pr welcome.
>>>>>>
>>>>>> Congrats to our two 20 year olds in ireland who are taking names up
>>>>>> in Dublin !
>>>>>>
>>>>>> Have fun,
>>>>>>
>>>>>> -Sebastien
>>>
