Open alexweininger opened 4 months ago
@peterbom could you describe how the AKS extension would utilize these changes? Would you just be instantiating a
VSCodeAzureSessionProvider
and ignoringVSCodeAzureSubscriptionProvider
? Would you be instantiating both?
@alexweininger - yes, that's what I'm thinking: instantiating a VSCodeAzureSessionProvider
and ignoring VSCodeAzureSubscriptionProvider
A quick summary of my reasoning:
AzureSessionProvider
gets us credentials easily I don't think we'd have a big need for an AzureSubscriptionProvider
.yes, that's what I'm thinking: instantiating a
VSCodeAzureSessionProvider
and ignoringVSCodeAzureSubscriptionProvider
Great, that's what I figured. And I completely agree with your reasoning. I think other extensions like should do the same.
@peterbom When you have a chance, could you add me as a contributor to https://github.com/peterbom/vscode-azuretools/tree/experiment/session-provider? That you don't have to do all the changes yourself.
I originally wanted to try to get this PR in before we officially announce the Azure Account extension deprecation, but now I've decided to wait. Once announced, I'm expecting teams to come to us with specific asks and needs for their migration, and I'd like to make sure we cover those in this refactor.
I've gathered a list of all extensions that depend on Azure Account and I don't think as many will actually need these changes as I thought. Only 2-3 out of about 25. If my research is correct, and that's truly the case, then I'd like to hold off on putting these changes through. The added complexity of the session provider might not be worth it if only the 2-3 partners are depending on it, while 25 others only need a subscription provider.
I originally wanted to try to get this PR in before we officially announce the Azure Account extension deprecation, but now I've decided to wait. Once announced, I'm expecting teams to come to us with specific asks and needs for their migration, and I'd like to make sure we cover those in this refactor.
I've gathered a list of all extensions that depend on Azure Account and I don't think as many will actually need these changes as I thought. Only 2-3 out of about 25. If my research is correct, and that's truly the case, then I'd like to hold off on putting these changes through. The added complexity of the session provider might not be worth it if only the 2-3 partners are depending on it, while 25 others only need a subscription provider.
@alexweininger agreed, good plan. Those needing a session provider should also consider just directly using the account APIs provided by VSCode, these are more session-shaped.
Goals: improve structure of our auth package so it can be more easily consumed by partner extensions that don't necessary follow our tree view structure. This is specifically coming from Peter, who works on the AKS extension and basically wrote all of this code as part of their own migration off of Azure Account.
Putting this PR up so I can give feedback and ask questions easier as we iterate over this code.