Bug 1053222 - Review Request: fedora-dockerfiles - Example dockerfiles to assist standing up containers quickly
Summary: Review Request: fedora-dockerfiles - Example dockerfiles to assist standing u...
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review   
(Show other bugs)
Version: rawhide
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Matthew Miller
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-14 21:35 UTC by Lokesh Mandvekar
Modified: 2014-07-01 22:59 UTC (History)
9 users (show)

Fixed In Version: fedora-dockerfiles-0-0.3.git7753bdf.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-03-02 03:45:32 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
mattdm: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)

Description Lokesh Mandvekar 2014-01-14 21:35:20 UTC
Spec URL: http://lsm5.fedorapeople.org/fedora-dockerfiles/SOURCES/fedora-dockerfiles.spec
SRPM URL: http://lsm5.fedorapeople.org/fedora-dockerfiles/SRPMS/fedora-dockerfiles-0-0.1.git202887b.fc21.src.rpm

Description: 
This package provides a community contributed set of examples that can
assist in learning about Docker containers. Use these examples to
stand up test environments using the Docker container engine.

Fedora Account System Username: lsm5

koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=6405939

$ rpmlint SOURCES/fedora-dockerfiles.spec SRPMS/fedora-dockerfiles-0-0.1.git202887b.fc21.src.rpm RPMS/noarch/fedora-dockerfiles-0-0.1.git202887b.fc21.noarch.rpm
SOURCES/fedora-dockerfiles.spec:19: W: setup-not-quiet
fedora-dockerfiles.src:19: W: setup-not-quiet
2 packages and 1 specfiles checked; 0 errors, 2 warnings.

Comment 1 Christopher Meng 2014-01-21 14:54:16 UTC
Is it better to name it docker-fedora?  Like cmake-fedora? 

Thanks.

Comment 2 Lokesh Mandvekar 2014-01-21 15:03:55 UTC
(In reply to Christopher Meng from comment #1)
> Is it better to name it docker-fedora?  Like cmake-fedora? 
> 
> Thanks.

Upstream said they aren't ready to endorse this package officially (yet). imho, something like docker-* might give the impression of official affiliation, (what do you think?)

I'm told it's ok to name something fedora-PACKAGE. There seem to be quite a few of those which aren't official fedora packages.

Personally I'm ok with whatever (upto majority vote).

Comment 3 Lokesh Mandvekar 2014-01-21 15:18:03 UTC
(In reply to Lokesh Mandvekar from comment #2)
> (In reply to Christopher Meng from comment #1)
> > Is it better to name it docker-fedora?  Like cmake-fedora? 
> > 
> > Thanks.
> 
> Upstream said they aren't ready to endorse this package officially (yet).
> imho, something like docker-* might give the impression of official
> affiliation, (what do you think?)

By upstream here, I mean docker and not Scott Collier (the current upstream for this package) :)

Comment 4 Matthew Miller 2014-02-04 14:09:41 UTC
Finally getting around to the review -- sorry.

/usr/share/fedora-dockerfiles needs to be owned by the package (list %dir %dir %{_datadir}/%{name} in the %files)

Not necessary, but it might be cleaner to do the install part in a loop.

Also: the auto-picked up deps on /bin/bash and /bin/sh are spurious, since those scripts are executed inside the container. I think that making the scripts not executable will fix that (although I'm not sure that the RUN command will still work?). So maybe filter out the deps with RPM kludges -- or else make whatever Dockerfile modifications are needed so the scripts can be shipped nonexecutable. (That actually makes most sense to me because they could theoretically actually be disastrous if run on the host accidentally.)

Question for Scott: do we want to do GPLv2 or a more permissive license? Although it's some amount of overhead, it might be nice to clarify the license specifically in each Dockerfile (or at least each subdirectory); this gives us some room to use different possibly-conflicting licenses for different contributions in the future.

Comment 5 Lokesh Mandvekar 2014-02-05 02:39:38 UTC
(In reply to Matthew Miller from comment #4)
> Finally getting around to the review -- sorry.
> 
> /usr/share/fedora-dockerfiles needs to be owned by the package (list %dir
> %dir %{_datadir}/%{name} in the %files)
> 
> Not necessary, but it might be cleaner to do the install part in a loop.

Sure thing. I'll put up a new version after Scott updates upstream.

> 
> Also: the auto-picked up deps on /bin/bash and /bin/sh are spurious, since
> those scripts are executed inside the container. I think that making the
> scripts not executable will fix that (although I'm not sure that the RUN
> command will still work?). So maybe filter out the deps with RPM kludges --
> or else make whatever Dockerfile modifications are needed so the scripts can
> be shipped nonexecutable. (That actually makes most sense to me because they
> could theoretically actually be disastrous if run on the host accidentally.)

So the current Dockerfiles seem to handle chmod +x by themselves so I think we can -x scripts by default.
If that's agreeable, Scott please see my PR for -x on scripts on your github repo :)


> 
> Question for Scott: do we want to do GPLv2 or a more permissive license?
> Although it's some amount of overhead, it might be nice to clarify the
> license specifically in each Dockerfile (or at least each subdirectory);
> this gives us some room to use different possibly-conflicting licenses for
> different contributions in the future.

Comment 6 scollier 2014-02-11 21:32:54 UTC
(In reply to Matthew Miller from comment #4)
> Finally getting around to the review -- sorry.
> 
> /usr/share/fedora-dockerfiles needs to be owned by the package (list %dir
> %dir %{_datadir}/%{name} in the %files)
> 
> Not necessary, but it might be cleaner to do the install part in a loop.
> 
> Also: the auto-picked up deps on /bin/bash and /bin/sh are spurious, since
> those scripts are executed inside the container. I think that making the
> scripts not executable will fix that (although I'm not sure that the RUN
> command will still work?). So maybe filter out the deps with RPM kludges --
> or else make whatever Dockerfile modifications are needed so the scripts can
> be shipped nonexecutable. (That actually makes most sense to me because they
> could theoretically actually be disastrous if run on the host accidentally.)
> 
> Question for Scott: do we want to do GPLv2 or a more permissive license?
> Although it's some amount of overhead, it might be nice to clarify the
> license specifically in each Dockerfile (or at least each subdirectory);
> this gives us some room to use different possibly-conflicting licenses for
> different contributions in the future.

Good idea.  I added GPLv2 to each subdirectory.  Hopefully that'll work.

Comment 7 scollier 2014-02-11 21:33:28 UTC
(In reply to Lokesh Mandvekar from comment #5)
> (In reply to Matthew Miller from comment #4)
> > Finally getting around to the review -- sorry.
> > 
> > /usr/share/fedora-dockerfiles needs to be owned by the package (list %dir
> > %dir %{_datadir}/%{name} in the %files)
> > 
> > Not necessary, but it might be cleaner to do the install part in a loop.
> 
> Sure thing. I'll put up a new version after Scott updates upstream.
> 
> > 
> > Also: the auto-picked up deps on /bin/bash and /bin/sh are spurious, since
> > those scripts are executed inside the container. I think that making the
> > scripts not executable will fix that (although I'm not sure that the RUN
> > command will still work?). So maybe filter out the deps with RPM kludges --
> > or else make whatever Dockerfile modifications are needed so the scripts can
> > be shipped nonexecutable. (That actually makes most sense to me because they
> > could theoretically actually be disastrous if run on the host accidentally.)
> 
> So the current Dockerfiles seem to handle chmod +x by themselves so I think
> we can -x scripts by default.
> If that's agreeable, Scott please see my PR for -x on scripts on your github
> repo :)
> 

Done.

> 
> > 
> > Question for Scott: do we want to do GPLv2 or a more permissive license?
> > Although it's some amount of overhead, it might be nice to clarify the
> > license specifically in each Dockerfile (or at least each subdirectory);
> > this gives us some room to use different possibly-conflicting licenses for
> > different contributions in the future.

Comment 8 Lokesh Mandvekar 2014-02-11 23:23:45 UTC
%changelog
* Tue Feb 11 2014 Lokesh Mandvekar <lsm5@redhat.com> 0-0.2.git7753bdf
- use a loop to install stuff
- include firefox and nodejs
- install separate license for each program

Spec URL: http://lsm5.fedorapeople.org/fedora-dockerfiles/fedora-dockerfiles.spec
SRPM URL: http://lsm5.fedorapeople.org/fedora-dockerfiles/SRPMS/fedora-dockerfiles-0-0.2.git7753bdf.fc21.src.rpm

BTW, there's this:

$ rpmlint RPMS/noarch/fedora-dockerfiles-0-0.2.git7753bdf.fc21.noarch.rpm
fedora-dockerfiles.noarch: E: non-executable-script /usr/share/fedora-dockerfiles/mysql/start.sh 0644L /bin/bash
fedora-dockerfiles.noarch: E: non-executable-script /usr/share/fedora-dockerfiles/postgres/postgresql-setup 0644L /bin/sh
fedora-dockerfiles.noarch: E: non-executable-script /usr/share/fedora-dockerfiles/firefox/xstartup 0644L /bin/sh
fedora-dockerfiles.noarch: E: non-executable-script /usr/share/fedora-dockerfiles/postgres/start_postgres.sh 0644L /bin/bash
fedora-dockerfiles.noarch: E: non-executable-script /usr/share/fedora-dockerfiles/mysql/config_mysql.sh 0644L /bin/bash
fedora-dockerfiles.noarch: E: non-executable-script /usr/share/fedora-dockerfiles/wordpress_single_container/foreground.sh 0644L /bin/bash
fedora-dockerfiles.noarch: E: non-executable-script /usr/share/fedora-dockerfiles/wordpress_single_container/start.sh 0644L /bin/bash
fedora-dockerfiles.noarch: E: non-executable-script /usr/share/fedora-dockerfiles/postgres/postgres_user.sh 0644L /bin/bash
fedora-dockerfiles.noarch: E: non-executable-script /usr/share/fedora-dockerfiles/ssh/start.sh 0644L /bin/bash
1 packages and 0 specfiles checked; 9 errors, 0 warnings.

Can this be ignored, or should the install location be changed perhaps?

Comment 9 Matthew Miller 2014-02-11 23:45:56 UTC
I think that can be ignored. I can't think of a better location, and they're really not _supposed_ to be executed.

Comment 10 Matthew Miller 2014-02-19 15:33:31 UTC
oops -- need to own "/usr/share/fedora-dockerfiles"

Comment 11 Lokesh Mandvekar 2014-02-19 15:52:24 UTC
%changelog
* Wed Feb 19 2014 Lokesh Mandvekar <lsm5@redhat.com> 0-0.3.git7753bdf
- own main package directory

Spec URL: http://lsm5.fedorapeople.org/fedora-dockerfiles/fedora-dockerfiles.spec
SRPM URL: http://lsm5.fedorapeople.org/fedora-dockerfiles/SRPMS/fedora-dockerfiles-0-0.3.git7753bdf.fc21.src.rpm

Comment 12 Matthew Miller 2014-02-19 15:59:39 UTC
Package review passed.

Comment 13 Lokesh Mandvekar 2014-02-19 16:07:21 UTC
(In reply to Matthew Miller from comment #12)
> Package review passed.

Thanks Matt!




New Package SCM Request
=======================
Package Name: fedora-dockerfiles
Short Description: Example dockerfiles to assist standing up containers quickly
Owners: lsm5
Branches: f20 el6 epel7
InitialCC:

Comment 14 Gwyn Ciesla 2014-02-19 16:19:49 UTC
Git done (by process-git-requests).

Comment 15 Fedora Update System 2014-02-19 16:41:19 UTC
fedora-dockerfiles-0-0.3.git7753bdf.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/fedora-dockerfiles-0-0.3.git7753bdf.el6

Comment 16 Fedora Update System 2014-02-19 16:47:55 UTC
fedora-dockerfiles-0-0.3.git7753bdf.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/fedora-dockerfiles-0-0.3.git7753bdf.fc20

Comment 17 Fedora Update System 2014-02-20 07:00:55 UTC
fedora-dockerfiles-0-0.3.git7753bdf.el6 has been pushed to the Fedora EPEL 6 testing repository.

Comment 18 Fedora Update System 2014-03-02 03:45:32 UTC
fedora-dockerfiles-0-0.3.git7753bdf.fc20 has been pushed to the Fedora 20 stable repository.

Comment 19 Fedora Update System 2014-03-06 21:13:19 UTC
fedora-dockerfiles-0-0.3.git7753bdf.el6 has been pushed to the Fedora EPEL 6 stable repository.


Note You need to log in before you can comment on or make changes to this bug.