Add a `LEAPP_SESSION_NAME` environment variable

[Gowiem]

Is your feature request related to a problem? Please describe. In my current setup, I utilize the AWS_PROFILE environment variable to help me know what my current AWS profile session is. See below screenshot. Unfortunately, with the way Leapp works I don't have something to piggy back off of as a means to pick up the name of the current session since everything surrounds the default profile and credentials. As a way to get at that information, it would be great if Leapp could provide an environment variable that would be set across the system to enable folks like me who deal with many sessions a day to know what their current session is without having to look at the Leapp console.

Describe the solution you'd like Add a LEAPP_SESSION_NAME environment variable system wide that corresponds to the currently selected and authenticated session.

Describe alternatives you've considered You could also put this in an info file in ~/.Leapp/ if that would be preferred for whatever reason.

Additional context N/A

[pethron]

Thanks for the suggestion @Gowiem, we were thinking about it, but there are a few issues to address. The main problem is to define a consistent behavior across the whole app, mainly because this works if you activate only one session. Still, we need to take into account even multiple active sessions.

I think we can use this issue to discuss the behavior. Do you have any suggestions?

[Gowiem]

@pethron 👍 glad it is on the table.

Few ideas:

1. Numbered environment variables: LEAPP_SESSION_1_NAME, LEAPP_SESSION_2_NAME, etc.
2. When the user has multiple sessions, then comma separate them: LEAPP_SESSION_NAME=client2,client6,personal
3. Write it out the current actives sessions info as a JSON file and we can use jq to handle it.

[pethron]

I like n. 2 and 3 (and probably can implement both). The number 2 is good to have an easy way to get that info, but on the downsides, you should need to open a new terminal window to get the updated status because of how environment variables work. The number 3, I think, would be extremely easy to implement. Also, take note that we could open an endpoint to get this info (through REST or through the CLI). This would be updated in real-time and shouldn't need to refresh env variables, but I think the tool you're using to display the CLI info should check the state at every command you run. Also, do you expect to see current sessions all the time?

[Gowiem]

@pethron From what you mentioned, option #3 sounds preferable as it sounds like it would unlock the CLI command that would show current sessions. I like that route.

Also, do you expect to see current sessions all the time?

Not sure what you mean by that. I only expect to see the current sessions if I have actively started a session and it's active. If the session has expired due to an MFA or token timeout then I would expect it to get removed from the current sessions. That make sense?