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
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@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.ht... [8] https://docs.openshift.org/latest/architecture/infrastructure_components/kub... [9] https://docs.openshift.org/latest/architecture/infrastructure_components/web...
~~ Tomáš Tomeček Software Engineer Developer Experience UTC+2 (CEST)
On Fri, Jul 3, 2015 at 2:39 AM, Tomas Tomecek ttomecek@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.
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@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.ht... [8] https://docs.openshift.org/latest/architecture/infrastructure_components/kub... [9] https://docs.openshift.org/latest/architecture/infrastructure_components/web...
~~ Tomáš Tomeček Software Engineer Developer Experience UTC+2 (CEST)
On Mon, Jul 6, 2015 at 9:18 AM, Adam Miller maxamillion@fedoraproject.org wrote:
On Fri, Jul 3, 2015 at 2:39 AM, Tomas Tomecek ttomecek@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@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.ht... [8] https://docs.openshift.org/latest/architecture/infrastructure_components/kub... [9] https://docs.openshift.org/latest/architecture/infrastructure_components/web...
~~ Tomáš Tomeček Software Engineer Developer Experience UTC+2 (CEST)
Quoting Adam Miller (2015-07-06 18:27:31)
On Mon, Jul 6, 2015 at 9:18 AM, Adam Miller maxamillion@fedoraproject.org wrote:
On Fri, Jul 3, 2015 at 2:39 AM, Tomas Tomecek ttomecek@redhat.com 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)
Quoting Adam Miller (2015-07-06 16:18:21)
On Fri, Jul 3, 2015 at 2:39 AM, Tomas Tomecek ttomecek@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@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.ht... [8] https://docs.openshift.org/latest/architecture/infrastructure_components/kub... [9] https://docs.openshift.org/latest/architecture/infrastructure_components/web...
[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)
On Tue, Jul 7, 2015 at 6:30 AM, Tomas Tomecek ttomecek@redhat.com wrote:
Quoting Adam Miller (2015-07-06 16:18:21)
On Fri, Jul 3, 2015 at 2:39 AM, Tomas Tomecek ttomecek@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:
- Koji builder has a static user and this one is configured within osbs to be
able to submit builds.
No user mapping atm.
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@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.ht... [8] https://docs.openshift.org/latest/architecture/infrastructure_components/kub... [9] https://docs.openshift.org/latest/architecture/infrastructure_components/web...
[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)
Quoting Adam Miller (2015-07-08 22:42:07)
On Tue, Jul 7, 2015 at 6:30 AM, Tomas Tomecek ttomecek@redhat.com wrote:
Quoting Adam Miller (2015-07-06 16:18:21)
On Fri, Jul 3, 2015 at 2:39 AM, Tomas Tomecek ttomecek@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
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_instance_... [2] https://github.com/DBuildService/osbs-client/blob/master/docs/osbs_instance_...
~~ Tomáš Tomeček Software Engineer Developer Experience UTC+2 (CEST)
On Thu, Jul 9, 2015 at 5:06 AM, Tomas Tomecek ttomecek@redhat.com wrote:
Quoting Adam Miller (2015-07-08 22:42:07)
On Tue, Jul 7, 2015 at 6:30 AM, Tomas Tomecek ttomecek@redhat.com wrote:
Quoting Adam Miller (2015-07-06 16:18:21)
On Fri, Jul 3, 2015 at 2:39 AM, Tomas Tomecek ttomecek@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
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_instance_... [2] https://github.com/DBuildService/osbs-client/blob/master/docs/osbs_instance_...
~~ Tomáš Tomeček Software Engineer Developer Experience UTC+2 (CEST)
rel-eng@lists.fedoraproject.org
-
Adam Miller -
Tomas Tomecek