Questions about OSBS

Tomas Tomecek ttomecek at redhat.com
Tue Jul 7 11:30:00 UTC 2015


Quoting Adam Miller (2015-07-06 16:18:21)
> On Fri, Jul 3, 2015 at 2:39 AM, Tomas Tomecek <ttomecek at redhat.com> wrote:
> > 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 existing
> > OpenShift v3 deployment: all you need to have there is:
> >
> >  * build image
> >  * k8s secret [5] 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) [10]

> >
> >> - 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
> different network.

Now I get it.

It really depends what you want to do. OpenShift has some more patches [11] in
their registry.

We've been using traditional docker-registry for some time and it was working
just fine.

> >> - The ContainerBuild Koji plugin is hardcoding koji_hub_path
> >>   - 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 koji?)
> >>   - 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
permissions.

> >> - Is is possible to use OSBS against the new Atomic Enterprise[4]
> >> instead of OpenShift V3?
> >
> > I think so. I'm not sure what version of OpenShift is used in Enterprise but I'm
> > 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 [9].
> >
> > 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
--help`)

> - 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 support
> 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 them
> 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.

> Thank you,
> -AdamM
> 
> >
> >> Thank you,
> >> -AdamM
> >>
> >> [0] - https://github.com/openshift/origin
> >> [1] - https://github.com/DBuildService/osbs-client
> >> [2] - https://github.com/release-engineering/koji-containerbuild
> >> [3] - https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
> >> [4] - https://github.com/projectatomic/atomic-enterprise
> >> _______________________________________________
> >> rel-eng mailing list
> >> rel-eng at lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/rel-eng
> >
> > [5] https://github.com/DBuildService/osbs-client/blob/master/docs/secret.md
> > [6] https://docs.openshift.org/latest/admin_guide/overview.html
> > [7] https://docs.openshift.org/latest/admin_guide/manage_authorization_policy.html
> > [8] https://docs.openshift.org/latest/architecture/infrastructure_components/kubernetes_infrastructure.html#master
> > [9] https://docs.openshift.org/latest/architecture/infrastructure_components/web_console.html

[10] https://github.com/DBuildService/osbs-client/blob/master/docs/secret.md
[11] https://github.com/openshift/docker-registry-extensions

~~
Tomáš Tomeček
Software Engineer
Developer Experience
UTC+2 (CEST)


More information about the rel-eng mailing list