Greetings folks,Thank you Kenny for laying down some of the ground work for what I'm going to detail.
As has been mentioned, we're currently running into issues with EasyCLA on GitLab. This issue showed up at the end of May when GitLab 15 was released which removed a feature that was in use by EasyCLA. We are presently trying to get an ETA from product engineering as to when this will be resolved.
Next up, there is a mention about EMCO using GitLab and not having issues. After familiarizing myself with EMCO I can state that they are not having issues on GitLab because their charter does not currently require a CLA and only a DCO which is something that _is_ enforceable in GitLab. As such, there is not a 1:1 comparison for project governance inside the SCM platform. They may be an LFN project, but all top level projects in an umbrella are not governed the same way and comparisons about code governance must always be look at through the lens of each projects requirements.
Now, on the topic of how do we get around the problem with EasyCLA that currently exists in GitLab. Kenny, mentioned that Gerrit is an option and it is. We can create repositories in Gerrit and mirror them to GitLab. Changes can be made in Gerrit and mirrored to GitLab on merge. The only thing that will not work with this is GitLab workflows that are _not_ schedule based. So Merge Request, merge, etc workflows are not trigerable since the code isn't being actively worked directly in the GitLab repository. Our understanding about the workflows in question is that they are primarily schedule based, as such this would be a workable solution until EasyCLA is working correctly again on GitLab and we can transition the repositories to be on GitLab as their primary source. We will admit that it is a bit clunky to work with, particularly around workflow development, but it's the only practical solution we have for CLA enforcement currently.
On the topic of not needing root rights or shell access. Thank you for the clarification, this makes it much easier for LF Release Engineering to partner with you on getting a workable solution in place.
Finally, thank you for raising the ticket along with the subsequent follow up with the link to the Orange GitLab repositories. I have taken a quick look at the repositories and I have three distinct concerns with them all in the context of bringing this under ONAP Project governance as seed code. These are:
* Several repositories have no license and this causes issues with ONAP being able to ingest the repositories. The ones that do thankfully have Apache 2
* I understand that the intent is to _not_ take the history of these repositories, but do a squash commit. This is good because I see (in my brief exploration) many commits with no DCO, which again is a requirement of repositories for ONAP.
* For the repositories that have no license on them, we would have to have someone from Orange do the code proposal, otherwise we run into copyright issues. As it stands, someone from Orange really should be the one to do the squash commit proposal for all of them.
With all of that being said, I need to re-iterate Kenny's statement about everything needing to be under CLA as that is the current governing charter which we are just being the enforcers of. As mentioned, EasyCLA was previously working and GitLab's May update is causing it to fail. With EasyCLA not presently operating correctly on GitLab, the only way to properly enforce this is by way of Gerrit until such time as EasyCLA has been fixed.
-Andy- On 6/23/22 15:10, [email protected] wrote:
+onap-tsc Dear ONAP TSC and Community,While in Porto last week I got a bit ahead of myself during a discussion on the way forward for the use of GitLab pipelines by the Integration team. This was related to making a GitLab repo for Integration more or less a read-only mirror until a 2 hour timeout bug with GitLab can be addressed. That mirror scenario is still a valid solution, however it is a workaround for a specific bug and not a workaround to any legal requirements set forth in the charter.There has been lots of discussion that we are only taking what Orange has already written and bringing it into ONAP, so what is the big issue? I can break it down this way:* Currently the content we want is all in an Integration repo structure owned by Orange * Even though that content has been used extensively by the ONAP community, "ONAP Project a Series of LF Projects, LLC", has no legal jurisdiction or process control over those repos and everything in them. * What we want now is a set of Integration repos which is owned by, "ONAP Project a Series of LF Projects, LLC", to run the pipelines. * The ONAP Charter is very prescriptive stating that, "*all new inbound code contributions to the Project must be made pursuant to a duly executed ONAP Project Corporate Contribution License Agreement*"The key provision in the Charter is that it applies to *_the Project_* and not a stipulation that is limited to the ONAP codebase itself.As such the legal requirement is that we approach the code we are pulling in from Orange exactly the same way we would bring in seed code coming into the Project from any other channel.If the ONAP Project is going to own the reop – regardless of what is in it- then direct CLA control is non-negotiable unless the TSC wishes to pursue changing the actual legal Charter to do away with the CLA requirement. I'd anticipate that to be a 6-9 month effort to work its way through all of your legal departments.What needs to happen to work around the GitLab bug still means that: * The inbound content needs to be under CLA control, with all of the proper licensing, etc. * Currently CLA control for the Project is managed via our Gerrit implementation * The GitLab repos can be directly mirrored from Gerrit, thus inheriting CLA control * Any changes that need to be reflected in the GitLab repos would actually need to be made in Gerrit until the GitLab bug is fixed. * Once the bug is fixed, GitLab could be used directlyThere is nothing stopping anyone from creating a repo used by the ONAP community just the same way that Orange did. However, if/when the community decides to bring any such repo "in house", we would still need to do all of the same due diligence with regards to seed code.Andy Grimberg will follow up with some additional info. Thanks! -kenny *From:* Lefevre, Catherine <[email protected]> *Sent:* Thursday, June 23, 2022 10:11 AM*To:* Heather Kirksey <[email protected]>; Kenny Paul <[email protected]>; Andrew Grimberg <[email protected]> *Cc:* Bengt Thuree <[email protected]>; [email protected]; Jagiełło, Michał <[email protected]>; Closset, Christophe <[email protected]>; [email protected]*Subject:* RE: [URGENT]: ONAP GITLAB Request Dear all,The Open Gitlab from Orange is integration · GitLab <https://gitlab.com/Orange-OpenSource/lfn/onap/integration>Andreas/Michal/Chris – please correct me if I am wrong – thank you Best regards Catherine *From:* Lefevre, Catherine *Sent:* Thursday, June 23, 2022 11:21 AM*To:* Heather Kirksey <[email protected] <mailto:[email protected]>>; Kenny Paul <[email protected] <mailto:[email protected]>>; Andrew Grimberg <[email protected] <mailto:[email protected]>> *Cc:* Bengt Thuree <[email protected] <mailto:[email protected]>>; [email protected] <mailto:[email protected]>; Jagiełło, Michał <[email protected] <mailto:[email protected]>>; Closset, Christophe <[email protected] <mailto:[email protected]>>; [email protected] <mailto:[email protected]>*Subject:* [URGENT]: ONAP GITLAB Request *Importance:* High Good morning All,As a follow-up from the LFN DDF event last week, we were in agreement to move all the Gitlab activities created on the Open Gilab Orange to a dedicated ONAP Gitlab.The question about ‘easyCLA” was also discussed and we agreed to proceed as a short term plan by creating an ONAP Gitlab with the support of LFN IT.I understand this morning that easyCLA is again a blocker to proceed.Our intention is not to ‘fork’ the code from “Open Gilab Orange” but we have already our own ONAP pipelines (locally) that we want to push to the public ONAP GitLab.Therefore we do not see any issue about these ONAP pipelines as EMCO Open Source community is already maintaining their code in Gitlab - https://gitlab.com/project-emco/core/emco-base <https://gitlab.com/project-emco/core/emco-base>Please note when we talk about ‘code’ – this is not source code but “Jenkins jobs”. The actual ONAP source code will always stay in the ONAP official gerrit - https://gerrit.onap.org/ <https://gerrit.onap.org/>This request is nothing related to the OOM Gitlab that was a POC for the OOM team.This request is about ONAP Gitlab will be exactly what Orange did to run their gating but this time we will use ONAP GITLAB to run our ONAP testing, using runners from UNH.As discussed last week, this is a matter of urgency therefore if we have no more agreement with the LFN then we will create our own Gitlab.When the LF IT will be able to fix their current internal concern then we will be more than happy to migrate our ONAP Gitlab.Our plan is to create our own ONAP Gitlab (without LF IT) on Monday 27^th , 2022 if you have still some concerns as we cannot wait without impacting our Kohn plan.The administration of this ONAP Gitlab will be limited to few key stakeholders.We confirm that we do not need any admin root rights/shell access to run the runners.UNH was the lab suggested by LF IT due to the firewall issue to be used as runners.The following LF IT ticket has been created as requested - Migration of Orange ONAP Gitlab to a Public ONAP Gitlab - Project Services - Service Desk (linuxfoundation.org) <https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-24198>Best regards, Catherine *Catherine Lefèvre * *AVP Software Development & Engineering* *AT&T Technology Services – Network Systems Common Platform & Services* *ONAP TSC Chair* ** ** Phone: *+32 2 418 49 22* Mobile:*+32 475 77 36 73*** [email protected] <mailto:[email protected]> */TEXTING and DRIVING… It Can Wait/*// *AT&T* BUROGEST OFFICE PARK SA Avenue des Dessus-de-Lives, 2 5101 Loyers (Namur) Belgium ** *//**/NOTE:/*/This email (or its attachments) contains information belonging to the sender, which may be confidential. proprietary and/or legally privileged. The information is intended only for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient, you are hereby notified that any disclosure, distribution or taking of any action in reliance on the content of this is strictly forbidden. If you have received this e-mail in error please immediately notify the sender identified above./
-- Andrew J Grimberg Manager Release Engineering The Linux Foundation NOTICE: The Linux Foundation supports their employees with flexible work hours. If you recieve mail from me outside of standard business hours please be aware that I do not expect a response until the next standard business day. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#8738): https://lists.onap.org/g/onap-tsc/message/8738 Mute This Topic: https://lists.onap.org/mt/91953512/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/21656/1412191262/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
OpenPGP_signature
Description: OpenPGP digital signature
