Skip to content

Conversation

satra
Copy link
Contributor

@satra satra commented Jun 13, 2025

Reference Issues or PRs

On AWS instance_types can take a list and at present it is limited to one instance type. This PR allows for multiple instance_types.

What does this implement/fix?

Put a x in the boxes that apply

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds a feature)
  • Breaking change (fix or feature that would cause existing features not to work as expected)
  • Documentation Update
  • Code style update (formatting, renaming)
  • Refactoring (no functional changes, no API changes)
  • Build related changes
  • Other (please describe):

Documentation

  • For new features or enhancements, a corresponding PR has been opened in the documentation repository (if applicable)
    • Link to docs PR:

Testing

  • Did you test the pull request locally?
  • Did you add new tests?

How to test this PR?

Any other comments?

@satra satra marked this pull request as ready for review June 14, 2025 02:33
@satra satra requested a review from a team as a code owner June 14, 2025 02:33
@satra satra requested review from dcmcand and marcelovilla and removed request for a team June 14, 2025 02:33
@marcelovilla
Copy link
Member

Hey @satra, thanks for your contribution!

Would you be able to elaborate on your use case a bit more, particularly how others might benefit from this feature? I can see the value for spot node groups, but it's less clear how broadly applicable it is beyond that.

We’ll also need to consider whether to keep the current schema as-is—allowing users to pass a comma-separated string of instance types—or move toward a more structured approach, like a list of strings. Additionally, we should think about how this aligns with feature parity across other cloud providers.

@satra
Copy link
Contributor Author

satra commented Jun 17, 2025

availability of resources can vary across AWS instance types. thus having the ability to choose across instance types when scaling up can be helpful. this is a bit more useful in the context of spot where instances can be limited, but i believe applies to non-spot use cases as well.

regarding generalizability or structuring the input, i did the current PR to both support my needs, maintain backwards compatibility, and my general ignorance of the capability across providers. can alter the PR based on generalizability.

This was squashed with the commit for

    fix: change check for multiple instance types

and while rebasing we had a conflict for
	src/_nebari/stages/infrastructure/template/aws/modules/kubernetes/main.tf

Annotation for our "manual patch queue":

PR: nebari-dev#3070
@yarikoptic
Copy link
Contributor

FYI @satra - with @asmacdo we rebased and squashed into a single commit with extra info to help us "manage" the patch queue

yarikoptic pushed a commit to asmacdo/nebari that referenced this pull request Oct 2, 2025
This was squashed with the commit for

    fix: change check for multiple instance types

and while rebasing we had a conflict for
	src/_nebari/stages/infrastructure/template/aws/modules/kubernetes/main.tf

Annotation for our "manual patch queue":

PR: nebari-dev#3070
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: New 🚦

Development

Successfully merging this pull request may close these issues.

3 participants