Closed grepory closed 8 years ago
docker2aci is already adding those annotation while converting (perhaps it should be better documented):
"annotations": [
{
"name": "created",
"value": "2016-09-23T18:08:51Z"
},
{
"name": "appc.io/docker/registryurl",
"value": "registry-1.docker.io"
},
{
"name": "appc.io/docker/repository",
"value": "library/debian"
},
{
"name": "appc.io/docker/imageid",
"value": "37c816ae4431cabacbd1cf9ef8b50f9945ebc47a9aaa26a315612edc52b12c32"
},
{
"name": "appc.io/docker/parentimageid",
"value": "d0c4f1eb7dc8f4dae2b45fe5c0cf4cfc70e5be85d933f5f5f4deb59f134fb520"
},
{
"name": "appc.io/docker/cmd",
"value": "[\"/bin/bash\"]"
},
{
"name": "appc.io/docker/tag",
"value": "latest"
}
]
I think those annotations so far cover metadata that we found was needed by other tools. Do they cover your usecase too or do you need something else additionally?
@lucab he's referring specifically to keeping docker labels around, which we should probably add.
Luca Bruno notifications@github.com schrieb am Mi., 19. Okt. 2016, 11:52:
docker2aci is already adding those annotation while converting (perhaps it should be better documented):
"annotations": [ { "name": "created", "value": "2016-09-23T18:08:51Z" }, { "name": "appc.io/docker/registryurl", "value": "registry-1.docker.io" }, { "name": "appc.io/docker/repository", "value": "library/debian" }, { "name": "appc.io/docker/imageid", "value": "37c816ae4431cabacbd1cf9ef8b50f9945ebc47a9aaa26a315612edc52b12c32" }, { "name": "appc.io/docker/parentimageid", "value": "d0c4f1eb7dc8f4dae2b45fe5c0cf4cfc70e5be85d933f5f5f4deb59f134fb520" }, { "name": "appc.io/docker/cmd", "value": "[\"/bin/bash\"]" }, { "name": "appc.io/docker/tag", "value": "latest" } ]
I think those annotations so far cover metadata that we found was needed by other tools. Do they cover your usecase too or do you need something else additionally?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/appc/docker2aci/issues/208#issuecomment-254767031, or mute the thread https://github.com/notifications/unsubscribe-auth/ACewN39GKtu7HcpOS6uVJIltYEwT0lrgks5q1eh5gaJpZM4KaXfq .
I did indeed mean that very thing. We use the LABEL directive in our docker files to encode build-time information into the image. Then when the image is signed, so is that static metadata. This is pretty important to our ability to track what is deployed: who built it, when did they build it, what git rev was used to build it, etc.
Makes sense. I think we can just create appc.io/docker/labels annotations and store them in there.
Greg Poirier notifications@github.com schrieb am Mi., 19. Okt. 2016, 18:48:
I did indeed mean that very thing. We use the LABEL directive in our docker files to encode build-time information into the image. Then when the image is signed, so is that static metadata. This is pretty important to our ability to track what is deployed: who built it, when did they build it, what git rev was used to build it, etc.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/appc/docker2aci/issues/208#issuecomment-254872016, or mute the thread https://github.com/notifications/unsubscribe-auth/ACewNyj_52PyoeOV81hiOQkYA9dKy6Sbks5q1knAgaJpZM4KaXfq .
We have tooling around the label-schema.org stuff. Would it be horribly inappropriate to keep the current label namespace?
Do you mean copy the labels to annotations?
Greg Poirier notifications@github.com schrieb am Mi., 19. Okt. 2016, 19:11:
We have tooling around the label-schema.org stuff. Would it be horribly inappropriate to keep the current label namespace?
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/appc/docker2aci/issues/208#issuecomment-254878559, or mute the thread https://github.com/notifications/unsubscribe-auth/ACewN_1TzkD3f5qR0u8ckD4OxhnNjDv5ks5q1k9PgaJpZM4KaXfq .
Yes, if annotations are the equivalent of docker labels. What is the difference between an appc annotation vs appc label?
appc labels are more like selectors, used for discovery. So there should be a small set of well known labels used as "query parameters" when trying to locate an image (analogous to tags, but immutable).
Annotations can be arbitrary and hence are pretty much equivalent to docker labels.
Greg Poirier notifications@github.com schrieb am Do., 20. Okt. 2016, 00:28:
Yes, if annotations are the equivalent of docker labels. What is the difference between an appc annotation vs appc label?
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/appc/docker2aci/issues/208#issuecomment-254959522, or mute the thread https://github.com/notifications/unsubscribe-auth/ACewNxSeRWZlGIV-0YukvsZ3dgF9GbSJks5q1pmLgaJpZM4KaXfq .
Assuming that appc annotations == docker labels.
We right now use:
FROM #{docker_image}
LABEL org.label-schema.schema-version="1.0"
LABEL org.label-schema.name="#{job_name}"
LABEL org.label-schema.build-date="#{Time.now.to_datetime.rfc3339}"
LABEL org.label-schema.vcs-ref="#{git_rev}"
LABEL org.label-schema.os-release="#{os_release(docker_image)}"
LABEL org.label-schema.vendor="Stripe"
Pardon the Ruby, but every image we create gets these labels.
From the exported image, we take all of the labels from the config file referenced in manifest.json and make those annotations in the resulting appc manifest without modifying the label identifiers (use the label-schema.org naming scheme instead of the /-delimited namespacing that coreos uses).
Closed by #223.
It would appear that annotations are the equivalent to Docker labels: i.e. immutable image metadata. Is that the case, and if so, can we support keeping image labels around as annotations after conversion? Or as labels?