earthscope: Rename the resource request labels #6351
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
Adding clearer descriptions to resource allocation choices, and removing smallest server option for now.
|
Merging this PR will trigger the following deployment actions. Support deploymentsNo support upgrades will be triggered Staging deployments
Production deployments
|
changed : to -
yuvipanda
changed the title
|
Thanks @sarahwilson523! We like to keep the labels consistent, as we may have to make adjustments constantly (one is coming up in #6313 for example). I'm happy to merge this, but would like to revert it post the workshop. Does that seem acceptable? |
|
Hi Yuvi,
Having custom labels is not critical or urgent on our end. We also don't
want to have to update our documentation with new descriptions and then
revert back. So we can leave as is for now.
However, I will share our reasoning why we requested this change:
- It is hard for students/general users to find/remember the correct
option to pick when they are seeing a fractional number, especially when
many of the options look similar (same CPU description). We liked having
conceptually-named terminology like 'small/medium/large' to help users
conceptualize what was appropriate for their work, then we modified this to
a light-to-heavy scale which doesn't quite have the same connotation that
"bigger is better."
- Having multiple options with the same 'Up to 3.7 CPU' descriptor does
not characterize the CPU differences between these servers. It does not
give users any intuition why their script might run flawlessly one day, and
crash out of resources the next (which we encountered while testing
notebooks for next week's course). The performance variability can be
frustrating If users don't have any idea that they're using dynamically
scaling or shared resources, or understand what minimum they might get
throttled to.
- We thought the idea of fractional CPU/RAM is a little hard to
conceptualize; we'd prefer to use whole numbers so users have an easier
time understanding/remembering what they're getting (and our documentation
can point them to the common.values file if they really need the details)
Again, totally understand that this change doesn't align with your update
rollout model... but maybe there's a balance you could find in creating
labels that are a little more comprehensible for a broad spectrum of users?
Thanks,
Sarah
…On Mon, Jul 14, 2025 at 3:28 PM Yuvi ***@***.***> wrote:
*yuvipanda* left a comment (2i2c-org/infrastructure#6351)
<#6351 (comment)>
Thanks @sarahwilson523 <https://github.com/sarahwilson523>! We like to
keep the labels consistent, as we may have to make adjustments constantly
(one is coming up in #6313
<#6313> for example). I'm
happy to merge this, but would like to revert it post the workshop. Does
that seem acceptable?
—
Reply to this email directly, view it on GitHub
<#6351 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BINBKV64TX4O6K3C3N3EU4D3IQOHJAVCNFSM6AAAAACBKVHWPSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZRGA2DEMZQGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
yuvipanda
added a commit
to yuvipanda/pilot-hubs
that referenced
this pull request
Jul 15, 2025
Based on 2i2c-org#6351 (comment) 1. Much more limited use of fractions - only for CPUs under 2. No fractions over that, everything is rounded to nearest whole number 2. The display name indicates how much CPU is guaranteed 3. The description indicates CPU limits with appropriate wording 4. Allow specifying multiple node types in one go, makes copy pasting easier. 5. No longer specify 'default: true', as first one is default now
yuvipanda
added a commit
to yuvipanda/pilot-hubs
that referenced
this pull request
Jul 15, 2025
Based on conversation in 2i2c-org#6351 Regenerated based on 2i2c-org#6313
|
@sarahwilson523 that is extremely valuble feedback! I'm incorporating that into the overall work we're doing in improving these resource options. I've incorporated your points 2 and 3 into the script (#6313), and the options now look like this: 
The changes are:
I do agree with you on point 1, where descriptive words are better than just the numbers. We had considered using t shirt sizes (XS, S, M, L, XL, XXL, etc) but that implied the 'bigger is better' problem. I love the idea of using suggested names per-workload (light, moderate, etc) - but that can't be systematized as much, as what's 'standard' is going to change community to community. I think a pathway to explore is to either allow a community to pick 'standard' and we autogenerate names for instances smaller and bigger than that, or simply allow them to fully customize the labels. I'll spend a little more time thinking about it. I've deployed these changes (#6366) to the staging geolab (https://staging.geolab.earthscope.cloud/hub/oauth_login). Can you test it out and let me know what you think? In particular, do you think it's worth deploying this to earthscope as is, or should we wait until we have descriptive labels? Thank you very much for your high quality feedback @sarahwilson523, it helps us make changes not just for geolab but for all our communities! It's well appreciated. |
|
Thanks Yuvi.
The change to staging is great progress and clarifies the choices quite a
bit! We'd still love to see a conceptual label, but we also struggled to
choose the right verbiage. There's room for more brainstorming here.
Can you please roll this out to our hub some time *after 7/28? *We have
already sent out login instructions for students in next week's course to
do the pre-course homework, and we don't want things to change for them.
Thanks again for hearing our feedback!
Sarah
…On Tue, Jul 15, 2025 at 2:11 PM Yuvi ***@***.***> wrote:
*yuvipanda* left a comment (2i2c-org/infrastructure#6351)
<#6351 (comment)>
@sarahwilson523 <https://github.com/sarahwilson523> that is extremely
valuble feedback! I'm incorporating that into the overall work we're doing
in improving these resource options.
I've incorporated your points 2 and 3 into the script (#6313
<#6313>), and the options
now look like this:
image.png (view on web)
<https://github.com/user-attachments/assets/2d0c57e9-da6e-49ca-839b-b6321c252765> image.png
(view on web)
<https://github.com/user-attachments/assets/a8552b68-6512-41f4-a6f6-79783abfda6c>
The changes are:
1. Much more limited use of fractions - only for CPUs under 2. No
fractions over that, everything is rounded to nearest whole number
2. The display name indicates how much CPU is guaranteed
3. The description indicates CPU limits with appropriate wording
I do agree with you on point 1, where descriptive words are better than
just the numbers. We had considered using t shirt sizes (XS, S, M, L, XL,
XXL, etc) but that implied the 'bigger is better' problem. I love the idea
of using suggested names per-workload (light, moderate, etc) - but that
can't be systematized as much, as what's 'standard' is going to change
community to community. I *think* a pathway to explore is to either allow
a community to pick 'standard' and we autogenerate names for instances
smaller and bigger than that, or simply allow them to fully customize the
labels. I'll spend a little more time thinking about it.
I've deployed these changes (#6366
<#6366>) to the staging
geolab (https://staging.geolab.earthscope.cloud/hub/oauth_login). Can you
test it out and let me know what you think? In particular, do you think
it's worth deploying this to earthscope as is, or should we wait until we
have descriptive labels?
Thank you very much for your high quality feedback @sarahwilson523
<https://github.com/sarahwilson523>, it helps us make changes not just
for geolab but for all our communities! It's well appreciated.
—
Reply to this email directly, view it on GitHub
<#6351 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BINBKV6TYXJRH3G5WZAGX6T3IVN7TAVCNFSM6AAAAACBKVHWPSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZVGM3TQOJSGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@sarahwilson523 thank you! I have updated the other PR with the date so we can merge that after the course. I'll let you know when we do. For the labels, what do you think of us using T shirt sizes to start with? It would go XXS, XS, M, L, XL, XXL and so on. We may try to make them consistent (so an M in one community always matches an M in another community), and they are pretty extendible by just adding more X in front of them. Do you think this would be an incremental improvement over what we have now in staging, or a potential step backwards? |
jnywong
pushed a commit
to jnywong/infrastructure
that referenced
this pull request
Aug 7, 2025
Based on 2i2c-org#6351 (comment) 1. Much more limited use of fractions - only for CPUs under 2. No fractions over that, everything is rounded to nearest whole number 2. The display name indicates how much CPU is guaranteed 3. The description indicates CPU limits with appropriate wording 4. Allow specifying multiple node types in one go, makes copy pasting easier. 5. No longer specify 'default: true', as first one is default now
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Adding clearer display names for resource allocation choices, and removing smallest server option for now.