Uh oh!
There was an error while loading. Please reload this page.
CLOUDSTACK-9507: ListVM response's guest_os id should be a UUID - #1686
CLOUDSTACK-9507: ListVM response's guest_os id should be a UUID#1686yadvr wants to merge 1 commit into
Conversation
The listVirtualMachines API response contains a guest os_type_id field which is an integer, and therefore not useful or easily consumable. This fixes and migrates the returned type from an id (integer) to a uuid (string). It makes the response consistent with other API responses such as those of listTemplates and allow end users to consume this uuid. Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
blueorangutan
commented
Sep 23, 2016
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
blueorangutan
commented
Sep 23, 2016
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-22 |
serg38
commented
Sep 23, 2016
@rhtyd Somehow it works fine without this patch |
serg38
commented
Sep 23, 2016
@rhtyd I think you meant guest_os_type not guest_os_id. In this case the issue is not only that it returns ID instead of UUID but also that it doesn't return ID of os type. In the sample output ostypeid":12 is not correct OS type which is supposed to be 1 ( CentOs). The right response seems to be |
yadvr
commented
Sep 27, 2016
@serg38 I mean the os_type_id, which was previously returned as an integer but should be returned as a uuid. The uuid would be consumeable by the listGuestOsMapping API. |
serg38
commented
Sep 27, 2016
@rhytd Current implementation has a bug as well that returns GuestOsId in place of GuestOsTypeId. I am for not only switching to UUID but also for fixing it and returning correct output. |
jburwell
commented
Sep 27, 2016
@rhtyd @serg38 while I agree that this change makes logical sense, it breaks the API compatibility which we guarantee for major releases. 5.0.0 is scheduled to open on 5 December 2016. I suggest that we hold this PR until that time when we will be accepting changes that break API backwards compatibility. |
yadvr
commented
Oct 21, 2016
Instead of changing the response type, another way is additive -- to introduce a new key (guestosuuid) in the response that returns the uuid for the expected key. |
serg38
commented
Oct 21, 2016
@rhtyd This clearly a bug. os_type_id was always supposed to be a OS type as per: @SerializedName(ApiConstants.OS_TYPE_ID) Currently it returns an OS Id. Guest OS UUID is already part of response as guestosid . Basically there are 3 options:
|
yadvr
commented
Nov 20, 2016
@blueorangutan package |
blueorangutan
commented
Nov 20, 2016
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
blueorangutan
commented
Nov 20, 2016
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-199 |
serg38
commented
Nov 23, 2016
I am -1 in the current form |
yadvr
commented
Nov 24, 2016
This PR will be on hold until next set of 4.8.x, 4.9.x, 4.10.x releases. |
cloudmonger
commented
Mar 8, 2017
ACS CI BVT RunSumarry: Link to logs Folder (search by build_no):https://www.dropbox.com/sh/yj3wnzbceo9uef2/AAB6u-Iap-xztdm6jHX9SjPja?dl=0 Failed tests:
Skipped tests: Passed test suits: |
yadvr
commented
Jul 23, 2017
Break api response, closing for now |
blueorangutan
commented
Jul 23, 2017
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
blueorangutan
commented
Jul 23, 2017
Packaging result: ✖centos6 ✖centos7 ✖debian. JID-830 |
…to '4.18.0.0-scclouds' Permitir que contas com o _plugin_ Quota desabilitado continuem acessando as APIs do Quota Closesapache#1686 See merge request scclouds/scclouds!710
The listVirtualMachines API response contains a guest os_type field which
is an integer, and therefore not useful or easily consumable. This fixes and
migrates the returned type from an id (integer) to a uuid (string). It makes
the response consistent with other API responses such as those of listTemplates
and allow end users to consume this uuid.
/cc @jburwell@karuturi -- this is a minor change. It may be debatable if this break api response compatibility, please advise.
@blueorangutan package