12:04:01 #startmeeting Env and Stacks (2015-04-23) 12:04:01 Meeting started Thu Apr 23 12:04:01 2015 UTC. The chair is hhorak. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:04:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 12:04:06 #meetingname env-and-stacks 12:04:06 The meeting name has been set to 'env-and-stacks' 12:04:10 #chair bkabrda hhorak juhp ncoghlan vpavlin sicampbell walters ttomecek phracek 12:04:10 Current chairs: bkabrda hhorak juhp ncoghlan phracek sicampbell ttomecek vpavlin walters 12:04:26 hhorak: Hi 12:04:30 hi everyone 12:04:31 #topic init process 12:04:34 Hi 12:04:45 Hi there 12:05:20 hello 12:05:22 * langdon lurks 12:05:26 I don't see msuchy so let's wait with playground for later 12:05:31 hello 12:05:39 .hello langdon 12:05:41 langdon: langdon 'Langdon White' 12:05:41 #topic Dockerfiles recommended tips 12:06:07 #link https://lists.fedoraproject.org/pipermail/env-and-stacks/2015-April/000771.html 12:06:51 I just wanted to make this visible ^ we basically need to find how the 'default' user should look like in a docker container 12:07:29 I think that UID should start after 1000. 12:07:46 phracek: good, why? 12:08:12 hhorak: users defined in Fedora and I think in RHEL starts after 1000. 12:08:26 I actually think it should be 1000, because that's most convenient for most developer 12:08:53 cause most developers have uid 1000 on their machine 12:09:21 hhorak: Does it mean only one user or container can have own user? 12:09:27 a problem i see with any major changes to the base image like this is the possibility of breaking layers 12:09:48 walters: yeah, that's a very good point 12:10:35 this proposal is solving a real problem...but it feels like it's one we can't fix well on our end, just document best practices for user management in derived containers? 12:10:53 I can see some potential long term fixes in Docker where containers can allocate uids from the host or from some centralized system 12:11:05 as beyond just running unprivileged, there's the problem of uid clashes 12:11:10 phracek: that's actually the thing -- container has own passwd file but common kernel, so the UID in the container matches the UID in the host (as far as I understand the docker world) 12:11:28 walters: If I have UID 1000, then how it can break layers? 12:11:40 (if your mysql db is owned by uid 1000 and your frontend server is running nginx as 1000, you have circumvented security if they end up sharing volumes) 12:11:51 walters: solving it as best practice is totally fine with me :) 12:12:01 walters: Hmmm, I see. 12:12:40 on the other hand maybe we could just do it at a major version (f23?) 12:12:50 walters: I guess for services that run under own user (mysql run as mysql user) then the container should use this user.. the problem I try to solve is more about containers which do not have such a user available.. 12:12:53 could be reasonable to have a porting guide in that case 12:14:58 user namespaces 12:15:22 at some point, they will land in docker and then we'll have new problem 12:15:50 +1 on doing best practices instead of real changes 12:16:08 walters: has the example with running both mysql and nginx by user with UID 1000 some reason I don't get? 12:16:11 * ttomecek is checking how user namespaces work exactly 12:16:16 ttomecek: do you know if it's to be implemented soon or if it's "far future"? 12:16:41 the problem with user namespaces is the filesystems aren't namespaced 12:16:41 bkabrda, there is something already in docker 1.6 12:16:56 windows actually beats us by having UUIDs for uids rather than 32 bit integers 12:20:31 so, what problems can we get into in case the user has 1000 as UID and user on host doesn't? is my concern real, that we can expect user will mount something that is not readable in the container and vice versa? 12:20:56 by "mounting" I mean mounting the volume.. 12:21:41 hhorak: yeah. or user mounts Python source code in and the files get bytecompiled by Python in the container, which results in all sorts of funny errors 12:22:13 so that's why I actually was thinking about gaining some number <500, the same as for services.. 12:22:55 and user on host may or may not be part of the particular group to be able to work with those files on host 12:25:02 thinking about mock, it actually works the same, right? isn't container very similar what mock is -- own userspace with common kernel? 12:25:05 If we define some number lower < 500 then I think that a organization needs to standard them. 12:25:22 phracek: we have process for that in fedora 12:25:25 We should be avare about the numbers. 12:25:37 like 22 is already covered by ssh. 12:25:43 I mean port. 12:26:12 hhorak: ok. It should be announced outside of Fedora. Only for information. 12:26:34 i saw one of the openshift guys mention btw they were planning on randomly allocating a uid per app 12:26:47 (which is actually similar to what Android does) 12:26:53 phracek: ports are different things, but you're correct we would need to get one allocated 12:27:52 hhorak: Yeah, I have mixed to things. ;) 12:28:19 walters: that sounds like a way to go unless we find it is not good idea :) 12:28:24 *untill 12:31:11 #proposal let's first try to create the default user (if we need to create one) with randomly allocated UID and see what happens.. 12:31:36 * phracek nods 12:31:39 ah...well openshift has a higher level system that's in a position to do uid allocation 12:32:17 ok, here's a problem with that: what if developer wants to create *another* user in that container and wants to assign a certain UID to it? then it may happen that the randomu UID will collide... 12:32:40 I really don't think there's a reason to do this randomly 12:32:50 when we can just pick one and stick to it 12:33:03 so one simple thing to do would be to make a fedora/envs-and-stacks-base image that has this default user, and derive Docker-like language base images from that 12:33:16 and fedora/envs-and-stacks-base derives from fedora:22 etc 12:34:34 walters: I'd be fine even with the best practice way -- just document it and do it the same in every container that needs it (not everyone does) 12:37:24 it still doesn't seem to have clear answer, moving to another topic and try to narrow this down on ML or next meeting? 12:40:40 #info a problem any major changes to the base image like this is the possibility of breaking layers 12:40:40 #info openshift has a higher level system that's in a position to do uid allocation 12:40:41 #idea one simple thing to do would be to make a fedora/envs-and-stacks-base image that has this default user, and derive Docker-like language base images from that 12:40:41 #idea or we can just document best practices for user management in derived containers 12:41:27 (i was doing some searching around this, found the `--user` argument to `docker run` which at least i didn't know about) 12:42:12 walters: cool, I didn't know about that either 12:42:48 was in https://groups.google.com/forum/#!topic/docker-user/946c4tetS6E 12:43:49 #link https://groups.google.com/forum/#!topic/docker-user/946c4tetS6E 12:44:46 well, let's move to next topic, we've spent quite long with this one.. 12:44:58 #topic Playground result repo 12:46:04 you might notice we didn't got to agreement with msuchy on the ML about whether the playground repo should be "updated set of copr repo files on clients" or "one repo regenerated on server"... 12:46:38 IIRC, we were more thinking about "one repo regenerated on server" when we discussed this last time, or do I remember incorectly? 12:47:32 #info still not sure whether the playground repo should be "updated set of copr repo files on clients" or "one repo regenerated on server" 12:49:02 btw. jstanek would like to hack on playground idea a bit, so we were chatting about the tool that would "check conflicts of packages from copr with fedora base" -- jstanek, correct? 12:50:06 we also talked about the dnf part, but as mentioned by msuchy (who I hoped would be here today) this part should be already implemented 12:50:11 hhorak: We were chatting about multiple tools, nothing too concrete AFAIK 12:50:49 but as the dnf should be implemented, the conflict checking seems to remain 12:51:59 jstanek: exactly. so this one may be one of the tools we still look for :) it should (simply said) check that we don't ship some package in playground that would influence packages in the fedora base (by influencing I mean upgrade, prevent to install, ...) 12:52:59 #info looking for a tool that will (simply said) check that we don't ship some package in playground that would influence packages in the fedora base (by influencing I mean upgrade, prevent to install, ...) 12:53:07 OK, so only additional software, no variants of existing packages? 12:53:28 jstanek: right, this is what the content should be for the playground 12:54:36 we may have a similar repo that would provide updated variants of the same packages as in fedora base, but for now we'll focus on things that cannot be in fedora from some reason (e.g. guidelines) 12:55:26 hhorak: OK, got it 12:55:37 jstanek: great :) 12:57:49 speaking about playground generally, another task would be copr vs. taskotron vs. rpmgrill integration.. a coplex thing, that may consist of: 1) make rpmgrill working in taskotron 2) make rpmgrill to work with copr (now tight to koji pretty much) 3) make taskotron to listen and react on copr builds 12:57:50 hhorak, but this "override" problem is just a "warning" right? i do want to be able to upgrade/change/conflict potentially, right? or is this "playground shouldn't conflict" but a copr could? 12:58:29 * phracek is back after a minute 12:59:11 langdon: the later, we talked about this few weeks back and (IIRC) decided we don't want to allow conflicts in playground, for conflicting packages we have pure coprs or will have some other repo in the future 13:00:23 hhorak, ack.. 13:00:40 langdon: the reason is that we want to allow to enable whole playground repo at once -- in that case users would get updates for all packages, potentianally breaking the system.. 13:00:41 hhorak: yeah. 13:01:31 I think that playgroung repo should be only one. 13:02:13 Or split to more with to specific issues like developer playground repo, users playgroung repo, etc. 13:03:36 phracek: I would start with one repo first, then experiment with specializations ;) 13:04:38 I think one repo should be enough; if something doesn't fit into playground, it should most likely be just a plain copr repo 13:04:47 jstanek: good, I think it may result in quite useful general tool, we'll see... just use ML or come to the meeting if anything is not clear.. 13:05:45 At the beginning yes. Definitelly and we will see. 13:07:02 hhorak: Do we have any similar existing tools, which I could check first (links appreciated)? 13:07:03 #info for other volunteers :) another task would be copr vs. taskotron vs. rpmgrill integration.. a coplex thing, that may consist of: 1) make rpmgrill working in taskotron 2) make rpmgrill to work with copr (now tight to koji pretty much) 3) make taskotron to listen and react on copr builds 13:07:33 jstanek: the only similar I know of is depcheck from taskotron -- you may check what it does.. 13:08:46 #info we still do not have agreement with msuchy on the ML about whether the playground repo should be "updated set of copr repo files on clients" or "one repo regenerated on server"... let's try to narrow that down 13:09:27 #link https://fedoraproject.org/wiki/Taskotron/Tasks/depcheck 13:09:39 jstanek: ^ not sure how recent the wiki page is 13:09:58 #topic Modular Fedora -- more versions available, not necessarily install-able 13:10:00 hhorak: thanks 13:10:28 it was nice discussion the last week, so who was not there, I recommend to read the log :) (or at least minutes) 13:10:43 and langdon should have something related to this? 13:11:24 hhorak, yes, I am working on the write up for a "fedora objective" to work through these problems 13:11:38 * langdon in a few meetings at once right now 13:12:05 I would like to send out a draft of the "proposal"(?) later today but at the latest, the end of the week 13:13:54 langdon: nice, do you expect any action from us except reading it and comment on it? 13:14:18 hhorak, nope.. just to let me know if you have any other concerns as well 13:14:35 this is directly related to trying to do an objective based on the meeting last week 13:15:54 I miss some action item today, so... 13:15:54 #action everybody to follow the ML and try to actively participate :) 13:16:22 #topic open floor 13:16:37 phracek: ^ you had something on you mind, right? 13:16:45 hhorak: yes. 13:17:03 But I think that meeting is out of the time. 13:17:38 But I have an idea... 13:17:57 Let's say that you are new developer and you don't know hot to install a things to Fedora. 13:18:19 I know that we have the DA. But I would like to have a page in developer.fp.org 13:18:57 Therefore we create (with jstribny) a page which could navigate a new developers or advanced to specific things. 13:19:03 See some screenshots. 13:19:14 http://download.eng.brq.redhat.com/scratch/phracek/landing_page.png 13:19:22 http://download.eng.brq.redhat.com/scratch/phracek/project_page.png 13:19:49 I have already mentioned it on app-infra 13:20:06 and have responses that it would be good to implemented. 13:20:11 very nice! 13:20:18 E.g. Docker could have parts like: 13:20:24 Install (relevant to Fedora) 13:20:32 etc. 13:21:01 Another distributions already have pages like developer.{apple|ubuntu}.com 13:21:12 AND we miss the page. 13:21:35 Do you have any topic or idea which should be mentioned here? 13:21:55 Currently now we have: Docker, Vagrant, DA (of course), Copr, Atomic. 13:22:11 If you have any idea feel free to response on app-infra. 13:22:13 ML list. 13:22:20 That's all. 13:22:23 phracek: maybe we can talk about this on the next meeting, because I'll have to think about this before I'll start saying what I miss there :) 13:22:33 Yes. 13:22:42 hhorak: Please take it to the agenda pls. 13:23:33 phracek: I think this is really good start, we can add things later, but having something to start would be awesome! 13:23:59 yeah, next meeting brings me to the last item.. 13:23:59 #topic Chair for next week (hhorak not available) 13:24:00 YES. We need to be better then other distributions. 13:24:15 anybody volunteers to chair the meeting the next week? 13:24:37 I usually can't make it to the meeting at all during the alternating week... 13:26:02 I have promised that next weekend I will take care of my kids. I am not able to join to the meeting too. 13:26:20 Sorry. Next Thursday. of course 13:26:31 phracek: right, it is before the bank holiday.. 13:27:30 so let's close without having a victim :) if nobody volunteers, the meeting won't happen then... 13:28:32 #info no volunteer found for the next week's meeting, so we're still looking for one 13:28:43 #endmeeting