Porter Mixin requires environment variables to be set with TenantId/SubscriptionId/ClientId/Secret

[simongdavies]

These should not need to be provided in some environments (e.g. CloudShell\ACI), should be able to support configuration from CloudShell environment , MSI etc.

[squillace]

Just bounced into this. No, no no to mixins requiring extra involvement to work, especially undocumented ones. Have this reference credentials passed to the bundle. I could see it working directly with the Azure plugin in some way, but it has to work standing alone. :-|

[squillace]

https://github.com/deislabs/porter-arm/blob/d9c7288912caa1b5efa30138138027c15ad65c0f/pkg/arm/config.go#L12

This enforces specific strings inside your bundle.

[carolynvs]

Unassigning as assignments indicate what Vaughn and I are currently working on. Sometimes that's aspirational but 😀

This mixin needs some design effort instead of one off issues. I've written up some context below but it would be good to re-establish the purpose of this mixin, decide if it is still needed, how it fits in with the az mixin and how users will interact with it in various contexts.

Perhaps this exposes a desired feature where mixins can inject credential definitions in a bundle but with the uncertainty of the bundle, I do not want to spend time on that until we have a solid plan for the mixin first.

Context: It was one of the original mixins, written with custom support for various Azure services, then we realized that would not scale at all (see OSBA). I wrote the az mixin instead and we have been directing people there. Work has been done to remove the custom services so that it instead is good for applying arm templates. As seen by this issue, there are still assumptions that don't work well with Porter's architecture.

[squillace]

that's a good response. I can see in fact that it's possible that some things should be integrated with the Azure plugin rather than inside mixins per se, too. This mixin was also because the az mixin was just too damned big. Maybe a fix would be to figure out what can be ripped out of azure cli to be useful? I can work on that...

[carolynvs]

Oh you mean the azure cli is too damn big. 😀 I wish they would just spend a year and rewrite it in Go just to make me happy. Obviously that makes perfect business sense.

This is why for little stuff I wrote this: https://github.com/carolynvs/az-cli

[squillace]

it's not the python that's big: it's that they don't strip out the test code -- they just ship the entire thing. but 2/3 of the code is test code. :-|