Add session persistence for Gemini

[noahlwest]

Adds session persistence for gemini, so users can continue where they left off, or continue their session in a different interface.

• session persistence is not enabled by default. Users will need to use --new-session flag to start a new session and --session flag to resume a session. We can change this later when it's implemented for all models + if users desire this behavior.
• adds session manager for handling session operations, with create/describe/list/delete session operations
• initializes conversation with chat history when resuming a session
• currently implemented for gemini, other providers will display a not implemented error if you try to use session flags with them

To try it out, use kubectl-ai --new-session to start a new session, and kubectl-ai --session <session id> to resume a session. If you don't know your session id, you can use kubectl-ai sessions to list them.

demo showing session persistence from terminal -> terminal -> web: https://github.com/user-attachments/assets/1e73d9bf-b1d9-4165-985c-67dfe7c5a708

demo showing loading different sessions: https://github.com/user-attachments/assets/c8b2d6c7-3833-485a-9bfd-7bb228c203e9

demo showing behavior without session flags (same as today) and trying to use sessions on unsupported providers: https://github.com/user-attachments/assets/5edcf484-f5f1-4125-9de8-8460af14a543

[droot]

This is looking great. A few things we should think more about:

• What is the default behavior when it gets merged. Would it surprise users in anyway. If yes, and the surprise is negative, can they opt-in to this functionality ? if by default, persisting the session is off, can we make it easy for them to discover it.
• I see that we don't yet support for other llm providers, so if we merge this, will it cause any issues for other llms ?
• minor: I do see gollm now depending on kubectl-ai/pkg/api, does it create any issues for people depending on gollm ?

[droot]

I think from UX point of view, if I load an existing session (or if that is the default behavior), the UX should give a hint saying it is using persisted session (or resuming) with something so that user know that it is not a brand new session in case they wanted to have a brand new.

[noahlwest]

What is the default behavior when it gets merged.

After this is merged, default behavior should continue as normal. To use sessions, users will need to opt in with --new-session or -session flags.

I see that we don't yet support for other llm providers, so if we merge this, will it cause any issues for other llms ?

After this is merged, if someone tries to use another provider without session flags, things work as before. If they try to an unsupported provider with session flags, it will return an error on startup about session persistence being not yet implemented for that provider.

I think from UX point of view, if I load an existing session (or if that is the default behavior), the UX should give a hint saying it is using persisted session (or resuming) with something so that user know that it is not a brand new session in case they wanted to have a brand new.

After this is merged, if an existing session is loaded, there will be a welcome back message with a hint to use --new-session if they don't want to continue last session.

I've updated PR description and provided demos.

[droot]

Thanks @noahlwest

This is looking quite good. I have a few comments that probably can simplify a few things. But if it is complicating the implementation, lets discuss.

[droot]

Just thinking:
we can define the interface here (closer to the user of the interface) and also enforce here that pkg/sessions/Session implements the interface.

[droot]

Adds session persistence for gemini, so users can continue where they left off, or continue their session in a different interface.

• session persistence is not enabled by default. Users will need to use --new-session flag to start a new session and --session flag to resume a session. We can change this later when it's implemented for all models + if users desire this behavior.
• adds session manager for handling session operations, with create/describe/list/delete session operations
• initializes conversation with chat history when resuming a session
• currently implemented for gemini, other providers will display a not implemented error if you try to use session flags with them

To try it out, use kubectl-ai --new-session to start a new session, and kubectl-ai --session <session id> to resume a session. If you don't know your session id, you can use kubectl-ai sessions to list them.

demo showing session persistence from terminal -> terminal -> web: https://github.com/user-attachments/assets/1e73d9bf-b1d9-4165-985c-67dfe7c5a708

demo showing loading different sessions: https://github.com/user-attachments/assets/c8b2d6c7-3833-485a-9bfd-7bb228c203e9

demo showing behavior without session flags (same as today) and trying to use sessions on unsupported providers: https://github.com/user-attachments/assets/5edcf484-f5f1-4125-9de8-8460af14a543

Thanks for sharing the demos, they really helped in seeing the UX. Looking very good.

[droot]

This is awesome. I was about to merge it, but then found a few nits that can potentially simplify the code even further. We can do it in a follow up as well if you prefer. happy to discuss over gvc if that can help resolve this faster.

[droot]

Thanks for working through this. Looks great, getting it in.