New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CLOUDSTACK-9507: ListVM response's guest_os id should be a UUID #1686
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>
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-22 |
@rhtyd Somehow it works fine without this patch |
@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 |
@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. |
@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. |
@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. |
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. |
@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:
|
@blueorangutan package |
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-199 |
I am -1 in the current form |
This PR will be on hold until next set of 4.8.x, 4.9.x, 4.10.x releases. |
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: |
Break api response, closing for now |
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
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 Closes apache#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