This repository was archived by the owner on Nov 1, 2023. It is now read-only.
Expand valid scaleset names #3045
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov Report
@@ Coverage Diff @@
## main #3045 +/- ##
==========================================
+ Coverage 31.42% 31.50% +0.07%
==========================================
Files 306 306
Lines 36622 36638 +16
==========================================
+ Hits 11508 11542 +34
+ Misses 25114 25096 -18
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Member
Author
|
Passed check-pr. |
chkeita
approved these changes
Apr 25, 2023
tevoinea
approved these changes
May 10, 2023
Porges
added a commit
that referenced
this pull request
May 21, 2023
Scaleset names are now permitted to be any (valid) strings, instead of only GUIDs. When we generate a scaleset name it is now based upon the pool name; for example the pool `pool` might get a scaleset named `pool-3b24ba211cad4b078655914754485838`. This should be backwards-compatible since GUIDs are [already serialized to table storage as strings](https://github.com/microsoft/onefuzz/blob/dddcfa49490e44834afc9a6910c350698022792c/src/ApiService/ApiService/onefuzzlib/orm/EntityConverter.cs#L190-L191), so this simply loosens the restrictions placed upon them. Scaleset IDs now have a strong type in the same way as other IDs; this helps to avoid mixing them up with other strings. Because of this I found one bug in the scaleset search query logic due to Pool ID/VMSS ID confusion. As part of fixing this I've changed the scaleset search query to only return nodes from the table rather than querying Azure to find a list; this seems to be sufficient for the CLI.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #2189.
Scaleset names are now permitted to be any (valid) strings, instead of only GUIDs. When we generate a scaleset name it is now based upon the pool name; for example the pool
poolmight get a scaleset namedpool-3b24ba211cad4b078655914754485838.This should be backwards-compatible since GUIDs are already serialized to table storage as strings, so this simply loosens the restrictions placed upon them.
Scaleset IDs now have a strong type in the same way as other IDs; this helps to avoid mixing them up with other strings. Because of this I found one bug in the scaleset search query logic due to Pool ID/VMSS ID confusion. As part of fixing this I've changed the scaleset search query to only return nodes from the table rather than querying Azure to find a list; this seems to be sufficient for the CLI.