Quoting Adam Miller (2015-07-06 16:18:21)
On Fri, Jul 3, 2015 at 2:39 AM, Tomas Tomecek
> Quoting Adam Miller (2015-07-02 16:46:37)
>> - Are there any docs on how to deploy OSBS on top of a pre-existing
>> OpenShift V3 Environment? (The current OSBS deploy docs and ansible
>> are only single-node)
> We no longer use all-in-one, instead we use proper master/node setup. Therefore
> you can use multi-node setup very easily.
> As I'm thinking about it now, I can't figure out any issues with using
> OpenShift v3 deployment: all you need to have there is:
> * build image
> * k8s secret  if you want to push to pulp registry
How would I go about setting that up? There is something I'm missing
here likely due to my inexperience with the system.
k8s secret is an object where you can store arbitrary data and k8s will mount it
inside container (we use it now to store client certificates for authentication
with pulp) 
>> - How would someone go about configuration for internal vs external
>> docker registry to be used with OSBS?
> Could you please elaborate? I'm not totally sure about the question.
I was curious how to handle the scenario of having a docker-registry
inside OpenShift that OpenShift/kubernetes is aware of vs a
docker-registry that is external to OpenShift, potentially on a
Now I get it.
It really depends what you want to do. OpenShift has some more patches  in
We've been using traditional docker-registry for some time and it was working
>> - The ContainerBuild Koji plugin is hardcoding
>> - Is there a reason/motivation behind this?
>> - Can this be a configuration parameter?
>> - How does OSBS and the Koji plugin negotiate authentication/authorization?
>> - What users within OSBS/OpenShift map to Koji users? (Do they at all?)
>> - Where does the responsibility for user mapping exists? (just defer to
>> - How to determine what users are allowed to build and/or build for
>> what koji tags?
Any update on the above questions?
Since koji part is not my area I wanted to defer answers to Pavol, but I guess I
can provide some:
1. Koji builder has a static user and this one is configured within osbs to be
able to submit builds.
2. No user mapping atm.
3. Anyone can build anything - same as for RPMs afaik. koji just sends e-mail to
image owners. Since images are not part of any tags, I'm not sure how to handle
>> - Is is possible to use OSBS against the new Atomic
>> instead of OpenShift V3?
> I think so. I'm not sure what version of OpenShift is used in Enterprise but
> assuming this shouldn't be a problem.
Atomic Enterprise doesn't use OpenShift.
As I said, I'm not familiar with it.
>> - Main motivation/curiosity is that for the build system we don't
>> really need a giant portion of what OpenShift offers and the
>> maintenance, administrative overhead and security aspects are of
>> concern. (This is mostly an idle curiosity, I'm not advocating for one
>> over the other but I wanted to bring it up).
> Chain rebuilds will be nice feature to get from OpenShift. Also, OpenShift has
> very sweet web interface .
> On the other hand, I totally understand your concerns. Maybe having some
> automation on top of atomic-reactor could be more suitable.
That's partially what I'm trying to sort out is if automation wrapping
atomic-reactor would suffice or if running full fledged OpenShift
simply to use it as a build system is really what we want to do. From
a systems administration standpoint, OpenShift adds a lot of
complexity and is something that a number of members in the Fedora
Infrastructure team have never used so there would be a learning curve
and I just want to make sure we do our due diligence before requesting
the team to take on something this big.
I also had a few follow up questions that I didn't think of at first pass:
- What changes would be needed to fedpkg to enable the layered builds?
Just provide configuration. No code changes needed (try `fedpkg container-build
- On the topic of DistGit, does/should the OSBS koji/rpkg/fedpkg
integration share a DistGit space or should it have completely new git
repos with a new naming convention?
we name repos like this: $name-docker
AFAIK we have no constraints for this
- What about non x86-64 architectures? Are there any plans to
those (at present, both i686 and armv7hl are supported primary
architectures in Fedora and we need to address that)
This is something what we haven't discussed much.
- How does the koji plugin handle build artifacts? Does it store
in a registry or does the build artifact end up on a datastore of
koji's and then the image has to be handled elsewhere?
What's the difference between build artifacts and images?
- Also, this one is an idle curiosity but is there any upstream
collaboration with The Foreman team around layered image building
and/or auto detection of when images need rebuilding for updates? I
saw a screencast where they were showing off some capabilities that I
thought were overlapping and figured I would ask. I also heard at Red
Hat Summit 2015 just a couple weeks ago that Satellite 6.1 Beta is
utilizing some aspect of The Foreman to auto-rebuild layered images
when updates are detected as necessary
They are using atomic-reactor. That's all I know tbh.