Date
Attendees
- Dan Timoney
- 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.