Migrate models from hosted instance into gitlab.com/finosfoundation
maoo opened this issue · 4 comments
In order to enable wider collaboration across FINOS community, the Alloy models should be hosted in the public gitlab.com instance, instead of gitlab.alloy.finos.org, as it's currently done. This will enable any gitlab.com user to request access and start collaborating.
New ACL definition
Below is the matrix of actors and actions that will be available in Alloy Studio after the opensourcing of the platform.
- Anonymous user
- can see all models code (publicly available)
- cannot access Alloy Studio
- GitLab.com user
- same as Anonymous user
- Read-only modeler
- same as GitLab.com user
- can access Alloy Studio
- can read all models code
- Contributor modeler (on a given model)
- same as Read-only modeler
- can submit changes on the given model
- Approver modeler (on a given model)
- same as Write modeler
- can approve changes
The proposed implementation on GitLab.com would require the creation of:
- An Alloy sub-group of finosfoundation
- A sub-group of Alloy for each modeling initiative
- 3 sub-groups of each modeling initiative group called readers (Reporter), contributors (Developer) and approvers (Maintainer)
Onboarding
When Alloy points to gitlab.com, users will self sign up; in order to request read-only, contributor or approver access, there will be a form available on www.finos.org/alloy , which will request the Gitlab.com username (currently is asking the GitHub.com username); FINOS Staff will receive the requests and manage the Gitlab.com group members accordingly.
The existing modelers will need to create or reuse a gitlab.com account and submit their username to FINOS Staff (ie via the form on finos.org/alloy page). FINOS Staff will guide them through the process and make sure their modeling activity doesn't suffer any downtime.
Technical tasks
Below is a plan of attack to tackle the technical tasks involved in this migration; activities are grouped in milestones.
ASAP
These preparation steps should be inspired by the current FINOS configuration of GitHub.com/finos, documented on https://odp.finos.org/docs/project-collaboration.
- Review gitlab.com/finosfoundation main configuration, comparing with https://odp.finos.org/docs/project-collaboration
- Produce a comparison matrix for features, across GitHub and GitLab
- Create a GitLab Group structure documented above
- For each modeling initiative (ie CDM) create a GitLab project (same names as the existing ones)
- Setup group-based permissions
- Review branch protection setup (enforce cla-bot and master protection)
- Mao pulls from gitlab.alloy.finos.org/... and push into gitlab.com/finosfoundation/... from a local workstation
- Add documentation to odp.finos.org
1 month prior to the migration
- Communicate to all Pilot participants (email from all GitLab users within the current Alloy-Pilot group) the date of the migration
- Explain what happens (why) and what they must do the day after the migration
- Participants must sign up to Gitlab.com and provide us with their GitLab Username
- Mao/Aitana add pilot participants into the respective GitLab sub-group
- If maintainer, the maintainer sub-group (ie CDM-maintainers)
- If reporter, the Alloy main group
- Mao/Aitana document onboarding procedure on odp.finos.org (and linked into alloy.finos.org)
Before the migration
- James B. deploys a new version of Alloy that is tested against gitlab.com/finosfoundation API endpoints
- Deploy GitLab Runners
- James B. and mao test alloy.finos.org/studio using the sample-modeling project on gitlab.com/finosfoundation
Migration day
Mao and James B. will perform the following activities during a shared screen session:
- Archive projects on gitlab.alloy/finos.org
- Update README to point to new locations
- Pull and push all modeling projects across Git endpoints
- Run checklist (TBD)
- Notifications and announcements
+1. One thing that would be nice, but possibly an aspirational goal, is to say that read-only users and gitlab.com users are the same. That way there wouldnt be any signup to view models in Studio, which would more fully meet our goal of being publicly visible, but users are still identified so we can blacklist any bad actors. This would need some development so let's put it in the backlog if we agree.
+1. One thing that would be nice, but possibly an aspirational goal, is to say that read-only users and gitlab.com users are the same. That way there wouldnt be any signup to view models in Studio, which would more fully meet our goal of being publicly visible, but users are still identified so we can blacklist any bad actors. This would need some development so let's put it in the backlog if we agree.
Thanks @gs-bracej , I share the same aspirational goal, although I've big concern: what's the impact on system load, and therefore scalability/costs of the platform? And is there any way we could enable this without running the risk to bring the platform down due to usage spikes?
It's interesting to notice that this scenario would need less configurations at Alloy and GitLab level, and it perfectly fits into FINOS project collaboration guidelines, which is what we adopt across all our GitHub hosted projects.
That is an excellent point! I think in read-only mode it isnt possible to trigger a compile, so the load on the exec server should be negligible. However as part of the development for this we should ensure that this is the case, I'll add that part to the issue.
Today we migrated models to gitlab.com/finosfoundation/legend , please see https://groups.google.com/u/1/a/finos.org/g/legend/c/n1VBLlkkHvg
Congratulations to the Legend team for achieving this important milestone!