Questions about OSBS

Wed Jul 8 20:42:07 UTC 2015

On Tue, Jul 7, 2015 at 6:30 AM, Tomas Tomecek <ttomecek at redhat.com> wrote:
> 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]

My apologies, I don't think I explained this very well. I'm having a
disconnect in terms of how I would go about the configuration and
deployment of OSBS to an existing OpenShift environment. Would it be
possible to have a (possibly step-by-step) guide to accomplish this?

I'm curious about things such as:
  - Does OSBS need a Project inside of OpenShift?
  - What kind of access to OpenShift does the OSBS builder need?
  - Can OSBS share an OpenShift environment with other projects/users?
  - How to configure the above

I've done some digging into atomic-reactor and I'm a fan :) ... I'm
just still trying to wrap my head around the OSBS + OpenShift
integration points though so I apologize for my ignorance on the topic
but would greatly appreciate more information in that area.

Thank you,
-AdamM

>
>> >
>> >> - 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)