Re: [onap-tsc] Committer promotion requests for Integration

2019-02-13 Thread Stephen Terrill
Hi,

I just wanted to check the process on this now.  Originally for each the 
committer promotion and new repository requests, the TSC held a vote.  Then 
this was streamlined we decided to have the release responsible, and if it was 
all OK (voted by PTLs, history of Metacritic contribution, a reasonable and 
small number of committers; then release manager OKd and the TSC was informed, 
otherwise it was raised to the TSC by the release manager for further 
discussion and final decision.  We have had a change of guard but no decision 
to re-evaluate the process.  I assume then that we continue to follow the same. 
With this email I wanted to check that we have a common assumption regarding 
this.

BR,

Steve

From: onap-tsc@lists.onap.org  On Behalf Of Yang Xu
Sent: Tuesday 12 February 2019 06:48
To: onap-tsc@lists.onap.org; Jim Baker ; 'Kenny 
Paul' 
Subject: [onap-tsc] Committer promotion requests for Integration

Dear TSC,

Integration team has voted to promote Brian Freeman (5/5 votes) and Mariusz 
Wagner(4/5 votes) to Integration committers. Please see their promotion 
requests here:

https://wiki.onap.org/display/DW/Integration+Committer+Promotion+Requests+for+Brian+Freemam
https://wiki.onap.org/display/DW/Integration+Committer+Promotion+Requests+for+Mariusz+Wagner

Best regards,

-Yang Xu
Integration PTL




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

View/Reply Online (#4623): https://lists.onap.org/g/onap-tsc/message/4623
Mute This Topic: https://lists.onap.org/mt/29747106/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-discuss] ONAP DockerHub migration for docker image releases

2019-02-13 Thread Catherine LEFEVRE
Dear all,

I agree that a better planification upfront would be appreciated so we can 
better assess any impact on the ONAP activities & the ONAP Community.

Can we get confirmation that we will maintain Nexus to be consistent with our 
Casablanca/Casablanca Maintenance Release notes?
If not then we need to understand what’s the plan to minimize the impacts on 
anybody who would like to use the latest Casablanca containers.

Many thanks and regards
Catherine

From: onap-tsc@lists.onap.org [mailto:onap-tsc@lists.onap.org] On Behalf Of Jim 
Baker
Sent: Wednesday, February 13, 2019 2:56 PM
To: morgan.richo...@orange.com
Cc: jwagant...@linuxfoundation.org; kp...@linuxfoundation.org; 
bthu...@linuxfoundation.org; onap-tsc@lists.onap.org; 
onap-disc...@lists.onap.org; onap-rele...@lists.onap.org; DANNO Vincent TGI/OLN 
; LAMBERT Guillaume TGI/OLN 
; OLLIVIER Cédric TGI/OLN 
; cc...@linuxfoundation.org; hagb...@gmail.com
Subject: Re: [onap-tsc] [onap-discuss] ONAP DockerHub migration for docker 
image releases

Greetings Morgan,
Thanks for sharing your concerns. I do know that dockerhub has been discussed 
in the PTL and TSC meetings in the context of Nexus not able to support 
multiple manifests. Additional updates to both forums are planned.

You are aware the current infrastructure is not impacted by enabling DockerHub? 
Also, have you or your team never experienced delays in having to request 
releases?

I cannot speak to any of the earlier situations you cite, and I am interested 
in LFN acting as a transparent, shared objective partner. I'm interested in 
hearing more about how LF can increase transparency? Please share more ideas on 
how to accomplish this.

Thanks for reaching out,
Jim

On Wed, Feb 13, 2019 at 6:38 AM 
mailto:morgan.richo...@orange.com>> wrote:
Hi Jessica,

I was wondering if this option had been discussed at TSC level or in the 
mailing list.
I think it is a good option technically speaking so I am fine with it.
It echoes some current discussions on the tooling at lfnetworking level 
https://wiki.lfnetworking.org/display/LN/Meeting+notes

I am just sometimes a little bit puzzled on the role of LF
G. Orwell wrote “All animals are equal, but some animals are more equal than 
others.”
Within the context of our communities, is LF code more equal than others?
The proposal is very prescriptive (forcing PTL to have a docker hub account - I 
could imagine it could be incompatible with company policies) and beyond a 
support task.

Some months ago, there was a huge refactoring of jjb jobs before an ODL release 
(but due to the release cadence it is necessarily always closed to a 
release...) .
The decision had been taken a little bit unilaterally by LF, some projects had 
to adapt at the last minute to be in the release.
Another illustration could be the resource allocation at lfnetworking level. As 
an example in OPNFV the rules for the hardware allocation are not fully clear. 
Some projects have lots of machines, some not, some projects have to wait for 
months where some other got immediately the hardware they need, and often 
without a strong correlation with the project activity and the code produced.
More transparency on LF side would be better for the whole communities.

I imagine that the goal is to be quick and efficient but the road to hell is 
paved with good intentions!

One more time, as a community member, I think that moving to Docker Hub is the 
good way to go.

Regards

/Morgan

Le lundi 11 février 2019 à 18:38 -0800, Jessica Wagantall a écrit :
Dear ONAP team,

I would like to announce that we are working on a migration for docker images 
from Nexus3 to DockerHub.
The main motivation to do so is to allow teams to move towards a model that 
will easily allow them to manage their own docker image releases more 
independently.

We have several task in progress, and I would like to summarize them here:
·LF is working on 2 new global-jjb templates for docker verify and 
docker merge.
·The merge job will post Snapshot and Staging images directly into 
DockerHub.
·Releases to DockerHub will be made on demand as PTLs wish.
·For now, only PTLs will be given these permissions, but extended 
permissions to committers will be considered as we go.
·The process to release will be done manually by PTLs similarly to how 
LF does it (docker pull image, docker tag using release tag #.#.#, docker push 
to DockerHub).
·We will work with tech teams to move to the new docker templates in 
global-jjb and eventually remove local templates.
·To avoid overhead, we will only be making DockerHub publications of 
Snapshots and Staging artifacts on new merge and not on a daily basis. (We want 
to minimize the 

Re: [onap-tsc] [onap-discuss] ONAP DockerHub migration for docker image releases

2019-02-13 Thread Jim Baker
Greetings Morgan,
Thanks for sharing your concerns. I do know that dockerhub has been
discussed in the PTL and TSC meetings in the context of Nexus not able to
support multiple manifests. Additional updates to both forums are planned.

You are aware the current infrastructure is not impacted by enabling
DockerHub? Also, have you or your team never experienced delays in having
to request releases?

I cannot speak to any of the earlier situations you cite, and I am
interested in LFN acting as a transparent, shared objective partner. I'm
interested in hearing more about how LF can increase transparency? Please
share more ideas on how to accomplish this.

Thanks for reaching out,
Jim

On Wed, Feb 13, 2019 at 6:38 AM  wrote:

> Hi Jessica,
>
> I was wondering if this option had been discussed at TSC level or in the
> mailing list.
> I think it is a good option technically speaking so I am fine with it.
> It echoes some current discussions on the tooling at lfnetworking level
> https://wiki.lfnetworking.org/display/LN/Meeting+notes
>
> I am just sometimes a little bit puzzled on the role of LF
> G. Orwell wrote “All animals are equal, but some animals are more equal
> than others.”
> Within the context of our communities, is LF code more equal than others?
> The proposal is very prescriptive (forcing PTL to have a docker hub
> account - I could imagine it could be incompatible with company policies)
> and beyond a support task.
>
> Some months ago, there was a huge refactoring of jjb jobs before an ODL
> release (but due to the release cadence it is necessarily always closed to
> a release...) .
> The decision had been taken a little bit unilaterally by LF, some projects
> had to adapt at the last minute to be in the release.
> Another illustration could be the resource allocation at lfnetworking
> level. As an example in OPNFV the rules for the hardware allocation are not
> fully clear. Some projects have lots of machines, some not, some projects
> have to wait for months where some other got immediately the hardware they
> need, and often without a strong correlation with the project activity and
> the code produced.
> More transparency on LF side would be better for the whole communities.
>
> I imagine that the goal is to be quick and efficient but the road to hell
> is paved with good intentions!
>
> One more time, as a community member, I think that moving to Docker Hub is
> the good way to go.
>
> Regards
>
> /Morgan
>
> Le lundi 11 février 2019 à 18:38 -0800, Jessica Wagantall a écrit :
>
> Dear ONAP team,
>
> I would like to announce that we are working on a migration for docker
> images from Nexus3 to DockerHub.
> The main motivation to do so is to allow teams to move towards a model
> that will easily allow them to manage their own docker image releases more
> independently.
>
> We have several task in progress, and I would like to summarize them here:
>
>- LF is working on 2 new global-jjb templates for docker verify and
>docker merge.
>- The merge job will post Snapshot and Staging images directly into
>DockerHub.
>- Releases to DockerHub will be made on demand as PTLs wish.
>- For now, only PTLs will be given these permissions, but extended
>permissions to committers will be considered as we go.
>- The process to release will be done manually by PTLs similarly to
>how LF does it (docker pull image, docker tag using release tag #.#.#,
>docker push to DockerHub).
>- We will work with tech teams to move to the new docker templates in
>global-jjb and eventually remove local templates.
>- To avoid overhead, we will only be making DockerHub publications of
>Snapshots and Staging artifacts on new merge and not on a daily basis. (We
>want to minimize the resource usage and avoid re-pushing the same image if
>it has not changed).
>- We are going to work on making this transition smooth and switch to
>the new global-jjb jobs once it is confirmed by tech teams that the correct
>images are being posted in DockerHub. This means that some teams might have
>both jobs pushing to Nexus3 and DockerHub at the same time and will be able
>to disable Nexus3 pushes once they are comfortable.
>
>
> As mentioned, LF has started working towards this model and we will let he
> community know on every milestone.
>
> As a first step for the community, particularly PTLs:
> Can we please request all PTLs to register into DockerHub and update their
> DockerHub ID in wiki.onap.org/display/DW/Resources+and+Repositories so
> that LF can proceed and open the permissions please?
>
> Thanks a ton!
> Jess
>
> 
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par