Hi all, here my 2 cents. I also dislike the idea to use gerrit as repo for the code and clone it to gitlab, as it would make the work too complicated. I already mentioned, that the projects, we need to copy and adapt from the Orange Gitlab area are just helper tools to automate the testing of ONAP in the integration project, but not contain any ONAP sourcecode. Therefor I don't think the licencing and EasyCLA issue should not appear to it.
Best regards Andreas -----Ursprüngliche Nachricht----- Von: Jagiełło, Michał <[email protected]> Gesendet: Freitag, 24. Juni 2022 14:55 An: [email protected]; [email protected]; 'Heather Kirksey' <[email protected]> Cc: 'Bengt Thuree' <[email protected]>; Geissler, Andreas <[email protected]>; Closset, Christophe <[email protected]>; [email protected]; Rajewski, Łukasz <[email protected]>; Krzysztof Kuzmicki <[email protected]>; Alexander Mazuruk <[email protected]>; Fiachra Corcoran <[email protected]> Betreff: RE: [onap-tsc] [URGENT]: ONAP GITLAB Request + Integration commiters How will it look like? If I make a change on Gerrit review when it will be visible on GitLab? After merge? If yes we need to merge changes before we can really verify that running pipeline. Then probably we need to create another gating system to verify changes on testing pipelines which is going to run testing pipelines. That makes life complicated. We need to have an Maintainer access to that project, so we could rerun failed pipelines, run unscheduled pipelines etc. Could that be done with that mirroring option? Not all Orange repositories we need to migrate to Gerrit. On DT we also execute ONAP tests on GitLab which uses the same mechanism but the flow is different (less steps). I never said we need to use Orange version of pipelines, that's going to be a mix of solutions Orange and DT did, but kept in one place and maintained by the community. BR, Michal -----Original Message----- From: [email protected] <[email protected]> On Behalf Of Catherine LEFEVRE Sent: Friday, June 24, 2022 12:27 PM To: [email protected]; [email protected]; 'Heather Kirksey' <[email protected]> Cc: 'Bengt Thuree' <[email protected]>; Geissler, Andreas <[email protected]>; Jagiełło, Michał <[email protected]>; Closset, Christophe <[email protected]>; [email protected] Subject: Re: [onap-tsc] [URGENT]: ONAP GITLAB Request Importance: High Good morning All, Thanks for the clarifications and for the proposal. Michal, Andreas, I believe that the proposal of pushing the code to ONAP gerrit repo that will be cloned to ONAP Gitlab repo is acceptable. Can you please confirm? Thank you Many Thanks and Best regards, Catherine -----Original Message----- From: [email protected] <[email protected]> On Behalf Of Andrew Grimberg Sent: Friday, June 24, 2022 12:47 AM To: [email protected]; Lefevre, Catherine <[email protected]>; 'Heather Kirksey' <[email protected]> Cc: 'Bengt Thuree' <[email protected]>; [email protected]; 'Jagiełło, Michał' <[email protected]>; Closset, Christophe <[email protected]>; [email protected]; 'onap-tsc' <[email protected]> Subject: Re: [onap-tsc] [URGENT]: ONAP GITLAB Request 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 directly > > There 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-24 > 198> > > 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. T-MOBILE POLSKA S.A. z siedzibą w Warszawie Adres: ul. Marynarska 12, 02-674 Warszawa Zarząd Spółki: Andreas Maierhofer – Prezes Zarządu; Juraj Andráš – Członek Zarządu, Dyrektor ds. Finansowych; Dorota Kuprianowicz-Legutko – Członek Zarządu, Dyrektor ds. Polityki Personalnej; Goran Marković – Członek Zarządu, Dyrektor ds. Rynku Prywatnego; Petri Pehkonen – Członek Zarządu, Dyrektor ds. Technologii i Innowacji; Agnieszka Rynkowska – Członek Zarządu, Dyrektor ds. Rynku Biznesowego. Spółka zarejestrowana w Sądzie Rejonowym dla m.st. Warszawy w Warszawie, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego. KRS 0000391193 | NIP 526-10-40-567 | Regon 011417295 Kapitał zakładowy 711.210.000 złotych, kapitał wpłacony w całości. DUŻE ZMIANY ZACZYNAJĄ SIĘ OD MAŁYCH - CHROŃ PLANETĘ, NIE DRUKUJ TEGO E-MAILA, JEŻELI NIE MUSISZ. Ta wiadomość i jej treść są zastrzeżone w szczegółowym zakresie dostępnym na http://www.t-mobile.pl/stopka This e-mail and its contents are subject to a DISCLAIMER with important RESERVATIONS: see http://www.t-mobile.pl/stopka -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#8742): https://lists.onap.org/g/onap-tsc/message/8742 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]] -=-=-=-=-=-=-=-=-=-=-=-
