[atomic-wg] Issue #256: atomic command changes: prefer file over label
by Dusty Mabe
dustymabe added a new comment to an issue you are following:
``
> Example of multi-line description is here: https://hhorak.fedorapeople.org/httpd-docker/Dockerfile
> I think it works still quite well and looks better in the Dockerfile than one long line IMO.
Yes, but what you are doing is breaking up what will be a single line into multiple lines when you define it. That is perfectly fine IMHO. What I didn't want was newlines in the actual value. I think what you have is fine, assuming I understand everything correctly.
You also have SUMMARY and DESCRIPTION. I think what we were proposing for DESCRIPTION actually matches more closely with what you have for SUMMARY. I know this is taken from rpm world, I just wonder if we need both.
> Anyway, the New requirements seem fine to me, with those thoughts:
> ad 3: I expect that OSBS in Fedora uses atomic-reactor that is able to convert and add the README.md from dist-git to help.1 and add the COPY command into the Dockerfile. Why not use this feature? It would limit the maintainer's responsibility to maintain README.md only.
I don't think we knew about this feature. Do you have a link to more details?
> ad 6: There is an 'url' label in the generic guidelines if anybody wants to point users to some URL: https://github.com/projectatomic/ContainerApplicationGenericLabels/
interesting. I like it. `url` could be useful and I really like `vcs-type`, `vcs-url`, and `vcs-ref` as well. Is it able to automate adding those labels into the image with OSBS as well?
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/256
7 years
[atomic-wg] Issue #196 `moving to docker 1.13 in Fedora 25`
by Pagure
dustymabe reported a new issue against the project: `atomic-wg` that you are following:
``
In the meeting today @runcom brought up the topic of:
- removing docker-latest in Fedora (mail thread on that [here](https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-January/msg00037.html))
- moving to docker 1.13 (just released) in Fedora 25
There are some concerns over moving to docker 1.13 but we believe that if we are able to qualify it enough it would be beneficial to go to the latest version so that @runcom doesn't have to manage so many versions of docker. The current proposal is:
- first, wait 4 weeks
- let some bugs from initial release work itself out
- many of us are traveling over the next few weeks anyway so this won't hurt
- 2nd, put out update to updates-testing and wait some time for thorough tests to be conducted on the testing ostree.
- If there are big issues with 1.13 that don't have a ready fix (performance issues, complicated issues that don't have fixes) then we can unpush 1.13 from updates-testing and put out security fixes etc for 1.12. We'd like to not have to unpush if possible though.
Another thing that might be useful is a condensed list of changes from 1.12 to 1.13. @runcom, could you provide us with that information?
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/196
7 years
[atomic-wg] Issue #234 `Container guidelines for containers with volumes`
by James Hogarth
jhogarth reported a new issue against the project: `atomic-wg` that you are following:
``
To protect persistent data it's common to use a VOLUME in the Dockerfile to automatically generate and mount a volume for the container on the host.
Best practice when running these containers should be to used a named volume at that point to ensure persistent when the container is updated.
If VOLUME is not in the Dockerfile then there is a risk of data loss on container updates with an admin not paying attention to which data should be persistent.
I'd suggest we should allow VOLUME in the guidelines for the container maintainer to be clear what is considered important data that must be persisted but we should have a way of making it clear what should be declared at runtime.
An example would be the owncloud container review request which makes the httpd and owncloud configuration directories volumes for persistence and allow customisation, and makes the owncloud data directory a volume to prevent data loss.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/234
7 years
[atomic-wg] Issue #256: atomic command changes: prefer file over label
by Josh Berkus
jberkus added a new comment to an issue you are following:
``
Ref issues #243 #267
New requirements:
1. Every image is required to have a "description" label, which will be 1-3 lines of human-readable text on what the image is for. This description is meant to be searchable by skopeo.
2. Images are required to have either a "help" label or a "help" file, the latter being preferred. They should not have both.
3. The Help file can be named "help.1" or "README.md". It must be COPYd into the image and reside in the root directory.
4. If the maintainer prefers a "help" label, the label should include an executable command which displays a help page in some reasonable text format. Minimally, this could be as simple as "echo 'How to use this image'".
5. For users who don't use the Atomic CLI, we will offer simple instructions on how to display the help ("docker run --rm some:image /bin/cat help1.txt && /bin/cat README.md").
6. We will do nothing with URLs for the time being. Instead, we will implement a HELPURL system at some later date when we have the resources to do so completely automatically. In the meantime, help files are browseable on dist-git.
Does this work for everyone? In this case, the only required change to "atomic help" is supporting README.md. The reason we want that, btw, is for Github user friendliness.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/256
7 years