|
Re: [E] Re: [release] Phosphorus SR1 RC
Luis Gomez
OK, int/test changes are merged now.
toggle quoted messageShow quoted text
|
|
|
|
Re: [E] Re: [release] Phosphorus SR1 RC
Sangwook Ha
3 integration/test patches for OpenFlow Plugin are ready for review (submitted one more to address an EOS test case): Luis, please take a look at the changes. Thanks, Sangwook
On Tue, Nov 23, 2021 at 12:08 PM Sangwook Ha via lists.opendaylight.org <sangwook.ha=verizon.com@...> wrote:
|
|
|
|
Re: [E] Re: [release] Phosphorus SR1 RC
Sangwook Ha
In addition to the integration/test change 98642, we need some additional changes for OpenFlow Plugin tests to support the stricter URL requirements & status code change (204 for RPC with empty response): I'm running some test jobs in the sandbox now, and should be ready for review. Thanks, Sangwook
On Tue, Nov 23, 2021 at 11:23 AM Robert Varga <nite@...> wrote: On 22/11/2021 23:11, Daniel de la Rosa wrote:
|
|
|
|
Re: [release] Phosphorus SR1 RC
Robert Varga
On 22/11/2021 23:11, Daniel de la Rosa wrote:
it seems that there are still BGPCEP, OVSDB and OFP issuesOkay, so BGPCEP should be all clear, the RESTCONF regression blocking OFP perf tests is resolved. One of the OVSDB failures has a controller tracker, but we won't be able to fix it for SR1. Th eonly outstanding item I am currently tracking is this: https://git.opendaylight.org/gerrit/c/integration/test/+/98642 Luis, can you review it, please? Thanks, Robert
|
|
|
|
Re: [release] Phosphorus SR1 RC
Robert Varga
On 22/11/2021 23:11, Daniel de la Rosa wrote:
it seems that there are still BGPCEP, OVSDB and OFP issuesOn the OFP side, we have a RESTCONF regression: https://jira.opendaylight.org/browse/NETCONF-834 I have the fix and will be rolling it out as soon as possible. Regards, Robert
|
|
|
|
Re: [release] Phosphorus SR1 RC
Robert Varga
On 22/11/2021 23:11, Daniel de la Rosa wrote:
it seems that there are still BGPCEP, OVSDB and OFP issuesOn the BGPCEP side, this seems to be a problem with in RFC8040 request URI format: http://10.30.170.109:8181/rests/data/odl-data-change-counter-config:data-change-counter-config/data-change-counter results it: <errors xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf"> <error> <error-tag>missing-attribute</error-tag> <error-message>Entry '(urn:opendaylight:params:xml:ns:yang:bgpcep:data-change-counter-config?revision=2017-04-24)data-change-counter-config' requires key or value predicate to be present. </error-message> <error-type>protocol</error-type> </error> </errors> I think that should read http://10.30.170.109:8181/rests/data/odl-data-change-counter-config:data-change-counter-config=data-change-counter instead, but let me get back to you. Regards, Robert
|
|
|
|
Re: [release] Phosphorus SR1 RC
On Sun, Nov 21, 2021 at 3:06 PM Robert Varga <nite@...> wrote: On 15/11/2021 20:22, Robert Varga wrote: it seems that there are still BGPCEP, OVSDB and OFP issues
|
|
|
|
Re: [release] Phosphorus SR1 RC
Robert Varga
On 15/11/2021 20:22, Robert Varga wrote:
On 15/11/2021 17:54, Daniel de la Rosa wrote:Alright, so BGPCEP-988 is confirmed passing in a Sulfur, thanks to Marek and Olivier for tracking it down and fixing it.The bgpcep regression (https://jira.opendaylight.org/browse/BGPCEP-988) is tricky, as it seems we turned around a rock under which it was hiding for couple of years. With bgpcep-0.16.11 we are back to passing completely here: https://jenkins.opendaylight.org/releng/view/autorelease/job/bgpcep-csit-1node-userfeatures-all-sulfur/ The corresponding Phosphorus job's manual runs seem to be mismatching on distro name somehow, but the next AR should be fine AFAICT. Regards, Robert
|
|
|
|
Re: [release] Phosphorus SR1 RC
Robert Varga
On 19/11/2021 06:27, Richard Kosegi wrote:
Hi,Confirmed on Sulfur here: https://jenkins.opendaylight.org/releng/job/daexim-csit-3node-clustering-basic-only-sulfur/ Thanks, Robert Regards,
|
|
|
|
Re: [release] Phosphorus SR1 RC
Richard Kosegi <richard.kosegi@...>
Hi, I removed references to prefix-shard module in daexim's tests https://git.opendaylight.org/gerrit/c/integration/test/+/98613 CSIT seems to pass on sandbox https://jenkins.opendaylight.org/sandbox/view/All/job/daexim-csit-1node-basic-only-phosphorus/1/ Regards, Richard
On Fri, 19 Nov 2021 at 00:57, Daniel de la Rosa <ddelarosa0707@...> wrote:
|
|
|
|
Re: [release] Phosphorus SR1 RC
On Thu, Nov 18, 2021 at 10:38 AM Robert Varga <nite@...> wrote: On 18/11/2021 19:28, Richard Kosegi wrote: Richard, is this something you can help with ? Thanks
Daniel de la Rosa ODL Release Manager
|
|
|
|
Submit a Session for the LFN Developer & Testing Forum!
Casey Cain
The next LFN Developer & Testing Forum is scheduled for January 10-13, 2022. Once again we will be virtually gathering the LFN project technical communities to progress our releases; discuss project architecture, direction, and integration points; and further innovate through the open source networking stack. Participating LFN projects include Anuket, EMCO, ODIM, ONAP, OpenDaylight, Tungsten Fabric, and XGVela. We’ll also be hosting a track with fellow networking projects and initiatives including the 5G Super Blueprint, LFN End User Advisory Group (EUAG), and L3AF. We welcome you to submit your topic proposals on the wiki page here. Topic Proposals are due December 3rd! Learn more about the event and register here. The event is free to attend but registration is required. Please send any questions to ccain@.... You can also join the discussion on our event Slack in the #general channel here. Best, Casey Cain Senior Technical Community Architect Linux Foundation _________________ WeChat: okaru6 WhatsApp: +1.503.779.4519 Sent via Superhuman
|
|
|
|
Re: [release] Phosphorus SR1 RC
Robert Varga
On 18/11/2021 19:36, Daniel de la Rosa wrote:
Ok, thanks for the clarification.. so @Robert Varga <mailto:nite@...> this is not part of the controller tickets that you and @Tomáš Cére <mailto:tomas.cere@...> are working on?Nope, those two are related to the new EOS implementation. Regards, Robert
|
|
|
|
Re: [release] Phosphorus SR1 RC
Robert Varga
On 18/11/2021 19:28, Richard Kosegi wrote:
Hi Daniel,Right, but prefix shards have been removed in https://jira.opendaylight.org/browse/CONTROLLER-1977, so daexim should not rely on them... Regards, Robert Regards,
|
|
|
|
Re: [release] Phosphorus SR1 RC
Ok, thanks for the clarification.. so @Robert Varga this is not part of the controller tickets that you and @Tomáš Cére are working on?
On Thu, Nov 18, 2021 at 10:28 AM Richard Kosegi <richard.kosegi@...> wrote:
|
|
|
|
Re: [release] Phosphorus SR1 RC
Richard Kosegi <richard.kosegi@...>
Hi Daniel, I don't think this has anything to do with daexim, it can't import data into an operational datastore because the offending module (shard-prefix) is not loaded. The Module seems to belong to controller IIRC: Schema node with name prefix-shards was not found under (urn:ietf:params:xml:ns:netconf:base:1.0)data Regards, Richard.
On Thu, 18 Nov 2021 at 17:15, Daniel de la Rosa <ddelarosa0707@...> wrote:
|
|
|
|
ODL Slack Channel
Casey Cain
Hello everyone, This is a reminder that we have a Slack channel available for open ODL discussion here: https://join.slack.com/t/lfntech/shared_invite/zt-xzd50vsy-ap53baNIVSxDyunb9zB6jA Best, Casey Cain Senior Technical Community Architect Linux Foundation _________________ WeChat: okaru6 WhatsApp: +1.503.779.4519
|
|
|
|
Re: [release] Phosphorus SR1 RC
Thanks Robert and all... Richard, we are having some issues with Daexim, is that something you can help with?
On Mon, Nov 15, 2021 at 11:22 AM Robert Varga <nite@...> wrote: On 15/11/2021 17:54, Daniel de la Rosa wrote:
|
|
|
|
Re: [E] Re: [integration-dev] integration/distribution version issues
Robert Varga
On 17/11/2021 17:42, Ha, Sangwook wrote:
Looking at the release & version bump cycle, some of the steps may be simplified, and hopefully automated:Yes there is and there is quite a bit of history attached to that. Our governance clearly states that each project is independent, which in this context means is free to release whenever as well as can decide to release outside of Simultaneous Release. During our initial (Hydrogen, 2014) release, we have had all projects integrating on SNAPSHOTs and the release party was ... not awesome. If you see git tags like "jenkins-controller-bulk-release-prepare-only-2-1", those are from that period. There were multiple technical reasons why it did not go so well. As a reaction to that, autorelease was created, to have all projects still integrated on SNAPSHOTs, but projects gave up their right to release on their own and instead all projects were release by LFN personnel in one large chunk -- we are still doing this for MSI projects. The experience of being integrated on SNAPSHOTs was ... not exactly great -- it lead to the creation of validate-autorelease and distribution-check jobs, which gate every patch so that it does not happen to break downstreams. We have mostly addressed the technical issues by 2017 and started peeling projects away from autorelease with odlparent-2.0.0 (IIRC). Fast forward to today and autorelease does not carry a single kernel project. With that context, I will never agree to going for "release together" -- that amounts to autorelease hell. I have endured it for years upon years and have toiled sweat and blood to get out of it. I am *NEVER* going back to that, period. Can we do better than we are doing today? Certainly. There are multiple reasons why kernel project releases happen "a few days apart". It is mostly a manual process and you can probably guess whose time is being spent on it. There is silver lining, though, as Nexus promotions take ~30 minutes for most projects, not 2+ hours like they used to just two months ago. Now if we only had reliable automation taking advantage of that... Regards, Robert
|
|
|
|
TSC Meeting for Novembre 18, 2021 at 9 am Pacific
Guillaume Lambert
Hello OpenDaylight Community, Next TSC meeting is Novembre 11 , 2021 at 9 am Pacific Time. The agenda proposal and the connection details for this meeting are available at the following URL: If you need to add anything, please let me know or add it there. The meeting minutes will be at the same location after the meeting is over. Best Regards Guillaume _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
|
|
|