Date   

Re: Issue with Linux Foundation and expectations on ODL projects

Abhijit Kumbhare
 

Also:
  • Casey Cain to work with LF IT to address communications to the community regarding security issues. 06 Mar 2020 
  • Casey Cain to follow up with Allan Clarke Thanh Ha and the community on Plastic security issues 06 Mar 2020 


On Fri, Mar 6, 2020 at 3:03 PM Luis Gomez <ecelgp@...> wrote:
Hi Jamo,

Few outcomes from yesterday TSC call (at least for me):

1) Thanh will open a ticket to LF to work on a new feature to notify users upfront if there is a security problem in the staging build. I think Allan was waiting long time to get this information.
2) LF will look at the current Nexus IQ problem of reporting old SW security issues in new SW scans.
3) In the situations where it is believed Nexus IQ is not doing the right thing (like this one), the impacted project/person will rise a mail to ODL security team (security@...) with all the details. The ODL security will analyze the problem and if it turns out to be a tool problem, the security team will provide an immediate waiver. If there is a real sec issue, the project/person will have to fix or ask a waiver to the TSC.
4) ODL community needs more and better communication on how things work and change in LF.

BR/Luis


> On Mar 6, 2020, at 10:37 AM, JamO Luhrsen <jluhrsen@...> wrote:
>
> I missed the TSC meeting last night. Can someone recap over email what came of
> this? I see one note in the minutes that Casey indicated that no change has
> occurred in the policy regarding security violations, but that doesn't seem
> accurate since Plastic v2.1.6 was successfully released, but v2.1.7 is blocked
> on security policies. Maybe I don't understand something, but that feels like
> something changed...
>
> Also, nobody is answering why the nexus IQ reports are failing v2.1.7 with
> logs and messages about v2.1.6. Allan has mentioned that multiple times and
> it keeps getting ignored.
>
> Thanks,
> JamO
>
> On 3/5/20 7:01 PM, Thanh ha wrote:
>> On Thu, 5 Mar 2020 at 16:45, Anil Belur <abelur@...> wrote:
>> On Fri, Mar 6, 2020 at 2:05 AM Allan <aclarke@...> wrote:
>> Greetings!
>>
>> 
>> I have been trying to get a new release of the Plastic sub-project out for 3 weeks now and have been clogged up in LF helpdesk.
>>
>> 
>> *Summary*
>>
>> 
>> LF is not allowing newer release of Plastic 2.1.7 that fixes 3rd party vulnerabilities already in 2.1.6 release.
>>
>> LF wants ODL after-the-fact approval for Plastic 2.1.6 that is already publicly available.
>>
>> Both LF tooling (Nexus IQ) and vulnerability process is broken.
>>
>> 
>> *Details*
>>
>> 
>> Here is the sequence of events AFAIKT:
>>
>> 
>>      • Plastic 2.1.6 released (months ago)
>>      • LF silently changes release process to require Nexus IQ passing (no docs, no links to help PTLs BTW)
>>      • Plastic 2.1.7 candidate build successful but not available for testing
>>      • LF helpdesk says Nexus IQ violations making build unavailable
>>      • (Older version of Guava and Groovy have exposure on features not used by Plastic)
>>      • LF finally gets accounts and links fixed so Nexus IQ reports are available to PTL
>>      • New version of Plastic 2.1.7 candidate build (violations fixed)
>>      • Build still not available due to “violations” (what???)
>>      • Nexus IQ report is all screwed up in the UI, mixing 2.1.6 and 2.1.7 up, mislabeling, clearly buggy
>>      • Nexus IQ report appears to be showing old violations against ALREADY RELEASED 2.1.6
>>      • LF says because security violations are involved, the ODL Security group needs waivers.
>> 
>> *Conclusion*
>>
>> 
>> I would like to release Plastic 2.1.7. It has improvements and fixes violations in 3rd party libraries.
>>
>> It has been languishing and holding up the next major release.
>>
>> I would like a release process that understands when “the horse has left the barn” and that thinks it is a good thing when a new release fixes vulnerabilities in an old release.
>>
>> 
>> Allan Clarke
>>
>> Plastic PTL
>>
>> 
>>
>>
>> Greetings Allan:
>>
>> I understand the concerns on the delay in releasing Plastic, please find my response below.
>> 
>> 1. The policy violations are security issues outside the scope of LF/RE's to determine if they can be waived.
>> 2. The policy violations showing up on stage repositories is a "feature" and not a "bug", and a proactive way to ensure these violations are going to be addressed early on before a release.
>> 3. The violations seen recently in plastic is a result of updating the "Nexus platform plugin", which is working as expected and not a result of any to Nexus repository level setting.
>> 4. It's seldom up to LF or the PTL's to waive IQ policy violations, waivers can only come from the ODL security team as approved by the TSC.
>>
>> The concerning thing here for me is LF deployed a new release process requiring someone or group of people to analyse and provide a security waiver to projects before allowing the project to be released and actively blocks the project from doing so. While the goal of this process might be fine and proactive the way LF decided to unleash this to the world is not.
>>
>> The community was not informed of the new process, nor has there been any communication to the communitiy to setup a process for providing security waivers to projects (if there has I apologies as I have not seen it and would welcome someone to correct me otherwise). The problem is today there is no way for a PTL to have this security waiver approved.
>>
>> I'm not sure how LF can justify implementing a new "feature" without first implementing any processes around to support the feature with the community, then seemingly telling the community it is their problem to handle it.
>>
>> Regards,
>> Thanh
>>
>>
>>
>
>


Re: Issue with Linux Foundation and expectations on ODL projects

Luis Gomez
 

Hi Jamo,

Few outcomes from yesterday TSC call (at least for me):

1) Thanh will open a ticket to LF to work on a new feature to notify users upfront if there is a security problem in the staging build. I think Allan was waiting long time to get this information.
2) LF will look at the current Nexus IQ problem of reporting old SW security issues in new SW scans.
3) In the situations where it is believed Nexus IQ is not doing the right thing (like this one), the impacted project/person will rise a mail to ODL security team (security@...) with all the details. The ODL security will analyze the problem and if it turns out to be a tool problem, the security team will provide an immediate waiver. If there is a real sec issue, the project/person will have to fix or ask a waiver to the TSC.
4) ODL community needs more and better communication on how things work and change in LF.

BR/Luis

On Mar 6, 2020, at 10:37 AM, JamO Luhrsen <jluhrsen@...> wrote:

I missed the TSC meeting last night. Can someone recap over email what came of
this? I see one note in the minutes that Casey indicated that no change has
occurred in the policy regarding security violations, but that doesn't seem
accurate since Plastic v2.1.6 was successfully released, but v2.1.7 is blocked
on security policies. Maybe I don't understand something, but that feels like
something changed...

Also, nobody is answering why the nexus IQ reports are failing v2.1.7 with
logs and messages about v2.1.6. Allan has mentioned that multiple times and
it keeps getting ignored.

Thanks,
JamO

On 3/5/20 7:01 PM, Thanh ha wrote:
On Thu, 5 Mar 2020 at 16:45, Anil Belur <abelur@...> wrote:
On Fri, Mar 6, 2020 at 2:05 AM Allan <aclarke@...> wrote:
Greetings!


I have been trying to get a new release of the Plastic sub-project out for 3 weeks now and have been clogged up in LF helpdesk.


*Summary*


LF is not allowing newer release of Plastic 2.1.7 that fixes 3rd party vulnerabilities already in 2.1.6 release.

LF wants ODL after-the-fact approval for Plastic 2.1.6 that is already publicly available.

Both LF tooling (Nexus IQ) and vulnerability process is broken.


*Details*


Here is the sequence of events AFAIKT:


• Plastic 2.1.6 released (months ago)
• LF silently changes release process to require Nexus IQ passing (no docs, no links to help PTLs BTW)
• Plastic 2.1.7 candidate build successful but not available for testing
• LF helpdesk says Nexus IQ violations making build unavailable
• (Older version of Guava and Groovy have exposure on features not used by Plastic)
• LF finally gets accounts and links fixed so Nexus IQ reports are available to PTL
• New version of Plastic 2.1.7 candidate build (violations fixed)
• Build still not available due to “violations” (what???)
• Nexus IQ report is all screwed up in the UI, mixing 2.1.6 and 2.1.7 up, mislabeling, clearly buggy
• Nexus IQ report appears to be showing old violations against ALREADY RELEASED 2.1.6
• LF says because security violations are involved, the ODL Security group needs waivers.

*Conclusion*


I would like to release Plastic 2.1.7. It has improvements and fixes violations in 3rd party libraries.

It has been languishing and holding up the next major release.

I would like a release process that understands when “the horse has left the barn” and that thinks it is a good thing when a new release fixes vulnerabilities in an old release.


Allan Clarke

Plastic PTL




Greetings Allan:

I understand the concerns on the delay in releasing Plastic, please find my response below.

1. The policy violations are security issues outside the scope of LF/RE's to determine if they can be waived.
2. The policy violations showing up on stage repositories is a "feature" and not a "bug", and a proactive way to ensure these violations are going to be addressed early on before a release.
3. The violations seen recently in plastic is a result of updating the "Nexus platform plugin", which is working as expected and not a result of any to Nexus repository level setting.
4. It's seldom up to LF or the PTL's to waive IQ policy violations, waivers can only come from the ODL security team as approved by the TSC.

The concerning thing here for me is LF deployed a new release process requiring someone or group of people to analyse and provide a security waiver to projects before allowing the project to be released and actively blocks the project from doing so. While the goal of this process might be fine and proactive the way LF decided to unleash this to the world is not.

The community was not informed of the new process, nor has there been any communication to the communitiy to setup a process for providing security waivers to projects (if there has I apologies as I have not seen it and would welcome someone to correct me otherwise). The problem is today there is no way for a PTL to have this security waiver approved.

I'm not sure how LF can justify implementing a new "feature" without first implementing any processes around to support the feature with the community, then seemingly telling the community it is their problem to handle it.

Regards,
Thanh



Re: Issue with Linux Foundation and expectations on ODL projects

JamO Luhrsen
 

I missed the TSC meeting last night. Can someone recap over email what came of
this? I see one note in the minutes that Casey indicated that no change has
occurred in the policy regarding security violations, but that doesn't seem
accurate since Plastic v2.1.6 was successfully released, but v2.1.7 is blocked
on security policies. Maybe I don't understand something, but that feels like
something changed...

Also, nobody is answering why the nexus IQ reports are failing v2.1.7 with
logs and messages about v2.1.6. Allan has mentioned that multiple times and
it keeps getting ignored.

Thanks,
JamO

On 3/5/20 7:01 PM, Thanh ha wrote:

On Thu, 5 Mar 2020 at 16:45, Anil Belur <abelur@...> wrote:
On Fri, Mar 6, 2020 at 2:05 AM Allan <aclarke@...> wrote:

Greetings!

 

I have been trying to get a new release of the Plastic sub-project out for 3 weeks now and have been clogged up in LF helpdesk.

 

*Summary*

 

LF is not allowing newer release of Plastic 2.1.7 that fixes 3rd party vulnerabilities already in 2.1.6 release.

LF wants ODL after-the-fact approval for Plastic 2.1.6 that is already publicly available.

Both LF tooling (Nexus IQ) and vulnerability process is broken.

 

*Details*

 

Here is the sequence of events AFAIKT:

 

  • Plastic 2.1.6 released (months ago)
  • LF silently changes release process to require Nexus IQ passing (no docs, no links to help PTLs BTW)
  • Plastic 2.1.7 candidate build successful but not available for testing
  • LF helpdesk says Nexus IQ violations making build unavailable
  • (Older version of Guava and Groovy have exposure on features not used by Plastic)
  • LF finally gets accounts and links fixed so Nexus IQ reports are available to PTL
  • New version of Plastic 2.1.7 candidate build (violations fixed)
  • Build still not available due to “violations” (what???)
  • Nexus IQ report is all screwed up in the UI, mixing 2.1.6 and 2.1.7 up, mislabeling, clearly buggy
  • Nexus IQ report appears to be showing old violations against ALREADY RELEASED 2.1.6
  • LF says because security violations are involved, the ODL Security group needs waivers.

 

*Conclusion*

 

I would like to release Plastic 2.1.7. It has improvements and fixes violations in 3rd party libraries.

It has been languishing and holding up the next major release.

I would like a release process that understands when “the horse has left the barn” and that thinks it is a good thing when a new release fixes vulnerabilities in an old release.

 

Allan Clarke

Plastic PTL

 



Greetings Allan:

I understand the concerns on the delay in releasing Plastic, please find my response below.
 
1. The policy violations are security issues outside the scope of LF/RE's to determine if they can be waived.
2. The policy violations showing up on stage repositories is a "feature" and not a "bug", and a proactive way to ensure these violations are going to be addressed early on before a release. 
3. The violations seen recently in plastic is a result of updating the "Nexus platform plugin", which is working as expected and not a result of any to Nexus repository level setting. 
4. It's seldom up to LF or the PTL's to waive IQ policy violations, waivers can only come from the ODL security team as approved by the TSC.

The concerning thing here for me is LF deployed a new release process requiring someone or group of people to analyse and provide a security waiver to projects before allowing the project to be released and actively blocks the project from doing so. While the goal of this process might be fine and proactive the way LF decided to unleash this to the world is not.

The community was not informed of the new process, nor has there been any communication to the communitiy to setup a process for providing security waivers to projects (if there has I apologies as I have not seen it and would welcome someone to correct me otherwise). The problem is today there is no way for a PTL to have this security waiver approved.

I'm not sure how LF can justify implementing a new "feature" without first implementing any processes around to support the feature with the community, then seemingly telling the community it is their problem to handle it.

Regards,
Thanh



    


Re: Issue with Linux Foundation and expectations on ODL projects

Thanh ha <zxiiro@...>
 

On Thu, 5 Mar 2020 at 16:45, Anil Belur <abelur@...> wrote:
On Fri, Mar 6, 2020 at 2:05 AM Allan <aclarke@...> wrote:

Greetings!

 

I have been trying to get a new release of the Plastic sub-project out for 3 weeks now and have been clogged up in LF helpdesk.

 

*Summary*

 

LF is not allowing newer release of Plastic 2.1.7 that fixes 3rd party vulnerabilities already in 2.1.6 release.

LF wants ODL after-the-fact approval for Plastic 2.1.6 that is already publicly available.

Both LF tooling (Nexus IQ) and vulnerability process is broken.

 

*Details*

 

Here is the sequence of events AFAIKT:

 

  • Plastic 2.1.6 released (months ago)
  • LF silently changes release process to require Nexus IQ passing (no docs, no links to help PTLs BTW)
  • Plastic 2.1.7 candidate build successful but not available for testing
  • LF helpdesk says Nexus IQ violations making build unavailable
  • (Older version of Guava and Groovy have exposure on features not used by Plastic)
  • LF finally gets accounts and links fixed so Nexus IQ reports are available to PTL
  • New version of Plastic 2.1.7 candidate build (violations fixed)
  • Build still not available due to “violations” (what???)
  • Nexus IQ report is all screwed up in the UI, mixing 2.1.6 and 2.1.7 up, mislabeling, clearly buggy
  • Nexus IQ report appears to be showing old violations against ALREADY RELEASED 2.1.6
  • LF says because security violations are involved, the ODL Security group needs waivers.

 

*Conclusion*

 

I would like to release Plastic 2.1.7. It has improvements and fixes violations in 3rd party libraries.

It has been languishing and holding up the next major release.

I would like a release process that understands when “the horse has left the barn” and that thinks it is a good thing when a new release fixes vulnerabilities in an old release.

 

Allan Clarke

Plastic PTL

 



Greetings Allan:

I understand the concerns on the delay in releasing Plastic, please find my response below.
 
1. The policy violations are security issues outside the scope of LF/RE's to determine if they can be waived.
2. The policy violations showing up on stage repositories is a "feature" and not a "bug", and a proactive way to ensure these violations are going to be addressed early on before a release. 
3. The violations seen recently in plastic is a result of updating the "Nexus platform plugin", which is working as expected and not a result of any to Nexus repository level setting. 
4. It's seldom up to LF or the PTL's to waive IQ policy violations, waivers can only come from the ODL security team as approved by the TSC.

The concerning thing here for me is LF deployed a new release process requiring someone or group of people to analyse and provide a security waiver to projects before allowing the project to be released and actively blocks the project from doing so. While the goal of this process might be fine and proactive the way LF decided to unleash this to the world is not.

The community was not informed of the new process, nor has there been any communication to the communitiy to setup a process for providing security waivers to projects (if there has I apologies as I have not seen it and would welcome someone to correct me otherwise). The problem is today there is no way for a PTL to have this security waiver approved.

I'm not sure how LF can justify implementing a new "feature" without first implementing any processes around to support the feature with the community, then seemingly telling the community it is their problem to handle it.

Regards,
Thanh


Re: Issue with Linux Foundation and expectations on ODL projects

Allan
 

Thanks for the reply, Anil. That did answer some questions I had.

 

My questions:

  1. Why is there no link or docs connecting a built-but-not-available staging build to a vulnerability report?
  2. Why are there two projects in Nexus IQ (both plastic and odl-plastic)?
  3. Why does the Nexus IQ report show 2.1.6 in the titles/labels but shows 2.1.6 and 2.1.7 as detailed names?
  4. Why does anyone need anyone’s permission to release a new version that fixes vulnerabilities?

 

These questions point to 4 serious issues with releasing projects. It would be great if answers to these are covered in the TSC meeting.

 

The response “you need security waivers” (for a past release!) dodges all of the issues raised above and really does nothing to address the 4 issues above.

 

Allan Clarke

Plastic PTL

 

PS - It is possible (maybe probable) that I have misunderstandings here, so please feel free to correct me.

 

From: Anil Belur <abelur@...>
Date: Thursday, March 5, 2020 at 3:45 PM
To: Allan <aclarke@...>
Cc: tsc <TSC@...>, Thanh Ha <thanh.ha@...>, Jordan Conway <jconway@...>, Andrew Grimberg <agrimberg@...>, Casey Cain <ccain@...>
Subject: Re: [OpenDaylight TSC] Issue with Linux Foundation and expectations on ODL projects

 

 

 

On Fri, Mar 6, 2020 at 2:05 AM Allan <aclarke@...> wrote:

Greetings!

 

I have been trying to get a new release of the Plastic sub-project out for 3 weeks now and have been clogged up in LF helpdesk.

 

*Summary*

 

LF is not allowing newer release of Plastic 2.1.7 that fixes 3rd party vulnerabilities already in 2.1.6 release.

LF wants ODL after-the-fact approval for Plastic 2.1.6 that is already publicly available.

Both LF tooling (Nexus IQ) and vulnerability process is broken.

 

*Details*

 

Here is the sequence of events AFAIKT:

 

  • Plastic 2.1.6 released (months ago)
  • LF silently changes release process to require Nexus IQ passing (no docs, no links to help PTLs BTW)
  • Plastic 2.1.7 candidate build successful but not available for testing
  • LF helpdesk says Nexus IQ violations making build unavailable
  • (Older version of Guava and Groovy have exposure on features not used by Plastic)
  • LF finally gets accounts and links fixed so Nexus IQ reports are available to PTL
  • New version of Plastic 2.1.7 candidate build (violations fixed)
  • Build still not available due to “violations” (what???)
  • Nexus IQ report is all screwed up in the UI, mixing 2.1.6 and 2.1.7 up, mislabeling, clearly buggy
  • Nexus IQ report appears to be showing old violations against ALREADY RELEASED 2.1.6
  • LF says because security violations are involved, the ODL Security group needs waivers.

 

*Conclusion*

 

I would like to release Plastic 2.1.7. It has improvements and fixes violations in 3rd party libraries.

It has been languishing and holding up the next major release.

I would like a release process that understands when “the horse has left the barn” and that thinks it is a good thing when a new release fixes vulnerabilities in an old release.

 

Allan Clarke

Plastic PTL

 

 

 

Greetings Allan:

I understand the concerns on the delay in releasing Plastic, please find my response below.

 
1. The policy violations are security issues outside the scope of LF/RE's to determine if they can be waived.

2. The policy violations showing up on stage repositories is a "feature" and not a "bug", and a proactive way to ensure these violations are going to be addressed early on before a release. 

3. The violations seen recently in plastic is a result of updating the "Nexus platform plugin", which is working as expected and not a result of any to Nexus repository level setting. 

4. It's seldom up to LF or the PTL's to waive IQ policy violations, waivers can only come from the ODL security team as approved by the TSC.

I've also set this up as a topic on today's TSC agenda.  

 

Regards,

Anil


Re: Issue with Linux Foundation and expectations on ODL projects

Anil Belur
 



On Fri, Mar 6, 2020 at 2:05 AM Allan <aclarke@...> wrote:

Greetings!

 

I have been trying to get a new release of the Plastic sub-project out for 3 weeks now and have been clogged up in LF helpdesk.

 

*Summary*

 

LF is not allowing newer release of Plastic 2.1.7 that fixes 3rd party vulnerabilities already in 2.1.6 release.

LF wants ODL after-the-fact approval for Plastic 2.1.6 that is already publicly available.

Both LF tooling (Nexus IQ) and vulnerability process is broken.

 

*Details*

 

Here is the sequence of events AFAIKT:

 

  • Plastic 2.1.6 released (months ago)
  • LF silently changes release process to require Nexus IQ passing (no docs, no links to help PTLs BTW)
  • Plastic 2.1.7 candidate build successful but not available for testing
  • LF helpdesk says Nexus IQ violations making build unavailable
  • (Older version of Guava and Groovy have exposure on features not used by Plastic)
  • LF finally gets accounts and links fixed so Nexus IQ reports are available to PTL
  • New version of Plastic 2.1.7 candidate build (violations fixed)
  • Build still not available due to “violations” (what???)
  • Nexus IQ report is all screwed up in the UI, mixing 2.1.6 and 2.1.7 up, mislabeling, clearly buggy
  • Nexus IQ report appears to be showing old violations against ALREADY RELEASED 2.1.6
  • LF says because security violations are involved, the ODL Security group needs waivers.

 

*Conclusion*

 

I would like to release Plastic 2.1.7. It has improvements and fixes violations in 3rd party libraries.

It has been languishing and holding up the next major release.

I would like a release process that understands when “the horse has left the barn” and that thinks it is a good thing when a new release fixes vulnerabilities in an old release.

 

Allan Clarke

Plastic PTL

 



Greetings Allan:

I understand the concerns on the delay in releasing Plastic, please find my response below.
 
1. The policy violations are security issues outside the scope of LF/RE's to determine if they can be waived.
2. The policy violations showing up on stage repositories is a "feature" and not a "bug", and a proactive way to ensure these violations are going to be addressed early on before a release. 
3. The violations seen recently in plastic is a result of updating the "Nexus platform plugin", which is working as expected and not a result of any to Nexus repository level setting. 
4. It's seldom up to LF or the PTL's to waive IQ policy violations, waivers can only come from the ODL security team as approved by the TSC.

I've also set this up as a topic on today's TSC agenda.  


Regards,
Anil


Re: Issue with Linux Foundation and expectations on ODL projects

Abhijit Kumbhare
 

Yes - let us discuss it tonight at the TSC meeting.


On Thu, Mar 5, 2020 at 10:47 AM Luis Gomez <ecelgp@...> wrote:
Abhijit, can we bring this topic in tonight’s TSC?

BR/Luis

Begin forwarded message:

From: "Allan" <aclarke@...>
Subject: [OpenDaylight TSC] Issue with Linux Foundation and expectations on ODL projects
Date: March 5, 2020 at 8:05:00 AM PST
To: tsc <TSC@...>
Cc: Thanh Ha <thanh.ha@...>

Greetings!
 
I have been trying to get a new release of the Plastic sub-project out for 3 weeks now and have been clogged up in LF helpdesk. 
 
*Summary*
 
LF is not allowing newer release of Plastic 2.1.7 that fixes 3rdparty vulnerabilities already in 2.1.6 release.
LF wants ODL after-the-fact approval for Plastic 2.1.6 that is already publicly available. 
Both LF tooling (Nexus IQ) and vulnerability process is broken.
 
*Details*
 
Here is the sequence of events AFAIKT:
 
  • Plastic 2.1.6 released (months ago)
  • LF silently changes release process to require Nexus IQ passing (no docs, no links to help PTLs BTW)
  • Plastic 2.1.7 candidate build successful but not available for testing
  • LF helpdesk says Nexus IQ violations making build unavailable
  • (Older version of Guava and Groovy have exposure on features not used by Plastic)
  • LF finally gets accounts and links fixed so Nexus IQ reports are available to PTL
  • New version of Plastic 2.1.7 candidate build (violations fixed)
  • Build still not available due to “violations” (what???)
  • Nexus IQ report is all screwed up in the UI, mixing 2.1.6 and 2.1.7 up, mislabeling, clearly buggy
  • Nexus IQ report appears to be showing old violations against ALREADY RELEASED 2.1.6
  • LF says because security violations are involved, the ODL Security group needs waivers.
 
*Conclusion*
 
I would like to release Plastic 2.1.7. It has improvements and fixes violations in 3rd party libraries.
It has been languishing and holding up the next major release.
I would like a release process that understands when “the horse has left the barn” and that thinks it is a good thing when a new release fixes vulnerabilities in an old release.
 
Allan Clarke
Plastic PTL
 


Issue with Linux Foundation and expectations on ODL projects

Luis Gomez
 

Abhijit, can we bring this topic in tonight’s TSC?

BR/Luis

Begin forwarded message:

From: "Allan" <aclarke@...>
Subject: [OpenDaylight TSC] Issue with Linux Foundation and expectations on ODL projects
Date: March 5, 2020 at 8:05:00 AM PST
To: tsc <TSC@...>
Cc: Thanh Ha <thanh.ha@...>

Greetings!
 
I have been trying to get a new release of the Plastic sub-project out for 3 weeks now and have been clogged up in LF helpdesk. 
 
*Summary*
 
LF is not allowing newer release of Plastic 2.1.7 that fixes 3rdparty vulnerabilities already in 2.1.6 release.
LF wants ODL after-the-fact approval for Plastic 2.1.6 that is already publicly available. 
Both LF tooling (Nexus IQ) and vulnerability process is broken.
 
*Details*
 
Here is the sequence of events AFAIKT:
 
  • Plastic 2.1.6 released (months ago)
  • LF silently changes release process to require Nexus IQ passing (no docs, no links to help PTLs BTW)
  • Plastic 2.1.7 candidate build successful but not available for testing
  • LF helpdesk says Nexus IQ violations making build unavailable
  • (Older version of Guava and Groovy have exposure on features not used by Plastic)
  • LF finally gets accounts and links fixed so Nexus IQ reports are available to PTL
  • New version of Plastic 2.1.7 candidate build (violations fixed)
  • Build still not available due to “violations” (what???)
  • Nexus IQ report is all screwed up in the UI, mixing 2.1.6 and 2.1.7 up, mislabeling, clearly buggy
  • Nexus IQ report appears to be showing old violations against ALREADY RELEASED 2.1.6
  • LF says because security violations are involved, the ODL Security group needs waivers.
 
*Conclusion*
 
I would like to release Plastic 2.1.7. It has improvements and fixes violations in 3rd party libraries.
It has been languishing and holding up the next major release.
I would like a release process that understands when “the horse has left the barn” and that thinks it is a good thing when a new release fixes vulnerabilities in an old release.
 
Allan Clarke
Plastic PTL
 


Issue with Linux Foundation and expectations on ODL projects

Allan
 

Greetings!

 

I have been trying to get a new release of the Plastic sub-project out for 3 weeks now and have been clogged up in LF helpdesk.

 

*Summary*

 

LF is not allowing newer release of Plastic 2.1.7 that fixes 3rd party vulnerabilities already in 2.1.6 release.

LF wants ODL after-the-fact approval for Plastic 2.1.6 that is already publicly available.

Both LF tooling (Nexus IQ) and vulnerability process is broken.

 

*Details*

 

Here is the sequence of events AFAIKT:

 

  • Plastic 2.1.6 released (months ago)
  • LF silently changes release process to require Nexus IQ passing (no docs, no links to help PTLs BTW)
  • Plastic 2.1.7 candidate build successful but not available for testing
  • LF helpdesk says Nexus IQ violations making build unavailable
  • (Older version of Guava and Groovy have exposure on features not used by Plastic)
  • LF finally gets accounts and links fixed so Nexus IQ reports are available to PTL
  • New version of Plastic 2.1.7 candidate build (violations fixed)
  • Build still not available due to “violations” (what???)
  • Nexus IQ report is all screwed up in the UI, mixing 2.1.6 and 2.1.7 up, mislabeling, clearly buggy
  • Nexus IQ report appears to be showing old violations against ALREADY RELEASED 2.1.6
  • LF says because security violations are involved, the ODL Security group needs waivers.

 

*Conclusion*

 

I would like to release Plastic 2.1.7. It has improvements and fixes violations in 3rd party libraries.

It has been languishing and holding up the next major release.

I would like a release process that understands when “the horse has left the barn” and that thinks it is a good thing when a new release fixes vulnerabilities in an old release.

 

Allan Clarke

Plastic PTL

 


TSC Meeting for March 5, 2020 at 10 pm Pacific - Agenda

Abhijit Kumbhare
 

Next TSC meeting is March 5, 2020 at 10 pm Pacific Time. The zoom session for the meeting is: https://zoom.us/j/657152618.

Agenda for this meeting is at:


If you need to add anything, please let me know.

Thanks,
Abhijit


Re: Daniel De La Rosa to proxy for me in TSC APAC Meeting (3/5/2020)

Abhijit Kumbhare
 

Thanks for letting us know.


On Wed, Mar 4, 2020 at 9:38 PM JamO Luhrsen <jluhrsen@...> wrote:
Thanks,
JamO


Daniel De La Rosa to proxy for me in TSC APAC Meeting (3/5/2020)

JamO Luhrsen
 

Thanks,
JamO


Re: Wiki Migration Update - PTL Action Needed

Abhijit Kumbhare
 

Awesome - thanks!


On Wed, Mar 4, 2020 at 2:28 PM Casey Cain <ccain@...> wrote:
Hello, everyone.

I wanted to provide a brief update on the migration to Confluence from MediaWiki.

I have updated all of the existing Project pages listed on the new wiki with a new Project Template to simplify the migration process.  I have also created a new page that explains how to create a new Project Page and Release Plan from a pre-made template: https://wiki.lfnetworking.org/x/pAD_AQ
I will demo this on the next TSC Call

All PTLs should look to import their project data from https://wiki-archive.opendaylight.org/view/Project_list to the new wiki.
Most data can simply be copy and pasted directly from MediaWiki.  Please just remember to update any links that may break during the transfer process.

PTLs should also update their quick descriptions and link to their latest documentation from the Projects Page.  I have completed this for some projects as an example.

If you have any questions or need assistance with your Project migration, please let me know.

Best,
Casey Cain
Technical Program Manager / Community Architect
Linux Foundation
_________________
IRC - CaseyLF
WeChat - okaru6


Wiki Migration Update - PTL Action Needed

Casey Cain
 

Hello, everyone.

I wanted to provide a brief update on the migration to Confluence from MediaWiki.

I have updated all of the existing Project pages listed on the new wiki with a new Project Template to simplify the migration process.  I have also created a new page that explains how to create a new Project Page and Release Plan from a pre-made template: https://wiki.lfnetworking.org/x/pAD_AQ
I will demo this on the next TSC Call

All PTLs should look to import their project data from https://wiki-archive.opendaylight.org/view/Project_list to the new wiki.
Most data can simply be copy and pasted directly from MediaWiki.  Please just remember to update any links that may break during the transfer process.

PTLs should also update their quick descriptions and link to their latest documentation from the Projects Page.  I have completed this for some projects as an example.

If you have any questions or need assistance with your Project migration, please let me know.

Best,
Casey Cain
Technical Program Manager / Community Architect
Linux Foundation
_________________
IRC - CaseyLF
WeChat - okaru6


Re: [integration-dev] [release] [it-infrastructure-alerts][notice] ODL Jenkins maintenance window - 1600-1800 PST, Mar 01, 2020.

Andrew Grimberg
 

Ok, we should be good now. I've updated the plugin, verified that builds
of ci-management-cfg-merge should _not_ destroy the cloud config again
and released the build queue.

We should be good now. Sorry for all the churn on this. We're working on
developing a new method for doing the community manageable parts of
Jenkins to be less brittle. Our cloud management scripting while it
works is unfortunately subject to getting messed up by API changes in
the plugin.

-Andy-

On 2020-03-03 10:09, Andrew Grimberg via Lists.Opendaylight.Org wrote:
We're going to be taking another brief outage on the Jenkins node.

While we got things up and working again it all came to a halt when the
regularly schedule ci-management-cfg-merge job fired and wiped out the
cloud configuration.

It looks like the version of the OpenStack plugin we're running is not
compatible with the latest version of global-jjb. We're going to change
the plugin to the version that I just verified works on the ODL sandbox.

-Andy-

On 2020-03-02 23:55, Abhijit Kumbhare wrote:
Thanks for the update. Hopefully gets resolved soon.

On Mon, Mar 2, 2020 at 11:14 PM Anil Belur <abelur@...
<mailto:abelur@...>> wrote:

Hello all,

The maintenance work is now complete. We've had to copy all plugins
from sandbox over to releng, since resolving the dependencies
manually is not straight forward and Jenkins plugin management does
not handle dependencies as well as packaging. We have an existing
backup of the plugin directory. Going forward, if we have any
missing plugins on the production/releng that will need to be installed.

Note: we are seeing a metadata issue on the cloud, when the nodes
are coming online, which is causing the Jenkins jobs to fail. I'm
working with the cloud provider to get this resolved. 

Apologies for any inconvenience. 

Thanks,
Anil

On Thu, Feb 27, 2020 at 1:35 PM Anil Belur via
Lists.Opendaylight.Org <http://Lists.Opendaylight.Org>
<abelur=linuxfoundation.org@...
<mailto:linuxfoundation.org@...>> wrote:

What: LF will perform maintenance on ODL Jenkins servers to
upgrade the plugins to the latest.

When: 1600-1800 PST, Sunday, Mar 01, 2020

Why: The latest OpenStack API requires OpenStack-clouds plugin
updated and also many other plugins outdated and require to be
updated. 
 
Impact: All ODL Jenkins (sandbox/releng) may be inaccessible
during this time and
Jenkins will be put in shutdown mode before the window starts
and any long-running Jenkins jobs _will_ be canceled if they
don't complete before the start of the window.

Notices will be posted to the mailing lists and in #opendaylight
on Freenode at the start and end of the maintenance.

Thanks,
Anil Belur






--
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation


Re: [integration-dev] [release] [it-infrastructure-alerts][notice] ODL Jenkins maintenance window - 1600-1800 PST, Mar 01, 2020.

Andrew Grimberg
 

We're going to be taking another brief outage on the Jenkins node.

While we got things up and working again it all came to a halt when the
regularly schedule ci-management-cfg-merge job fired and wiped out the
cloud configuration.

It looks like the version of the OpenStack plugin we're running is not
compatible with the latest version of global-jjb. We're going to change
the plugin to the version that I just verified works on the ODL sandbox.

-Andy-

On 2020-03-02 23:55, Abhijit Kumbhare wrote:
Thanks for the update. Hopefully gets resolved soon.

On Mon, Mar 2, 2020 at 11:14 PM Anil Belur <abelur@...
<mailto:abelur@...>> wrote:

Hello all,

The maintenance work is now complete. We've had to copy all plugins
from sandbox over to releng, since resolving the dependencies
manually is not straight forward and Jenkins plugin management does
not handle dependencies as well as packaging. We have an existing
backup of the plugin directory. Going forward, if we have any
missing plugins on the production/releng that will need to be installed.

Note: we are seeing a metadata issue on the cloud, when the nodes
are coming online, which is causing the Jenkins jobs to fail. I'm
working with the cloud provider to get this resolved. 

Apologies for any inconvenience. 

Thanks,
Anil

On Thu, Feb 27, 2020 at 1:35 PM Anil Belur via
Lists.Opendaylight.Org <http://Lists.Opendaylight.Org>
<abelur=linuxfoundation.org@...
<mailto:linuxfoundation.org@...>> wrote:

What: LF will perform maintenance on ODL Jenkins servers to
upgrade the plugins to the latest.

When: 1600-1800 PST, Sunday, Mar 01, 2020

Why: The latest OpenStack API requires OpenStack-clouds plugin
updated and also many other plugins outdated and require to be
updated. 
 
Impact: All ODL Jenkins (sandbox/releng) may be inaccessible
during this time and
Jenkins will be put in shutdown mode before the window starts
and any long-running Jenkins jobs _will_ be canceled if they
don't complete before the start of the window.

Notices will be posted to the mailing lists and in #opendaylight
on Freenode at the start and end of the maintenance.

Thanks,
Anil Belur




--
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation


Re: [integration-dev] [release] [it-infrastructure-alerts][notice] ODL Jenkins maintenance window - 1600-1800 PST, Mar 01, 2020.

Abhijit Kumbhare
 

Thanks for the update. Hopefully gets resolved soon.

On Mon, Mar 2, 2020 at 11:14 PM Anil Belur <abelur@...> wrote:
Hello all,

The maintenance work is now complete. We've had to copy all plugins from sandbox over to releng, since resolving the dependencies manually is not straight forward and Jenkins plugin management does not handle dependencies as well as packaging. We have an existing backup of the plugin directory. Going forward, if we have any missing plugins on the production/releng that will need to be installed.

Note: we are seeing a metadata issue on the cloud, when the nodes are coming online, which is causing the Jenkins jobs to fail. I'm working with the cloud provider to get this resolved. 

Apologies for any inconvenience. 

Thanks,
Anil

On Thu, Feb 27, 2020 at 1:35 PM Anil Belur via Lists.Opendaylight.Org <abelur=linuxfoundation.org@...> wrote:
What: LF will perform maintenance on ODL Jenkins servers to upgrade the plugins to the latest.

When: 1600-1800 PST, Sunday, Mar 01, 2020

Why: The latest OpenStack API requires OpenStack-clouds plugin updated and also many other plugins outdated and require to be updated. 
 
Impact: All ODL Jenkins (sandbox/releng) may be inaccessible during this time and
Jenkins will be put in shutdown mode before the window starts and any long-running Jenkins jobs _will_ be canceled if they don't complete before the start of the window.

Notices will be posted to the mailing lists and in #opendaylight on Freenode at the start and end of the maintenance.

Thanks,
Anil Belur



Re: [release] [it-infrastructure-alerts][notice] ODL Jenkins maintenance window - 1600-1800 PST, Mar 01, 2020.

Anil Belur
 

Hello all,

The maintenance work is now complete. We've had to copy all plugins from sandbox over to releng, since resolving the dependencies manually is not straight forward and Jenkins plugin management does not handle dependencies as well as packaging. We have an existing backup of the plugin directory. Going forward, if we have any missing plugins on the production/releng that will need to be installed.

Note: we are seeing a metadata issue on the cloud, when the nodes are coming online, which is causing the Jenkins jobs to fail. I'm working with the cloud provider to get this resolved. 

Apologies for any inconvenience. 

Thanks,
Anil

On Thu, Feb 27, 2020 at 1:35 PM Anil Belur via Lists.Opendaylight.Org <abelur=linuxfoundation.org@...> wrote:

What: LF will perform maintenance on ODL Jenkins servers to upgrade the plugins to the latest.

When: 1600-1800 PST, Sunday, Mar 01, 2020

Why: The latest OpenStack API requires OpenStack-clouds plugin updated and also many other plugins outdated and require to be updated. 
 
Impact: All ODL Jenkins (sandbox/releng) may be inaccessible during this time and
Jenkins will be put in shutdown mode before the window starts and any long-running Jenkins jobs _will_ be canceled if they don't complete before the start of the window.

Notices will be posted to the mailing lists and in #opendaylight on Freenode at the start and end of the maintenance.

Thanks,
Anil Belur


Re: [release] [it-infrastructure-alerts][notice] ODL Jenkins maintenance window - 1600-1800 PST, Mar 01, 2020.

Anil Belur
 

With the Jenkins plugin updates on production, we are seeing some dependencies errors between plugins is causing Jenkins to throw up errors on boot.
Working on resolving the dependencies ATM.

Dependency errors:
Some plugins could not be loaded due to unsatisfied dependencies. Fix these issues and restart Jenkins to restore the functionality provided by these plugins.
Pipeline: Groovy version 2.80
Script Security Plugin version 1.58 is older than required. To fix, install version 1.63 or later.
Command Agent Launcher Plugin version 1.4
Script Security Plugin version 1.58 is older than required. To fix, install version 1.68 or later.
Jenkins Git plugin version 4.1.1
Script Security Plugin version 1.58 is older than required. To fix, install version 1.66 or later.
JMS Messaging Plugin version 1.1.13
Script Security Plugin version 1.58 is older than required. To fix, install version 1.68 or later.
Downstream dependency errors:
These plugins failed to load because of one or more of the errors above. Fix those and these plugins will load again.
Pipeline: Declarative Extension Points API version 1.5.1
Pipeline: Groovy version 2.80 failed to load. Fix this plugin first.
Pipeline Graph Analysis Plugin version 1.10
Pipeline: Groovy version 2.80 failed to load. Fix this plugin first.
Pipeline version 2.6
Pipeline: Stage View Plugin version 2.13 failed to load. Fix this plugin first.
Pipeline: Stage View Plugin version 2.13
Pipeline: REST API Plugin version 2.13 failed to load. Fix this plugin first.
Forensics API Plugin version 0.7.0
Pipeline: Groovy version 2.80 failed to load. Fix this plugin first.
Maven Cascade Release Plugin version 1.3.2
Jenkins Git plugin version 4.1.1 failed to load. Fix this plugin first.
Pipeline: Declarative version 1.5.1
Pipeline: Shared Groovy Libraries version 2.15 failed to load. Fix this plugin first.
Pipeline: Shared Groovy Libraries version 2.15
Pipeline: Groovy version 2.80 failed to load. Fix this plugin first.
Warnings Next Generation Plugin version 8.0.0
Forensics API Plugin version 0.7.0 failed to load. Fix this plugin first.
Pipeline: Multibranch version 2.21
Pipeline: Groovy version 2.80 failed to load. Fix this plugin first.
Gradle Plugin version 1.36
Pipeline: Groovy version 2.80 failed to load. Fix this plugin first.
Docker Pipeline version 1.22
Pipeline: Groovy version 2.80 failed to load. Fix this plugin first.
Pipeline: REST API Plugin version 2.13
Pipeline Graph Analysis Plugin version 1.10 failed to load. Fix this plugin first.
Pipeline: Declarative Agent API version 1.1.1
Pipeline: Declarative Extension Points API version 1.5.1 failed to load. Fix this plugin first.

On Thu, Feb 27, 2020 at 1:35 PM Anil Belur via Lists.Opendaylight.Org <abelur=linuxfoundation.org@...> wrote:

What: LF will perform maintenance on ODL Jenkins servers to upgrade the plugins to the latest.

When: 1600-1800 PST, Sunday, Mar 01, 2020

Why: The latest OpenStack API requires OpenStack-clouds plugin updated and also many other plugins outdated and require to be updated. 
 
Impact: All ODL Jenkins (sandbox/releng) may be inaccessible during this time and
Jenkins will be put in shutdown mode before the window starts and any long-running Jenkins jobs _will_ be canceled if they don't complete before the start of the window.

Notices will be posted to the mailing lists and in #opendaylight on Freenode at the start and end of the maintenance.

Thanks,
Anil Belur


[it-infrastructure-alerts][notice] ODL Jenkins maintenance window - 1600-1800 PST, Mar 01, 2020.

Anil Belur
 

What: LF will perform maintenance on ODL Jenkins servers to upgrade the plugins to the latest.

When: 1600-1800 PST, Sunday, Mar 01, 2020

Why: The latest OpenStack API requires OpenStack-clouds plugin updated and also many other plugins outdated and require to be updated. 
 
Impact: All ODL Jenkins (sandbox/releng) may be inaccessible during this time and
Jenkins will be put in shutdown mode before the window starts and any long-running Jenkins jobs _will_ be canceled if they don't complete before the start of the window.

Notices will be posted to the mailing lists and in #opendaylight on Freenode at the start and end of the maintenance.

Thanks,
Anil Belur

1821 - 1840 of 14349