feat: adding new Playground Manager V2 (chat based)

[axel7083]

What does this PR do?

Introducing PlaygroundManagerV2 which use the InferenceManager. This is specifically made for a chat base interaction with the model.

I am deprecating all the PlaygroundManager methods. Should be removed in a near future.

New apis

• getPlaygroundConversations get the list of conversations available
• createPlaygroundConversation return a conversation id
• submitPlaygroundMessage submit a message to a conversation

Screenshot / video of UI

What issues does this PR fix or reference?

Fixes #509

Related to

• discussion(playground): design and features #401
• Playground should look similar to a chat #145

How to test this PR?

• unit tests

[axel7083]

draft until improvement

[feloy]

Will this class PlaygroundManagerV2 manage all the playgrounds (as the deprecated class PlayGroundManager is doing with its playgrounds field?

I'll need to get the list of playgrounds, and add new ones in #525, should I rely on this class, or should I use/create another one?

To sum up, it's not clear to me why we are creating this PlaygroundV2Manager and deprecating the PlaygroundManager, if it will cover 100% of it, when, ...?

[jeffmaury]

Will this class PlaygroundManagerV2 manage all the playgrounds (as the deprecated class PlayGroundManager is doing with its playgrounds field?

I'll need to get the list of playgrounds, and add new ones in #525, should I rely on this class, or should I use/create another one?

To sum up, it's not clear to me why we are creating this PlaygroundV2Manager and deprecating the PlaygroundManager, if it will cover 100% of it, when, ...?

We have 2 concept now the inference server and the playgrounds (conversation with a model). So we have a manager for each of them

[axel7083]

Will this class PlaygroundManagerV2 manage all the playgrounds (as the deprecated class PlayGroundManager is doing with its playgrounds field?
I'll need to get the list of playgrounds, and add new ones in #525, should I rely on this class, or should I use/create another one?
To sum up, it's not clear to me why we are creating this PlaygroundV2Manager and deprecating the PlaygroundManager, if it will cover 100% of it, when, ...?

We have 2 concept now the inference server and the playgrounds (conversation with a model). So we have a manager for each of them

I will create an epic

[feloy]

To start working on the playgrounds list page (first part of #525), I will need to 'mock' a list of playgrounds. There is one provided by the playground-states store (for now relying on the PlaygroundV1Manager). Can I expect to have something similar with the new architecture (a store with playgrounds information - I'm not worried if the information is different, but will the architecture, based on a store, will be the same)?

[axel7083]

To start working on the playgrounds list page (first part of #525), I will need to 'mock' a list of playgrounds. There is one provided by the playground-states store (for now relying on the PlaygroundV1Manager). Can I expect to have something similar with the new architecture (a store with playgrounds information - I'm not worried if the information is different, but will the architecture, based on a store, will be the same)?

This is hard to say yet ! As I mention in https://github.com/projectatomic/ai-studio/issues/535 we have two concept now, Conversation and playground, for now I guess that this Pull Request is outdated, as the PlaygroundManager will not be the one holding the data

[feloy]

I would propose to keep the PlaygroundManager interface as it is (startPlayground / stopPlayground / askPlayground / sendPlaygroundState), or with some minor changes (adding a name at least), and change how these methods are implemented, to make use of the InferenceServer.

It seems to me that changing to using an Inference server should be transparent as much as possible from the frontend point of view.

[axel7083]

I would propose to keep the PlaygroundManager interface as it is (startPlayground / stopPlayground / askPlayground / sendPlaygroundState), or with some minor changes (adding a name at least), and change how these methods are implemented, to make use of the InferenceServer.

It seems to me that changing to using an Inference server should be transparent as much as possible from the frontend point of view.

@feloy IMO it does not make really much sense to keep the api startPlayground | stopPlayground as there implementation will not match their naming, as you do not start a playground you start an inference server and the playground will connect to it.

Almost all the code of the current playground manager is about lifecycle of the container, which is now handled by the InferenceManager.

[axel7083]

@feloy following the discussion we had this morning, I added tests !

[feloy]

LGTM
As discussed, the interfaces will change by internalizing some values (model, etc) when we first create a Playground passing a model ID and the playground starts itself the inference server (will be part of #539)

[feloy]

thanks!