Skip to content
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

Proposal: Instance Storage config per Bundle #763

Closed
vdice opened this issue Oct 21, 2019 · 2 comments
Closed

Proposal: Instance Storage config per Bundle #763

vdice opened this issue Oct 21, 2019 · 2 comments
Labels
nope This will not be worked on, #SorryNotSorry

Comments

@vdice
Copy link
Member

vdice commented Oct 21, 2019

A framework for remote claim storage was added in #699 (:tada:!)

Currently, configuration of instance storage is done Porter-wide via Porter's Configuration file.

However, I'm wondering if it would be useful to offer the ability to set (or override) this particular instance storage config per bundle.

Say, if I use the same porter client to manage bundles using the local/default filesystem instance storage plugin but then wish to use the same client to manage bundles using remote instance storage plugins (perhaps via https://github.com/deislabs/porter-azure-plugins). In such a scenario, it would be preferred not to have to toggle the Porter-wide setting when switching contexts. Perhaps a bundle-specific override could take precedence over any Porter-wide setting?

@squillace
Copy link

Hmmmm. let's game the user story. Should a dev have the ability to flip storage per anything? Yes. Should a tool, or a team player? Hmmmmmmmmmmmmmmm. Why would a bundle be involved at all? It's the mode of the user, not the bundle-scoping, that must change periodically.

Of course, this leaves an easy UX problem: I "forgot" I was in Azure cloud mode, now I upgraded a claim but the claim is in the cloud and I was supposed to be doing that in AWS S3 mode. So..... uh.... how do we do this and prevent easy "forgotten context" problems?

@carolynvs
Copy link
Member

Closing now that we have a more mature storage system.

@carolynvs carolynvs added the nope This will not be worked on, #SorryNotSorry label Mar 11, 2022
@carolynvs carolynvs moved this from Inbox to Done in Porter and Mixins Apr 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
nope This will not be worked on, #SorryNotSorry
Projects
Development

No branches or pull requests

3 participants