hhorak added a new comment to an issue you are following:
``
> 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?
Big part of the atomic-reactor functionality is available via plugins, and this feature is available in the pre_add_help plugin:
https://github.com/projectatomic/atomic-reactor/blob/master/atomic_reactor/…
The tool go-md2man is used to convert the README.md to help.1
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/256
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
ttomecek added a new comment to an issue you are following:
``
I like the new requirements: it should be clear to finish the implementation.
Is `atomic` meant to interact with description label in any way?
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/256
hhorak 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.
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.
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/
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/256
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
dustymabe added a new comment to an issue you are following:
``
seems reasonable. one small change I would make is that the description be only 1 line. I would prefer to only have one line even if it is a long line, I think.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/256
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
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
The status of the issue: `Consider creating redirection site for image Help Files` of project: `atomic-wg` has been updated to: Closed by jberkus.
https://pagure.io/atomic-wg/issue/255
jberkus added a new comment to an issue you are following:
``
This is not going to be required, so closing the issue.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/255