Questions about OSBS

[Adam Miller]

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.

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

- Is there any sort of OSBS Administration guide?
  - Once this is setup, how do we admin it? Users that need to be
created, maintenance, database trimming, etc.
  - Method to keep atomic-reactor buildroot image updated?
  - How to know/detect/determine that the atomic-reactor buildroot
image needs updating?

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

- How would someone go about configuration for internal vs external
docker registry to be used with OSBS?

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

- Is is possible to use OSBS against the new Atomic Enterprise[4]
instead of OpenShift V3?
  - 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).

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

[Tomas Tomecek]

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

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

>  - 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?
>  
>  - 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.

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

>  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(a)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...
[8]
https://docs.openshift.org/latest/architecture/infrastructure_components/...
[9]
https://docs.openshift.org/latest/architecture/infrastructure_components/...

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

[Adam Miller]

On Fri, Jul 3, 2015 at 2:39 AM, Tomas Tomecek <ttomecek(a)redhat.com&gt; 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.

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(a)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...
>  [8]
> https://docs.openshift.org/latest/architecture/infrastructure_components/...
>  [9]
> https://docs.openshift.org/latest/architecture/infrastructure_components/...
>
>  ~~
>  Tomáš Tomeček
>  Software Engineer
>  Developer Experience
>  UTC+2 (CEST)

[Adam Miller]

On Mon, Jul 6, 2015 at 9:18 AM, Adam Miller
<maxamillion(a)fedoraproject.org&gt; wrote:
>  On Fri, Jul 3, 2015 at 2:39 AM, Tomas Tomecek
> <ttomecek(a)redhat.com&gt; 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(a)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...
> > [8]
> https://docs.openshift.org/latest/architecture/infrastructure_components/...
> > [9]
> https://docs.openshift.org/latest/architecture/infrastructure_components/...
> >
> > ~~
> > Tomáš Tomeček
> > Software Engineer
> > Developer Experience
> > UTC+2 (CEST)

[Tomas Tomecek]

Quoting Adam Miller (2015-07-06 18:27:31)
>  On Mon, Jul 6, 2015 at 9:18 AM, Adam Miller
>  <maxamillion(a)fedoraproject.org&gt; wrote:
>  > On Fri, Jul 3, 2015 at 2:39 AM, Tomas Tomecek <ttomecek(a)redhat.com&gt; wrote:
>  >> Quoting Adam Miller (2015-07-02 16:46:37)
>  >>>   - 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 guess it could work. But you need some sort of scheduler then. And ideally an
API entry point.

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

[Tomas Tomecek]

Quoting Adam Miller (2015-07-06 16:18:21)
>  On Fri, Jul 3, 2015 at 2:39 AM, Tomas Tomecek
> <ttomecek(a)redhat.com&gt; 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(a)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...
>  > [8]
> https://docs.openshift.org/latest/architecture/infrastructure_components/...
>  > [9]
> https://docs.openshift.org/latest/architecture/infrastructure_components/...
[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)

[Adam Miller]

On Tue, Jul 7, 2015 at 6:30 AM, Tomas Tomecek <ttomecek(a)redhat.com&gt; wrote:
>  Quoting Adam Miller (2015-07-06 16:18:21)
> > On Fri, Jul 3, 2015 at 2:39 AM, Tomas Tomecek <ttomecek(a)redhat.com&gt; 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(a)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...
> > > [8]
> https://docs.openshift.org/latest/architecture/infrastructure_components/...
> > > [9]
> https://docs.openshift.org/latest/architecture/infrastructure_components/...
>
>  [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)

[Tomas Tomecek]

Quoting Adam Miller (2015-07-08 22:42:07)
>  On Tue, Jul 7, 2015 at 6:30 AM, Tomas Tomecek
> <ttomecek(a)redhat.com&gt; wrote:
>  > Quoting Adam Miller (2015-07-06 16:18:21)
>  >> On Fri, Jul 3, 2015 at 2:39 AM, Tomas Tomecek <ttomecek(a)redhat.com&gt;
> 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 
Oh, I'm sorry. I should have read more carefully.

I just went through the existing [1] deployment guide and am able to see that
the points you mentioned are missing there. Will definitely improve.

Regarding the step by step guide, if you need it, we can totally provide such
guide. But I'm afraid it would be just a subset of the existing deployment guide
[1]. Would enhancing the existing guide be sufficient?

I'll CC in the PR of the guide enhancement.


[1] https://github.com/DBuildService/osbs-client/blob/master/docs/osbs_instan...
[2]
https://github.com/DBuildService/osbs-client/blob/master/docs/osbs_instan...

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

[Adam Miller]

On Thu, Jul 9, 2015 at 5:06 AM, Tomas Tomecek <ttomecek(a)redhat.com&gt; wrote:
>  Quoting Adam Miller (2015-07-08 22:42:07)
> > On Tue, Jul 7, 2015 at 6:30 AM, Tomas Tomecek <ttomecek(a)redhat.com&gt; wrote:
> > > Quoting Adam Miller (2015-07-06 16:18:21)
> > >> On Fri, Jul 3, 2015 at 2:39 AM, Tomas Tomecek <ttomecek(a)redhat.com&gt;
> 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
>
>  Oh, I'm sorry. I should have read more carefully.
>
>  I just went through the existing [1] deployment guide and am able to see that
>  the points you mentioned are missing there. Will definitely improve.
>
>  Regarding the step by step guide, if you need it, we can totally provide such
>  guide. But I'm afraid it would be just a subset of the existing deployment guide
>  [1]. Would enhancing the existing guide be sufficient? 
Yeas, that would absolutely be sufficient. Thank you very much!

-AdamM

>  I'll CC in the PR of the guide enhancement.
>
>
>  [1] https://github.com/DBuildService/osbs-client/blob/master/docs/osbs_instan...
>  [2]
> https://github.com/DBuildService/osbs-client/blob/master/docs/osbs_instan...
>
>  ~~
>  Tomáš Tomeček
>  Software Engineer
>  Developer Experience
>  UTC+2 (CEST)