1. TSC@lists.opendaylight.org
  2. Messages
   Date   
Re: TSC Meeting Minutes Jan 9, 2020

TIMONEY, DAN
 

Thanks – I just subscribed to the TSC mailing list

 

From: Abhijit Kumbhare <abhijitkoss@...>
Date: Thursday, January 16, 2020 at 2:05 AM
To: Luis Gomez <ecelgp@...>
Cc: Robert Varga <nite@...>, "TIMONEY, DAN" <dt5972@...>, "FREEMAN, BRIAN D" <bf1936@...>, tsc <tsc@...>, "LEFEVRE, CATHERINE" <catherine.lefevre@...>, Daniel De La Rosa <ddelarosa@...>
Subject: Re: [OpenDaylight TSC] TSC Meeting Minutes Jan 9, 2020

 

Approved. However I have requested Brian and Dan to subscribe to the TSC mailing list to avoid the need to manually approve each message. 

 

On Wed, Jan 15, 2020 at 4:22 PM Luis Gomez <ecelgp@...> wrote:

FYI it looks like folks are not getting the messages in this thread, so if anyone is moderator for TSC channel please approve pending messages.

> On Jan 15, 2020, at 12:29 PM, Robert Varga <nite@...> wrote:
>
> On 15/01/2020 20:51, TIMONEY, DAN wrote:
>> As for doing an upgrade mid release, that would be a major issue for us.  In ONAP, SDKs (including CCSDK -which is where the ODL port is done) are required to provide stable release artifacts at API freeze (M3) - about 4-6 weeks prior to code freeze.  So, a mid release upgrade would be risky - especially since we know from experience that SRs often include breaking changes.
>
> Understood. I am by no means implying that we do not break things,
> because we do and sometimes we do not even know. Sorry for the wall of
> text that follows.
>
> Given that both projects are on a 6-month schedule and we do have the
> ability to do cross-project CI, we should be able to engage much earlier
> so that a supported ONAP release is backed by a supported ODL release.
>
> Based on my current understanding, the best we can strive for is to make
> sure that Dan has a fully-vetted fresh ODL SR1 by the time he has to
> commit to it.
>
> That does include committing resources on his part and do a non-trivial
> amount of work, so we need to maximize the time window for this activity.
>
> From ODL perspective, the dates and the process for Magnesium are:
> -
> https://docs.opendaylight.org/en/latest/release-process/release-schedule.html
> -
> https://docs.opendaylight.org/en/latest/release-process/managed-release.html
>
> 1) we are entering code freeze on 2020-02-03, at which point we will
> start picking a release candidate
>
> 2) code is being stabilized for 3-4 weeks to address any identified
> issues blocking the release (i.e. regressions)
>
> 3) on 2020-02-17 we release GA for release activities, with branches
> unlocking as soon they are done
>
> 4) on 2020-03-09 the release is GA
>
> 6) on 2020-04-13 stable/magnesium will be locked down pending SR1 release
>
> 5) on 2020-04-20 we will release SR1
>
> If the current process is such that CCSDK is not considering anything
> before SR1, we are losing roughly 8 to 11 weeks engagement time during
> which the ODL community is most focused on identifying and fixing issues
> with the release.
>
> Once SR1 is done, our focus is shifting on the next release (which is
> already open for 8 weeks).
>
> It feels like all we need is to make sure your 6-month release template
> and ours are shifted by the right number of weeks in a given calendar year.
>
> If we have that, we can have inter-project CI/CD kick in at the right
> time to drive the process, too. :)
>
> Regards,
> Robert
>
>

Re: TSC Meeting Minutes Jan 9, 2020

Abhijit Kumbhare
 

Approved. However I have requested Brian and Dan to subscribe to the TSC mailing list to avoid the need to manually approve each message. 

On Wed, Jan 15, 2020 at 4:22 PM Luis Gomez <ecelgp@...> wrote:
FYI it looks like folks are not getting the messages in this thread, so if anyone is moderator for TSC channel please approve pending messages.

> On Jan 15, 2020, at 12:29 PM, Robert Varga <nite@...> wrote:
>
> On 15/01/2020 20:51, TIMONEY, DAN wrote:
>> As for doing an upgrade mid release, that would be a major issue for us.  In ONAP, SDKs (including CCSDK -which is where the ODL port is done) are required to provide stable release artifacts at API freeze (M3) - about 4-6 weeks prior to code freeze.  So, a mid release upgrade would be risky - especially since we know from experience that SRs often include breaking changes.
>
> Understood. I am by no means implying that we do not break things,
> because we do and sometimes we do not even know. Sorry for the wall of
> text that follows.
>
> Given that both projects are on a 6-month schedule and we do have the
> ability to do cross-project CI, we should be able to engage much earlier
> so that a supported ONAP release is backed by a supported ODL release.
>
> Based on my current understanding, the best we can strive for is to make
> sure that Dan has a fully-vetted fresh ODL SR1 by the time he has to
> commit to it.
>
> That does include committing resources on his part and do a non-trivial
> amount of work, so we need to maximize the time window for this activity.
>
> From ODL perspective, the dates and the process for Magnesium are:
> -
> https://docs.opendaylight.org/en/latest/release-process/release-schedule.html
> -
> https://docs.opendaylight.org/en/latest/release-process/managed-release.html
>
> 1) we are entering code freeze on 2020-02-03, at which point we will
> start picking a release candidate
>
> 2) code is being stabilized for 3-4 weeks to address any identified
> issues blocking the release (i.e. regressions)
>
> 3) on 2020-02-17 we release GA for release activities, with branches
> unlocking as soon they are done
>
> 4) on 2020-03-09 the release is GA
>
> 6) on 2020-04-13 stable/magnesium will be locked down pending SR1 release
>
> 5) on 2020-04-20 we will release SR1
>
> If the current process is such that CCSDK is not considering anything
> before SR1, we are losing roughly 8 to 11 weeks engagement time during
> which the ODL community is most focused on identifying and fixing issues
> with the release.
>
> Once SR1 is done, our focus is shifting on the next release (which is
> already open for 8 weeks).
>
> It feels like all we need is to make sure your 6-month release template
> and ours are shifted by the right number of weeks in a given calendar year.
>
> If we have that, we can have inter-project CI/CD kick in at the right
> time to drive the process, too. :)
>
> Regards,
> Robert
>
>

Re: TSC Meeting Minutes Jan 9, 2020

TIMONEY, DAN <dt5972@...>
 

Brian, all:

We really don't have the resources to accommodate an OpenDaylight upgrade in Frankfurt. As Brian notes, we have definitely seen breaking changes in SRs before, and we simply did not have the resources in Frankfurt to support doing an SR upgrade. We chose instead to spend some time refactoring so that our binaries can be less tightly coupled to specific OpenDaylight releases and, hopefully, able to support multiple OpenDaylight releases in a future release.

As for doing an upgrade mid release, that would be a major issue for us. In ONAP, SDKs (including CCSDK -which is where the ODL port is done) are required to provide stable release artifacts at API freeze (M3) - about 4-6 weeks prior to code freeze. So, a mid release upgrade would be risky - especially since we know from experience that SRs often include breaking changes.

Dan
On 1/15/20, 2:22 PM, "FREEMAN, BRIAN D" <bf1936@...> wrote:

Dan's the one in charge but we have seen breaking changes in SR's before - sometimes it happens when you have to up rev so we dont do it lightly.

Neon SR3 simply came out after we had to commit to the frankfurt schedule.

So ... we'll let Dan think about it but right now I suspect he doesnt have the resources to do the build changes and patches required. Its not a one liner for us .

I think the rigor of doing a release and then an SR1 to fix things that might not have made it (or not found till more people use it) is useful so I'm not suggesting not doing the Base release (defeats the purpose of waiting till patches from broader exposure are incorporated).

Brian

-----Original Message-----
From: Robert Varga <nite@...>
Sent: Wednesday, January 15, 2020 2:15 PM
To: FREEMAN, BRIAN D <bf1936@...>; Abhijit Kumbhare <abhijitkoss@...>; tsc <tsc@...>
Cc: LEFEVRE, CATHERINE <catherine.lefevre@...>; TIMONEY, DAN <dt5972@...>
Subject: Re: [OpenDaylight TSC] TSC Meeting Minutes Jan 9, 2020

On 15/01/2020 19:47, FREEMAN, BRIAN D wrote:
> Does seem like Release to EOL is rather short (1 year) and doesn’t
> factor in the SR’s but I think this is more about bug fixes and patches
> not whether a client can use it.

Well, ONAP's release-to-EOL is even more aggressive, with no support
overlap between releases at all
(https://wiki.onap.org/display/DW/Long+Term+Roadmap) :)

Don't get me wrong, I am not pushing for you to change anything, I just
want to make sure there is a wide understanding of what the situation is.

> I’m sure this isnt a change but given the size of Sodium and the timing
> even of SR3 (like a month ago) we couldn’t base Frankfurt on either Neon
> SR3 or Sodium SR1 (as a downstream we have avoided SR0’s)

I think we need to have a conversation about releases dates and upgrade
processes, really:

1) if our downstreams our avoiding GAs, what is the point of making
them? If nobody adopts GAs, SR1s are essentially the same thing, just 6
weeks later.

2) our SR upgrades are reasonably safe, as far as I can tell, and in the
particular case of Neon SR3 not adopting it means you are way behind on
CVEs -- so why would it be a problem for ONAP to do such an upgrade
mid-release?

Regards,
Robert
Re: TSC Meeting Minutes Jan 9, 2020

FREEMAN, BRIAN D <bf1936@...>
 

Dan's the one in charge but we have seen breaking changes in SR's before - sometimes it happens when you have to up rev so we dont do it lightly.

Neon SR3 simply came out after we had to commit to the frankfurt schedule.

So ... we'll let Dan think about it but right now I suspect he doesnt have the resources to do the build changes and patches required. Its not a one liner for us .

I think the rigor of doing a release and then an SR1 to fix things that might not have made it (or not found till more people use it) is useful so I'm not suggesting not doing the Base release (defeats the purpose of waiting till patches from broader exposure are incorporated).

Brian

-----Original Message-----
From: Robert Varga <nite@...>
Sent: Wednesday, January 15, 2020 2:15 PM
To: FREEMAN, BRIAN D <bf1936@...>; Abhijit Kumbhare <abhijitkoss@...>; tsc <tsc@...>
Cc: LEFEVRE, CATHERINE <catherine.lefevre@...>; TIMONEY, DAN <dt5972@...>
Subject: Re: [OpenDaylight TSC] TSC Meeting Minutes Jan 9, 2020

On 15/01/2020 19:47, FREEMAN, BRIAN D wrote:
Does seem like Release to EOL is rather short (1 year) and doesn’t
factor in the SR’s but I think this is more about bug fixes and patches
not whether a client can use it.
Well, ONAP's release-to-EOL is even more aggressive, with no support
overlap between releases at all
(https://wiki.onap.org/display/DW/Long+Term+Roadmap) :)

Don't get me wrong, I am not pushing for you to change anything, I just
want to make sure there is a wide understanding of what the situation is.

I’m sure this isnt a change but given the size of Sodium and the timing
even of SR3 (like a month ago) we couldn’t base Frankfurt on either Neon
SR3 or Sodium SR1 (as a downstream we have avoided SR0’s)
I think we need to have a conversation about releases dates and upgrade
processes, really:

1) if our downstreams our avoiding GAs, what is the point of making
them? If nobody adopts GAs, SR1s are essentially the same thing, just 6
weeks later.

2) our SR upgrades are reasonably safe, as far as I can tell, and in the
particular case of Neon SR3 not adopting it means you are way behind on
CVEs -- so why would it be a problem for ONAP to do such an upgrade
mid-release?

Regards,
Robert
Re: TSC Meeting Minutes Jan 9, 2020

FREEMAN, BRIAN D <bf1936@...>
 

Its too late for Frankfurt to switch to Sodium SR1

 

Brian

 

 

From: Abhijit Kumbhare <abhijitkoss@...>
Sent: Wednesday, January 15, 2020 1:56 PM
To: FREEMAN, BRIAN D <bf1936@...>
Cc: Robert Varga <nite@...>; tsc <tsc@...>; LEFEVRE, CATHERINE <catherine.lefevre@...>; TIMONEY, DAN <dt5972@...>
Subject: Re: [OpenDaylight TSC] TSC Meeting Minutes Jan 9, 2020

 

Dan Timoney has been working with Luis including using meetings for the ODL distribution. We can figure out any version issues in the next meeting with ONAP.

 

Dan had mentioned that they were planning to integrate Sodium SR2 (once available) in February for Guilin - and Neon SR1 for El Alto release and for Frankfurt. But it probably  makes sense to have Frankfurt based on Sodium SR1 which is already available? But better to sort it out in a meeting sometime soon.

 

On Wed, Jan 15, 2020 at 10:47 AM FREEMAN, BRIAN D <bf1936@...> wrote:

Does seem like Release to EOL is rather short (1 year) and doesn’t factor in the SR’s but I think this is more about bug fixes and patches not whether a client can use it.

 

I’m sure this isnt a change but given the size of Sodium and the timing even of SR3 (like a month ago) we couldn’t base Frankfurt on either Neon SR3 or Sodium SR1 (as a downstream we have avoided SR0’s)

 

I know at least one customer that will be on a Neon base still after 3/2020. I think that just means the distribution provider is doing the support/bug fixes if needed.

 

Brian

 

 

Formal Release

2019-03-25

6 months after Start Date

Start Date +6 months

Formal release

Service Release 1

2019-05-16

1.5 month after Formal Release

Start Date +7.5 months

Service Release 1 (SR1)

Service Release 2

2019-09-06

3 months after SR1

Start Date +10.5 months

Service Release 2 (SR2)

Service Release 3

2019-12-05

4 months after SR2

Start Date +14 months

Service Release 3 (SR3) - Final Service Release

Service Release 4

N/A

Not Available Anymore

Not Available Anymore

Service Release 4 (SR4) - N/A

Release End of Life

2020-03-25

4 months after SR3

Start Date +18 months

End of Life - coincides with the Formal Release of the current release+2 versions and the start of the current release+3 versions

 

 

-----Original Message-----
From: Robert Varga <nite@...>
Sent: Wednesday, January 15, 2020 11:34 AM
To: Abhijit Kumbhare <abhijitkoss@...>; tsc <tsc@...>
Cc: LEFEVRE, CATHERINE <catherine.lefevre@...>; FREEMAN, BRIAN D <bf1936@...>
Subject: Re: [OpenDaylight TSC] TSC Meeting Minutes Jan 9, 2020

 

On 13/01/2020 22:18, Abhijit Kumbhare wrote:

> Hi TSC,

>

> Please find & review the TSC meeting minutes below:

>

> TSC Meeting minutes Jan 9, 2020 <https://wiki.lfnetworking.org/x/8wKkAQ>

 

Quoting the minutes:

 

> Neon SR3 is done, including managed projects. We are just waiting for Anil Belur to complete the packaging work so the downloads page can be updated. Also Jamo Luhrsenwill reduce the autorelease jobs since it is practically EOL

 

One thing re: releases, fresh off the ONAP DDF:

 

ONAP Frankfurt is currently targeting the use of Neon SR1 (or perhaps

SR3), which puts that release (5/7/2020,

https://wiki.onap.org/display/DW/Release+Planning%3A++Frankfurt) firmly

after our Neon EOL date (3/25/2020,

https://docs.opendaylight.org/en/stable-neon/release-process/release-schedule.html).

 

I think we need to do some cross-community work to make sure there are

no surprises.

 

Regards,

Robert

 
Re: TSC Meeting Minutes Jan 9, 2020

FREEMAN, BRIAN D <bf1936@...>
 

Does seem like Release to EOL is rather short (1 year) and doesn’t factor in the SR’s but I think this is more about bug fixes and patches not whether a client can use it.

 

I’m sure this isnt a change but given the size of Sodium and the timing even of SR3 (like a month ago) we couldn’t base Frankfurt on either Neon SR3 or Sodium SR1 (as a downstream we have avoided SR0’s)

 

I know at least one customer that will be on a Neon base still after 3/2020. I think that just means the distribution provider is doing the support/bug fixes if needed.

 

Brian

 

 

Formal Release

2019-03-25

6 months after Start Date

Start Date +6 months

Formal release

Service Release 1

2019-05-16

1.5 month after Formal Release

Start Date +7.5 months

Service Release 1 (SR1)

Service Release 2

2019-09-06

3 months after SR1

Start Date +10.5 months

Service Release 2 (SR2)

Service Release 3

2019-12-05

4 months after SR2

Start Date +14 months

Service Release 3 (SR3) - Final Service Release

Service Release 4

N/A

Not Available Anymore

Not Available Anymore

Service Release 4 (SR4) - N/A

Release End of Life

2020-03-25

4 months after SR3

Start Date +18 months

End of Life - coincides with the Formal Release of the current release+2 versions and the start of the current release+3 versions

 

 

-----Original Message-----
From: Robert Varga <nite@...>
Sent: Wednesday, January 15, 2020 11:34 AM
To: Abhijit Kumbhare <abhijitkoss@...>; tsc <tsc@...>
Cc: LEFEVRE, CATHERINE <catherine.lefevre@...>; FREEMAN, BRIAN D <bf1936@...>
Subject: Re: [OpenDaylight TSC] TSC Meeting Minutes Jan 9, 2020

 

On 13/01/2020 22:18, Abhijit Kumbhare wrote:

> Hi TSC,

>

> Please find & review the TSC meeting minutes below:

>

> TSC Meeting minutes Jan 9, 2020 <https://wiki.lfnetworking.org/x/8wKkAQ>

 

Quoting the minutes:

 

> Neon SR3 is done, including managed projects. We are just waiting for Anil Belur to complete the packaging work so the downloads page can be updated. Also Jamo Luhrsenwill reduce the autorelease jobs since it is practically EOL

 

One thing re: releases, fresh off the ONAP DDF:

 

ONAP Frankfurt is currently targeting the use of Neon SR1 (or perhaps

SR3), which puts that release (5/7/2020,

https://wiki.onap.org/display/DW/Release+Planning%3A++Frankfurt) firmly

after our Neon EOL date (3/25/2020,

https://docs.opendaylight.org/en/stable-neon/release-process/release-schedule.html).

 

I think we need to do some cross-community work to make sure there are

no surprises.

 

Regards,

Robert

 
Re: TSC members please vote for Karthikeyan as new NetVirt committer

Karthikeyan <karthikeyangceb007@...>
 

Thank you all whoever voted for me.

Thanks & Regards,
Karthikeyan.

On Mon, Jan 6, 2020 at 1:17 PM Abhinav Gupta <abhinav.gupta@...> wrote:

Congratulations Karthikeyan! Please work with the LF team as discussed for the rights.

I’ve updated the NetVirt wiki.

 

Regards,
Abhinav

 

From: Abhijit Kumbhare <abhijitkoss@...>
Sent: Thursday, January 2, 2020 12:59 AM
To: Robert Varga <nite@...>
Cc: Abhinav Gupta <abhinav.gupta@...>; tsc <tsc@...>
Subject: Re: [OpenDaylight TSC] TSC members please vote for Karthikeyan as new NetVirt committer

 

With Robert’s and Tejas’s tipping point  votes  - this vote carries. 

 

Abhinav - can you please work with the LF IT to make sure committer rights get assigned? These days it requires an opening a ticket in LF Jira (if I remember right) - Anil Belur will be able to help you point the page. LF has a holiday till end of this week - so I assume he will be able to help you on Monday (anyway the IT ticket will not progress before that). Also please update the NetVirt wiki to include Karthikeyan as an active committer. Also if the active committers lis needs cleaning up - please do so. 

 

On Wed, Jan 1, 2020 at 5:02 PM Robert Varga <nite@...> wrote:

On 27/12/2019 13:49, Abhijit Kumbhare wrote:
> Hello TSC members,
>
> Please vote either -1, 0 or +1 for Karthikeyan as NetVirt committer.

+1.

I think that carries.

Regards,
Robert
Re: TSC Meeting Minutes Jan 9, 2020

Luis Gomez
 

FYI it looks like folks are not getting the messages in this thread, so if anyone is moderator for TSC channel please approve pending messages.

On Jan 15, 2020, at 12:29 PM, Robert Varga <nite@...> wrote:

On 15/01/2020 20:51, TIMONEY, DAN wrote:
As for doing an upgrade mid release, that would be a major issue for us. In ONAP, SDKs (including CCSDK -which is where the ODL port is done) are required to provide stable release artifacts at API freeze (M3) - about 4-6 weeks prior to code freeze. So, a mid release upgrade would be risky - especially since we know from experience that SRs often include breaking changes.
Understood. I am by no means implying that we do not break things,
because we do and sometimes we do not even know. Sorry for the wall of
text that follows.

Given that both projects are on a 6-month schedule and we do have the
ability to do cross-project CI, we should be able to engage much earlier
so that a supported ONAP release is backed by a supported ODL release.

Based on my current understanding, the best we can strive for is to make
sure that Dan has a fully-vetted fresh ODL SR1 by the time he has to
commit to it.

That does include committing resources on his part and do a non-trivial
amount of work, so we need to maximize the time window for this activity.

From ODL perspective, the dates and the process for Magnesium are:
-
https://docs.opendaylight.org/en/latest/release-process/release-schedule.html
-
https://docs.opendaylight.org/en/latest/release-process/managed-release.html

1) we are entering code freeze on 2020-02-03, at which point we will
start picking a release candidate

2) code is being stabilized for 3-4 weeks to address any identified
issues blocking the release (i.e. regressions)

3) on 2020-02-17 we release GA for release activities, with branches
unlocking as soon they are done

4) on 2020-03-09 the release is GA

6) on 2020-04-13 stable/magnesium will be locked down pending SR1 release

5) on 2020-04-20 we will release SR1

If the current process is such that CCSDK is not considering anything
before SR1, we are losing roughly 8 to 11 weeks engagement time during
which the ODL community is most focused on identifying and fixing issues
with the release.

Once SR1 is done, our focus is shifting on the next release (which is
already open for 8 weeks).

It feels like all we need is to make sure your 6-month release template
and ours are shifted by the right number of weeks in a given calendar year.

If we have that, we can have inter-project CI/CD kick in at the right
time to drive the process, too. :)

Regards,
Robert
Re: TSC Meeting Minutes Jan 9, 2020

Robert Varga
 

On 15/01/2020 20:51, TIMONEY, DAN wrote:
As for doing an upgrade mid release, that would be a major issue for us. In ONAP, SDKs (including CCSDK -which is where the ODL port is done) are required to provide stable release artifacts at API freeze (M3) - about 4-6 weeks prior to code freeze. So, a mid release upgrade would be risky - especially since we know from experience that SRs often include breaking changes.
Understood. I am by no means implying that we do not break things,
because we do and sometimes we do not even know. Sorry for the wall of
text that follows.

Given that both projects are on a 6-month schedule and we do have the
ability to do cross-project CI, we should be able to engage much earlier
so that a supported ONAP release is backed by a supported ODL release.

Based on my current understanding, the best we can strive for is to make
sure that Dan has a fully-vetted fresh ODL SR1 by the time he has to
commit to it.

That does include committing resources on his part and do a non-trivial
amount of work, so we need to maximize the time window for this activity.

From ODL perspective, the dates and the process for Magnesium are:
-
https://docs.opendaylight.org/en/latest/release-process/release-schedule.html
-
https://docs.opendaylight.org/en/latest/release-process/managed-release.html

1) we are entering code freeze on 2020-02-03, at which point we will
start picking a release candidate

2) code is being stabilized for 3-4 weeks to address any identified
issues blocking the release (i.e. regressions)

3) on 2020-02-17 we release GA for release activities, with branches
unlocking as soon they are done

4) on 2020-03-09 the release is GA

6) on 2020-04-13 stable/magnesium will be locked down pending SR1 release

5) on 2020-04-20 we will release SR1

If the current process is such that CCSDK is not considering anything
before SR1, we are losing roughly 8 to 11 weeks engagement time during
which the ODL community is most focused on identifying and fixing issues
with the release.

Once SR1 is done, our focus is shifting on the next release (which is
already open for 8 weeks).

It feels like all we need is to make sure your 6-month release template
and ours are shifted by the right number of weeks in a given calendar year.

If we have that, we can have inter-project CI/CD kick in at the right
time to drive the process, too. :)

Regards,
Robert

?
signature.asc

Re: TSC Meeting Minutes Jan 9, 2020

Robert Varga
 

On 15/01/2020 19:47, FREEMAN, BRIAN D wrote:
Does seem like Release to EOL is rather short (1 year) and doesn’t
factor in the SR’s but I think this is more about bug fixes and patches
not whether a client can use it.
Well, ONAP's release-to-EOL is even more aggressive, with no support
overlap between releases at all
(https://wiki.onap.org/display/DW/Long+Term+Roadmap) :)

Don't get me wrong, I am not pushing for you to change anything, I just
want to make sure there is a wide understanding of what the situation is.

I’m sure this isnt a change but given the size of Sodium and the timing
even of SR3 (like a month ago) we couldn’t base Frankfurt on either Neon
SR3 or Sodium SR1 (as a downstream we have avoided SR0’s)
I think we need to have a conversation about releases dates and upgrade
processes, really:

1) if our downstreams our avoiding GAs, what is the point of making
them? If nobody adopts GAs, SR1s are essentially the same thing, just 6
weeks later.

2) our SR upgrades are reasonably safe, as far as I can tell, and in the
particular case of Neon SR3 not adopting it means you are way behind on
CVEs -- so why would it be a problem for ONAP to do such an upgrade
mid-release?

Regards,
Robert

?
signature.asc

Re: TSC Meeting Minutes Jan 9, 2020

Abhijit Kumbhare
 

Dan Timoney has been working with Luis including using meetings for the ODL distribution. We can figure out any version issues in the next meeting with ONAP.

Dan had mentioned that they were planning to integrate Sodium SR2 (once available) in February for Guilin - and Neon SR1 for El Alto release and for Frankfurt. But it probably  makes sense to have Frankfurt based on Sodium SR1 which is already available? But better to sort it out in a meeting sometime soon.


On Wed, Jan 15, 2020 at 10:47 AM FREEMAN, BRIAN D <bf1936@...> wrote:

Does seem like Release to EOL is rather short (1 year) and doesn’t factor in the SR’s but I think this is more about bug fixes and patches not whether a client can use it.

 

I’m sure this isnt a change but given the size of Sodium and the timing even of SR3 (like a month ago) we couldn’t base Frankfurt on either Neon SR3 or Sodium SR1 (as a downstream we have avoided SR0’s)

 

I know at least one customer that will be on a Neon base still after 3/2020. I think that just means the distribution provider is doing the support/bug fixes if needed.

 

Brian

 

 

Formal Release

2019-03-25

6 months after Start Date

Start Date +6 months

Formal release

Service Release 1

2019-05-16

1.5 month after Formal Release

Start Date +7.5 months

Service Release 1 (SR1)

Service Release 2

2019-09-06

3 months after SR1

Start Date +10.5 months

Service Release 2 (SR2)

Service Release 3

2019-12-05

4 months after SR2

Start Date +14 months

Service Release 3 (SR3) - Final Service Release

Service Release 4

N/A

Not Available Anymore

Not Available Anymore

Service Release 4 (SR4) - N/A

Release End of Life

2020-03-25

4 months after SR3

Start Date +18 months

End of Life - coincides with the Formal Release of the current release+2 versions and the start of the current release+3 versions

 

 

-----Original Message-----
From: Robert Varga <nite@...>
Sent: Wednesday, January 15, 2020 11:34 AM
To: Abhijit Kumbhare <abhijitkoss@...>; tsc <tsc@...>
Cc: LEFEVRE, CATHERINE <catherine.lefevre@...>; FREEMAN, BRIAN D <bf1936@...>
Subject: Re: [OpenDaylight TSC] TSC Meeting Minutes Jan 9, 2020

 

On 13/01/2020 22:18, Abhijit Kumbhare wrote:

> Hi TSC,

>

> Please find & review the TSC meeting minutes below:

>

> TSC Meeting minutes Jan 9, 2020 <https://wiki.lfnetworking.org/x/8wKkAQ>

 

Quoting the minutes:

 

> Neon SR3 is done, including managed projects. We are just waiting for Anil Belur to complete the packaging work so the downloads page can be updated. Also Jamo Luhrsenwill reduce the autorelease jobs since it is practically EOL

 

One thing re: releases, fresh off the ONAP DDF:

 

ONAP Frankfurt is currently targeting the use of Neon SR1 (or perhaps

SR3), which puts that release (5/7/2020,

https://wiki.onap.org/display/DW/Release+Planning%3A++Frankfurt) firmly

after our Neon EOL date (3/25/2020,

https://docs.opendaylight.org/en/stable-neon/release-process/release-schedule.html).

 

I think we need to do some cross-community work to make sure there are

no surprises.

 

Regards,

Robert

 
Re: TSC Meeting Minutes Jan 9, 2020

Robert Varga
 

On 13/01/2020 22:18, Abhijit Kumbhare wrote:
Hi TSC,

Please find & review the TSC meeting minutes below:

TSC Meeting minutes Jan 9, 2020 <https://wiki.lfnetworking.org/x/8wKkAQ>
Quoting the minutes:

Neon SR3 is done, including managed projects. We are just waiting for Anil Belur to complete the packaging work so the downloads page can be updated. Also Jamo Luhrsenwill reduce the autorelease jobs since it is practically EOL
One thing re: releases, fresh off the ONAP DDF:

ONAP Frankfurt is currently targeting the use of Neon SR1 (or perhaps
SR3), which puts that release (5/7/2020,
https://wiki.onap.org/display/DW/Release+Planning%3A++Frankfurt) firmly
after our Neon EOL date (3/25/2020,
https://docs.opendaylight.org/en/stable-neon/release-process/release-schedule.html).

I think we need to do some cross-community work to make sure there are
no surprises.

Regards,
Robert

?
signature.asc

Re: Moving from sonar.opendaylight.org to Sonarcloud.io

Anil Belur
 

Greetings Robert:

Trying to catch up on where we are with the sonarcloud migrations. I think another issue has been identified with 0% coverage, that is caused by an update on the Java analyzer. 
With sonarcloud it's no longer possible to import jacoco.exec reports, and the workaround suggested is to use XML format. This needs to be fixed in the pom files.

Example on how this is fixed on an external project:
https://github.com/synyx/urlaubsverwaltung/pull/930/files

Thanks,
Anil


 
 



On Fri, Dec 13, 2019 at 8:01 AM Eric Ball <eball@...> wrote:
At this point, what's still needed before we start merging these changes? I can continue to address any concerns with this, but if there isn't anything further, I'd like to start getting these changes reviewed and merged. https://git.opendaylight.org/gerrit/q/status:open+sonarcloud

On Mon, Dec 9, 2019 at 1:50 PM Robert Varga <nite@...> wrote:
On 09/12/2019 22:36, Eric Ball wrote:
> Ok, I've recreated the "ODL way" Java quality profile (59 of 60 rules;
> one was deprecated) in Sonarcloud, and set it as the default. Future
> runs should reflect only those rules that were chosen. I still think
> this should probably be updated, as it has not changed in 5 years, but
> for now the results should be closer to what you're getting in SonarQube.

Yeah, I was going to write that, but haven't gotten to it. We certainly
should take the default sonarcloud profile and re-evaluate it.

Regards,
Robert
LF Networking 2019 Year In Review Now Available

Brandon Wick
 

LFN Communities, 

As we embark on 2020, we invite you to join us for a look back at 2019 -- a significant year for LF Networking. The LF Networking 2019 Year in Review has now been published to the LFN Website. This 28-page, detailed report recaps the highlights and achievements of 2019 while offering insights from LFN community leaders on where the project is headed in 2020 and from LFN leadership on the state of the open source networking industry. 


Thank you to all LFN members and LFN project community participants for your contributions in 2019. Here's to a great 2020!

Best, 

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
+1.917.282.0960
TSC Meeting Minutes Jan 9, 2020

Abhijit Kumbhare
 

Hi TSC,

Please find & review the TSC meeting minutes below:


If you find something that needs to be amended, please let me know - we can update it on the confluence page above. 

Thanks,
Abhijit
Re: TWS: Micro Distributions - Lighty

Tejas Nevrekar
 

Hi Robert, et al,

Hope you are doing well. 

From the last TWS there was an action to review the lighty proposal at the start of the year (06-Jan). 

Since you could not make it today and last week for the TWS, could you please suggest a more convenient time this week, preferably close to 9 AM PST that we can meet for the same purpose?

Thanks and Regards,

Tejas. S. Nevrekar
Mobile: +91-99805 31339
Bangalore, INDIA.


On Mon, Jan 13, 2020 at 3:03 PM Tejas Nevrekar <tejas.nevrekar@...> wrote:
Hi all,

Just a reminder of the TWS scheduled today at 9:00 AM PST to further on "Micro-distribution for ODL". 


As per the last minutes https://wiki.lfnetworking.org/display/ODL/Dec+16%2C+2019, we have an action to review the Lighty proposal at https://wiki.opendaylight.org/view/Project_Proposals:Lighty.

Regards,

Tejas. S. Nevrekar
Mobile: +91-99805 31339
Bangalore, INDIA.
TWS: Micro Distributions - Lighty

Tejas Nevrekar
 

Hi all,

Just a reminder of the TWS scheduled today at 9:00 AM PST to further on "Micro-distribution for ODL". 


As per the last minutes https://wiki.lfnetworking.org/display/ODL/Dec+16%2C+2019, we have an action to review the Lighty proposal at https://wiki.opendaylight.org/view/Project_Proposals:Lighty.

Regards,

Tejas. S. Nevrekar
Mobile: +91-99805 31339
Bangalore, INDIA.
Re: Magnesium service release proposal for the two

Daniel de la Rosa
 

Thanks Luis.. just a small correction to make this more accurate... after Magnesium GA, we will be releasing  Sodium SR3


Magnesium GA -> Sodium SR3 -> Magnesium SR1 -> Aluminum GA -> Magnesium SR2 -> Silicium GA -> Aluminum SR1 -> etc

Please let us know if you have any additional feedback

Thanks


On Thu, Jan 9, 2020 at 4:34 PM Luis Gomez <ecelgp@...> wrote:
I think the 6 months after Magnesium release will conflict with Aluminum release. If we really want to have 1 effective release every ~2 months, we have to space the SRs ~4 months:

Magnesium GA -> Sodium SR2 -> Magnesium SR1 -> Aluminum GA -> Magnesium SR2 -> Silicium GA

On Jan 9, 2020, at 2:06 PM, Daniel de la Rosa <ddelarosa@...> wrote:

Hello TSC members, here is my current proposal, basically a Magnesium SR every 3 months.  Let's review this on today's meeting or over email

MagnesiumMagnesium New
2019-09-092019-09-09
2020-03-092020-03-096 months after Start Date
2020-04-20N/A1.5 month after Formal Release
2020-07-20Magnesium SR1 2020-07-203 months after SR1
2020-11-164 months after SR2
N/AMagnesium SR2 ( 6 m after Formal Release) 2020-10-20Not available anymore
2021-03-082021-03-0812 months after formal release


Thanks





--
Daniel de la Rosa
Customer Support Manager
Lumina Networks Inc.
e: ddelarosa@...
m:  +1 408 7728120




--
Daniel de la Rosa
Customer Support Manager
Lumina Networks Inc.
e: ddelarosa@...
m:  +1 408 7728120
Re: Magnesium service release proposal for the two

Luis Gomez
 

I think the 6 months after Magnesium release will conflict with Aluminum release. If we really want to have 1 effective release every ~2 months, we have to space the SRs ~4 months:

Magnesium GA -> Sodium SR2 -> Magnesium SR1 -> Aluminum GA -> Magnesium SR2 -> Silicium GA

On Jan 9, 2020, at 2:06 PM, Daniel de la Rosa <ddelarosa@...> wrote:

Hello TSC members, here is my current proposal, basically a Magnesium SR every 3 months.  Let's review this on today's meeting or over email

MagnesiumMagnesium New
2019-09-092019-09-09
2020-03-092020-03-096 months after Start Date
2020-04-20N/A1.5 month after Formal Release
2020-07-20Magnesium SR1 2020-07-203 months after SR1
2020-11-164 months after SR2
N/AMagnesium SR2 ( 6 m after Formal Release) 2020-10-20Not available anymore
2021-03-082021-03-0812 months after formal release


Thanks





--
Daniel de la Rosa
Customer Support Manager
Lumina Networks Inc.
e: ddelarosa@...
m:  +1 408 7728120
Magnesium service release proposal for the two

Daniel de la Rosa
 

Hello TSC members, here is my current proposal, basically a Magnesium SR every 3 months.  Let's review this on today's meeting or over email

MagnesiumMagnesium New
2019-09-092019-09-09
2020-03-092020-03-096 months after Start Date
2020-04-20N/A1.5 month after Formal Release
2020-07-20Magnesium SR1 2020-07-203 months after SR1
2020-11-164 months after SR2
N/AMagnesium SR2 ( 6 m after Formal Release) 2020-10-20Not available anymore
2021-03-082021-03-0812 months after formal release


Thanks





--
Daniel de la Rosa
Customer Support Manager
Lumina Networks Inc.
e: ddelarosa@...
m:  +1 408 7728120
1861 - 1880 of 14243