search

getporter / helm2-mixin

Helm mixin for Porter
https://porter.sh/mixins/helm
Apache License 2.0
13 stars 7 forks source link

feat(*): implement upgrade #13

Closed vdice closed 5 years ago

vdice commented 5 years ago

This represents the naive/mostly-copy-paste implementation.

As you'll note, upgrade.go looks nearly identical to the pre-existing install.go, just with a slightly different cmd base. We could extract shared logic into a new file that both could use (upsert.go?) which has a cmd base of helm upgrade, with, conditionally, --install, depending on caller (install.go vs upgrade.go). Should we go this route here? And/or a diff approach?

vdice commented 5 years ago

I believe https://github.com/deislabs/porter/issues/123 is needed before use via porter

carolynvs commented 5 years ago

Good question on the helm install vs helm upgrade --install. Couple things come to mind:

  1. Most people use helm upgrade --install because it's easier to use in a script where you don't know the state and are just hammering a system and don't care if it was already there or not. It's just easier to script.
  2. duffle doesn't have a convenience like that. When people script installing/upgrading bundles, they are going to have to pick duffle install or duffle upgrade and know which is the right to call. Right? (Though when porter has an install command, we could do something different).
  3. When people go through the logs for the mixin, what would be easier to debug? Seeing helm install for an install action or helm upgrade --install? Do you think it would matter?

Basically if it doens't affect the UX, let's go with whatever makes sense to you on the implementation.