Bug 1124928 - [RFE] Local hosting for development artifacts
Summary: [RFE] Local hosting for development artifacts
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: RFE
Version: 3.0.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: Steve Speicher
QA Contact: Johnny Liu
: 1335266 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2014-07-30 16:08 UTC by Eric Rich
Modified: 2019-07-11 08:05 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Last Closed: 2016-11-29 22:30:30 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:0066 normal SHIPPED_LIVE Red Hat OpenShift Container Platform 3.4 RPM Release Advisory 2017-01-18 17:23:26 UTC

Description Eric Rich 2014-07-30 16:08:43 UTC
Description of problem:

It should be part of the Red Hat product line that a local hosting for Development Artifacts for Continuous Integration and Continuous Delivery be something included in the portfolio. 

As this is similar to what Satellite offers I fell this is the best place to file this. As the products already attempts to address similar issues for RPM specifically. 

In short it would be nice to see capsules that offer the functionality of mirroring / self hosting artifacts repositories for development tools like: 

Maven - java
npm - nodejs
pip / setuptools - python
cpan - perl
composer - php
rake / bundle - ruby

The following are sample ways that mirrors can be created with some of these tools. 

Maven : http://archiva.apache.org/index.cgi or http://www.sonatype.org/nexus/
Nodejs: https://www.npmjs.org/package/npm-lazy-mirror
Python: https://pypi.python.org/pypi/localshop

However in addition to mirroring it would be good to have a direct sync from RHC provided for these tools for the packages we support. 

As well as for the ability for customer to pull in or include upstream packages after they have been vetted internally. 
Additional info:


Comment 1 RHEL Product and Program Management 2014-07-30 16:24:06 UTC
Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

Comment 5 Randy Barlow 2016-01-21 18:36:31 UTC
Hello Eric! I wanted to let you know that upstream Pulp does offer support for Python:


I hope that is useful for you!

Comment 6 Eric Rich 2016-01-21 18:46:13 UTC
Based on http://www.pulpproject.org/docs/ it seems like: RPM's, Puppet Modules, Docker Images and Python eggs (pip). 

What about other types of artifacts for perl, php, or java?

Comment 7 Randy Barlow 2016-01-21 19:00:10 UTC
Hi again Eric,

You can see pretty much the whole list of our plugins by scanning the project names at:


Currently, we've got Python, Docker, RPM, OSTree, and Puppet. There is also a development repository for Debian support but it is not ready for use and honestly isn't getting much attention.

I also happen to know that Viktor Jancik has worked on creating a set of plugins for NPM support, but I'm not sure where that stands. Viktor, can you add a note about your progress here?

The upstream Pulp project would love to get contributions for more types. We are currently working on some ambitious features in our platform and so haven't had much time to focus on new types recently. If you or anyone you know has some cycles to write a little Python and would like some direction, please feel free to reach out to me and I will assist in getting you started on making your own Pulp plugin!

Comment 9 Dan McPherson 2016-07-11 19:15:17 UTC
*** Bug 1335266 has been marked as a duplicate of this bug. ***

Comment 13 Benjamin Holmes 2016-08-22 14:32:16 UTC
I've done some work on adding both Nexus and Artifactory to OCP as Docker images for clients I've been working with, and I've found Artifactory to be a much easier fit. I've noticed issues with Nexus 3 whereby it doesn't seem to cache any artifacts locally when proxying repositories, or at least syill checks the upstream regardless of what you've told it to do...


Artifactory can be deployed with:

    oc new-app docker.bintray.io/jfrog/artifactory-oss:latest

You need to create a service account for it, as per - https://blog.openshift.com/understanding-service-accounts-sccs/

You also need to create a persistent volume claim mounted at /var/opt/jfrog/artifactory/data

Nexus can be deployed with:

    oc new-app https://github.com/benemon/docker-nexus3

It requires a persistent volume claim mounted at /nexus-data

HTH someone looking at this issue. Given the simplicity of adding the above into OCP as an end user, I no longer see the requirement for Satellite to pick this up.

Comment 18 Steve Speicher 2016-11-29 22:30:30 UTC
Note, we have produced some samples on how to deploy Nexus at https://docs.openshift.org/latest/dev_guide/app_tutorials/maven_tutorial.html

We don't plan to provide anything in OpenShift native / out-of-the-box for this. I would expect this to be provided by some of the language distributions through the JBoss, .Net and Node.js teams, or even Satellite.

Note You need to log in before you can comment on or make changes to this bug.