Re: [onap-tsc] ONAP Project Lifecycle: recommended actions

[Kenny Paul]

>From my POV, setting it as a TSC policy is the simplest approach. 

Order of operations for this stuff is:

*   LFN Charter <- Legal document over LFN
*   ONAP Charter -< Legal document over ONAP
*   ONAP Community Document <-  Rules for community management
*   TSC Policies <-  Operational best practices to be followed

 

The first 3 all require legal review.

-kenny

 

From: onap-tsc@lists.onap.org  On Behalf Of Jason Hunt
Sent: Friday, June 5, 2020 12:46 PM
To: onap-tsc@lists.onap.org
Cc: az9...@att.com; k.opas...@samsung.com; onap-rele...@lists.onap.org; 
onap-tsc@lists.onap.org; p.paw...@f5.com
Subject: Re: [onap-tsc] ONAP Project Lifecycle: recommended actions

 

 

I don't think we'd want to codify that list of criteria into the technical 
community document, so what we might want to do is amend the document to 
require a Security Subcommittee review prior to a project moving to the mature 
or core phases.  This would need to be voted on by the TSC.  Should we cover it 
in the next TSC meeting?




Regards,
Jason Hunt
Distinguished Engineer, IBM

Phone: +1-314-749-7422
Email: djh...@us.ibm.com <mailto:djh...@us.ibm.com> 
Twitter: @DJHunt

 

 

- Original message -
From: "Sylvain Desbureaux via lists.onap.org" 
mailto:sylvain.desbureaux=orange@lists.onap.org> >
Sent by: onap-tsc@lists.onap.org <mailto:onap-tsc@lists.onap.org> 
To: Krzysztof Opasiak mailto:k.opas...@samsung.com> >, 
"onap-tsc@lists.onap.org <mailto:onap-tsc@lists.onap.org> " 
mailto:onap-tsc@lists.onap.org> >
Cc: "az9...@att.com <mailto:az9...@att.com> " mailto:az9...@att.com> >, "onap-rele...@lists.onap.org 
<mailto:onap-rele...@lists.onap.org> " mailto:onap-rele...@lists.onap.org> >, "p.paw...@f5.com 
<mailto:p.paw...@f5.com> " mailto:p.paw...@f5.com> >
Subject: [EXTERNAL] Re: [onap-tsc] ONAP Project Lifecycle: recommended actions
Date: Fri, Jun 5, 2020 10:08 AM


+1
and one day we may need to be able to add new criterias for the ops
(I'm thinking opentracing compatibility, prometheus endpoints, ...)

De : Krzysztof Opasiak [k.opas...@samsung.com]
Envoyé : vendredi 5 juin 2020 16:53
À : onap-tsc@lists.onap.org <mailto:onap-tsc@lists.onap.org> 
Cc : az9...@att.com <mailto:az9...@att.com> ; onap-rele...@lists.onap.org 
<mailto:onap-rele...@lists.onap.org> ; p.paw...@f5.com <mailto:p.paw...@f5.com> 
; DESBUREAUX Sylvain TGI/OLN
Objet : Re: [onap-tsc] ONAP Project Lifecycle: recommended actions

... and correct Pawel Pawlak email;)


On 05.06.2020 16:53, Krzysztof Opasiak wrote:
> Hi Jason,
>
> On 05.06.2020 16:27, Jason Hunt wrote:
>>Krzysztof,
>> Great point.  There are two options to address it:
>> 1. The TSC votes to amend the Technical Community Document to include
>> security in the criteria for the mature state
>> 2.  We modify the template for the maturity reviews to allow for
>> security information to be included under the "mature artifacts"
>> criteria.  The TSC would then include that in its decision whether a
>> project has met the "mature artifacts" portion of the criteria.
>
> I'll deffer this to Pawel & Amy to decide which way to go.
>
>> I would prefer the latter and am happy to make the update.  Please let
>> me know if there is suggested input you would like to see from projects
>> so that we can update the template accordingly.
>
> I'd definitely would like to make sure that before any project is called
> mature it:
>
> 1) Does not hardcode any credentials in the container & OOM helm charts
> 2) Its docker containers are free of any hardcoded certificates
> 3) It doesn't use static TLS certificates but obtains them at runtime
> 4) It has no open OJSI tickets
> 5) It has no known vulnerabilities in its direct dependencies
> 6) It uses base image that is free of license violation and
> vulnerabilities (aka recommended by seccom)
> 7) Does not run as a root
> 8) Does not access any DB as root from the application container (unless
> there is a valid reason for that which has been presented & approved by
> SECCOM)
> 9) Does not access any DB that is owned by other service
> 10) Uses only well-known, open source libraries for handling crypto
> 11) Does not contain its own user store
> 12) Can be access & used via ingress controller
> 13) Has no runtime Internet dependencies
> 14) Use secure communication to access anything that is outside of
> kubernetes cluster
> 15) Has no unprotected APIs/UIs exposed
> 16) Has only a single process per container
> 17) Has properly configured liveness & readiness checks
> 18) Container rootfs is mounted read-only
>
> @Pawel
> @Amy
&g

Re: [onap-tsc] ONAP Project Lifecycle: recommended actions

[Eric Debeau via lists.onap.org]

Hello

I believe that we need more formal proof of maturity checked by tools to avoid 
any dispute.


›Successful participation in releases: The project demonstrates stable output 
(code base, documents) within its history of releases in accordance with the 
release policy.

=> How to check that a document is stable ?


›Architecture has been reviewed by the Architecture Committee => It do not see 
a proof a maturity. Every project should pass the Architecture Review and can 
claim to become mature. We should state the project passed the Architecture 
Committe


›Project is active and contributes to ONAP: The project demonstrates a stable 
or increasing number of contributions across recent releases. Contributions are 
commits which got merged to a repository of an ONAP project or a related 
upstream project. Commits can for example be patches to update the requirements 
document of a project, code addition to an ONAP or upstream project repository, 
new test cases and so forth.

=> OK. It is easy to check with bitergia


›Mature artifacts produced: The project demonstrates that the artifacts 
produced by the project are deployable (where applicable) and have been 
successfully deployed, configured and used by end users (typically, service 
providers).

=> Any project can claim that if they are in the release !
=> We need more technical proofs : eg code quality, test coverage...

Best Regards

Eric

De : onap-tsc@lists.onap.org [onap-tsc@lists.onap.org] de la part de Jason Hunt 
[djh...@us.ibm.com]
Envoyé : vendredi 5 juin 2020 21:45
À : onap-tsc@lists.onap.org
Cc : az9...@att.com; k.opas...@samsung.com; onap-rele...@lists.onap.org; 
onap-tsc@lists.onap.org; p.paw...@f5.com
Objet : Re: [onap-tsc] ONAP Project Lifecycle: recommended actions


I don't think we'd want to codify that list of criteria into the technical 
community document, so what we might want to do is amend the document to 
require a Security Subcommittee review prior to a project moving to the mature 
or core phases.  This would need to be voted on by the TSC.  Should we cover it 
in the next TSC meeting?


Regards,
Jason Hunt
Distinguished Engineer, IBM

Phone: +1-314-749-7422
Email: djh...@us.ibm.com
Twitter: @DJHunt


- Original message -
From: "Sylvain Desbureaux via lists.onap.org" 

Sent by: onap-tsc@lists.onap.org
To: Krzysztof Opasiak , "onap-tsc@lists.onap.org" 

Cc: "az9...@att.com" , "onap-rele...@lists.onap.org" 
, "p.paw...@f5.com" 
Subject: [EXTERNAL] Re: [onap-tsc] ONAP Project Lifecycle: recommended actions
Date: Fri, Jun 5, 2020 10:08 AM

+1
and one day we may need to be able to add new criterias for the ops
(I'm thinking opentracing compatibility, prometheus endpoints, ...)

De : Krzysztof Opasiak [k.opas...@samsung.com]
Envoyé : vendredi 5 juin 2020 16:53
À : onap-tsc@lists.onap.org
Cc : az9...@att.com; onap-rele...@lists.onap.org; p.paw...@f5.com; DESBUREAUX 
Sylvain TGI/OLN
Objet : Re: [onap-tsc] ONAP Project Lifecycle: recommended actions

... and correct Pawel Pawlak email;)


On 05.06.2020 16:53, Krzysztof Opasiak wrote:
> Hi Jason,
>
> On 05.06.2020 16:27, Jason Hunt wrote:
>>Krzysztof,
>> Great point.  There are two options to address it:
>> 1. The TSC votes to amend the Technical Community Document to include
>> security in the criteria for the mature state
>> 2.  We modify the template for the maturity reviews to allow for
>> security information to be included under the "mature artifacts"
>> criteria.  The TSC would then include that in its decision whether a
>> project has met the "mature artifacts" portion of the criteria.
>
> I'll deffer this to Pawel & Amy to decide which way to go.
>
>> I would prefer the latter and am happy to make the update.  Please let
>> me know if there is suggested input you would like to see from projects
>> so that we can update the template accordingly.
>
> I'd definitely would like to make sure that before any project is called
> mature it:
>
> 1) Does not hardcode any credentials in the container & OOM helm charts
> 2) Its docker containers are free of any hardcoded certificates
> 3) It doesn't use static TLS certificates but obtains them at runtime
> 4) It has no open OJSI tickets
> 5) It has no known vulnerabilities in its direct dependencies
> 6) It uses base image that is free of license violation and
> vulnerabilities (aka recommended by seccom)
> 7) Does not run as a root
> 8) Does not access any DB as root from the application container (unless
> there is a valid reason for that which has been presented & approved by
> SECCOM)
> 9) Does not access any DB that is owned by other service
> 10) Uses only well-known, open source libraries for handling crypto
&g

Re: [onap-tsc] ONAP Project Lifecycle: recommended actions

[David McBride]

Hi Jason,

This has been added as an agenda item for Mondays’s PTL meeting.

David

On Thu, Jun 4, 2020 at 3:13 PM Jason Hunt  wrote:

>
> TSC and PTLs,
>
> Per the discussion in today's TSC meeting, we wanted to make everyone
> aware of the ONAP project lifecycle and encourage projects to consider
> their status and any changes.
>
> The current lifecycle is depicted in this diagram:
>
>
>
> The suggestion is that we use this lifecycle to place the ONAP project
> portfolio into three buckets:
>
>
>
> - *Mature projects:* for projects with active release participation &
> solid artifacts; they should submit for a "maturity review"
>
> - *Inactive (Archived) projects*: for projects where there is no longer
> any contributions, they should follow the termination review
>
> - *Other (Incubation) projects*: for those projects that are still active
> but not ready for move to "mature" phase
>
>
>
> For *mature projects*, the TSC encourages qualifying projects to submit
> for a maturity review.  They do this by filling out the template in the
> wiki (https://wiki.onap.org/display/DW/Project+Maturity+Review+Template)
> and send an email to the TSC list.  In order to accelerate reviews (and
> free up time on the TSC calls), we may want to form a working group to do a
> preliminary maturity review for the projects.  The group would submit their
> recommendations to the TSC who would then vote +1/0/-1 for promotion to the
> mature phase.
>
>
> For the *inactive projects*, there is no guidance on who should initiate
> a termination review.  Because there may not be a PTL, perhaps the TSC
> could initiate a termination review for a project.  Again, we may want a
> working group to conduct the steps of the termination review.  This group
> should consist of people who are familiar with the project or at least
> interface with/depend upon the project.  This working group will need to
> walk through the steps of the termination review as outlined here: (scroll
> down)
>
> https://wiki.onap.org/display/DW/ONAP+Project+and+Component+Lifecycle
>
>
>
> All other projects need no action.
>
>
>
> Background slide deck on project lifecycle reviews:
> https://wiki.lfnetworking.org/pages/viewpage.action?pageId=25364127=/25364127/28738708/ONAP%20Proj%20Lifecycle%20and%20Review%2015Jan2020%20v1.pdf
> 
>
>
> Please reply with any questions on the process.
>
>
> Regards,
> Jason Hunt
> Distinguished Engineer, IBM
>
> Phone: +1-314-749-7422
> Email: djh...@us.ibm.com
> Twitter: @DJHunt
>
> 
>
> --
*David McBride*
Release Manager
Linux Foundation Networking (LFN)
Mobile: +1.805.276.8018
Email/Google Talk: dmcbr...@linuxfoundation.org
IRC: dmcbride

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6492): https://lists.onap.org/g/onap-tsc/message/6492
Mute This Topic: https://lists.onap.org/mt/74681700/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-tsc] ONAP Project Lifecycle: recommended actions

[Krzysztof Opasiak via lists.onap.org]

... and correct Pawel Pawlak email;)


On 05.06.2020 16:53, Krzysztof Opasiak wrote:
> Hi Jason,
> 
> On 05.06.2020 16:27, Jason Hunt wrote:
>>    Krzysztof,
>> Great point.  There are two options to address it:
>> 1. The TSC votes to amend the Technical Community Document to include
>> security in the criteria for the mature state
>> 2.  We modify the template for the maturity reviews to allow for
>> security information to be included under the "mature artifacts"
>> criteria.  The TSC would then include that in its decision whether a
>> project has met the "mature artifacts" portion of the criteria.
> 
> I'll deffer this to Pawel & Amy to decide which way to go.
> 
>> I would prefer the latter and am happy to make the update.  Please let
>> me know if there is suggested input you would like to see from projects
>> so that we can update the template accordingly.
> 
> I'd definitely would like to make sure that before any project is called
> mature it:
> 
> 1) Does not hardcode any credentials in the container & OOM helm charts
> 2) Its docker containers are free of any hardcoded certificates
> 3) It doesn't use static TLS certificates but obtains them at runtime
> 4) It has no open OJSI tickets
> 5) It has no known vulnerabilities in its direct dependencies
> 6) It uses base image that is free of license violation and
> vulnerabilities (aka recommended by seccom)
> 7) Does not run as a root
> 8) Does not access any DB as root from the application container (unless
> there is a valid reason for that which has been presented & approved by
> SECCOM)
> 9) Does not access any DB that is owned by other service
> 10) Uses only well-known, open source libraries for handling crypto
> 11) Does not contain its own user store
> 12) Can be access & used via ingress controller
> 13) Has no runtime Internet dependencies
> 14) Use secure communication to access anything that is outside of
> kubernetes cluster
> 15) Has no unprotected APIs/UIs exposed
> 16) Has only a single process per container
> 17) Has properly configured liveness & readiness checks
> 18) Container rootfs is mounted read-only
> 
> @Pawel
> @Amy
> Do you have anything more to add?
> 
>> By the way, for the "core" state of projects (which comes after
>> "mature"), the criteria in the Technical Community Document include:
>> "Stability, Security, Scalability and Performance levels have reached a
>> high bar."
> 
> Right. But it would be great to ensure some "basic" security from
> project which is called mature right?
> 
>>
>> Regards,
>> Jason Hunt
>> Distinguished Engineer, IBM
>>
>> Phone: +1-314-749-7422
>> Email: djh...@us.ibm.com
>> Twitter: @DJHunt
>>
>>  - Original message -
>>  From: "Krzysztof Opasiak via lists.onap.org"
>>  
>>  Sent by: onap-tsc@lists.onap.org
>>  To: onap-tsc@lists.onap.org, onap-rele...@lists.onap.org, Jason Hunt
>>  
>>  Cc: "pawel.pawl...@orange.com" , "ZWARICO,
>>  AMY" 
>>  Subject: [EXTERNAL] Re: [onap-tsc] ONAP Project Lifecycle:
>>  recommended actions
>>  Date: Fri, Jun 5, 2020 9:05 AM
>>  Hi Jason,
>>
>>  On 05.06.2020 00:13, Jason Hunt wrote:
>>   > TSC and PTLs,
>>   > Per the discussion in today's TSC meeting, we wanted to make everyone
>>   > aware of the ONAP project lifecycle and encourage projects to
>>  consider
>>   > their status and any changes.
>>   > The current lifecycle is depicted in this diagram:
>>   >
>>   > The suggestion is that we use this lifecycle to place the ONAP
>>  project
>>   > portfolio into three buckets:
>>   >
>>   > -*Mature projects:*for projects with active release participation &
>>   > solid artifacts; they should submit for a "maturity review"
>>   >
>>   > - *Inactive (Archived) projects*: for projects where there is no
>>  longer
>>   > any contributions, they should follow the termination review
>>   >
>>   > -*Other (Incubation) projects*: for those projects that are still
>>  active
>>   > but not ready for move to "mature" phase
>>   >
>>   > For *mature projects*, the TSC encourages qualifying projects to
>>  submit
>>   > for a maturity review.  They do this by filling out the template
>>  in the
>>   >

Re: [onap-tsc] ONAP Project Lifecycle: recommended actions

[Jason Hunt]

 Krzysztof,
 
Great point.  There are two options to address it:
 
1. The TSC votes to amend the Technical Community Document to include security in the criteria for the mature state
2.  We modify the template for the maturity reviews to allow for security information to be included under the "mature artifacts" criteria.  The TSC would then include that in its decision whether a project has met the "mature artifacts" portion of the criteria.
 
I would prefer the latter and am happy to make the update.  Please let me know if there is suggested input you would like to see from projects so that we can update the template accordingly.
 
By the way, for the "core" state of projects (which comes after "mature"), the criteria in the Technical Community Document include:
 
"Stability, Security, Scalability and Performance levels have reached a high bar."
 
Regards,Jason HuntDistinguished Engineer, IBMPhone: +1-314-749-7422Email: djh...@us.ibm.comTwitter: @DJHunt
 
 
- Original message -From: "Krzysztof Opasiak via lists.onap.org" Sent by: onap-tsc@lists.onap.orgTo: onap-tsc@lists.onap.org, onap-rele...@lists.onap.org, Jason Hunt Cc: "pawel.pawl...@orange.com" , "ZWARICO, AMY" Subject: [EXTERNAL] Re: [onap-tsc] ONAP Project Lifecycle: recommended actionsDate: Fri, Jun 5, 2020 9:05 AM 
Hi Jason,On 05.06.2020 00:13, Jason Hunt wrote:> TSC and PTLs,> Per the discussion in today's TSC meeting, we wanted to make everyone> aware of the ONAP project lifecycle and encourage projects to consider> their status and any changes.> The current lifecycle is depicted in this diagram:>> The suggestion is that we use this lifecycle to place the ONAP project> portfolio into three buckets:>> -*Mature projects:*for projects with active release participation &> solid artifacts; they should submit for a "maturity review">> - *Inactive (Archived) projects*: for projects where there is no longer> any contributions, they should follow the termination review>> -*Other (Incubation) projects*: for those projects that are still active> but not ready for move to "mature" phase>> For *mature projects*, the TSC encourages qualifying projects to submit> for a maturity review.  They do this by filling out the template in the> wiki (https://wiki.onap.org/display/DW/Project+Maturity+Review+Template  > )> and send an email to the TSC list.  In order to accelerate reviews (and> free up time on the TSC calls), we may want to form a working group to> do a preliminary maturity review for the projects.  The group> would submit their recommendations to the TSC who would then vote> +1/0/-1 for promotion to the mature phase.Shouldn't we have any security review before we move project to themature state? There is no single question regarding security in thistemplate...>> For the*inactive projects*, there is no guidance on who should initiate> a termination review.  Because there may not be a PTL, perhaps the TSC> could initiate a termination review for a project.  Again, we may want a> working group to conduct the steps of the termination review.  This> group should consist of people who are familiar with the project or at> least interface with/depend upon the project.  This working group will> need to walk through the steps of the termination review as outlined> here: (scroll down)>> https://wiki.onap.org/display/DW/ONAP+Project+and+Component+Lifecycle  > >> All other projects need no action.>> Background slide deck on project lifecycle reviews:> https://wiki.lfnetworking.org/pages/viewpage.action?pageId=25364127=/25364127/28738708/ONAP%20Proj%20Lifecycle%20and%20Review%2015Jan2020%20v1.pdf  > >> Please reply with any questions on the process.>> Regards,> Jason Hunt> Distinguished Engineer, IBM>> Phone: +1-314-749-7422> Email: djh...@us.ibm.com> Twitter: @DJHunt>>--Krzysztof OpasiakSamsung R Institute PolandSamsung Electronics 
 


_._,_._,_

Links:


You receive all messages sent to this group.





View/Reply Online (#6487) |


  Reply To Group

| Reply To Sender



|

Re: [onap-tsc] ONAP Project Lifecycle: recommended actions

[Krzysztof Opasiak via lists.onap.org]

Hi Jason,

On 05.06.2020 00:13, Jason Hunt wrote:
> TSC and PTLs,
> Per the discussion in today's TSC meeting, we wanted to make everyone 
> aware of the ONAP project lifecycle and encourage projects to consider 
> their status and any changes.
> The current lifecycle is depicted in this diagram:
> 
> The suggestion is that we use this lifecycle to place the ONAP project 
> portfolio into three buckets:
> 
> -*Mature projects:*for projects with active release participation & 
> solid artifacts; they should submit for a "maturity review"
> 
> - *Inactive (Archived) projects*: for projects where there is no longer 
> any contributions, they should follow the termination review
> 
> -*Other (Incubation) projects*: for those projects that are still active 
> but not ready for move to "mature" phase
> 
> For *mature projects*, the TSC encourages qualifying projects to submit 
> for a maturity review.  They do this by filling out the template in the 
> wiki (https://wiki.onap.org/display/DW/Project+Maturity+Review+Template 
> )
>  
> and send an email to the TSC list.  In order to accelerate reviews (and 
> free up time on the TSC calls), we may want to form a working group to 
> do a preliminary maturity review for the projects.  The group 
> would submit their recommendations to the TSC who would then vote 
> +1/0/-1 for promotion to the mature phase.

Shouldn't we have any security review before we move project to the 
mature state? There is no single question regarding security in this 
template...

> 
> For the*inactive projects*, there is no guidance on who should initiate 
> a termination review.  Because there may not be a PTL, perhaps the TSC 
> could initiate a termination review for a project.  Again, we may want a 
> working group to conduct the steps of the termination review.  This 
> group should consist of people who are familiar with the project or at 
> least interface with/depend upon the project.  This working group will 
> need to walk through the steps of the termination review as outlined 
> here: (scroll down)
> 
> https://wiki.onap.org/display/DW/ONAP+Project+and+Component+Lifecycle 
> 
> 
> All other projects need no action.
> 
> Background slide deck on project lifecycle reviews: 
> https://wiki.lfnetworking.org/pages/viewpage.action?pageId=25364127=/25364127/28738708/ONAP%20Proj%20Lifecycle%20and%20Review%2015Jan2020%20v1.pdf
>  
> 
> 
> Please reply with any questions on the process.
> 
> Regards,
> Jason Hunt
> Distinguished Engineer, IBM
> 
> Phone: +1-314-749-7422
> Email: djh...@us.ibm.com
> Twitter: @DJHunt
> 
> 

-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6486): https://lists.onap.org/g/onap-tsc/message/6486
Mute This Topic: https://lists.onap.org/mt/74681700/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-