nebari-dev
enh: allow multiple instance types for aws
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)
- [X] 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
- [x] Did you test the pull request locally?
- [ ] Did you add new tests?
How to test this PR?
Any other comments?
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.
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.
FYI @satra - with @asmacdo we rebased and squashed into a single commit with extra info to help us "manage" the patch queue
