Steve, (And the rest of kolla) This raises a question I've had for a while and wanted to talk through.
Right now, kolla versions containers based on the kolla version (packaging version). In most package managers dpkg/rpm/etc, the versioning is done in a very different way. The software being shipped gets the version number, and a packaging version number is appended with a dash. so, 14.0.3-1 If the packaging is buggy but the software doesn't have a new release, it gives a nice place to fix that: 14.0.3-2 This lets the user very quickly see what the upstream software number is, which is what is most cared about. Its flexible enough to use complicated packaging versions too . For example, redhats kernel package: kernel-3.10.0-327.13.3 (version 3.10.0 kernel, 327.13.3 version of the package) I think containers are a slightly more unique case as not only the primary software release is in there, but also all its dependencies. so there is a case where the primary software doesn't change, the packaging stuff doesn't change, but the dependencies get updated. So, I think my proposal is to tag on a build number at the end. so something like: 14.0.3-1-1 then a pure dependency security update (openssl upgraded for example) would produce 14.0.3-1-2 If we tag everything this way, it should be easy for someone to know, for example, what version of nova the package was, and if there is a more up to date version of the package then what is currently running on their system. It would allow folks to apply the common pattern for packaging that is already commonly understood. We might even might be able to automate the scanning/update process in kolla to assist with that at some point. What do you think? Thanks, Kevin ________________________________ From: Steven Dake (stdake) [std...@cisco.com] Sent: Friday, November 18, 2016 3:51 AM To: zhu.z...@zte.com.cn Cc: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [kolla] Obtaining version information for Docker container Zhu, This isn’t the first time this question has been asked :) Since this is a technical matter, I’ve copied openstack-dev for a wider audience. I don’t have a clear solution to obtaining version manifests for container content or the upstream container version. Perhaps someone in our broader community may have an answer. The best I’ve got is we could add a general shell command that can be run with docker exec to obtain a proper version manifest of both 1 and 2 (formatted in YAML or plaintext). This could be placed in the base container image to enable a general diagnostic and certificate of origin tool. Perhaps someone has a better solution? Regards -steve From: "zhu.z...@zte.com.cn<mailto:zhu.z...@zte.com.cn>" <zhu.z...@zte.com.cn<mailto:zhu.z...@zte.com.cn>> Date: Friday, November 18, 2016 at 1:56 AM To: Steven Dake <std...@cisco.com<mailto:std...@cisco.com>> Subject: <no subject> Hello，nice to meet you. I am a contributor of Kolla. Excuse me, I have a question to bother you. The question is that how to get openstack component version from a running container or image. you know , the version info is wrapped by the container, it is not easy to get them there are two type of versions one: version in a image, two: version in a running container two is easy, for example , we can get it by calling docker exec... but how to get the one, Is there any way, Thanks.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
