Make the front-end multi tenant.

[zippeurfou]

We should allow the front-end to be multi-tenant. This create a non optimal frontend experience. Here is an example who did it: https://github.com/Lightning-AI/LAI-Hackernews-App/blob/main/hackernews_app/flows/hackernews_ui.py

[belerico]

Thanks for the reference @zippeurfou! I will open a or in the next few days with the fixes

[otaj]

Hi, @belerico, @zippeurfou.

I am not really sure if the multi-tenancy would be a simple fix. Here's a list of things I believe are necessary in order to have multi-tenancy work nicely:

• Create a session id for each new user
• However, it is necessary for this session id to be persistent across the whole app, so that training can pick this up and train according to the user settings

To be fair, I'm not really sure how much more work will be needed on the training side as I haven't really dived too much into the code yet, but I'm not sure it would be easy. But, I'd also like to be proven wrong :D

[belerico]

Hi @otaj, yeah you're right: after I've dived into more I have to agree with you. The main problem here is that the app state it has to be session_id dependent in every component. Two solutions came into mind, none of them I'm 100% sure they'll work:

1. The config page sets a new session_id as needed, while the root flow creates an RLTrainFlow for every session_id, storing them in Lightning dict. In this way every session_id it will have its own RLTrainFlow associated and everything will be separated; on the other hand the number of different processes will grow at a rate of at least 4N, where N is the number of different session_ids (considering only 1 player, 1 tester, 1 trainer and 1 logger)
2. The session_id will be propagated through the run method of every component, but that means that every state of every component will have to be session dependent

[otaj]

Option 2 is tricky, because if there would be two users coming at similar time, one would have to at least wait for the works of the other to finish before they would even start.

But, I believe it is the only correct option for public use case since you can currently have at most 5 works on public cloud

[otaj]

Anyway, @belerico , there's one important question - do you want/need some help with that or do you think you can manage on your own? :) I'd be happy to help if that's something you'd be interested in :)

[belerico]

Option 2 is tricky, because if there would be two users coming at similar time, one would have to at least wait for the works of the other to finish before they would even start.

But, I believe it is the only correct option for public use case since you can currently have at most 5 works on public cloud

Yeah, you're right. I need to rethink the architecture and the flows logic to work with option 2).

Anyway, @belerico , there's one important question - do you want/need some help with that or do you think you can manage on your own? :) I'd be happy to help if that's something you'd be interested in :)

Sure, thank you! Help is always welcome :) Let me first rethink the arch/logic, then i will share it here. BTW, unfortunately for the next days i can only work on this on my spare time...

[otaj]

Alright, I'll be patient :)