_________________________________________________________________________________________________________________________

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.

Hey everyone, especially those working on ODL
We are currently transitioning to JDK17 as part of Chlorine MRI bump.
Unfortunately we are at this point 11 days past the deadline, so things are moving quickly. The reason for that is because JDK17 is giving us https://openjdk.java.net/jeps/409 Sealed Classes.

Sealing an abstract class or an interface is, strictly speaking, an API-breaking change. While it does not break users per se, it can break them in two cases:
- they are using switch expressions, in which case making a class sealed can expose the user to new exhaustiveness checks: suddenly a switch expression may become exhaustive without a 'default' branch superfluous and unreachable (which is good) causing a build failure (which is bad)
- they are mocking or otherwise creating new subclasses/implementations of sealed classes/interfaces.

Hence this work needs to occur in parallel, which unfortunately also inflicts an autorelease-like dev experience on people working on breaking edge MRI.

Most of the breaking stuff is in, but nevertheless there may be times when your (or jenkins.odl) build breaks. If that happens, please retry with 'mvn -U' to get latest snapshots. If it's jenkins or -U does not help, please ping me -- I am trying to keep up with this, but there will be things I miss.

I expect things to begin to settle down in about a week, with ETA to normal integration being a week after that. I'll keep you posted here.

At the moment this pertains to odlparent, yangtools, mdsal and controller, all of which require JDK17 to build. infrautils is joining the party soon. aaa, netconf and bgpcep will follow.

Sorry about the inconvenience,
Robert

On 15/04/2022 02:23, Daniel de la Rosa wrote:

Anyhow, Integration test for AR#15 still has some issues
https://jenkins.opendaylight.org/releng/job/integration-distribution-test-sulfur/200/ <https://jenkins.opendaylight.org/releng/job/integration-distribution-test-sulfur/200/>
Should we just move forward like this?

So we have latest AR here: https://jenkins.opendaylight.org/releng/job/autorelease-release-sulfur-mvn38-openjdk11/29/

Triggered by Sangwook, because the previous run failed. We can expect AR #30 in ~4 hours and test results from that in another ~3 hours.

Based on the results of https://jenkins.opendaylight.org/releng/view/autorelease/job/integration-distribution-test-sulfur/219/, the release is GO from my perspective.

There seem to be OFP issues, though, I think Sangwook has the final say.

On the BGPCEP side of things, we have two failures:
1. one of them is a BGP policy 409, which I need to investigate, but I do not believe it's anything major
2. BGP ingest is plagued by https://jira.opendaylight.org/browse/CONTROLLER-2043, but I honestly think this is an environment issue

At any rate, looking at the schedule, we are *way* past the release date and in fact should be releasing Sulfur SR1 on 4/28, i.e. in two days.

I think we should just release as is, get the marketing stuff out, etc. and circle back for SR1 -- say, in two weeks. That would give us a few days of breathing time (I know I need some) and see what's what.

We also are ~2 weeks past the Chlorine MRI bump, so that switching gears makes a ton of sense -- I really want Chlorine to get us back on track with the calendar :)

Regards,
Robert

On 15/03/2022 18:44, Robert Varga wrote:

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:

[snip]

4. 2022.09 Chlorine, due out in September 2022, will not include the old implementation.

The old implementation is no longer present in netconf/master, hence this item is slated for delivery in 2022.09 Chlorine.

Regards,
Robert

On 25/09/2021 00:00, Robert Varga wrote:

Hello everyone,

Hello again,

as you might have noticed, Java 17 has been released: https://jdk.java.net/17/ with reference implementation here: https://jdk.java.net/java-se-ri/17

[snip]

IIUC, there are only a few issues which prevents us from adopting JDK 17 as a requirement:
- maven-xtend-plugin compatibility (due to Guice, what a surprise), which should be solved in 2.26.0, whenever that is available
- SpotBugs compatibility, which should be addressed in 4.4.x series

These issues have been addressed.

With all this in picture, I believe the proper course in OpenDaylight is to have:
- Sulfur (22.03) supporting both JDK11 and JDK17 at compile-time, with artifacts compatible with JDK11+
- All of Sulfur being validated with JDK17

Both these items are delivered, all projects participating on Sulfur GA verify each patch with both JDK11 and JDK17.

- Chlorine (22.09) to require JDK17+

This is now slated for delivery: odlparent/master and yangtools/master both require JDK17 and are taking advantage of JDK17 features. More projects are slated to follow.

Regards,
Robert

On 22/04/2022 10:11, Anil Belur wrote:

+1 We should be able switch to CentOS8 for the jobs that require JDK17, but there could be a few caveats that we should consider before we move the rest of the builders nodes.
Sigul (artifact signing) is built on CentOS7 and may not be compatible when we try to sign artifact on CentOS8.

Hmm, that would be a major problem and really soon. Sigul is part of stage jobs -- stage i.e. build + sign. We are exactly 2 patches away from odlparent/master requiring JDK17 to build -- and that just does not work on CentOS7.

We need either Sigul+CentOS8 or JDK17+CentOS7. The former is obviously the preferred solution.

Or, we need decoupling of stage's build and sign steps in a reliable manner -- which would really call for Jenkins Pipelines, but we have not even dipped our toes in that particular ocean...

Regards,
Robert

On Thu, Apr 21, 2022 at 9:14 AM Robert Varga <nite@... <mailto:nite@...>> wrote:
Hello everyone,
we are currently defaulting to centos7-builder-4c-4g here:
https://github.com/opendaylight/releng-builder/blob/master/jjb/defaults.yaml#L19=
<https://github.com/opendaylight/releng-builder/blob/master/jjb/defaults.yaml#L19=>
CentOS7 is ancient and cannot support our releases going forward, as it
lacks JDK17 -- which is scheduled to be required for Chlorine.
MRI projects have already switched to CentOS (Stream) 8, like here:
https://github.com/opendaylight/releng-builder/blob/master/jjb/netconf/netconf.yaml#L17=
<https://github.com/opendaylight/releng-builder/blob/master/jjb/netconf/netconf.yaml#L17=>
That having been said and provided we get a fix for
https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-23826
<https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-23826>,
I propose we switch the default build node to CentOS 8 and deal with
whatever fallout -- probably in June, as that is essentially quiet with
only Chlorine prep on the table.
Whaddya say?
Thanks,
Robert

LGTM, any change for updating current infra is +1 for me :)

> On Apr 20, 2022, at 4:14 PM, Robert Varga <nite@...> wrote:
>
> Hello everyone,
>
> we are currently defaulting to centos7-builder-4c-4g here: https://github.com/opendaylight/releng-builder/blob/master/jjb/defaults.yaml#L19=
>
> CentOS7 is ancient and cannot support our releases going forward, as it lacks JDK17 -- which is scheduled to be required for Chlorine.
>
> MRI projects have already switched to CentOS (Stream) 8, like here: https://github.com/opendaylight/releng-builder/blob/master/jjb/netconf/netconf.yaml#L17=
>
> That having been said and provided we get a fix for https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-23826, I propose we switch the default build node to CentOS 8 and deal with whatever fallout -- probably in June, as that is essentially quiet with only Chlorine prep on the table.
>
> Whaddya say?
>
> Thanks,
> Robert
>
>
>
>
>

LGTM, any change for updating current infra is +1 for me :)

Hello everyone,

we are currently defaulting to centos7-builder-4c-4g here: https://github.com/opendaylight/releng-builder/blob/master/jjb/defaults.yaml#L19=

CentOS7 is ancient and cannot support our releases going forward, as it lacks JDK17 -- which is scheduled to be required for Chlorine.

MRI projects have already switched to CentOS (Stream) 8, like here: https://github.com/opendaylight/releng-builder/blob/master/jjb/netconf/netconf.yaml#L17=

That having been said and provided we get a fix for https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-23826, I propose we switch the default build node to CentOS 8 and deal with whatever fallout -- probably in June, as that is essentially quiet with only Chlorine prep on the table.

Whaddya say?

Thanks,
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 Apr 14, 2022, at 3:20 PM, Robert Varga <nite@...> wrote:



On 09/04/2022 05:47, Luis Gomez wrote:

Hi TSC ex-colleagues,
As I promised, here is a list of topics for ODL modernization. This is all that came to my mind now but it could be more, the goal here is really to trigger some brainstorm and discussion.
1) Use cases:
Our YANG based platform made it easy for ODL to become the SDN controller of choice for HW devices supporting NETCONF and other control protocols like BGP-LS, PCEP, OPENFLOW where multi-vendor is important. However it made it hard to have a role in the cloud where YANG and protocols like NETCONF, BGP-LS, PCEP are almost not existent and multi-vendor is not that important. Now, given the amount of money and effort that is currently put in the cloud, it would make sense for ODL to at least participate in some cloud use case. For example, I believe ODL can still play some role in the hybrid cloud use case where HW devices need to talk to cloud devices, ODL could take care of the HW devices while another open source controller could take care of the cloud devices.

Strictly speaking: we already do, but through external integrations and those bring very little in terms of engagement/contributions :(

OK, then maybe it will help some marketing and/or white paper if anyone knows about these use cases in more detail :)

2) SW Platform:
The OSGI/Karaf platform was state-of-the-art 10 years back where there was no real micro-services platforms like K8s, but now it is just obsolete. In the new paradigm of micro-services, applications are loose-coupled and they are mostly self-contained (e.g. run their own processes within a container) although they can share some common resources like a database, a message broker, an API gateway, etc.

Weeeeeeeeeell. I could *very easily* sell you OSGi as:
- the original Java micro-service platform
- the current Java nano-service platform

Fair enough, I did not explained well myself, Java nano-service is still required but nowadays you can balance between java nano-service and container micro-service so with both at hand you can cover very much do anything you want. I think what we miss the most is infrastructure and devops work for container micro-services.

Also JPMS re-creates a (miserable) subset of OSGi. But that really is semantics, so let's not get distracted here.

OSGi is just another runtime. It always has been where ODL architectural principles are considered. Unfortunately some projects require it as a core dependency -- just because they did not know better at the time that code was merged. There has been some very solid work done over the past ~2 years to remove those assumptions.

What remains, though, is that OSGi+Karaf is the only thing that is seriously integrated *and tested*. Your next comments and my responses need to be considered with regard to this simple truth.

For ODL to fit in the new paradigm, we would need to:
- Replace ODL distribution with ODL applications that can run in their own container: NETCONF, BGP, PCEP, TPCE, etc

Agree. That is a packaging exercise. From the get go, we can (mostly, with notable exception of PCEP right now) do whatever you'd like... more below.

- Consolidate kernel repos and jars: Existing ODL applications share a common code called kernel. Today we have ~6 repositories and a bunch of jars for the kernel where there is a single person/organization maintaining the code.

Yeah, no. As the person referenced in that sentence, I have to say that the each repo (and project) has a rather well-defined scope -- as per our governance. It also keeps a reasonable straight-jacket on what is done and how.

Merging the repos would throw us back ~9 years when controller.git contained all of yangtools, mdsal, netconf, adsal, the works. It would also lower to guards we have against layering/design violations.

One example I can quote here is https://git.opendaylight.org/gerrit/c/openflowplugin/+/91313 -- that patch should have never been approved and it was upgraded SpotBugs which eventually found it. It took three days to correct -- not something we want to do if long-term maintainability is our goal.

Well, this consolidation idea was to ease the development and release work of the kernel components, but if maintainers of the code prefer the way it is today, I am totally cool with that :)

- Replace Karaf/OSGI framework with something more actual to plumb the java code and jars together (e.g. spring).

Right, and odlmicro just dropped the ball here in more than one way :(

The long-term plan here is to have OSGi DS annotations and a reasonable DI framework for static deployments. In this regard Blueprint is one of the worst decisions we have ever made.

In terms of "reasonable framework":

1. we have static Karaf fully supported, but per-use-case packaging has not been appearing. This is easy pickings most of the time: create a static karaf, put into a docker (or whathever) and you are done. It is a no-frills solution, boot time is at ~30% of what dynamic Karaf is.

2. odlmicro is moribund. Contributors are welcome, but if those do not step forward, https://github.com/PANTHEONtech/lighty is very much an alternative, which is not readily integratable into individual projects :(

3. what we *really* want to do is Dagger. That's pretty much the gold standard in Android apps, completely compile-time, all that jazz. While we have the basics ready in some places, noone has prototyped anything reasonable with it.

At this point, I think the idea behind odlmicro should be supplanted by a single goal: make everthing wireable via Dagger and provide a Dagger-based equivalent of netconf.git/static/pom.xml to get that use case up and running.

I may be wrong but I do not think anybody is after odlmicro nowadays. Anyway to me the problem Karaf/OSGI is not that much the boot time (option 1) but the usability and adoption aspect, developers like to write code in modern and well adopted platforms.

3) Infrastructure:
Here is kind of obsolete too. Some ideas to renew the build and test infrastructure:
Build pipeline:
- Move from JJB (not maintained anymore) to Jenkins pipelines or similar (work is ongoing).

Yeah, that's the idea, but I am not aware of anyone actively working on this.

- Move to a continuous release process where a merge in master produces a new release in the artifact repository (staging). This simplifies a lot the release process: just move artifacts from staging to release repository.

This ties in with your comment about consolidating repos. Rather that that, I wish we just had a reasonable infra to automatically release on patch merge -- including version bumps, CSIT validation, proper git history (which we do not have), all that jazz.

There is just no way I can over-sell this -- this is the core piece of automation we are missing. Requires some real DevOps folks, which we seem to be in short supply of these days.

- Every ODL application (NETCONF, BGP, PCEP, TPCE, etc) should generate a container automatically after a merge in master. We should be testing this vs ODL distribution.

Right, and we are building towards this. I think NETCONF is *almost* there, but I am not sure. This is a prerequisite to having maven-stage jobs executing CSIT prior to allowing release, which ties in to the previous point.

System test:
- Robot was the best open source system test framework 10 years back where organizations had developers and system engineers separated. Things have changed a lot since and many agile organizations nowadays have developers doing system integration and system test code apart from writing product features. Robot framework is good for system integrators with basic or non coding skills but bad for developers that have to ramp up in a new language that soon find very limiting. This is why I think at this moment it would be good to switch to something like pytest for example.

Yes.

At the end of the day, CSIT must be completely owned by the project it is testing and it must be reasonably maintainable. Neither int/test organization (we still carry SXP tests?!) nor RF fulfill (please point me to a reasonable IDE, can you?) that criteria :)

IMO int/test should be simply testing 1) non functional aspects like scale, security, etc 2) multiple applications together (not sure if this still makes sense), and 3) hosting common test libraries.

- Leverage K8s to do multi-application and scale testing.

I think int/packaging some overhaul here. At the end of the day, the first use case we need to have is a Docker (or whatever, I don't care) based on netconf.git/static being packaged as part of netconf-maven-merge job. I have no idea what we need to make that happen, though.

Work is ongoing but very slow due to lack of bandwidth contribution. So far we managed to create the infrastructure for dockers and some partial support for helm charts but there is still the work of getting containers down to some projects (not all need docker) and finalize the helm infrastructure work.

Regards,
Robert

On 15/04/2022 00:20, Robert Varga wrote:

- Leverage K8s to do multi-application and scale testing.

I think int/packaging some overhaul here. At the end of the day, the first use case we need to have is a Docker (or whatever, I don't care) based on netconf.git/static being packaged as part of netconf-maven-merge job. I have no idea what we need to make that happen, though.

Just to qualify this end-to-end in terms of the NETCONF/RESTCONF pass-through case.

netconf-maven-stage-master should produce a container containing the use-case, using whatever runtime (dynamic Karaf, static Karaf, Guice, Dagger, it does not matter.

netconf.git-hosted CSIT should combine that with a Helm chart on the LFIT-K8S-implementation-du-jour. Run netconf.git-hosted CSIT on that. ~80% of int/test infra is not in the picture.

If it passes, netconf-maven-release-merge is good to go and should run automatically (and lock the branch, bump versions, tag the release, all that jazz). No committer intervention necessary.

Once that completes, downstream projects should realize "hey, there is an upgraded upstream, perhaps I need to release with what I have", go through exactly the same process, rinse&repeat until you hit an autorelease project.

And then the question arises: why do we have autorelease and cannot just publish int/dist release based on this pipeline to Maven Central? :)

So ... what is up for getting their hands dirty?

Regards,
Robert