At this time we have a first approach for the mpic chart to try to deploy a first draft version of this webapp as soon as possible. The gitlab pipeline is now ready to publish docker images (T361345: Create the MPIC docker image build pipeline), the database is ready (T361955: Create an `mpic` MariaDB database), we have a first approach about the login (T361341: Add the MPIC idp client configuration) and we are already working on helmfiles (T361344: Create MPIC helmfiles). So our efforts right now are focused on deploying something to staging environment as soon as possible to see how/if everything is working fine there.

Just pausing this ticket because it seems that, so far, the current change is ok but we need to make some progress in related tasks to be sure which other parameters/configuration we need to add to the MPIC chart. For example:

• At this time we are using some secrets to log to SAL but there is an open discussion about if it's the right way to do that
• We'd need to add some config fields related to the login feature
• We need to explore more about how monitoring works to be sure which parameters we need to parameterize here about it

This task is currently paused waiting for other related features to be done:

• Waiting for the log in feature to validate the double-submit cookie before registering the instrument
• Waiting for the decision about how to log user interactions properly (At this time there is an open discussion to decide if SAL is the proper way to do it)

About the ENUM issue, I was wondering if we should focus on reducing the complexity here considering, just in case, what we would have to do in case we add a new contextual attribute some day. We added a new one just a few days ago (maybe I'm wrong and it's not so usual). Is it worth taking that into consideration? It doesn't sound good to have to modify the database schema if we add a new contextual attribute. That's why I also like the classical approach that Clare mentioned about having a separate table with all the values and just join them when needed.It's even better to search them when autocompleting in the ChipInput/Lookup component we have in the registration form. And in the case a contextual attribute is added/changes, we only need to add a new field/modify an existing one.

Ok!
We are working on the schema and SQL script at T360748: [User Story] Create the MPIC database schema. As soon as it's available we'll provide it to you.

The same thing wil need to be done for SAL I think, except I don't have the password.

Thank you @brouberol!
Are you ok if we provide you a SQL script to create the tables for the database?

Thanks @cjming! All this helps a lot to catch up on the database schema work.
I only have a few comments:

• Just in case because I would say were are not going to use that schema representation, it seems the owner column is missed in the json schema you have added above.
• Regarding the SQL script, I would say that task and security_legal don't need to be represented as TEXT (65k characters). I think we could just use VARCHAR with a convenient maximum size.
• According to the demo meeting we had last week, it seems we should add something to know the current status of an instrument (On, Off, Error). Could we take the opportunity to add some column to the instruments table to store it? I would say we can, at least, determine and save the On/Off status when an user turn the instrument on/off. According to that meeting, we had an action item to try to determine the error status, but as far as I understand it seems that status as a column is a reality and also the turn on/off feature. Please correct me if I'm wrong.

As a first step, I have been working on the GitLab CI/CD and I have added you as reviewer for a MR I have prepared: https://gitlab.wikimedia.org/repos/data-engineering/mpic/-/merge_requests/8
Can you take a look?

The following are what we considered before starting exploring for the most appropriate architecture for this project: