On 21/03/2022 14:24, Robert Varga wrote:

On 20/03/2022 19:50, Robert Varga wrote:

On 19/03/2022 16:37, Daniel de la Rosa wrote:

    Alright, so MDSAL-731 is fixed and it makes MDSAL-735 more diagnosable
    -- I plan to squash that today.


It looks like all issues have been resolved. So are we ready to pick the next AR as RC?

I am still working through netconf/bgpcep, plus the bump to MSI projects. I'll keep you posted.

bgpcep is ready for integration, but netconf is not -- as it turns the vast majority of patches dealing with SchemaNode.getPath() caller removal had to be reverted because ... let's say they were naive.

So fixing RESTCONF here is going to require a yangtools-8.0.2 release. The problem is that we lost a DataSchemaContextTree capability which was provided indirectly via SchemaNode.getPath() -- the details are in YANGTOOLS-1412.

I expect to have that fixed today and finish the RESTCONF integration tomorrow, so that the MRI bump should (fingers crossed) over the weekend.

It is way later than planned, expected or hoped, but unfortunately it is what it is. There is silver lining here, though: this effort found two bugs that have been squashed after lurking around for 7 years.

I'll keep you posted,
Robert

_________________________________________________________________________________________________________________________

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.

On 21/03/2022 14:45, Olivier Dugeon via lists.opendaylight.org wrote:

bgpcep is ready for integration, but netconf is not -- as it turns the vast majority of patches dealing with SchemaNode.getPath() caller removal had to be reverted because ... let's say they were naive.

Not yet for BGPCEP. I discover some late bugs on new PCE server last week. Patch is ready. I'll submit it this afternoon, just right after last verification.

Alright, anyway it's going to take a couple of days to sort out the RESTCONF stuff, so that (and the javadoc jobs) are the real blockers.

Regards,
Robert

Hello Robert,

On 20/03/2022 19:50, Robert Varga wrote:

On 19/03/2022 16:37, Daniel de la Rosa wrote:

    Alright, so MDSAL-731 is fixed and it makes MDSAL-735 more diagnosable
    -- I plan to squash that today.


It looks like all issues have been resolved. So are we ready to pick the next AR as RC?

I am still working through netconf/bgpcep, plus the bump to MSI projects. I'll keep you posted.

bgpcep is ready for integration, but netconf is not -- as it turns the vast majority of patches dealing with SchemaNode.getPath() caller removal had to be reverted because ... let's say they were naive.

Not yet for BGPCEP. I discover some late bugs on new PCE server last week. Patch is ready. I'll submit it this afternoon, just right after last verification.

Regards

Olivier

serviceutils is also ready to integrate, but there's a problem needing action in global-jjb: javadocs jobs are using mvn35 and thus end up exploding like here: https://jenkins.opendaylight.org/releng/job/serviceutils-maven-javadoc-verify-sulfur-openjdk11/32/

Even when we tell the job to use mvn38, it will unpack the correct maven, but will attempt to use mvn35: https://jenkins.opendaylight.org/releng/job/serviceutils-maven-javadoc-verify-sulfur-openjdk11/33/console

Regards,
Robert

_________________________________________________________________________________________________________________________

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.

On 20/03/2022 19:50, Robert Varga wrote:

On 19/03/2022 16:37, Daniel de la Rosa wrote:

    Alright, so MDSAL-731 is fixed and it makes MDSAL-735 more diagnosable
    -- I plan to squash that today.


It looks like all issues have been resolved. So are we ready to pick the next AR as RC?

I am still working through netconf/bgpcep, plus the bump to MSI projects. I'll keep you posted.

bgpcep is ready for integration, but netconf is not -- as it turns the vast majority of patches dealing with SchemaNode.getPath() caller removal had to be reverted because ... let's say they were naive.

serviceutils is also ready to integrate, but there's a problem needing action in global-jjb: javadocs jobs are using mvn35 and thus end up exploding like here: https://jenkins.opendaylight.org/releng/job/serviceutils-maven-javadoc-verify-sulfur-openjdk11/32/

Even when we tell the job to use mvn38, it will unpack the correct maven, but will attempt to use mvn35: https://jenkins.opendaylight.org/releng/job/serviceutils-maven-javadoc-verify-sulfur-openjdk11/33/console

Regards,
Robert

On 19/03/2022 16:37, Daniel de la Rosa wrote:

Alright, so MDSAL-731 is fixed and it makes MDSAL-735 more diagnosable
-- I plan to squash that today.
It looks like all issues have been resolved. So are we ready to pick the next AR as RC?

I am still working through netconf/bgpcep, plus the bump to MSI projects. I'll keep you posted.

Regards,
Robert

On 16/03/2022 23:46, Robert Varga wrote:

On 16/03/2022 00:53, Daniel de la Rosa wrote:

Hello Robert

Hello Daniel,

    The major outstanding item are the MD-SAL regressions detected in ovsdb
    (and same thing is biting netconf) and bgpcep, tracked as MDSAL-731 and
    MDSAL-735 respectivelly.


Another day has passed :) so i guess we have to wait until these two are fixed to pick a RC?

Yes, unfortunately and I am still struggling with the fix, it turns out to be more complicated than expected, but I am converging on a solution.

Alright, so MDSAL-731 is fixed and it makes MDSAL-735 more diagnosable -- I plan to squash that today.

Regards,
Robert

_________________________________________________________________________________________________________________________

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.

On 16/03/2022 00:53, Daniel de la Rosa wrote:

Hello Robert

Hello Daniel,

The major outstanding item are the MD-SAL regressions detected in ovsdb
(and same thing is biting netconf) and bgpcep, tracked as MDSAL-731 and
MDSAL-735 respectivelly.
Another day has passed :) so i guess we have to wait until these two are fixed to pick a RC?

Yes, unfortunately and I am still struggling with the fix, it turns out to be more complicated than expected, but I am converging on a solution.

Regards,
Robert

On 01/12/2021 11:14, Robert Varga wrote:

The tracker issue for the removal is https://jira.opendaylight.org/browse/NETCONF-837 and the plan of action is as follows:
1. Phosphorus SR2, due out 2022-01-27, will issue a single (mild) warning on startup. We will continue to install the implementation as part of the 'odl-restconf' feature.
2. 2022.03 Sulfur, due out 2022-03-17, will not install the old implementation by default. Users will be required to explicitly install the 'odl-restconf-nb-bierman02' feature. The warning introduced in step 1. will be updated to warn about the fact the feature is no longer supported and scheduled for removal in the next major release.
3. Old implementation will be removed from the netconf git repository's master branch as soon as the 3.0.x stability branch for Sulfur is created -- i.e. March/April 2022.
4. 2022.09 Chlorine, due out in September 2022, will not include the old implementation.
Unless serious objections to this are raised by 2022-01-10 we will execute it exactly as outlined above.

No objections received up until now (~2 months after the dealine), this is the official plan of action.

Regards,
Robert

On 14/03/2022 17:46, Daniel de la Rosa wrote:

Hello TSC and all
Please let me know if you have any feedback on this proposal
https://wiki.opendaylight.org/display/ODL/Release+Schedule+for+Chlorine <https://wiki.opendaylight.org/display/ODL/Release+Schedule+for+Chlorine>

Ah, this is nice, but could you adjust the first column to contain links to Release Process requirements? that will make it easier for people unfamiliar with it to understand what means what.

From a quick glance it looks okay, except for the minor detail of me not attending the TSC call for the Middle Checkpoint :)

Regards,
Robert

On 10/03/2022 06:39, Daniel de la Rosa wrote:

Hello Robert and all
On Tue, Mar 8, 2022 at 12:58 PM Robert Varga <nite@... <mailto:nite@...>> wrote:
On 07/03/2022 17:00, Daniel de la Rosa wrote:
> Hello TSC and all
>
> We are going to code freeze Sulfur for all Managed Projects ( cut
and
> lock release branches ) on Monday March  14th at 10 am UTC
>
> Please remember that we only allow blocker bug fixes in release
branch
> after code freezes
 From MRI perspective, we are ... 5? ... months behind the
schedule. The
good news is that MDSAL-696, which was blocking yangtools-8 -> mdsal-9
integration is done and dusted.
Next steps are to integrate with:
- controller-5 (done unless maven-verify finds something)
- aaa-0.15 (should be a breeze)
- netconf-3 (not trivial, but the pieces should be mostly there)
- bgpcep-0.17 (not sure, if we pass this we should be okay overall)
As it stands, I expect the MRI projects to be ready to integrate on
Friday the 11th, with bgpcep-0.17 integration gating yangtools-8
release.
great news, so sounds like we can still move forward with Sulfur code freeze on 9/14 ...

so a day has passed, I am up for an update:
- there was a regression (YANGTOOLS-1407) detected in lispflow integration, that is taken care of
- https://git.opendaylight.org/gerrit/q/topic:sulfur-mri is started, with most of the patches in a reasonable shape
- of that, there are some prerequisites in OFP which can be merged --
and Sangwook already merged most of them
- there is a model-vs-code impedance in OFP, I will looking into that tomorrow -- either the code needs to be adjusted or the model, both are quite easy to do
- there is the same problem in lispflowmapping, I think I know the answer, but fired an email at Lori to confirm
- both netconf and bgpcep builds are passing to ~50% mark

The major outstanding item are the MD-SAL regressions detected in ovsdb (and same thing is biting netconf) and bgpcep, tracked as MDSAL-731 and MDSAL-735 respectivelly.

I believe they are manifestations on of a problem with the new RuntimeType code -- and seem to have a good idea as to what needs to be done. I am currently working on a prototype. In terms of progress, it needs a bit of work for a test drive, but so far the code challenges are asking all the right questions, AFAICT.

If all goes well, I should have a fix ready tomorrow, but I won't know until it's complete enough to face testing.

Regards,
Robert

_________________________________________________________________________________________________________________________

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.