Topics

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

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@... [mailto:onap-tsc@...] On Behalf Of Jim Baker
Sent: Wednesday, February 13, 2019 2:56 PM
To: morgan.richomme@...
Cc: jwagantall@...; kpaul@...; bthuree@...; onap-tsc@...; onap-discuss@...; onap-release@...; DANNO Vincent TGI/OLN <vincent.danno@...>; LAMBERT Guillaume TGI/OLN <guillaume.lambert@...>; OLLIVIER Cédric TGI/OLN <cedric.ollivier@...>; ccain@...; hagbard@...
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 <morgan.richomme@...> 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 erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


 

--

Jim Baker

Linux Foundation Networking - Technical Program Manager

mobile: +1 970 227 6007