Date   

Re: ODL modernization

Robert Varga
 

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 :(

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

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.

- 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.

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 :)

- 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.

Regards,
Robert


Re: [release] Sulfur code freeze

Robert Varga
 

On 13/04/2022 17:04, Daniel de la Rosa wrote:
Hello all,  any update on this? Sulfur integration test are still in bad shape
So we still do not have that ticket taken care of, but I realized we can work it around by changing the builders -- which we did and I spent today releasing MRI projects, which are now integrated.

I have kicked off an AR ahead of schedule here: https://jenkins.opendaylight.org/releng/job/autorelease-release-sulfur-mvn38-openjdk11/15/

It should complete just fine and the test results should come back in a much more reasonable shape -- most likely good enough to finally cut the branch.

Regards,
Robert

On Wed, Apr 6, 2022 at 4:04 PM Daniel de la Rosa via lists.opendaylight.org <http://lists.opendaylight.org> <ddelarosa0707=gmail.com@... <mailto:gmail.com@...>> wrote:
Great, thanks for the update.
On Wed, Apr 6, 2022 at 1:13 AM Robert Varga <nite@...
<mailto:nite@...>> wrote:
On 06/04/2022 01:21, Daniel de la Rosa wrote:
> Hello Robert and all
>
> it looks like we still have several issues
>
>
https://jenkins.opendaylight.org/releng/view/autorelease/job/integration-distribution-test-sulfur/190/
<https://jenkins.opendaylight.org/releng/view/autorelease/job/integration-distribution-test-sulfur/190/>

>
<https://jenkins.opendaylight.org/releng/view/autorelease/job/integration-distribution-test-sulfur/190/
<https://jenkins.opendaylight.org/releng/view/autorelease/job/integration-distribution-test-sulfur/190/>>
>
> are we still tracking some of these issues in jira tickets?
Yes, I think most of the issues are already fixed, but I am
waiting for
https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-23826
<https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-23826>
to issue the corresponding releases.
With the upgrade guide complete, I think we are good to branch,
though.
Ok it looks like @Anil Belur <mailto:abelur@...> is
still working on this issue so let's see if we can get an update shortly
Regards,
Robert


Re: ODL modernization

Guillaume Lambert
 

Hello Luis


Thanks for this feedback. I mostly share your concerns here at least about 2 and 3.

(about 1, I am not very involved in cloud use-cases and the situation is a bit different in core networks)


about 3)

We had some experience in tpce to use a combination of python tox + unittest + requests to develop blackbox testing suites for our REST APIs, mostly thanks to Cédric's guidance.
It might make sense for the infra tests too IMO.


My 2 cents


BR

Guillaume




De : TSC@... <TSC@...> de la part de Luis Gomez <ecelgp@...>
Envoyé : samedi 9 avril 2022 05:47
À : tsc
Objet : [OpenDaylight TSC] ODL modernization
 
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.

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.

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
- 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.
- Replace Karaf/OSGI framework with something more actual to plumb the java code and jars together (e.g. spring).

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).
- 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.
- 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.

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.
- Leverage K8s to do multi-application and scale testing.

BR/Luis




_________________________________________________________________________________________________________________________

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.


[tsc] Luis to proxy Anil on 14-04-2022

Anil Belur
 

Hello TSC members: 

I won't be able to attend the TSC call this week, Luis has agreed to be my proxy.

Cheers,
ab 


TSC Meeting for April 14, 2022 at 10 pm Pacific

Guillaume Lambert
 

Hello OpenDaylight Community,
 
The next TSC meeting is April 14, 2022 at 10 pm Pacific Time.
As usual, the agenda proposal and the connection details for this meeting are available in the wiki
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.


Re: [release] Sulfur code freeze

Daniel de la Rosa
 



Hello all,  any update on this? Sulfur integration test are still in bad shape



On Wed, Apr 6, 2022 at 4:04 PM Daniel de la Rosa via lists.opendaylight.org <ddelarosa0707=gmail.com@...> wrote:

Great, thanks for the update.

On Wed, Apr 6, 2022 at 1:13 AM Robert Varga <nite@...> wrote:
On 06/04/2022 01:21, Daniel de la Rosa wrote:
> Hello Robert and all
>
> it looks like we still have several issues
>
> https://jenkins.opendaylight.org/releng/view/autorelease/job/integration-distribution-test-sulfur/190/
> <https://jenkins.opendaylight.org/releng/view/autorelease/job/integration-distribution-test-sulfur/190/>
>
> are we still tracking some of these issues in jira tickets?

Yes, I think most of the issues are already fixed, but I am waiting for
https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-23826
to issue the corresponding releases.

With the upgrade guide complete, I think we are good to branch, though.

Ok it looks like @Anil Belur is still working on this issue so let's see if we can get an update shortly



Regards,
Robert


ODL modernization

Luis Gomez
 

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.

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.

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
- 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.
- Replace Karaf/OSGI framework with something more actual to plumb the java code and jars together (e.g. spring).

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).
- 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.
- 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.

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.
- Leverage K8s to do multi-application and scale testing.

BR/Luis


Re: TSC Meeting for April 7, 2022 at 9 am Pacific

Daniel de la Rosa
 

Hello all, 
Unfortunately I won't be able to make today's meeting. Sulfur RC is still pending so I'll follow up with  @Robert Varga via email once it is ready so I can setup a TSC approval form and start with Chlorine as soon as possible.

Thanks 

On Wed, Apr 6, 2022 at 2:13 AM <guillaume.lambert@...> wrote:

Hello OpenDaylight Community,
 
The next TSC meeting is April 7, 2022 at 9 am Pacific Time.
As usual, the agenda proposal and the connection details for this meeting are available in the wiki
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.

I take the opportunity to publicly congratulate our new TSC members Manoj & Ivan & Cédric.
And also to thank Luis & Navid & Oleksii for their commitment.
 
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.


Re: [release] Sulfur code freeze

Daniel de la Rosa
 

Great, thanks for the update.

On Wed, Apr 6, 2022 at 1:13 AM Robert Varga <nite@...> wrote:
On 06/04/2022 01:21, Daniel de la Rosa wrote:
> Hello Robert and all
>
> it looks like we still have several issues
>
> https://jenkins.opendaylight.org/releng/view/autorelease/job/integration-distribution-test-sulfur/190/
> <https://jenkins.opendaylight.org/releng/view/autorelease/job/integration-distribution-test-sulfur/190/>
>
> are we still tracking some of these issues in jira tickets?

Yes, I think most of the issues are already fixed, but I am waiting for
https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-23826
to issue the corresponding releases.

With the upgrade guide complete, I think we are good to branch, though.

Ok it looks like @Anil Belur is still working on this issue so let's see if we can get an update shortly



Regards,
Robert


TSC Meeting for April 7, 2022 at 9 am Pacific

Guillaume Lambert
 

Hello OpenDaylight Community,
 
The next TSC meeting is April 7, 2022 at 9 am Pacific Time.
As usual, the agenda proposal and the connection details for this meeting are available in the wiki
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.

I take the opportunity to publicly congratulate our new TSC members Manoj & Ivan & Cédric.
And also to thank Luis & Navid & Oleksii for their commitment.
 
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.


Re: [release] Sulfur code freeze

Robert Varga
 

On 06/04/2022 01:21, Daniel de la Rosa wrote:
Hello Robert and all
it looks like we still have several issues
https://jenkins.opendaylight.org/releng/view/autorelease/job/integration-distribution-test-sulfur/190/ <https://jenkins.opendaylight.org/releng/view/autorelease/job/integration-distribution-test-sulfur/190/>
are we still tracking some of these issues in jira tickets?
Yes, I think most of the issues are already fixed, but I am waiting for https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-23826 to issue the corresponding releases.

With the upgrade guide complete, I think we are good to branch, though.

Regards,
Robert


Re: [release] Sulfur code freeze

Daniel de la Rosa
 



On Fri, Apr 1, 2022 at 4:11 PM Robert Varga <nite@...> wrote:
On 31/03/2022 17:41, Robert Varga wrote:
> Alright, everything has been merged up.
>
> int/dist and autorelease need to have their jobs updated to use
> maven-3.8, please review the patches here:
>
> https://git.opendaylight.org/gerrit/c/releng/builder/+/100304
> https://git.opendaylight.org/gerrit/c/releng/builder/+/100306
>
> I am writing up the release notes and upgrade guide next.

So looking at
https://jenkins.opendaylight.org/releng/job/integration-distribution-test-sulfur/185/
we have plenty of badness.

The core problem is that a ton of test suites are depending on
OPERATIONAL_API, which points to old RESTCONF, which is no longer
installed by default. I have
https://git.opendaylight.org/gerrit/c/releng/builder/+/100359 to install
it for now, but we need to eventually (very soon) ditch it.

Luis, any idea on how to fix that in a sensible manner?

Also, RF is now reporting a ton of ugly 'Keyword 'BuiltIn.Run Keyword
Unless' is deprecated.' messages -- I'll take a peek next week unless
somebody beats me to it.

Finally, I am tracking two regressions in MD-SAL (already fixed) and one
in NETCONF (next on the list), but I'd like to get a better reading on
CSIT before rolling out the corresponding releases out.


Hello Robert and all 

it looks like we still have several issues
 

are we still tracking some of these issues in jira tickets? 
 

Regards,
Robert


2022 TSC Chairperson Election

Casey Cain
 

The self-nomination period for OpenDaylight TSC Chairperson is now open.  The role of the TSC Chair is to lead the TSC through meetings and discussions on relevant topics.  This election and nomination process is limited to TSC Members.  Any TSC Member can nominate themselves, run for election, and vote in the election for the TSC Chair.

The self-nomination period will be from  to  .  Interested TSC members may self-nominate here:  https://wiki.opendaylight.org/x/mG8EAQ

Please let me know if you have any questions.

Best,
Casey Cain
Senior Technical Community Architect
Linux Foundation
_________________
WeChat: okaru6
WhatsApp: +1.503.779.4519


2022 OpenDaylight TSC Election Results

Casey Cain
 

Please join me in congratulating the winners of the 2022 ODL TSC Election
  • Robert Varga
  • Ivan Hrasko
  • Manoj Chokka
  • Venkatrangan Govindarajan
  • Guillaume Lambert
  • Cedric Olivier
  • Anil Belur
We look forward to their leadership in the OpenDaylight Community!  I would also like to thank the outgoing TSC members.  Luis Gomez, Navid Ghazisaidi, and Oleskii Mozghovyi.  Your contributions to the community have been greatly appreciated and we hope you continue to support the community in the future.


Best,
Casey Cain
Senior Technical Community Architect
Linux Foundation
_________________
WeChat: okaru6
WhatsApp: +1.503.779.4519


Re: [release] Sulfur code freeze

Robert Varga
 

On 31/03/2022 17:41, Robert Varga wrote:
Alright, everything has been merged up.
int/dist and autorelease need to have their jobs updated to use maven-3.8, please review the patches here:
https://git.opendaylight.org/gerrit/c/releng/builder/+/100304
https://git.opendaylight.org/gerrit/c/releng/builder/+/100306
I am writing up the release notes and upgrade guide next.
So looking at https://jenkins.opendaylight.org/releng/job/integration-distribution-test-sulfur/185/ we have plenty of badness.

The core problem is that a ton of test suites are depending on OPERATIONAL_API, which points to old RESTCONF, which is no longer installed by default. I have https://git.opendaylight.org/gerrit/c/releng/builder/+/100359 to install it for now, but we need to eventually (very soon) ditch it.

Luis, any idea on how to fix that in a sensible manner?

Also, RF is now reporting a ton of ugly 'Keyword 'BuiltIn.Run Keyword Unless' is deprecated.' messages -- I'll take a peek next week unless somebody beats me to it.

Finally, I am tracking two regressions in MD-SAL (already fixed) and one in NETCONF (next on the list), but I'd like to get a better reading on CSIT before rolling out the corresponding releases out.

Regards,
Robert


Re: [release] Sulfur code freeze

Daniel de la Rosa
 

Thanks Robert... 

On Thu, Mar 31, 2022 at 8:41 AM Robert Varga <nite@...> wrote:
On 31/03/2022 01:20, Robert Varga wrote:
> On 29/03/2022 01:13, Robert Varga wrote:
>> On 28/03/2022 00:10, Robert Varga wrote:
>>> On 24/03/2022 01:24, Daniel de la Rosa wrote:
>>>>
>>>>
>>>> On Wed, Mar 23, 2022 at 3:47 PM Robert Varga <nite@...
>>>> <mailto:nite@...>> wrote:
>>>> That’s impressive. Ok thanks and it is all good. We will have a very
>>>> solid sulfur release
>>>
>>> A quick update here. We are on the home stretch now, with 31
>>> callsites still being bad. About a third are duplicate (e.g. they are
>>> the same weirdness across bierman20/rfc8040). They will need some
>>> amount of TLC, which I am not in position to give right now, sorry :(
>>
>> Okay, so I am down to 3 call sites, which fall into two categories:
>>
>> 1. old RESTCONF's URI parser leafref support. I think I can perform
>> sufficient surgery to make this work without having to rewrite that
>> thing (as was done for new RESTCONF, where this is a breeze)
>>
>> 2. two instances of a weird interaction with XML codec. It is not that
>> weird, I understand what is going on, it just needs a bit of more work.
>>
>> I will need another day to deal with them and, fingers crossed, UTs
>> should agree.
>
> This is now cleared, netconf-3.0.0 is out there. Most of the MSI update
> patches are done -- except openflowplugin.
>
> Upgraded spotbugs is finding some badness which was introduced in
> https://git.opendaylight.org/gerrit/c/openflowplugin/+/91313 and I need
> to figure out how to fix it.
>
> BGPCEP still has a four contributions left for review, I will take care
> of that tomorrow.

Alright, everything has been merged up.

int/dist and autorelease need to have their jobs updated to use
maven-3.8, please review the patches here:

https://git.opendaylight.org/gerrit/c/releng/builder/+/100304
https://git.opendaylight.org/gerrit/c/releng/builder/+/100306

I am writing up the release notes and upgrade guide next.


Ok great. @Anil Belur and/or @Luis Gomez  maybe you can take a look at this 

 

Bye,
Robert


Re: [release] Sulfur code freeze

Robert Varga
 

On 31/03/2022 01:20, Robert Varga wrote:
On 29/03/2022 01:13, Robert Varga wrote:
On 28/03/2022 00:10, Robert Varga wrote:
On 24/03/2022 01:24, Daniel de la Rosa wrote:


On Wed, Mar 23, 2022 at 3:47 PM Robert Varga <nite@... <mailto:nite@...>> wrote:
That’s impressive. Ok thanks and it is all good. We will have a very solid sulfur release
A quick update here. We are on the home stretch now, with 31 callsites still being bad. About a third are duplicate (e.g. they are the same weirdness across bierman20/rfc8040). They will need some amount of TLC, which I am not in position to give right now, sorry :(
Okay, so I am down to 3 call sites, which fall into two categories:

1. old RESTCONF's URI parser leafref support. I think I can perform sufficient surgery to make this work without having to rewrite that thing (as was done for new RESTCONF, where this is a breeze)

2. two instances of a weird interaction with XML codec. It is not that weird, I understand what is going on, it just needs a bit of more work.

I will need another day to deal with them and, fingers crossed, UTs should agree.
This is now cleared, netconf-3.0.0 is out there. Most of the MSI update patches are done -- except openflowplugin.
Upgraded spotbugs is finding some badness which was introduced in https://git.opendaylight.org/gerrit/c/openflowplugin/+/91313 and I need to figure out how to fix it.
BGPCEP still has a four contributions left for review, I will take care of that tomorrow.
Alright, everything has been merged up.

int/dist and autorelease need to have their jobs updated to use maven-3.8, please review the patches here:

https://git.opendaylight.org/gerrit/c/releng/builder/+/100304
https://git.opendaylight.org/gerrit/c/releng/builder/+/100306

I am writing up the release notes and upgrade guide next.

Bye,
Robert


Re: [release] Sulfur code freeze

Robert Varga
 

On 29/03/2022 01:13, Robert Varga wrote:
On 28/03/2022 00:10, Robert Varga wrote:
On 24/03/2022 01:24, Daniel de la Rosa wrote:


On Wed, Mar 23, 2022 at 3:47 PM Robert Varga <nite@... <mailto:nite@...>> wrote:
That’s impressive. Ok thanks and it is all good. We will have a very solid sulfur release
A quick update here. We are on the home stretch now, with 31 callsites still being bad. About a third are duplicate (e.g. they are the same weirdness across bierman20/rfc8040). They will need some amount of TLC, which I am not in position to give right now, sorry :(
Okay, so I am down to 3 call sites, which fall into two categories:
1. old RESTCONF's URI parser leafref support. I think I can perform sufficient surgery to make this work without having to rewrite that thing (as was done for new RESTCONF, where this is a breeze)
2. two instances of a weird interaction with XML codec. It is not that weird, I understand what is going on, it just needs a bit of more work.
I will need another day to deal with them and, fingers crossed, UTs should agree.
This is now cleared, netconf-3.0.0 is out there. Most of the MSI update patches are done -- except openflowplugin.

Upgraded spotbugs is finding some badness which was introduced in https://git.opendaylight.org/gerrit/c/openflowplugin/+/91313 and I need to figure out how to fix it.

BGPCEP still has a four contributions left for review, I will take care of that tomorrow.

Regards,
Robert


2022 Mentorship Program - Call for Mentors

Casey Cain
 

Today, we’re excited to open the call for mentors and project proposals for the 2022 LF Networking Mentorship ProgramThe Program is intended to provide a formal structure to connect mentors and student developers from around the globe to contribute their enthusiasm, time, and experience toward building sustainable LFN communities.

 Why should you consider mentoring for LF Networking Mentorship Program?
  • You believe in the value of mentorship in helping new developers to navigate open source development, the culture, the tooling and infrastructure to be a productive members of the community.  
  • You are passionate about teaching and guiding student developers, many of whom may be first time open-source contributors, 
  • You are eager to bring new perspectives, new ideas, and new talent into your community and projects.
  • You have a narrowly scoped mentorship project with clear learning objectives/outcomes and a mentee's work and potential contributions could add value to the project or community of which you're an active developer or maintainer.     
 I am interested in mentoring but how do I get started? 
What are the elements the LFN Mentorship Program will implement to maximize mentor/mentee collaboration success?
  • Mentor and mentee onboarding will be conducted at the start of the Program
  • Project planning that includes deliverables, milestones, and tasks will be completed collaboratively between the mentors and mentees during the first two weeks of the program and posted on the wiki to increase transparency and accountability.
  • Mentee presentations will be required to sharpen both presentation skills and to cultivate the ability to provide constructive feedback and critique that’s the norm in the open source community for developing technologies collaboratively and openly.
  • Mentee evaluation will be conducted on a regular cadence tied to milestone deliverable schedules to help mentors and LFN staff formalize and respond to progress.
While mentors will be on a voluntary basis, the hired mentees will be eligible to receive a stipend. As an added bonus, each mentee who successfully completes the Program will be invited and financially sponsored by LF Networking to attend an event/conference and present their work to the broader community (specific event TBD but will be during Q3 or Q4 of this year or Q1 of the following year).

If you have any questions, please contact mentorship@lfnetworking.org

We look forward to your submission of a mentorship project and thank you in advance for volunteering your time to contribute to the training of the new talent pool in the LF Networking communities.

Best,
Casey Cain
Senior Technical Community Architect
Linux Foundation
_________________
WeChat: okaru6
WhatsApp: +1.503.779.4519


TSC Meeting for March 31, 2022 at 10 pm Pacific

Guillaume Lambert
 

Hello OpenDaylight Community,
 
The next TSC meeting is March 31, 2022 at 10 pm Pacific Time.
As usual, the agenda proposal and the connection details for this meeting are available in the wiki
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.

221 - 240 of 14351