[MM-PulpFree] Investigate/Implement Start Meeting Endpt

[MuchToKnow]

The start meeting endpoint will need to spawn a MM404 instance to serve the meeting and return the information needed to connect to said instance to the FE so the websocket can be established.

The start meeting endpoint will also need to accept the users/team(s) present in the meeting in order to

• Load the voice biometrics data into 404 to give to MML for voice tagging.
• Initialize the meeting entry in our db and pass a meeting ID to 404. This will include associating the users that are part of the meeting with the meeting ID for use in future lookup.

Maybe?

• Pass User IDs to 404? (Do we need these for future writes to the DB during the meeting? This might depend quite a lot on DB structure so we should probably iron that out by next week to have something solid to work with)

Definitely going to need good communication for this one as it's probably going to be the biggest endpoint in PulpFree in terms of models that it relies on and actions performed.

@ErisMik @yuming-h Just gonna tag you guys since this relies a lot on all of your work and would love some input especially after we iron out models hopefully in the next meeting.

[ErisMik]

I think this will need to be ironed out next week / as design goes.

I don't think it makes sense to pass the biometrics data through 404, rather I think just user / team ids and then let MML grab that information from the DB?

[MuchToKnow]

So would MML have to make a db call for that info for every single job on the queue? I feel like this might be an issue.

I guess MML could cache this info and give it an hour or so to live depending on avg meeting times. But that makes it a bit less scaleable since, as you add more instances of MML, the chance that a job is processed by a worker that has the correct data cached gets slimmer.

With that being said I guess letting MML grab and cache is probably the best solution we have so far since the biometrics data is probably too heavy to be included in each request/job. We probably won't ever hit a scale that would affect the above and could just vertically scale for quite a while anyways.

[yuming-h]

Biometrics training data will have to be stored with whatever cloud service we go with, so MML will be able to handle it. That being said, there needs to be an endpoint to initialize training as well so keep that in mind. The new services we made at the meeting should be able to pass the user IDs associated with a voice back to the UI since they know about the DB anyways. As for the queue issue, I have no solution but this should definitely be discussed at a future meeting.

[MuchToKnow]

I thought we were going to try and use a library for the voice recognition instead of a cloud service?

The queue issue I mentioned is the same problem, I just worded it badly: Making sure MML is using the right voice recognition (biometrics) data for a given request so it only searches over voice data for users in that particular meeting.

I don't have a great solution but I think the caching one is pretty good as a start unless we want to look for cloud services.

[ErisMik]

I think we are going to go with a library based solution, I’m not sure how well a cloud solution will work even for MVP (also $$$$).

I think the caching will work well enough.

An alternative we can discuss is moving the data to its own DB specifically for MML use? PulpFree would still need access to populate it at some point however.

[ErisMik]

Started in branch 53-pf-start-meeting-endpoint

[ErisMik]

I just did a local test: Set up the docker engine on a rpi with a custom docker network and a configured nginx container. Then I was able to remotely spawn instances of a container with a configured hostname, then connect to them using // from my local machine. NGINX routing is so powerful.

So it looks like it's definitely doable for PF & 404, not at all difficult to setup, stateless on the 404 side, and doesn't require the creation of another service

From Slack, here for posterity