Questions about OSBS

Mon Jul 6 16:27:31 UTC 2015

On Mon, Jul 6, 2015 at 9:18 AM, Adam Miller
<maxamillion at fedoraproject.org> wrote:
> 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)
>>> Hello all,
>>>     I've been doing some digging into OpenShift V3[0], OSBS[1], and
>>> the Containerbuild plugin for koji[2] for the sake of the proposed
>>> Layered Image Build Service Change[3] and I was left with a few
>>> questions that I was hoping some subject matter experts on the various
>>> topics could fill in for me.
>>>
>>> - How is security between OSBS and Koji handled for the Koji plugin?
>>>   - These systems are disjoint and have to communicate somehow.
>>
>> Koji builders use https when they talk to OpenShift's REST API. We use Kerberos
>> there, but cert based authentication can be used also (actually, any
>> authentication).
>>
>>> - 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.
>
>>
>>> - Is there any sort of OSBS Administration guide?
>>
>> OpenShift team has a very detailed documentation [6].
>>
>>>   - Once this is setup, how do we admin it? Users that need to be
>>> created, maintenance, database trimming, etc.
>>
>> User administration [7]. OpenShift doesn't have relational database [8].
>>
>>>   - Method to keep atomic-reactor buildroot image updated?
>>
>> This is something we haven't really discussed yet. For now we are doing ad-hoc
>> rebuilds. I guess that you could create a cronjob and rebuild the image
>> periodically. Once OSBS will be capable of doing chain rebuilds, this will be
>> very easy to automate.
>>
>>>   - How to know/detect/determine that the atomic-reactor buildroot
>>> image needs updating?
>>
>> Good question. I assume that one indicator could be base image being rebuilt.
>> Also, atomic-reactor update could be the reason to update.
>>
>>> - Is there a timeline for OSBS update to OpenShift V3 1.0.0? (current
>>> upstream OSBS OpenShift version at the time of the writing is quite
>>> old - v0.5.2)
>>
>> Short answer is: we are working on it. I think that our codebase should already
>> suport v1 API. Martin Milata can comment on this way more.
>>
>>> - 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.
>
>>
>>> - 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?
>
>>> - 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.
>
>>
>>>   - 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.

Sorry to double post but I've been thinking more about this and was
curious what this might look like if we were to just use some sort of
automation around atomic-reactor? Would this need to be a whole new
project or just something that could be held under the atomic-reactor
umbrella such that it would offer a "stand alone" as well as a "with
OpenShift" type of functionality? I'm very interested in exploring
this as an option because the more I think about it, standing up an
entire PaaS simply for the build tooling seems heavy handed.

Thank you,
-AdamM

>
> 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?
> - 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?
> - 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)
> - 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?
>
> - 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
>
> 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
>>
>> ~~
>> Tomáš Tomeček
>> Software Engineer
>> Developer Experience
>> UTC+2 (CEST)