17:00:27 #startmeeting Env and Stacks (2015-10-01) 17:00:27 Meeting started Thu Oct 1 17:00:27 2015 UTC. The chair is hhorak. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:27 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:27 #meetingname env-and-stacks 17:00:27 The meeting name has been set to 'env-and-stacks' 17:00:44 #chair bkabrda hhorak juhp ncoghlan vpavlin jkaluza walters ttomecek phracek 17:00:44 Current chairs: bkabrda hhorak jkaluza juhp ncoghlan phracek ttomecek vpavlin walters 17:00:49 * jkaluza is here from train because of big delay of the train, so hopefully the connection will work :) 17:01:24 jkaluza: Czech Railways.. typical.. 17:01:32 :) 17:02:38 * hhorak wondering whether scollier is available (remembering the meeting and potentially slower responses) 17:02:55 hhorak, present. 17:04:42 hhorak: I'm here. 17:04:47 great 17:04:59 #topic Fedora + CentOS docker images naming conventions 17:05:42 so let's start with summarizing what image names we use currently.. 17:05:44 the namespaces are clear: fedora/ and centos/ 17:06:06 does anybody plan some more namespaces either for centos or fedora from some reason? 17:06:58 no, but the namespacing shouldn't matter much in this context I don't think. 17:07:13 * hhorak doesn't think there is such need either 17:08:28 is it just us? who's here from the fedora side? 17:08:31 I think it should be OK to just have these two 17:08:39 hi Evolution, i'm here. 17:08:49 scollier: ah, great! 17:09:09 #info we're fine with namespaces: centos/ and fedora/ (nothing more needed for now) 17:09:47 one thing to not hhorak, today on the mailing list, a conversation is going on to obselete fedora-dockerfiles. to be replaced with a dist-git process. this conversation is still valid though, regardless of where they live. 17:10:22 scollier: thx for the note 17:10:24 s/not/note 17:10:50 #info today on the mailing list, a conversation is going on to obselete fedora-dockerfiles. to be replaced with a dist-git process. 17:11:05 so, the image names.. in fedora there are usually simple package names used, right? 17:11:30 hhorak, correct 17:11:30 *almost* 17:11:52 .info Evolution 17:11:52 scollier: Error: You don't have the rss capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified. 17:12:04 whoami 17:12:05 we're not using (and I don't think fedora does either), the full package name. 17:12:22 for example, it's not centos/mariadb-server 17:12:37 it's just centos/mariadb currently. 17:12:46 scollier: is that true for fedora as well? 17:12:47 same for fedora 17:12:57 Evolution: ah, correct 17:13:13 so does there need to be a client/server distinction in this case? 17:13:42 all names listed here: https://hub.docker.com/u/fedora/ 17:14:12 ah, so it's even fedora/apache instead of fedora/httpd 17:14:28 Evolution, not to mention, you don't really know what version. 17:14:37 we aren't doing tags correctly 17:14:40 Evolution: I'd say client/server distinction is not necessary for now (not sure when something like that will be required in full-dockerized environment) 17:15:43 and there is also systemd-apache, probably a variant that runs systemd in the container.. 17:15:44 I swear I'm not trying to be contrary, but if it may be necessary we should plan it out now/soon-ish rather than waiting for it to be an issue. 17:16:56 scollier: do we *care* about tagging versions? 17:17:12 Evolution: what we do currently is including the client in the image as well, so whoever needs just the client, it is possible (e.g. for databases). If there was a client-only image, I'm not sure what benefits it would bring except some space saved. 17:17:14 I could see an argument either way. 17:18:00 hhorak: possibly security, based on how the container starts. otherwise you'd have a mariadb instance for every client. 17:18:05 Evolution, i'm not sure there's another good way of letting someone know which version of postgresql they are getting, so they know whether or not to bother because of compability. 17:18:18 Evolution: I think we do, with the modules ideas around recently, specifying version is quite important.. 17:19:41 the downside is that means someone has to bump the tag or dockerfile every time the container is (re)built. 17:19:41 there are also the SCL images under the centos/ namespace, that use names, that have been already used by openshift for some time: e.g. mysql-55-centos7 17:20:18 Evolution: unless the version is in the name itself, like fedora/mysql-55 17:20:42 right. the 3 options for version would be in the name itself, label, or tag. 17:21:12 if it was in label only, it couldn't be used for pull, could it? 17:21:34 not with docker. that would likely require the atomic app. 17:21:48 so that's a non-starter. 17:21:49 I think currently the people are using tags for version most of the time. 17:22:12 Evolution, you can get label info with docker inspect. that's all atomic app is doing 17:22:29 and I personally don't like versions in names, but I don't think I have any technical reason for that 17:22:34 scollier: from the repo, or from the local once it's pulled? 17:22:45 Evolution, local 17:23:10 generic label spec: https://github.com/projectatomic/ContainerApplicationGenericLabels 17:23:28 docker's search is terrible enough without requiring a local pull to get info. 17:23:35 includes name / versions 17:23:37 Evolution, ack 17:24:21 so that leaves tags or version-in-name. 17:24:46 Do we have any other use-case for tags if not for version? 17:26:08 jkaluza_: maybe a functionality thing as well, for systemd vs non-systemd 17:26:18 that's all I can think of. 17:26:22 jkaluza_: osbs uses not only versions but also version_release and some internal tags to identify the concrete build.. but since there may be more tags specified, we don't block using tags for any other purpose.. 17:26:41 Evolution: I would use name for functional thing and tag for version definitely in this case 17:27:00 hhorak: I see 17:27:38 is there a longterm plan for systemd with containers? will we eventually do away with non-systemd enabled containers? 17:27:43 jkaluza_: it's how docker hub works, so users are familiar with that, which may be another +1 for that aproach 17:27:56 hhorak: that's my point too 17:28:36 okay. so tagging for versions, but how granular. 17:28:59 full version-release info to match rpm? 17:29:18 here's an example from rhcloud, ISV related: registry-nginxinc.rhcloud.com/nginx/rhel7-nginx:1.9.2 17:29:23 or major/minor for 'mysql:5.5' or 'httpd:2.4' 17:30:07 Evolution: one thing against systemd in container is that openshift has some problems with it (not sure whether all are technical) and in rhscl we need to make the images so that openshift likes that.. which means we may have problem with including systemd there for example.. 17:30:35 okay. was just curious. 17:31:07 scollier: you okay with changing the fedora/apache to fedora/httpd and similar ? 17:31:39 Evolution, i'm ok with it, but if the deprecation proceeds, the httpd maintainer will need to do that. 17:31:45 Evolution: major only is more important for users, they don't care about bugfix version.. it may be there as well as additional tag, but major version is must for me.. 17:31:49 Evolution, i can do short term. 17:32:40 so namespace/packagename:version for non-scl packages. 17:33:30 is that sane for everyone? 17:33:42 Evolution: yeah, that makes sense to me 17:33:59 hhorak, Evolution, should the basename have version too? 17:34:05 like, fedora21/xxxxxx 17:34:09 or fedora22/xxxxx 17:34:18 like in the example I pasted above for rhel. 17:34:58 scollier: that would mean you'd have fedora22/mariadb-server, fedora23/mariadb-server etc 17:35:02 scollier: I don't think this is much relevant for user -- mongodb from fedora 21 and 23 should work the same.. 17:35:06 I don't think I like that. 17:35:47 hhorak, what about other layered app dependencies? 17:36:12 i get that mongo should work the same, but what if i have an app that i need x version of mongo, but also need fedora 21 ? 17:36:16 for w/e reason 17:36:29 when i create my layered image from that, it matters, no? 17:36:59 depends if we care about docker's ideal 'one container per foo' 17:37:10 hhorak, Evolution, or mongo on centos7 vs centos6 17:37:15 so $app would be a separate container from mongo 17:37:57 yea. ok. 17:38:21 to me the distro version shouldn't matter. if $app needs f21, then it's dockerfile would call out f21 as the base. the end result is a container with app 17:38:33 s/it's/its/ 17:38:51 +1 here, I think the distro is irelevant 17:38:55 ok 17:38:58 at least it is for me when using containers 17:39:07 just making sure we covered / discussed that use case. 17:39:09 I think about it the same, distro shouldn't matter.. 17:39:38 scollier: yeah. it's a good point to bring up, so we're all on the same page about it. 17:40:12 and it just means centos / fedora will do one way, rhel will do another. 17:40:19 good to go 17:40:27 scollier: typical snowflake rh :-P 17:40:31 heh 17:41:36 #info we should be fine with namespace/packagename:majorversion for non-scl packages, distro seems to be irrelevant, because we usually use one component in one container and don't care much about the rest of the system in the container 17:43:02 yeah, rh is different because there are more namespaces under internal registry.. 17:43:34 so for scl names, how much room do we have there because of openshift? 17:44:19 :) 17:44:37 Evolution: good question. bparees was worried about changing names that are being used now.. 17:44:57 but for centos/ namespace we just started, so I think we should be still fine to change image names 17:45:31 I would like to spell out the rhscl builds vs the community builds 17:45:39 *but* same arguement for distro version in there 17:46:02 the distro doesn't matter, and the namespace should cover if it's centos vs fedora vs rhel based. 17:46:34 Evolution: that's correct 17:46:51 so right now we have centos/postgresql-94-centos7 17:47:08 that 'centos7' at the end is extraneous to me. 17:47:25 but it doesn't specify if it's a rhscl build vs community. 17:47:44 hhorak: I wasn't around for your discussion with alphacc/kb on that earlier. what was the result of that? 17:50:10 hm, not sure now, but I don't think we came to any result for sclo names.. 17:51:09 i think it would be helpful to have a naming policy under project atomic, or somewhere for all these options. like the label policy linked to above. 17:51:40 * hhorak not sure whether we need to distinguish between rhscl build vs. community here.. 17:51:51 scollier: +1 17:52:13 scollier: yeah. I want this to not be a distro thing, but a collaborative thing. 17:52:16 very +1 here. 17:54:42 hhorak: the rhscl vs community build may matter more for the rpm/repo bits than container. 17:54:55 Evolution: reason why we distinguish packages into community and rhscl-rebuilt is that community is handy for rhscl customers as well, similar how epel works.. I fail to see the same reason with images. 17:55:23 so yeah, I agree.. 17:55:48 so the only thing I want to do is strip the trailing distro/version bit off the end. 17:55:59 since centos/foo-centos is redundant 17:56:43 I think that's sane, +1 17:56:56 if possible :_ 17:56:57 :) 17:57:22 hhorak: so we'd need to go back to ben and see how much trouble we're stirring up for him. 17:57:40 Evolution: I have the same opinion, but will need to check with openshift whether they have some important reason to have centos there.. imho it was necessary when the images were under openshift/name-version-centos and openshift/name-version-rhel 17:58:01 yes. I'm also thinking how/whether to distinguish base-package-based containers from sclo-based containers.. 17:58:04 hhorak: I also think that was the reason 17:58:30 hhorak: is it needed? 17:58:54 hhorak: as a user of container, do I care where the binary is stored in the container? 17:59:15 jkaluza: the base-package-based might be "supported" (in terms of updated) much longer.. 17:59:33 I don't think that matters so much. 17:59:38 but you're right that we try to hide the fact the image is SCL-based as we can.. 18:00:05 so, if we go down that road, then we're *really* screwing with container names for the openshift folks. 18:00:26 they have the version in the name. 18:01:44 Evolution: we use the version also in RH images, but there are more differences between rh and centos names already. 18:03:13 that might be a problem for users then. 18:03:29 ie, someone who tries openshift origins on rhel vs on centos. 18:04:12 that's something what I expect will be also openshift's argument 18:05:02 I have to run in a few minutes. are we able to pick this up again after making bparees cry? 18:05:39 yeah, better to talk with him as well. 18:06:27 but at least we know what to do with the base-system-based images 18:07:30 scollier: one thing I wanted to ask -- what about the labels for specifying the image name and tag(s)? 18:08:18 hhorak, we haven't done anything with labels except in a few instances, a couple from your team and the new sssd image. 18:08:19 that's it. 18:08:30 hhorak, so what would you like to see? 18:09:00 scollier: basically use the name and version labels as described at #link https://github.com/projectatomic/ContainerApplicationGenericLabels 18:09:02 #link https://github.com/projectatomic/ContainerApplicationGenericLabels 18:09:21 hhorak, makes sense. 18:09:42 scollier: it will be then much easier to switch to osbs once it is ready 18:09:50 hhorak, ah, ok. 18:10:54 maybe the rest of the labels (at least the common) should be recommended at least (release, summary, description) 18:15:42 #idea start using labels (at least name, version, maybe at least optionally summary, description) as described at https://github.com/projectatomic/ContainerApplicationGenericLabels 18:17:30 #info for the images coming from sclo at centos we need to talk to openshift guys about whether centos needs to stay as suffix 18:17:43 ok, it seems we're done for today, any last thoughts? 18:18:00 not from me. thanks hhorak 18:18:19 #action hhorak to apprach bparees with outcomes from today's discussion 18:18:35 scollier: Evolution: jkaluza: thank you all as well 18:18:39 #endmeeting