Date
1 - 7 of 7
Magnesium RC
JamO Luhrsen
Daniel can confirm, but I think all patches were merged and no more blockers
to deal with. this autorelease job: https://jenkins.opendaylight.org/releng/job/autorelease-release-magnesium-mvn35-openjdk11/207 produced this distro: https://nexus.opendaylight.org/content/repositories//autorelease-3877/org/opendaylight/integration/karaf/0.12.0/karaf-0.12.0.zip and triggered: https://jenkins.opendaylight.org/releng/job/integration-distribution-test-magnesium/187 tracking sheet for projects to update: https://docs.google.com/spreadsheets/d/1WgBX2c5DjQRfphM0sc3IKt7igW3EMxnUgANTcOlYD_U/edit#gid=1864238939 There is already one issue that I marked as a blocker until I can look more closely. It's the same problem I reported to Robert on his mdsal multipatch job, which is totally unrelated to the Magnesium release. I'm worried that it's a new regression we have. Thanks, JamO |
|
Thanks JamO for the update. I’ll follow up with PTL to make sure they get this done ASAP On Sat, Mar 14, 2020 at 12:05 PM JamO Luhrsen <jluhrsen@...> wrote: Daniel can confirm, but I think all patches were merged and no more blockers --
|
|
Abhijit Kumbhare
Thanks Jamo and Daniel! On Sat, Mar 14, 2020 at 12:32 PM Daniel de la Rosa <ddelarosa@...> wrote:
|
|
Robert Varga
On 14/03/2020 20:05, JamO Luhrsen wrote:
If it's the OVSDB issue, I have zero clue as to what is going on, except there is a ton of NPEs: 2020-03-14T07:03:59,899 | WARN | transaction-invoker-impl-0 | OvsdbOperationalCommandAggregator | 301 - org.opendaylight.ovsdb.southbound-impl - 1.10.0 | Exception trying to execute org.opendaylight.ovsdb.southbound.transactions.md.OvsdbPortUpdateCommand@e285fe0and it seems that verification is getting 401s -- probably because of these: 2020-03-14T07:04:57,040 | WARN | opendaylight-cluster-data-akka.actor.default-dispatcher-4 | EndpointReader | 47 - com.typesafe.akka.slf4j - 2.5.26 | Discarding inbound message to [Actor[akka://opendaylight-cluster-data/]] in read-only association to [akka.tcp://opendaylight-cluster-data@...:2550]. If this happens often you may consider using akka.remote.use-passive-connections=off or use Artery TCP.I have no remembrance of why we are using passive connections :( Regards, Robert |
|
Robert Varga
On 16/03/2020 09:44, Robert Varga wrote:
https://git.opendaylight.org/gerrit/c/controller/+/88437 switches them off.2020-03-14T07:04:57,040 | WARN | opendaylight-cluster-data-akka.actor.default-dispatcher-4 | EndpointReader | 47 - com.typesafe.akka.slf4j - 2.5.26 | Discarding inbound message to [Actor[akka://opendaylight-cluster-data/]] in read-only association to [akka.tcp://opendaylight-cluster-data@...:2550]. If this happens often you may consider using akka.remote.use-passive-connections=off or use Artery TCP.I have no remembrance of why we are using passive connections :( We cannot go to Artery TCP, as it has a nasty mem leak before 2.5.29 -- upgrade to that version is staged in the mri-sodium-sr3, though. Bye, Robert |
|
Chetan
Hi Robert,
toggle quoted message
Show quoted text
We are working on the fix to address this NPE. @Jamo, Was this NPE seen with earlier release also(I believe so as that codebase from which NPE thrown was same with earlier releases also). Also, can you point us to CSIT JOB popping with this NPE's. Thanks, Chetan -----Original Message-----
From: TSC@... <TSC@...> On Behalf Of Robert Varga Sent: 16 March 2020 14:15 To: JamO Luhrsen <jluhrsen@...>; release@...; integration-dev@...; tsc <TSC@...> Subject: Re: [OpenDaylight TSC] Magnesium RC On 14/03/2020 20:05, JamO Luhrsen wrote: If it's the OVSDB issue, I have zero clue as to what is going on, except there is a ton of NPEs: 2020-03-14T07:03:59,899 | WARN | transaction-invoker-impl-0 |and it seems that verification is getting 401s -- probably because of these: 2020-03-14T07:04:57,040 | WARN |I have no remembrance of why we are using passive connections :( Regards, Robert |
|
JamO Luhrsen
FYI, the problem I've been digging in to is now filed here:
toggle quoted message
Show quoted text
https://jira.opendaylight.org/browse/AAA-195 It's not ovsdb related, but more low-level and may not even be in AAA. The high level issue is that bundles are not starting up as expected so basic functionality (like authenticating a rest call) fails. More info is in the jira. Although it does seem to be a new issue, since it seems relatively infrequent (only saw it once in more than 125 tries in the sandbox) I think it does not need to block the formal Magnesium release. I did mark it as a blocker for Magnesium SR1. It would be a pretty ugly state for an end user to hit, if they happened to be unlucky. Thanks, JamO On 3/16/2020 8:32 PM, Chetan Arakere Gowdru wrote:
Hi Robert, |
|