-
Notifications
You must be signed in to change notification settings - Fork 22
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
feat(HMS-2255): launch to location of the resource group by default #730
Conversation
5082f94
to
e7342e6
Compare
/retest |
Failed: Maybe we need to update a test - images are now being launched in the location of the resource group rather than some hardcoded default, @akhil-jha |
e7342e6
to
dae1c21
Compare
Probably true. |
/retest lets try once more for good luck 🤷 |
Not your day: Failed: |
Ah, with so many failures in the pipeline, I've just not stopped to think that it might be a regression 🤦
|
dae1c21
to
6231399
Compare
@@ -147,9 +149,10 @@ func CreateAzureReservation(w http.ResponseWriter, r *http.Request) { | |||
EdgeID: logging.EdgeRequestId(r.Context()), | |||
AccountID: identity.AccountId(r.Context()), | |||
Args: jobs.LaunchInstanceAzureTaskArgs{ | |||
// Ignore location for now | |||
//Location: reservation.Detail.Location, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have ignored location previously and always substituted it for eastus
, now we're just explicit about it.
6231399
to
128afe2
Compare
if preload.AzureInstanceType.ValidateRegion(payload.Location) { | ||
logger.Warn().Msgf("Azure region passed with location suffix (%s), this is deprecated behaviour format", payload.Location) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the past, we've validated for location, but then actually ignored the param down the line and forced eastus, but we actually need regions, not locations in all the calls (even tho azure calls them Location 🤦)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this need to be part of this PR? Also I am not sure if I am following here. Can you explain?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, we required region+zone in the past, but then we dropped the value and used hard coded eastus
, so it worked, but our client expects only region (without the zone suffix).
So this patch accepts both, but when user passes the version with suffix, we now warn about it, so we can keep track of how many usages of that there is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok this is fine, if you want to go an extra mile I think you can refactor ValidateRegion
to accept variadic string and concatenate by _
because this is exactly how it works for all the clouds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's actually dash (-
) for EC2 and GCP and underscore _
for Azure 😮💨 xD
128afe2
to
83a74e3
Compare
iqe_provisioning_api.exceptions.ApiAttributeError: V1AWSReservationResponseDetail has no attribute 'public_ipv4' at ['['received_data', 'instances', 0, 'detail']']['public_ipv4'] Not related (out of quota). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure about the terminology. We have the "location" term and then there are "region" and "zone". To me, it looks like "location" is simply "region" and "zone" concatenated into one string, maybe we could adopt this in the codebase.
We need to figure out a good approach, the current proposal simply ditches the location completely, however, it is possible to technically have a VM in a different zone than resource group. Sure, it is not recommended, but it is possible. I would suggest that we keep this possibility at least in the API.
There are some changes I do not understand.
} | ||
return fmt.Sprintf("/resourceGroups/%s/providers/Microsoft.Compute/images/%s", azureUploadRequest.ResourceGroup, uploadOptions.ImageName), nil | ||
return azureUploadRequest.ResourceGroup, uploadOptions.ImageName, nil | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Multiple return values (except error) typically mean we should think about introducing a type. But this is still okay I believe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I was just lazy here, let me know if you insist, I agree struct would work better here 🤔
type AzureResourceGroup struct { | ||
ID string | ||
Name string | ||
Location string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You removed bunch of locations to region, shall we remove this one as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went back on the decision, lets keep Location, but explain it's region, not region with availability zone, as it souns like it the first look. I've added more description in the OpenAPI spec.
if preload.AzureInstanceType.ValidateRegion(payload.Location) { | ||
logger.Warn().Msgf("Azure region passed with location suffix (%s), this is deprecated behaviour format", payload.Location) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this need to be part of this PR? Also I am not sure if I am following here. Can you explain?
e843775
to
f1a09be
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All right, needs rebase tho.
e5d2cce
to
1a34c67
Compare
We should allow users to follow Azure default and use the resource group location by default.
1a34c67
to
008fded
Compare
Rebased and all 🍏 |
Okay, thanks a bunch for working on this. |
We should allow users to follow Azure default and use the resource group location by default.
This PR also makes the default Resource Group the image resource group.