ONAP/ODL Collaboration Meeting notes 2020-05-19
Date
May 19, 2020
Attendees
@Casey Cain
@Abhijit K
@Daniel De La Rosa
Dan Timoney
Atta Zabihi
Ruchira Agarwal
Rich T
Luis Gomez
Jamo Luhrsen
Topics
How should we handle releases?
ONAP is currently working on their Guilin Release Planning and will be ready in June.
Jamo suggested that SR1 would be a good point for alignment.
Dan mentioned that there was not an upgrade to ODL in the Frankfurt release. They are currently using the Neon release.
Jamo suggested adopting Magnesium.
Dan thinks that ONAP will not want to skip over Sodium.
Carriers that are using ONAP are using a vendor-supported version of ODL.
They tend to lag a little bit
Luis noted that perhaps they will have time by June to target the Magnesium which has already been released
If they want to stay with Sodium. It may make sense to use SR3 which will have some important updates. It should be available in 2 weeks.
Luis suggested that it is important to try to address the release gap to adopt important feature changes in ODL such as the Java 11 migration.
Abhijit also suggests the move to Magnesium as the delta in Magnesium is comparatively less.
Dan we don't import a lot of classes from ODL to make sure there are no issues with incompatibilities that could arise with their own dependencies.
Also looking to avoid strict adherence to YANG reference models.
Jamo asked how the team was bypassing some core features of ODL
Dan explained that they were only really using the MD-SAL portion of ODL.
ONAP team is still deciding which release they want to use. Sodium SR2/3.
We need to be able to support multiple versions of the release for vendors who are not leveraging the latest release.
Jamo suggested we could possibly do an SR4 version of Sodium to better support the ONAP community.
Or we can hold the release of SR3 to mid-July?
There was a question about etcd instead of MD-SAL
Jamo noted that the effort has stalled because of a lack of resources. However, we do have an ODL Micro Project that is under development.
There was a follow-up question about dynamic joining and leaving of the cluster
There is a method for doing it, but it currently isn't well tested or documented.
Jamo will follow up and update Rich T on the next call
Meeting time
The meeting is currently scheduled for once per month but we could make it every 2 weeks.
Dan: It makes sense to keep it monthly at this time.