Hi everyone, just a quick heads-up: I offered my help with maintaining Fedora-Dockerfiles [1] to Scott who accepted it, so I'm jumping in. In the following months, I'd like to keep number of opened pull requests and issues at minimum and also sort out some more complex issues like: - setting up CI - automatic pushing of tested images to dockerhub - cleanup of contribution guidelines, readmes, etc
I think that setting up CI is the most important thing to do right now, since hand testing the images is both error prone and time consuming. I'll try to keep the track of my thoughts and the overall progress in this at [2].
One of the things that I forgot to talk about with Scott was the relation of Fedora-Dockerfiles to Layered Image Build System proposal [3]. The proposal suggests that dist-git should be set up for Dockerfiles. Are there any plans to obsolete Fedora-Dockerfiles to dist-git repos? Or are these meant to run in parallel and have different purposes? I'd like to get answers to these questions before I start working on any of the issues mentioned above. (If there are no answers yet, then I'm happy to participate in the discussion!)
So to sum things up, I'm here for you now as another maintainer of Fedora-Dockerfiles. Feel free to communicate with me through the Github issue tracker, through this list, IRC (#fedora-devel is where I usually lurk) or my private mail. Thank you for your attention :)
On Thu, Oct 01, 2015 at 06:36:22AM -0400, Bohuslav Kabrda wrote:
One of the things that I forgot to talk about with Scott was the relation of Fedora-Dockerfiles to Layered Image Build System proposal [3]. The proposal suggests that dist-git should be set up for Dockerfiles. Are there any plans to obsolete Fedora-Dockerfiles to dist-git repos? Or are these meant to run in parallel and have different purposes? I'd like to get answers to these questions before I start working on any of the issues mentioned above. (If there are no answers yet, then I'm happy to participate in the discussion!)
My opinion is that the dist-git-for-dockerfiles plan should make Fedora Dockerfiles obsolete.
On 10/01/2015 09:50 AM, Matthew Miller wrote:
On Thu, Oct 01, 2015 at 06:36:22AM -0400, Bohuslav Kabrda wrote:
One of the things that I forgot to talk about with Scott was the relation of Fedora-Dockerfiles to Layered Image Build System proposal [3]. The proposal suggests that dist-git should be set up for Dockerfiles. Are there any plans to obsolete Fedora-Dockerfiles to dist-git repos? Or are these meant to run in parallel and have different purposes? I'd like to get answers to these questions before I start working on any of the issues mentioned above. (If there are no answers yet, then I'm happy to participate in the discussion!)
My opinion is that the dist-git-for-dockerfiles plan should make Fedora Dockerfiles obsolete.
How would users who aren't necessarily involved in the Fedora build process experiment building images with a Fedora base? Right now there's a rpm created from fedora-dockerfiles that includes all the Dockerfiles and makes it easy to experiment by placing all the Dockerfiles in /usr/share/fedora-dockerfiles. If we keep them both, it's somewhat duplicate work. I'm just curious how it would look. Right now the barrier to entry for experimentation is low. I'm concerned about raising that.
Also, the plan was for Vasek to submit Nulecule PRs to Fedora-dockerfiles, at some point, so people could experiment with them as well. I'd also like to see k8s example json / yaml files associated with select fedora-dockerfiles for easy experimentation. Would the nulecule / k8s get pushed into the dist-git as well?
On Thu, Oct 01, 2015 at 10:00:43AM -0500, Scott Collier wrote:
My opinion is that the dist-git-for-dockerfiles plan should make Fedora Dockerfiles obsolete.
How would users who aren't necessarily involved in the Fedora build process experiment building images with a Fedora base? Right now
Hopefully this new dist-git can be fronted by pagure, so it'd be a matter of visiting a web site like https://pagure.io/fedora-bootstrap (not a docker example, just a random one) and either downloading the docker file or doing a git clone.
there's a rpm created from fedora-dockerfiles that includes all the Dockerfiles and makes it easy to experiment by placing all the Dockerfiles in /usr/share/fedora-dockerfiles. If we keep them both, it's somewhat duplicate work. I'm just curious how it would look. Right now the barrier to entry for experimentation is low. I'm concerned about raising that.
Yeah, that's a good concern. We could also perhaps automate pulling all the dockerfiles from the dist-git into fedora-dockerfiles and keep that, for people who want to work with it that way.
Also, the plan was for Vasek to submit Nulecule PRs to Fedora-dockerfiles, at some point, so people could experiment with them as well. I'd also like to see k8s example json / yaml files associated with select fedora-dockerfiles for easy experimentation. Would the nulecule / k8s get pushed into the dist-git as well?
Maybe? Would it make sense for these to go together with the dockerfiles they're associated with in a git repo at that level, or would they be stand-alone and reference other repos? (Do you have some concrete examples?)
Another approach to all this would be to keep all the dockerfiles in one place -- it just means that everyone who has any commit access to anything gets commit access to everything, which we might not want as we scale.
----- Original Message -----
On Thu, Oct 01, 2015 at 10:00:43AM -0500, Scott Collier wrote:
My opinion is that the dist-git-for-dockerfiles plan should make Fedora Dockerfiles obsolete.
How would users who aren't necessarily involved in the Fedora build process experiment building images with a Fedora base? Right now
Hopefully this new dist-git can be fronted by pagure, so it'd be a matter of visiting a web site like https://pagure.io/fedora-bootstrap (not a docker example, just a random one) and either downloading the docker file or doing a git clone.
Heh, it seems that my career as Fedora-Dockerfiles comaintainer may be rather short :) I think having a web frontend with pull requests for the new dist-git is an awesome idea. I'm +0.9 for pagure. The advantage is that it will be completely under Fedora control, the small downside is that potential contributors from outside Fedora will have to create Fedora account, which might scare some people off.
there's a rpm created from fedora-dockerfiles that includes all the Dockerfiles and makes it easy to experiment by placing all the Dockerfiles in /usr/share/fedora-dockerfiles. If we keep them both, it's somewhat duplicate work. I'm just curious how it would look. Right now the barrier to entry for experimentation is low. I'm concerned about raising that.
Yeah, that's a good concern. We could also perhaps automate pulling all the dockerfiles from the dist-git into fedora-dockerfiles and keep that, for people who want to work with it that way.
So IIUC, the standard way to get dockerfiles from dist-git would be "fedpkg clone mariadb-docker" or similar. Perhaps we could provide a wrapper that anyone, even without Fedora account, like "fedora-get-dockerfile --list" or "fedora-get-dockerfile mariadb" (this would invoke "fedpkg clone --anonymous mariadb-docker").
Also, the plan was for Vasek to submit Nulecule PRs to Fedora-dockerfiles, at some point, so people could experiment with them as well. I'd also like to see k8s example json / yaml files associated with select fedora-dockerfiles for easy experimentation. Would the nulecule / k8s get pushed into the dist-git as well?
Maybe? Would it make sense for these to go together with the dockerfiles they're associated with in a git repo at that level, or would they be stand-alone and reference other repos? (Do you have some concrete examples?)
So I think that kubernetes/Nulecule examples should be standalone, since most often they'll reference multiple images. What I mean is that they would be a good fit for the current fedora-dockerfiles repo, but if we split the repo into multiple dist-git repos, they won't fit in any one of these.
Another approach to all this would be to keep all the dockerfiles in one place -- it just means that everyone who has any commit access to anything gets commit access to everything, which we might not want as we scale.
Yeah, scaling is a valid point. I think splitting into multiple repos is a good way to go assuming we address the concerns that Scott has raised.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader
On Fri, Oct 02, 2015 at 05:01:51AM -0400, Bohuslav Kabrda wrote:
Heh, it seems that my career as Fedora-Dockerfiles comaintainer may be rather short :) I think having a web frontend with pull requests for the new dist-git is an awesome idea. I'm +0.9 for pagure. The advantage is that it will be completely under Fedora control, the small downside is that potential contributors from outside Fedora will have to create Fedora account, which might scare some people off.
We want to make the web-pull-request process really easy for using Pagure as a documentation tool, too, so support for non-fedora-contributor drive-by contributions might come.
So IIUC, the standard way to get dockerfiles from dist-git would be "fedpkg clone mariadb-docker" or similar. Perhaps we could provide a wrapper that anyone, even without Fedora account, like "fedora-get-dockerfile --list" or "fedora-get-dockerfile mariadb" (this would invoke "fedpkg clone --anonymous mariadb-docker").
Cool.
Maybe? Would it make sense for these to go together with the dockerfiles they're associated with in a git repo at that level, or would they be stand-alone and reference other repos? (Do you have some concrete examples?)
So I think that kubernetes/Nulecule examples should be standalone, since most often they'll reference multiple images. What I mean is that they would be a good fit for the current fedora-dockerfiles repo, but if we split the repo into multiple dist-git repos, they won't fit in any one of these.
So, would all of _those_ examples go into a single entity (package, repo, whatever)? What should the distribution method for _these_ be?
----- Original Message -----
On Fri, Oct 02, 2015 at 05:01:51AM -0400, Bohuslav Kabrda wrote:
Heh, it seems that my career as Fedora-Dockerfiles comaintainer may be rather short :) I think having a web frontend with pull requests for the new dist-git is an awesome idea. I'm +0.9 for pagure. The advantage is that it will be completely under Fedora control, the small downside is that potential contributors from outside Fedora will have to create Fedora account, which might scare some people off.
We want to make the web-pull-request process really easy for using Pagure as a documentation tool, too, so support for non-fedora-contributor drive-by contributions might come.
Cool, this would really be a nice feature to have.
Maybe? Would it make sense for these to go together with the dockerfiles they're associated with in a git repo at that level, or would they be stand-alone and reference other repos? (Do you have some concrete examples?)
So I think that kubernetes/Nulecule examples should be standalone, since most often they'll reference multiple images. What I mean is that they would be a good fit for the current fedora-dockerfiles repo, but if we split the repo into multiple dist-git repos, they won't fit in any one of these.
So, would all of _those_ examples go into a single entity (package, repo, whatever)? What should the distribution method for _these_ be?
I'm not sure :) In fact, I'm wondering whether it's really necessary to be shipping these as RPMs. Dockerfiles are good candidates for shipping via RPMs, since they are the recipes used to build images that are actually out there (on dockerhub, etc). kubernetes/Nulecule examples, on the other hand, will be just *examples*, not something you would want to build, deploy and use as is.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader
On Wed, Oct 07, 2015 at 12:11:47AM -0400, Bohuslav Kabrda wrote:
So, would all of _those_ examples go into a single entity (package, repo, whatever)? What should the distribution method for _these_ be?
I'm not sure :) In fact, I'm wondering whether it's really necessary to be shipping these as RPMs. Dockerfiles are good candidates for shipping via RPMs, since they are the recipes used to build images that are actually out there (on dockerhub, etc). kubernetes/Nulecule examples, on the other hand, will be just *examples*, not something you would want to build, deploy and use as is.
Well, let's say we want to ship a Fedora Server role as an Atomic App. Or, say, Kolab. Where would the nulecule files for that live?
On 10/08/2015 07:55 AM, Matthew Miller wrote:
Well, let's say we want to ship a Fedora Server role as an Atomic App. Or, say, Kolab. Where would the nulecule files for that live?
So - we're currently keeping working examples here:
https://github.com/projectatomic/nulecule/tree/master/examples
I would love to see a central repo for any Nulecule / Atomic Apps.
For users, if they're pulling a pre-made app it should live on Docker Hub. So they'd just need "sudo atomic run fedora/kolab" or similar to grab it.
(I suppose Fedora could have its own registry for containers, but not sure we want to / are ready to go there.)
Best,
jzb
On Thu, Oct 08, 2015 at 09:09:11AM -0400, Joe Brockmeier wrote:
So - we're currently keeping working examples here: https://github.com/projectatomic/nulecule/tree/master/examples I would love to see a central repo for any Nulecule / Atomic Apps.
I *think* that in our first pass, layered images will all be produced by installing packages. So maybe each nulecule becomes an RPM? That seems like a lot of overhead. (But hey, when you've got a hammer....)
Alternately, maybe the Dockerfiles dist-git could have (well, have a lookaside cache to) source tarballs that aren't in RPM. Maybe that's already in the works in the upstream, but I don't know if we're ready for it.
For users, if they're pulling a pre-made app it should live on Docker Hub. So they'd just need "sudo atomic run fedora/kolab" or similar to grab it.
Yeah, I don't want to put users in the position of thinking they have to build them themselves, for sure.
(I suppose Fedora could have its own registry for containers, but not sure we want to / are ready to go there.)
The releng team working on this is talking about that as a possible target for F24.
On 10/06/2015 10:13 AM, Matthew Miller wrote:
On Fri, Oct 02, 2015 at 05:01:51AM -0400, Bohuslav Kabrda wrote:
Heh, it seems that my career as Fedora-Dockerfiles comaintainer may be rather short :) I think having a web frontend with pull requests for the new dist-git is an awesome idea. I'm +0.9 for pagure. The advantage is that it will be completely under Fedora control, the small downside is that potential contributors from outside Fedora will have to create Fedora account, which might scare some people off.
We want to make the web-pull-request process really easy for using Pagure as a documentation tool, too, so support for non-fedora-contributor drive-by contributions might come.
I really think a 'log in with github' ability would be great for pagure. It would also be great to have for BZ (which I know isn't FAS) but would make it easier for people who didn't want to create an account but wanted to report a bug.
On Fri, Oct 2, 2015 at 4:01 AM, Bohuslav Kabrda slavek@redhat.com wrote:
----- Original Message -----
On Thu, Oct 01, 2015 at 10:00:43AM -0500, Scott Collier wrote:
My opinion is that the dist-git-for-dockerfiles plan should make Fedora Dockerfiles obsolete.
How would users who aren't necessarily involved in the Fedora build process experiment building images with a Fedora base? Right now
Hopefully this new dist-git can be fronted by pagure, so it'd be a matter of visiting a web site like https://pagure.io/fedora-bootstrap (not a docker example, just a random one) and either downloading the docker file or doing a git clone.
Heh, it seems that my career as Fedora-Dockerfiles comaintainer may be rather short :) I think having a web frontend with pull requests for the new dist-git is an awesome idea. I'm +0.9 for pagure. The advantage is that it will be completely under Fedora control, the small downside is that potential contributors from outside Fedora will have to create Fedora account, which might scare some people off.
From what I understand is that pagure uses OAuth and at the moment the
only OAuth plugin in use is for FAS, we might be able to request to enable some short list of federated logins if: 1) that is in fact possible 2) the authors of pagure are open to it 3) the Fedora Infrastructure team is OK with it
there's a rpm created from fedora-dockerfiles that includes all the Dockerfiles and makes it easy to experiment by placing all the Dockerfiles in /usr/share/fedora-dockerfiles. If we keep them both, it's somewhat duplicate work. I'm just curious how it would look. Right now the barrier to entry for experimentation is low. I'm concerned about raising that.
Yeah, that's a good concern. We could also perhaps automate pulling all the dockerfiles from the dist-git into fedora-dockerfiles and keep that, for people who want to work with it that way.
So IIUC, the standard way to get dockerfiles from dist-git would be "fedpkg clone mariadb-docker" or similar. Perhaps we could provide a wrapper that anyone, even without Fedora account, like "fedora-get-dockerfile --list" or "fedora-get-dockerfile mariadb" (this would invoke "fedpkg clone --anonymous mariadb-docker").
Ultimately people could just git clone from the git repo in pagure. The only real thing that makes DistGit "special" is the branch layout, relationship, and some git hooks. Otherwise it's still just git and we can aggregate that information any way we choose. If there's ultimately a desire for a web hub, it's possible we could get something together similar to Fedora Packages[0]
Also, the plan was for Vasek to submit Nulecule PRs to Fedora-dockerfiles, at some point, so people could experiment with them as well. I'd also like to see k8s example json / yaml files associated with select fedora-dockerfiles for easy experimentation. Would the nulecule / k8s get pushed into the dist-git as well?
Maybe? Would it make sense for these to go together with the dockerfiles they're associated with in a git repo at that level, or would they be stand-alone and reference other repos? (Do you have some concrete examples?)
So I think that kubernetes/Nulecule examples should be standalone, since most often they'll reference multiple images. What I mean is that they would be a good fit for the current fedora-dockerfiles repo, but if we split the repo into multiple dist-git repos, they won't fit in any one of these.
I'm not sure that I follow the motivation behind keeping them standalone, could you elaborate why? Also, when you say "reference multiple images" so you mean as a Nulecule spec or $other/$similar?
Another approach to all this would be to keep all the dockerfiles in one place -- it just means that everyone who has any commit access to anything gets commit access to everything, which we might not want as we scale.
Yeah, scaling is a valid point. I think splitting into multiple repos is a good way to go assuming we address the concerns that Scott has raised.
I think the main concern here (unless I"ve misunderstood) is visibility and collaboration which I think we can solve. I like the idea of the different Dockerfiles being separate similar to packages in DistGit purely because that allows people with expertise in certain areas to participate in the areas they care about and avoid all the other line noise of a shared repository.
Just my $0.02
-AdamM
[0] - https://apps.fedoraproject.org/packages/
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader
-- Regards, Slavek Kabrda _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
----- Original Message -----
On Fri, Oct 2, 2015 at 4:01 AM, Bohuslav Kabrda slavek@redhat.com wrote:
----- Original Message -----
On Thu, Oct 01, 2015 at 10:00:43AM -0500, Scott Collier wrote:
My opinion is that the dist-git-for-dockerfiles plan should make Fedora Dockerfiles obsolete.
How would users who aren't necessarily involved in the Fedora build process experiment building images with a Fedora base? Right now
Hopefully this new dist-git can be fronted by pagure, so it'd be a matter of visiting a web site like https://pagure.io/fedora-bootstrap (not a docker example, just a random one) and either downloading the docker file or doing a git clone.
Heh, it seems that my career as Fedora-Dockerfiles comaintainer may be rather short :) I think having a web frontend with pull requests for the new dist-git is an awesome idea. I'm +0.9 for pagure. The advantage is that it will be completely under Fedora control, the small downside is that potential contributors from outside Fedora will have to create Fedora account, which might scare some people off.
From what I understand is that pagure uses OAuth and at the moment the only OAuth plugin in use is for FAS, we might be able to request to enable some short list of federated logins if:
- that is in fact possible
- the authors of pagure are open to it
- the Fedora Infrastructure team is OK with it
That would be nice! I'll try to ask pingou whether this would make sense to him (hopefully in the start of next week, I'm going to a conference for the rest of this week).
there's a rpm created from fedora-dockerfiles that includes all the Dockerfiles and makes it easy to experiment by placing all the Dockerfiles in /usr/share/fedora-dockerfiles. If we keep them both, it's somewhat duplicate work. I'm just curious how it would look. Right now the barrier to entry for experimentation is low. I'm concerned about raising that.
Yeah, that's a good concern. We could also perhaps automate pulling all the dockerfiles from the dist-git into fedora-dockerfiles and keep that, for people who want to work with it that way.
So IIUC, the standard way to get dockerfiles from dist-git would be "fedpkg clone mariadb-docker" or similar. Perhaps we could provide a wrapper that anyone, even without Fedora account, like "fedora-get-dockerfile --list" or "fedora-get-dockerfile mariadb" (this would invoke "fedpkg clone --anonymous mariadb-docker").
Ultimately people could just git clone from the git repo in pagure.
Yeah, you're right.
The only real thing that makes DistGit "special" is the branch layout, relationship, and some git hooks. Otherwise it's still just git and we can aggregate that information any way we choose. If there's ultimately a desire for a web hub, it's possible we could get something together similar to Fedora Packages[0]
Also, the plan was for Vasek to submit Nulecule PRs to Fedora-dockerfiles, at some point, so people could experiment with them as well. I'd also like to see k8s example json / yaml files associated with select fedora-dockerfiles for easy experimentation. Would the nulecule / k8s get pushed into the dist-git as well?
Maybe? Would it make sense for these to go together with the dockerfiles they're associated with in a git repo at that level, or would they be stand-alone and reference other repos? (Do you have some concrete examples?)
So I think that kubernetes/Nulecule examples should be standalone, since most often they'll reference multiple images. What I mean is that they would be a good fit for the current fedora-dockerfiles repo, but if we split the repo into multiple dist-git repos, they won't fit in any one of these.
I'm not sure that I follow the motivation behind keeping them standalone, could you elaborate why? Also, when you say "reference multiple images" so you mean as a Nulecule spec or $other/$similar?
So *assuming* we split fedora-dockerfiles in one-dockerfile-per-dist-git-repo style and there's a kubernetes/Nulecule file that references (*) more of them, it just doesn't fit into any one of these one-dockerfile repos.
(*) It's pretty much as you said it, an application based on e.g. a kubernetes config file will *typically* operate with (and thus reference) more than just one image.
Another approach to all this would be to keep all the dockerfiles in one place -- it just means that everyone who has any commit access to anything gets commit access to everything, which we might not want as we scale.
Yeah, scaling is a valid point. I think splitting into multiple repos is a good way to go assuming we address the concerns that Scott has raised.
I think the main concern here (unless I"ve misunderstood) is visibility and collaboration which I think we can solve. I like the idea of the different Dockerfiles being separate similar to packages in DistGit purely because that allows people with expertise in certain areas to participate in the areas they care about and avoid all the other line noise of a shared repository.
Just my $0.02
Thanks!
-AdamM
[0] - https://apps.fedoraproject.org/packages/
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader
-- Regards, Slavek Kabrda
On Tue, Oct 6, 2015 at 11:21 PM, Bohuslav Kabrda slavek@redhat.com wrote:
----- Original Message -----
On Fri, Oct 2, 2015 at 4:01 AM, Bohuslav Kabrda slavek@redhat.com wrote:
----- Original Message -----
On Thu, Oct 01, 2015 at 10:00:43AM -0500, Scott Collier wrote:
My opinion is that the dist-git-for-dockerfiles plan should make Fedora Dockerfiles obsolete.
How would users who aren't necessarily involved in the Fedora build process experiment building images with a Fedora base? Right now
Hopefully this new dist-git can be fronted by pagure, so it'd be a matter of visiting a web site like https://pagure.io/fedora-bootstrap (not a docker example, just a random one) and either downloading the docker file or doing a git clone.
Heh, it seems that my career as Fedora-Dockerfiles comaintainer may be rather short :) I think having a web frontend with pull requests for the new dist-git is an awesome idea. I'm +0.9 for pagure. The advantage is that it will be completely under Fedora control, the small downside is that potential contributors from outside Fedora will have to create Fedora account, which might scare some people off.
From what I understand is that pagure uses OAuth and at the moment the only OAuth plugin in use is for FAS, we might be able to request to enable some short list of federated logins if:
- that is in fact possible
- the authors of pagure are open to it
- the Fedora Infrastructure team is OK with it
That would be nice! I'll try to ask pingou whether this would make sense to him (hopefully in the start of next week, I'm going to a conference for the rest of this week).
+1 - Sounds good.
there's a rpm created from fedora-dockerfiles that includes all the Dockerfiles and makes it easy to experiment by placing all the Dockerfiles in /usr/share/fedora-dockerfiles. If we keep them both, it's somewhat duplicate work. I'm just curious how it would look. Right now the barrier to entry for experimentation is low. I'm concerned about raising that.
Yeah, that's a good concern. We could also perhaps automate pulling all the dockerfiles from the dist-git into fedora-dockerfiles and keep that, for people who want to work with it that way.
So IIUC, the standard way to get dockerfiles from dist-git would be "fedpkg clone mariadb-docker" or similar. Perhaps we could provide a wrapper that anyone, even without Fedora account, like "fedora-get-dockerfile --list" or "fedora-get-dockerfile mariadb" (this would invoke "fedpkg clone --anonymous mariadb-docker").
Ultimately people could just git clone from the git repo in pagure.
Yeah, you're right.
The only real thing that makes DistGit "special" is the branch layout, relationship, and some git hooks. Otherwise it's still just git and we can aggregate that information any way we choose. If there's ultimately a desire for a web hub, it's possible we could get something together similar to Fedora Packages[0]
Also, the plan was for Vasek to submit Nulecule PRs to Fedora-dockerfiles, at some point, so people could experiment with them as well. I'd also like to see k8s example json / yaml files associated with select fedora-dockerfiles for easy experimentation. Would the nulecule / k8s get pushed into the dist-git as well?
Maybe? Would it make sense for these to go together with the dockerfiles they're associated with in a git repo at that level, or would they be stand-alone and reference other repos? (Do you have some concrete examples?)
So I think that kubernetes/Nulecule examples should be standalone, since most often they'll reference multiple images. What I mean is that they would be a good fit for the current fedora-dockerfiles repo, but if we split the repo into multiple dist-git repos, they won't fit in any one of these.
I'm not sure that I follow the motivation behind keeping them standalone, could you elaborate why? Also, when you say "reference multiple images" so you mean as a Nulecule spec or $other/$similar?
So *assuming* we split fedora-dockerfiles in one-dockerfile-per-dist-git-repo style and there's a kubernetes/Nulecule file that references (*) more of them, it just doesn't fit into any one of these one-dockerfile repos.
(*) It's pretty much as you said it, an application based on e.g. a kubernetes config file will *typically* operate with (and thus reference) more than just one image.
Yes, I agree. For things like kubernetes and/or nulecule application definitions, I think those should live somewhere external independently at least for now. This isn't something we've currently been planning to handle in the Layered Image Build System, at least not at first. I'm not even sure what the implications are from a build system perspective because I was under the impression that those were just runtime definitions, but as time goes on this can definitely evolve.
-AdamM
Another approach to all this would be to keep all the dockerfiles in one place -- it just means that everyone who has any commit access to anything gets commit access to everything, which we might not want as we scale.
Yeah, scaling is a valid point. I think splitting into multiple repos is a good way to go assuming we address the concerns that Scott has raised.
I think the main concern here (unless I"ve misunderstood) is visibility and collaboration which I think we can solve. I like the idea of the different Dockerfiles being separate similar to packages in DistGit purely because that allows people with expertise in certain areas to participate in the areas they care about and avoid all the other line noise of a shared repository.
Just my $0.02
Thanks!
-AdamM
[0] - https://apps.fedoraproject.org/packages/
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader
-- Regards, Slavek Kabrda
-- Regards, Slavek Kabrda _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
----- Original Message -----
----- Original Message -----
On Fri, Oct 2, 2015 at 4:01 AM, Bohuslav Kabrda slavek@redhat.com wrote:
----- Original Message -----
On Thu, Oct 01, 2015 at 10:00:43AM -0500, Scott Collier wrote:
My opinion is that the dist-git-for-dockerfiles plan should make Fedora Dockerfiles obsolete.
How would users who aren't necessarily involved in the Fedora build process experiment building images with a Fedora base? Right now
Hopefully this new dist-git can be fronted by pagure, so it'd be a matter of visiting a web site like https://pagure.io/fedora-bootstrap (not a docker example, just a random one) and either downloading the docker file or doing a git clone.
Heh, it seems that my career as Fedora-Dockerfiles comaintainer may be rather short :) I think having a web frontend with pull requests for the new dist-git is an awesome idea. I'm +0.9 for pagure. The advantage is that it will be completely under Fedora control, the small downside is that potential contributors from outside Fedora will have to create Fedora account, which might scare some people off.
From what I understand is that pagure uses OAuth and at the moment the only OAuth plugin in use is for FAS, we might be able to request to enable some short list of federated logins if:
- that is in fact possible
- the authors of pagure are open to it
- the Fedora Infrastructure team is OK with it
That would be nice! I'll try to ask pingou whether this would make sense to him (hopefully in the start of next week, I'm going to a conference for the rest of this week).
So I talked to pingou and here's the result: - Pingou actually has an evil plan to propose deploying a pagure instance at pkgs.fedoraproject.org. This means that *all* fedora packages would get a nice web interface with PRs and such. So if this happened, the dockerfile repos would automatically get that too. (IIUC pingou is still working on some remaining pagure features needed for this, so a formal proposal hasn't been made yet) - The problem with Github login is that people without Fedora accounts haven't signed the FPCA. It'd probably be technically possible to have such users sign FPCA in pagure, but pingou was concerned about code duplication and other weird problems that may arise from this solution - I do agree with him on this one. We should probably just require people to create FAS account in this case and sign the FPCA while creating it.
On Tue, Oct 13, 2015 at 05:30:21AM -0400, Bohuslav Kabrda wrote:
- The problem with Github login is that people without Fedora
accounts haven't signed the FPCA. It'd probably be technically possible to have such users sign FPCA in pagure, but pingou was concerned about code duplication and other weird problems that may arise from this solution - I do agree with him on this one. We should probably just require people to create FAS account in this case and sign the FPCA while creating it.
This is drifting way off topic for Cloud list, but... the above is something we could probably solve simply by making the wording about the license of this particular contribution part of the PR, and not worry about the FPCA itself. We'd have to check with Legal, of course.
-
Adam Miller -
Bohuslav Kabrda -
Dusty Mabe -
Joe Brockmeier -
Matthew Miller -
Scott Collier