You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Charles Moulliard <ch...@gmail.com> on 2013/01/28 20:51:40 UTC
Question concerning json response of deployvirtualmachine (4.1)
Hi,
The json response of deployvirtualmachine - 4.1-SNAPSHOT contains now a
variable "cloudstack-version".
2013-01-28 20:31:42,796 | DEBUG | user thread 0 | AsyncRestClientProxy
| clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
1.5.3 | Invoking VirtualMachineAsyncClient.deployVirtualMachineInZone
2013-01-28 20:31:42,798 | DEBUG | i/o thread 0 |
avaUrlHttpCommandExecutorService | clouds.logging.log4j.Log4JLogger 60 |
115 - jclouds-log4j - 1.5.3 | Sending request -546853376: GET
http://localhost:8080/client/api?response=json&command=deployVirtualMachine&zoneid=320d876d-741c-4e71-9a1c-5a9e7838dd50&templateid=5c0b75a8-6927-11e2-a8a4-5c260a0287e9&serviceofferingid=ee9d812e-dd25-4e8f-83ed-1d0d22f39b5b&displayname=fabric-30a&name=fabric-30a&apiKey=EqYwkeuZnxxdkx-HnFOkCN5KkfCWyypfX5KVcX37116twCOXBau0QUWYB4pjHd8RyHn7kDP_rZnwGkpQWD4Qxg&signature=PF18u%2BqF%2FgOZyPN%2FpfR2VPyOlwY%3DHTTP/1.1
2013-01-28 20:31:42,799 | DEBUG | i/o thread 0 | headers
| clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
1.5.3 | >> GET
http://localhost:8080/client/api?response=json&command=deployVirtualMachine&zoneid=320d876d-741c-4e71-9a1c-5a9e7838dd50&templateid=5c0b75a8-6927-11e2-a8a4-5c260a0287e9&serviceofferingid=ee9d812e-dd25-4e8f-83ed-1d0d22f39b5b&displayname=fabric-30a&name=fabric-30a&apiKey=EqYwkeuZnxxdkx-HnFOkCN5KkfCWyypfX5KVcX37116twCOXBau0QUWYB4pjHd8RyHn7kDP_rZnwGkpQWD4Qxg&signature=PF18u%2BqF%2FgOZyPN%2FpfR2VPyOlwY%3DHTTP/1.1
2013-01-28 20:31:42,799 | DEBUG | i/o thread 0 | headers
| clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
1.5.3 | >> Accept: application/json
2013-01-28 20:31:43,187 | DEBUG | i/o thread 0 |
avaUrlHttpCommandExecutorService | clouds.logging.log4j.Log4JLogger 60 |
115 - jclouds-log4j - 1.5.3 | Receiving response -546853376: HTTP/1.1 200 OK
2013-01-28 20:31:43,187 | DEBUG | i/o thread 0 | headers
| clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
1.5.3 | << HTTP/1.1 200 OK
2013-01-28 20:31:43,188 | DEBUG | i/o thread 0 | headers
| clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
1.5.3 | << Server: Jetty(6.1.26)
2013-01-28 20:31:43,188 | DEBUG | i/o thread 0 | headers
| clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
1.5.3 | << Content-Type: text/javascript; charset=UTF-8
2013-01-28 20:31:43,189 | DEBUG | i/o thread 0 | headers
| clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
1.5.3 | << Content-Length: 169
2013-01-28 20:31:43,189 | DEBUG | i/o thread 0 | wire
| clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
1.5.3 | << "{ "deployvirtualmachineresponse" :
{"id":"1cce6cb7-2268-47ff-9696-d9e610f6619a","jobid":"13330fc9-8b3e-4582-aa3e-90883c041ff0"},
"cloudstack-version": "4.1.0-SNAPSHOT" }"
As I don't see it in the doc here (
http://incubator.apache.org/cloudstack/docs/api/apidocs-4.0.0/TOC_User.html),
can somebody confirms that this is new feature not yet published in the doc
? Can we disable it to be compatible with CloudStack 3.0 API ?
Regards,
--
Charles Moulliard
Apache Committer / Sr. Enterprise Architect (RedHat)
Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
Re: Question concerning json response of deployvirtualmachine (4.1)
Posted by Rohit Yadav <bh...@apache.org>.
On Wed, Jan 30, 2013 at 12:52 AM, Charles Moulliard <ch...@gmail.com> wrote:
> Hi,
>
> I have opened a ticket at jclouds. They should fix this problem in release
> 1.5.6 (Ticket --> https://github.com/jclouds/jclouds/issues/1254 and more
> info about Adrian Cole) but I don't know if it will be ready for tomorrow.
> If you have a fix that I can apply on cloudstack-4.1-SNAPSHOT, I can make a
> test today.
>
> Until now, jclouds target to receive this json response
> { "deployvirtualmachine" : {"id":1234, "jobid":50006} }
> but not this
> { "deployvirtualmachineresponse" :
> {"id":"1cce6cb7-2268-47ff-9696-d9e610f6619a","jobid":"13330fc9-8b3e-4582-aa3e-90883c041ff0"},
> "cloudstack-version": "4.1.0-SNAPSHOT" }
Oh but I think the response key always existed, at least from 3.x?
"deployvirtualmachineresponse" : {#response dict here}?
Pl. open an issue and assign to me, if it's an issue?
Regards.
>
> Regards,
>
> Charles
>
>
> On Tue, Jan 29, 2013 at 1:17 PM, Sebastien Goasguen <ru...@gmail.com>wrote:
>
>>
>> On Jan 29, 2013, at 10:07 AM, Rohit Yadav <bh...@apache.org> wrote:
>>
>> > On Tue, Jan 29, 2013 at 12:52 AM, Sebastien Goasguen <ru...@gmail.com>
>> wrote:
>> >>
>> >> It seems to be breaking Charles jclouds scripts.
>> >>
>> >> Did you fix it in master after 4.0 release ?
>> >
>> > This was done in api refactoring branch which was merged recently and
>> > it's in master only.
>> >
>> >> It could be that jclouds worked around this and that by fixing it, we
>> actually broke the jclouds client.
>> >
>> > I don't know how jclouds works and handles response. I would like to
>> > hear from jclouds and other folks who may have been affected and how
>> > they can be helped. If we don't want this information, we can get rid
>> > of it and it's just master, the fix is simple.
>>
>> Let's see what Charles has to say. He is preparing a demo for the BACD in
>> Ghent.
>>
>> If you can send the hot fix via email, maybe Charles can apply it and
>> rebuild to get things working.
>>
>> -Sebastien
>>
>> >
>> > Regards.
>> >
>> >> -sebastien
>> >>
>> >>>
>> >>> This information can be used by platforms that run on top of
>> >>> CloudStack and clients/scripts to implement logic to handle response
>> >>> based on version info.
>> >>>
>> >>> We can discuss and remove this field if we don't want it.
>> >>>
>> >>> Regards.
>> >>>
>> >>>>
>> >>>> Regards,
>> >>>>
>> >>>> --
>> >>>> Charles Moulliard
>> >>>> Apache Committer / Sr. Enterprise Architect (RedHat)
>> >>>> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
>> >>
>>
>>
>
>
> --
> Charles Moulliard
> Apache Committer / Sr. Enterprise Architect (RedHat)
> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
Re: Question concerning json response of deployvirtualmachine (4.1)
Posted by Rohit Yadav <bh...@apache.org>.
On Wed, Jan 30, 2013 at 12:52 AM, Charles Moulliard <ch...@gmail.com> wrote:
> Hi,
>
> I have opened a ticket at jclouds. They should fix this problem in release
> 1.5.6 (Ticket --> https://github.com/jclouds/jclouds/issues/1254 and more
> info about Adrian Cole) but I don't know if it will be ready for tomorrow.
> If you have a fix that I can apply on cloudstack-4.1-SNAPSHOT, I can make a
> test today.
>
> Until now, jclouds target to receive this json response
> { "deployvirtualmachine" : {"id":1234, "jobid":50006} }
> but not this
> { "deployvirtualmachineresponse" :
> {"id":"1cce6cb7-2268-47ff-9696-d9e610f6619a","jobid":"13330fc9-8b3e-4582-aa3e-90883c041ff0"},
> "cloudstack-version": "4.1.0-SNAPSHOT" }
Oh but I think the response key always existed, at least from 3.x?
"deployvirtualmachineresponse" : {#response dict here}?
Pl. open an issue and assign to me, if it's an issue?
Regards.
>
> Regards,
>
> Charles
>
>
> On Tue, Jan 29, 2013 at 1:17 PM, Sebastien Goasguen <ru...@gmail.com>wrote:
>
>>
>> On Jan 29, 2013, at 10:07 AM, Rohit Yadav <bh...@apache.org> wrote:
>>
>> > On Tue, Jan 29, 2013 at 12:52 AM, Sebastien Goasguen <ru...@gmail.com>
>> wrote:
>> >>
>> >> It seems to be breaking Charles jclouds scripts.
>> >>
>> >> Did you fix it in master after 4.0 release ?
>> >
>> > This was done in api refactoring branch which was merged recently and
>> > it's in master only.
>> >
>> >> It could be that jclouds worked around this and that by fixing it, we
>> actually broke the jclouds client.
>> >
>> > I don't know how jclouds works and handles response. I would like to
>> > hear from jclouds and other folks who may have been affected and how
>> > they can be helped. If we don't want this information, we can get rid
>> > of it and it's just master, the fix is simple.
>>
>> Let's see what Charles has to say. He is preparing a demo for the BACD in
>> Ghent.
>>
>> If you can send the hot fix via email, maybe Charles can apply it and
>> rebuild to get things working.
>>
>> -Sebastien
>>
>> >
>> > Regards.
>> >
>> >> -sebastien
>> >>
>> >>>
>> >>> This information can be used by platforms that run on top of
>> >>> CloudStack and clients/scripts to implement logic to handle response
>> >>> based on version info.
>> >>>
>> >>> We can discuss and remove this field if we don't want it.
>> >>>
>> >>> Regards.
>> >>>
>> >>>>
>> >>>> Regards,
>> >>>>
>> >>>> --
>> >>>> Charles Moulliard
>> >>>> Apache Committer / Sr. Enterprise Architect (RedHat)
>> >>>> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
>> >>
>>
>>
>
>
> --
> Charles Moulliard
> Apache Committer / Sr. Enterprise Architect (RedHat)
> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
Re: Question concerning json response of deployvirtualmachine (4.1)
Posted by Charles Moulliard <ch...@gmail.com>.
Hi,
I have opened a ticket at jclouds. They should fix this problem in release
1.5.6 (Ticket --> https://github.com/jclouds/jclouds/issues/1254 and more
info about Adrian Cole) but I don't know if it will be ready for tomorrow.
If you have a fix that I can apply on cloudstack-4.1-SNAPSHOT, I can make a
test today.
Until now, jclouds target to receive this json response
{ "deployvirtualmachine" : {"id":1234, "jobid":50006} }
but not this
{ "deployvirtualmachineresponse" :
{"id":"1cce6cb7-2268-47ff-9696-d9e610f6619a","jobid":"13330fc9-8b3e-4582-aa3e-90883c041ff0"},
"cloudstack-version": "4.1.0-SNAPSHOT" }
Regards,
Charles
On Tue, Jan 29, 2013 at 1:17 PM, Sebastien Goasguen <ru...@gmail.com>wrote:
>
> On Jan 29, 2013, at 10:07 AM, Rohit Yadav <bh...@apache.org> wrote:
>
> > On Tue, Jan 29, 2013 at 12:52 AM, Sebastien Goasguen <ru...@gmail.com>
> wrote:
> >>
> >> It seems to be breaking Charles jclouds scripts.
> >>
> >> Did you fix it in master after 4.0 release ?
> >
> > This was done in api refactoring branch which was merged recently and
> > it's in master only.
> >
> >> It could be that jclouds worked around this and that by fixing it, we
> actually broke the jclouds client.
> >
> > I don't know how jclouds works and handles response. I would like to
> > hear from jclouds and other folks who may have been affected and how
> > they can be helped. If we don't want this information, we can get rid
> > of it and it's just master, the fix is simple.
>
> Let's see what Charles has to say. He is preparing a demo for the BACD in
> Ghent.
>
> If you can send the hot fix via email, maybe Charles can apply it and
> rebuild to get things working.
>
> -Sebastien
>
> >
> > Regards.
> >
> >> -sebastien
> >>
> >>>
> >>> This information can be used by platforms that run on top of
> >>> CloudStack and clients/scripts to implement logic to handle response
> >>> based on version info.
> >>>
> >>> We can discuss and remove this field if we don't want it.
> >>>
> >>> Regards.
> >>>
> >>>>
> >>>> Regards,
> >>>>
> >>>> --
> >>>> Charles Moulliard
> >>>> Apache Committer / Sr. Enterprise Architect (RedHat)
> >>>> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
> >>
>
>
--
Charles Moulliard
Apache Committer / Sr. Enterprise Architect (RedHat)
Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
Re: Question concerning json response of deployvirtualmachine (4.1)
Posted by Charles Moulliard <ch...@gmail.com>.
Hi,
I have opened a ticket at jclouds. They should fix this problem in release
1.5.6 (Ticket --> https://github.com/jclouds/jclouds/issues/1254 and more
info about Adrian Cole) but I don't know if it will be ready for tomorrow.
If you have a fix that I can apply on cloudstack-4.1-SNAPSHOT, I can make a
test today.
Until now, jclouds target to receive this json response
{ "deployvirtualmachine" : {"id":1234, "jobid":50006} }
but not this
{ "deployvirtualmachineresponse" :
{"id":"1cce6cb7-2268-47ff-9696-d9e610f6619a","jobid":"13330fc9-8b3e-4582-aa3e-90883c041ff0"},
"cloudstack-version": "4.1.0-SNAPSHOT" }
Regards,
Charles
On Tue, Jan 29, 2013 at 1:17 PM, Sebastien Goasguen <ru...@gmail.com>wrote:
>
> On Jan 29, 2013, at 10:07 AM, Rohit Yadav <bh...@apache.org> wrote:
>
> > On Tue, Jan 29, 2013 at 12:52 AM, Sebastien Goasguen <ru...@gmail.com>
> wrote:
> >>
> >> It seems to be breaking Charles jclouds scripts.
> >>
> >> Did you fix it in master after 4.0 release ?
> >
> > This was done in api refactoring branch which was merged recently and
> > it's in master only.
> >
> >> It could be that jclouds worked around this and that by fixing it, we
> actually broke the jclouds client.
> >
> > I don't know how jclouds works and handles response. I would like to
> > hear from jclouds and other folks who may have been affected and how
> > they can be helped. If we don't want this information, we can get rid
> > of it and it's just master, the fix is simple.
>
> Let's see what Charles has to say. He is preparing a demo for the BACD in
> Ghent.
>
> If you can send the hot fix via email, maybe Charles can apply it and
> rebuild to get things working.
>
> -Sebastien
>
> >
> > Regards.
> >
> >> -sebastien
> >>
> >>>
> >>> This information can be used by platforms that run on top of
> >>> CloudStack and clients/scripts to implement logic to handle response
> >>> based on version info.
> >>>
> >>> We can discuss and remove this field if we don't want it.
> >>>
> >>> Regards.
> >>>
> >>>>
> >>>> Regards,
> >>>>
> >>>> --
> >>>> Charles Moulliard
> >>>> Apache Committer / Sr. Enterprise Architect (RedHat)
> >>>> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
> >>
>
>
--
Charles Moulliard
Apache Committer / Sr. Enterprise Architect (RedHat)
Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
Re: Question concerning json response of deployvirtualmachine (4.1)
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Jan 29, 2013, at 10:07 AM, Rohit Yadav <bh...@apache.org> wrote:
> On Tue, Jan 29, 2013 at 12:52 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>>
>> It seems to be breaking Charles jclouds scripts.
>>
>> Did you fix it in master after 4.0 release ?
>
> This was done in api refactoring branch which was merged recently and
> it's in master only.
>
>> It could be that jclouds worked around this and that by fixing it, we actually broke the jclouds client.
>
> I don't know how jclouds works and handles response. I would like to
> hear from jclouds and other folks who may have been affected and how
> they can be helped. If we don't want this information, we can get rid
> of it and it's just master, the fix is simple.
Let's see what Charles has to say. He is preparing a demo for the BACD in Ghent.
If you can send the hot fix via email, maybe Charles can apply it and rebuild to get things working.
-Sebastien
>
> Regards.
>
>> -sebastien
>>
>>>
>>> This information can be used by platforms that run on top of
>>> CloudStack and clients/scripts to implement logic to handle response
>>> based on version info.
>>>
>>> We can discuss and remove this field if we don't want it.
>>>
>>> Regards.
>>>
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Charles Moulliard
>>>> Apache Committer / Sr. Enterprise Architect (RedHat)
>>>> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
>>
Re: Question concerning json response of deployvirtualmachine (4.1)
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Jan 29, 2013, at 10:07 AM, Rohit Yadav <bh...@apache.org> wrote:
> On Tue, Jan 29, 2013 at 12:52 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>>
>> It seems to be breaking Charles jclouds scripts.
>>
>> Did you fix it in master after 4.0 release ?
>
> This was done in api refactoring branch which was merged recently and
> it's in master only.
>
>> It could be that jclouds worked around this and that by fixing it, we actually broke the jclouds client.
>
> I don't know how jclouds works and handles response. I would like to
> hear from jclouds and other folks who may have been affected and how
> they can be helped. If we don't want this information, we can get rid
> of it and it's just master, the fix is simple.
Let's see what Charles has to say. He is preparing a demo for the BACD in Ghent.
If you can send the hot fix via email, maybe Charles can apply it and rebuild to get things working.
-Sebastien
>
> Regards.
>
>> -sebastien
>>
>>>
>>> This information can be used by platforms that run on top of
>>> CloudStack and clients/scripts to implement logic to handle response
>>> based on version info.
>>>
>>> We can discuss and remove this field if we don't want it.
>>>
>>> Regards.
>>>
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Charles Moulliard
>>>> Apache Committer / Sr. Enterprise Architect (RedHat)
>>>> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
>>
Re: Question concerning json response of deployvirtualmachine (4.1)
Posted by Rohit Yadav <bh...@apache.org>.
On Tue, Jan 29, 2013 at 12:52 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>
> It seems to be breaking Charles jclouds scripts.
>
> Did you fix it in master after 4.0 release ?
This was done in api refactoring branch which was merged recently and
it's in master only.
> It could be that jclouds worked around this and that by fixing it, we actually broke the jclouds client.
I don't know how jclouds works and handles response. I would like to
hear from jclouds and other folks who may have been affected and how
they can be helped. If we don't want this information, we can get rid
of it and it's just master, the fix is simple.
Regards.
> -sebastien
>
>>
>> This information can be used by platforms that run on top of
>> CloudStack and clients/scripts to implement logic to handle response
>> based on version info.
>>
>> We can discuss and remove this field if we don't want it.
>>
>> Regards.
>>
>>>
>>> Regards,
>>>
>>> --
>>> Charles Moulliard
>>> Apache Committer / Sr. Enterprise Architect (RedHat)
>>> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
>
Re: Question concerning json response of deployvirtualmachine (4.1)
Posted by Rohit Yadav <bh...@apache.org>.
On Tue, Jan 29, 2013 at 12:52 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>
> It seems to be breaking Charles jclouds scripts.
>
> Did you fix it in master after 4.0 release ?
This was done in api refactoring branch which was merged recently and
it's in master only.
> It could be that jclouds worked around this and that by fixing it, we actually broke the jclouds client.
I don't know how jclouds works and handles response. I would like to
hear from jclouds and other folks who may have been affected and how
they can be helped. If we don't want this information, we can get rid
of it and it's just master, the fix is simple.
Regards.
> -sebastien
>
>>
>> This information can be used by platforms that run on top of
>> CloudStack and clients/scripts to implement logic to handle response
>> based on version info.
>>
>> We can discuss and remove this field if we don't want it.
>>
>> Regards.
>>
>>>
>>> Regards,
>>>
>>> --
>>> Charles Moulliard
>>> Apache Committer / Sr. Enterprise Architect (RedHat)
>>> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
>
Re: Question concerning json response of deployvirtualmachine (4.1)
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Jan 28, 2013, at 10:52 PM, Rohit Yadav <ro...@citrix.com> wrote:
> On Mon, Jan 28, 2013 at 11:53 AM, Chip Childers
> <ch...@sungard.com> wrote:
>> Forward from the user list. Rohit - want to answer?
>>
>>
>> ---------- Forwarded message ----------
>> From: Charles Moulliard <ch...@gmail.com>
>> Date: Mon, Jan 28, 2013 at 2:51 PM
>> Subject: Question concerning json response of deployvirtualmachine (4.1)
>> To: cloudstack-users@incubator.apache.org
>>
>>
>> Hi,
>>
>> The json response of deployvirtualmachine - 4.1-SNAPSHOT contains now a
>> variable "cloudstack-version".
>>
> ...
>> 1.5.3 | << "{ "deployvirtualmachineresponse" :
>> {"id":"1cce6cb7-2268-47ff-9696-d9e610f6619a","jobid":"13330fc9-8b3e-4582-aa3e-90883c041ff0"},
>> "cloudstack-version": "4.1.0-SNAPSHOT" }"
>>
>> As I don't see it in the doc here (
>> http://incubator.apache.org/cloudstack/docs/api/apidocs-4.0.0/TOC_User.html),
>
> It's because in apidocs we only document the response object fields.
>
>> can somebody confirms that this is new feature not yet published in the doc?
>
> If it's not there, it's a bug as xml response contains cloudstack
> version number. Can you open an issue?
>
>> Can we disable it to be compatible with CloudStack 3.0 API ?
>
> The version field was inconsistent in xml/json response, xml response
> contains the cloudstack version info but json did not and hoping that
> I remember it correctly, in the past versions cloudstack api response
> used to have version info in both so I fixed the issues to return
> version information in both xml and json response. While adding a new
> field in json response should not break any scripts
It seems to be breaking Charles jclouds scripts.
Did you fix it in master after 4.0 release ? It could be that jclouds worked around this and that by fixing it, we actually broke the jclouds client.
-sebastien
>
> This information can be used by platforms that run on top of
> CloudStack and clients/scripts to implement logic to handle response
> based on version info.
>
> We can discuss and remove this field if we don't want it.
>
> Regards.
>
>>
>> Regards,
>>
>> --
>> Charles Moulliard
>> Apache Committer / Sr. Enterprise Architect (RedHat)
>> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
Re: Question concerning json response of deployvirtualmachine (4.1)
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Jan 28, 2013, at 10:52 PM, Rohit Yadav <ro...@citrix.com> wrote:
> On Mon, Jan 28, 2013 at 11:53 AM, Chip Childers
> <ch...@sungard.com> wrote:
>> Forward from the user list. Rohit - want to answer?
>>
>>
>> ---------- Forwarded message ----------
>> From: Charles Moulliard <ch...@gmail.com>
>> Date: Mon, Jan 28, 2013 at 2:51 PM
>> Subject: Question concerning json response of deployvirtualmachine (4.1)
>> To: cloudstack-users@incubator.apache.org
>>
>>
>> Hi,
>>
>> The json response of deployvirtualmachine - 4.1-SNAPSHOT contains now a
>> variable "cloudstack-version".
>>
> ...
>> 1.5.3 | << "{ "deployvirtualmachineresponse" :
>> {"id":"1cce6cb7-2268-47ff-9696-d9e610f6619a","jobid":"13330fc9-8b3e-4582-aa3e-90883c041ff0"},
>> "cloudstack-version": "4.1.0-SNAPSHOT" }"
>>
>> As I don't see it in the doc here (
>> http://incubator.apache.org/cloudstack/docs/api/apidocs-4.0.0/TOC_User.html),
>
> It's because in apidocs we only document the response object fields.
>
>> can somebody confirms that this is new feature not yet published in the doc?
>
> If it's not there, it's a bug as xml response contains cloudstack
> version number. Can you open an issue?
>
>> Can we disable it to be compatible with CloudStack 3.0 API ?
>
> The version field was inconsistent in xml/json response, xml response
> contains the cloudstack version info but json did not and hoping that
> I remember it correctly, in the past versions cloudstack api response
> used to have version info in both so I fixed the issues to return
> version information in both xml and json response. While adding a new
> field in json response should not break any scripts
It seems to be breaking Charles jclouds scripts.
Did you fix it in master after 4.0 release ? It could be that jclouds worked around this and that by fixing it, we actually broke the jclouds client.
-sebastien
>
> This information can be used by platforms that run on top of
> CloudStack and clients/scripts to implement logic to handle response
> based on version info.
>
> We can discuss and remove this field if we don't want it.
>
> Regards.
>
>>
>> Regards,
>>
>> --
>> Charles Moulliard
>> Apache Committer / Sr. Enterprise Architect (RedHat)
>> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
Re: Question concerning json response of deployvirtualmachine (4.1)
Posted by Rohit Yadav <ro...@citrix.com>.
On Mon, Jan 28, 2013 at 11:53 AM, Chip Childers
<ch...@sungard.com> wrote:
> Forward from the user list. Rohit - want to answer?
>
>
> ---------- Forwarded message ----------
> From: Charles Moulliard <ch...@gmail.com>
> Date: Mon, Jan 28, 2013 at 2:51 PM
> Subject: Question concerning json response of deployvirtualmachine (4.1)
> To: cloudstack-users@incubator.apache.org
>
>
> Hi,
>
> The json response of deployvirtualmachine - 4.1-SNAPSHOT contains now a
> variable "cloudstack-version".
>
...
> 1.5.3 | << "{ "deployvirtualmachineresponse" :
> {"id":"1cce6cb7-2268-47ff-9696-d9e610f6619a","jobid":"13330fc9-8b3e-4582-aa3e-90883c041ff0"},
> "cloudstack-version": "4.1.0-SNAPSHOT" }"
>
> As I don't see it in the doc here (
> http://incubator.apache.org/cloudstack/docs/api/apidocs-4.0.0/TOC_User.html),
It's because in apidocs we only document the response object fields.
> can somebody confirms that this is new feature not yet published in the doc?
If it's not there, it's a bug as xml response contains cloudstack
version number. Can you open an issue?
> Can we disable it to be compatible with CloudStack 3.0 API ?
The version field was inconsistent in xml/json response, xml response
contains the cloudstack version info but json did not and hoping that
I remember it correctly, in the past versions cloudstack api response
used to have version info in both so I fixed the issues to return
version information in both xml and json response. While adding a new
field in json response should not break any scripts
This information can be used by platforms that run on top of
CloudStack and clients/scripts to implement logic to handle response
based on version info.
We can discuss and remove this field if we don't want it.
Regards.
>
> Regards,
>
> --
> Charles Moulliard
> Apache Committer / Sr. Enterprise Architect (RedHat)
> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
Re: Question concerning json response of deployvirtualmachine (4.1)
Posted by Rohit Yadav <ro...@citrix.com>.
On Mon, Jan 28, 2013 at 11:53 AM, Chip Childers
<ch...@sungard.com> wrote:
> Forward from the user list. Rohit - want to answer?
>
>
> ---------- Forwarded message ----------
> From: Charles Moulliard <ch...@gmail.com>
> Date: Mon, Jan 28, 2013 at 2:51 PM
> Subject: Question concerning json response of deployvirtualmachine (4.1)
> To: cloudstack-users@incubator.apache.org
>
>
> Hi,
>
> The json response of deployvirtualmachine - 4.1-SNAPSHOT contains now a
> variable "cloudstack-version".
>
...
> 1.5.3 | << "{ "deployvirtualmachineresponse" :
> {"id":"1cce6cb7-2268-47ff-9696-d9e610f6619a","jobid":"13330fc9-8b3e-4582-aa3e-90883c041ff0"},
> "cloudstack-version": "4.1.0-SNAPSHOT" }"
>
> As I don't see it in the doc here (
> http://incubator.apache.org/cloudstack/docs/api/apidocs-4.0.0/TOC_User.html),
It's because in apidocs we only document the response object fields.
> can somebody confirms that this is new feature not yet published in the doc?
If it's not there, it's a bug as xml response contains cloudstack
version number. Can you open an issue?
> Can we disable it to be compatible with CloudStack 3.0 API ?
The version field was inconsistent in xml/json response, xml response
contains the cloudstack version info but json did not and hoping that
I remember it correctly, in the past versions cloudstack api response
used to have version info in both so I fixed the issues to return
version information in both xml and json response. While adding a new
field in json response should not break any scripts
This information can be used by platforms that run on top of
CloudStack and clients/scripts to implement logic to handle response
based on version info.
We can discuss and remove this field if we don't want it.
Regards.
>
> Regards,
>
> --
> Charles Moulliard
> Apache Committer / Sr. Enterprise Architect (RedHat)
> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
Fwd: Question concerning json response of deployvirtualmachine (4.1)
Posted by Chip Childers <ch...@sungard.com>.
Forward from the user list. Rohit - want to answer?
---------- Forwarded message ----------
From: Charles Moulliard <ch...@gmail.com>
Date: Mon, Jan 28, 2013 at 2:51 PM
Subject: Question concerning json response of deployvirtualmachine (4.1)
To: cloudstack-users@incubator.apache.org
Hi,
The json response of deployvirtualmachine - 4.1-SNAPSHOT contains now a
variable "cloudstack-version".
2013-01-28 20:31:42,796 | DEBUG | user thread 0 | AsyncRestClientProxy
| clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
1.5.3 | Invoking VirtualMachineAsyncClient.deployVirtualMachineInZone
2013-01-28 20:31:42,798 | DEBUG | i/o thread 0 |
avaUrlHttpCommandExecutorService | clouds.logging.log4j.Log4JLogger 60 |
115 - jclouds-log4j - 1.5.3 | Sending request -546853376: GET
http://localhost:8080/client/api?response=json&command=deployVirtualMachine&zoneid=320d876d-741c-4e71-9a1c-5a9e7838dd50&templateid=5c0b75a8-6927-11e2-a8a4-5c260a0287e9&serviceofferingid=ee9d812e-dd25-4e8f-83ed-1d0d22f39b5b&displayname=fabric-30a&name=fabric-30a&apiKey=EqYwkeuZnxxdkx-HnFOkCN5KkfCWyypfX5KVcX37116twCOXBau0QUWYB4pjHd8RyHn7kDP_rZnwGkpQWD4Qxg&signature=PF18u%2BqF%2FgOZyPN%2FpfR2VPyOlwY%3DHTTP/1.1
2013-01-28 20:31:42,799 | DEBUG | i/o thread 0 | headers
| clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
1.5.3 | >> GET
http://localhost:8080/client/api?response=json&command=deployVirtualMachine&zoneid=320d876d-741c-4e71-9a1c-5a9e7838dd50&templateid=5c0b75a8-6927-11e2-a8a4-5c260a0287e9&serviceofferingid=ee9d812e-dd25-4e8f-83ed-1d0d22f39b5b&displayname=fabric-30a&name=fabric-30a&apiKey=EqYwkeuZnxxdkx-HnFOkCN5KkfCWyypfX5KVcX37116twCOXBau0QUWYB4pjHd8RyHn7kDP_rZnwGkpQWD4Qxg&signature=PF18u%2BqF%2FgOZyPN%2FpfR2VPyOlwY%3DHTTP/1.1
2013-01-28 20:31:42,799 | DEBUG | i/o thread 0 | headers
| clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
1.5.3 | >> Accept: application/json
2013-01-28 20:31:43,187 | DEBUG | i/o thread 0 |
avaUrlHttpCommandExecutorService | clouds.logging.log4j.Log4JLogger 60 |
115 - jclouds-log4j - 1.5.3 | Receiving response -546853376: HTTP/1.1 200 OK
2013-01-28 20:31:43,187 | DEBUG | i/o thread 0 | headers
| clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
1.5.3 | << HTTP/1.1 200 OK
2013-01-28 20:31:43,188 | DEBUG | i/o thread 0 | headers
| clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
1.5.3 | << Server: Jetty(6.1.26)
2013-01-28 20:31:43,188 | DEBUG | i/o thread 0 | headers
| clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
1.5.3 | << Content-Type: text/javascript; charset=UTF-8
2013-01-28 20:31:43,189 | DEBUG | i/o thread 0 | headers
| clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
1.5.3 | << Content-Length: 169
2013-01-28 20:31:43,189 | DEBUG | i/o thread 0 | wire
| clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
1.5.3 | << "{ "deployvirtualmachineresponse" :
{"id":"1cce6cb7-2268-47ff-9696-d9e610f6619a","jobid":"13330fc9-8b3e-4582-aa3e-90883c041ff0"},
"cloudstack-version": "4.1.0-SNAPSHOT" }"
As I don't see it in the doc here (
http://incubator.apache.org/cloudstack/docs/api/apidocs-4.0.0/TOC_User.html),
can somebody confirms that this is new feature not yet published in the doc
? Can we disable it to be compatible with CloudStack 3.0 API ?
Regards,
--
Charles Moulliard
Apache Committer / Sr. Enterprise Architect (RedHat)
Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
Re: Question concerning json response of deployvirtualmachine (4.1)
Posted by Chip Childers <ch...@sungard.com>.
I'm going to forward this to the dev list.
On Mon, Jan 28, 2013 at 2:51 PM, Charles Moulliard <ch...@gmail.com> wrote:
> Hi,
>
> The json response of deployvirtualmachine - 4.1-SNAPSHOT contains now a
> variable "cloudstack-version".
>
> 2013-01-28 20:31:42,796 | DEBUG | user thread 0 | AsyncRestClientProxy
> | clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
> 1.5.3 | Invoking VirtualMachineAsyncClient.deployVirtualMachineInZone
> 2013-01-28 20:31:42,798 | DEBUG | i/o thread 0 |
> avaUrlHttpCommandExecutorService | clouds.logging.log4j.Log4JLogger 60 |
> 115 - jclouds-log4j - 1.5.3 | Sending request -546853376: GET
> http://localhost:8080/client/api?response=json&command=deployVirtualMachine&zoneid=320d876d-741c-4e71-9a1c-5a9e7838dd50&templateid=5c0b75a8-6927-11e2-a8a4-5c260a0287e9&serviceofferingid=ee9d812e-dd25-4e8f-83ed-1d0d22f39b5b&displayname=fabric-30a&name=fabric-30a&apiKey=EqYwkeuZnxxdkx-HnFOkCN5KkfCWyypfX5KVcX37116twCOXBau0QUWYB4pjHd8RyHn7kDP_rZnwGkpQWD4Qxg&signature=PF18u%2BqF%2FgOZyPN%2FpfR2VPyOlwY%3DHTTP/1.1
> 2013-01-28 20:31:42,799 | DEBUG | i/o thread 0 | headers
> | clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
> 1.5.3 | >> GET
> http://localhost:8080/client/api?response=json&command=deployVirtualMachine&zoneid=320d876d-741c-4e71-9a1c-5a9e7838dd50&templateid=5c0b75a8-6927-11e2-a8a4-5c260a0287e9&serviceofferingid=ee9d812e-dd25-4e8f-83ed-1d0d22f39b5b&displayname=fabric-30a&name=fabric-30a&apiKey=EqYwkeuZnxxdkx-HnFOkCN5KkfCWyypfX5KVcX37116twCOXBau0QUWYB4pjHd8RyHn7kDP_rZnwGkpQWD4Qxg&signature=PF18u%2BqF%2FgOZyPN%2FpfR2VPyOlwY%3DHTTP/1.1
> 2013-01-28 20:31:42,799 | DEBUG | i/o thread 0 | headers
> | clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
> 1.5.3 | >> Accept: application/json
> 2013-01-28 20:31:43,187 | DEBUG | i/o thread 0 |
> avaUrlHttpCommandExecutorService | clouds.logging.log4j.Log4JLogger 60 |
> 115 - jclouds-log4j - 1.5.3 | Receiving response -546853376: HTTP/1.1 200 OK
> 2013-01-28 20:31:43,187 | DEBUG | i/o thread 0 | headers
> | clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
> 1.5.3 | << HTTP/1.1 200 OK
> 2013-01-28 20:31:43,188 | DEBUG | i/o thread 0 | headers
> | clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
> 1.5.3 | << Server: Jetty(6.1.26)
> 2013-01-28 20:31:43,188 | DEBUG | i/o thread 0 | headers
> | clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
> 1.5.3 | << Content-Type: text/javascript; charset=UTF-8
> 2013-01-28 20:31:43,189 | DEBUG | i/o thread 0 | headers
> | clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
> 1.5.3 | << Content-Length: 169
> 2013-01-28 20:31:43,189 | DEBUG | i/o thread 0 | wire
> | clouds.logging.log4j.Log4JLogger 60 | 115 - jclouds-log4j -
> 1.5.3 | << "{ "deployvirtualmachineresponse" :
> {"id":"1cce6cb7-2268-47ff-9696-d9e610f6619a","jobid":"13330fc9-8b3e-4582-aa3e-90883c041ff0"},
> "cloudstack-version": "4.1.0-SNAPSHOT" }"
>
> As I don't see it in the doc here (
> http://incubator.apache.org/cloudstack/docs/api/apidocs-4.0.0/TOC_User.html),
> can somebody confirms that this is new feature not yet published in the doc
> ? Can we disable it to be compatible with CloudStack 3.0 API ?
>
> Regards,
>
> --
> Charles Moulliard
> Apache Committer / Sr. Enterprise Architect (RedHat)
> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com