14:04:24 #startmeeting Rally 14:04:25 Meeting started Mon Nov 2 14:04:24 2015 UTC and is due to finish in 60 minutes. The chair is ikhudoshyn. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:04:26 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:04:28 The meeting name has been set to 'rally' 14:04:33 \o/ 14:04:34 o/ 14:04:54 hi 14:05:05 we need more people:) 14:05:10 hi 14:05:18 hi 14:05:18 boris-42 seems trying to get sleep enough after the summit 14:05:36 yeah 14:05:46 we got a couple items in the agenda 14:05:54 let's start 14:06:06 #topic [andreykurilin] Sudo access for rally user in docker container. - https://answers.launchpad.net/rally/+question/273388 14:06:21 andreykurilin: your turn 14:06:43 this question was raisen a lot of times 14:07:00 there are a lot of users, which want to use `sudo` inside container 14:07:05 *docker container 14:07:27 ` -u root` option for docker run sucks 14:07:46 since it doesn't save the state of container 14:08:18 as far as I remember, there were some comments from redixin side 14:08:47 but I don't remember why he dislike sudo rights inside our image 14:09:06 i dont dislike any rights, it just not docker way 14:09:13 :) 14:09:21 any user can do anything with image using -u root 14:09:34 is there a good reason why we dont use 'root' user, at all 14:09:35 ? 14:10:10 redixin: as far as I understand, if user install some package and turn off container, all changes will be lost 14:10:11 is there a good reason to why ppl not use 'root' user 14:10:12 tight? 14:10:33 *right 14:10:42 andreykurilin, there are 'image' and 'container' in docker 14:11:01 image is read-only 14:11:31 'container' is created when user run any single command 14:11:46 'container' is clone of 'image' 14:11:55 with changes made by this command 14:12:13 just read the docker docs before using it 14:12:17 omg 14:12:19 redixin: i'd even say 'container' is kinda a process run from command 14:12:34 okey 14:12:54 in fact don't ppl use root at all? 14:12:58 or do they 14:12:59 ? 14:13:40 there is no need to be root for launch benchmark 14:13:41 since there is nothing except rally in container, there is nothing to 'protect' from rally process 14:13:45 am I wrong? 14:13:57 my point is "if we can not restrict usage of root for our image, we should not add a headache for those who want to do it" 14:14:21 redixin: no need, that's true 14:14:28 andreykurilin: do not follow u 14:15:00 root is root even inside a jail 14:15:43 redixin: is it a general reasoning, or there is any particular use case when being root is evil inside container? 14:16:06 for me being root in a single user env sounds ok 14:16:27 is there any particular reason when being root is evil not inside a container? 14:17:12 docker at all seems to be about apps, not users 14:17:44 we should follow a best practices of using docker 14:18:10 docker is an LXC, first of all. So, LXC issues inherited 14:18:32 redixin: absolutely agree, so I've asked, do people useanother user in docker instead of root 14:18:32 > If a service can run without privileges, use USER to change to a non-root user. 14:18:33 ? 14:18:45 and if you have root in container, than you have toot on whole host 14:19:23 s/toot/root 14:19:26 oanufriev_: it's not the kind of behavior one could expect from 'jail' 14:19:55 redixin: ok sounds reasonable 14:20:35 andreykurilin: back to your question.. 14:20:36 if we use 'root' instead of 'rally' user, there will be another questions to us. like "using root is bad. why are you using root?" 14:21:02 redixin: ok, I'm fine with 'rally' too 14:21:44 andreykurilin: am I right, it's about ability to make sudo? 14:23:01 hm.. andreykurilin ? 14:24:01 we can make sudo for those people who dont want to use -u root for some reason 14:26:33 ok, we seem to lose andreykurilin for a while 14:26:56 redixin: sure we can)) but should we, really? 14:27:50 do we want to elaborate morenow, without topicstarter? 14:28:06 or just move to the next topic for a while? 14:28:34 ikhudoshyn, it may be useful if we want to just fast install and try some stuff 14:29:08 redixin: yes, that's understood 14:29:15 like if we already inside a container, and not want to spend one minute to go out and run -u root 14:29:45 yep. Ok, let's just fix that 14:30:18 sorry) 14:30:52 andreykurilin: it's ok 14:30:59 great to see u back 14:31:06 ikhudoshyn: "am I right, it's about ability to make sudo?" yes 14:31:17 looks like we're fine to just add sudo 14:31:47 "yep. Ok, let's just fix that" nice 14:32:14 can we just add 'NOPASSWD:' line to sudo conf, so that we could continue w/o passwd 14:32:15 ? 14:32:44 I suppose it would be nice to have a simple password 14:32:56 oh no 14:33:02 so users will think about "do I really need sudo" 14:33:31 +1 for no password 14:33:36 :( 14:33:39 ok 14:33:41 +1 for no passwd 14:33:55 can we save limited commands list to sudores? 14:34:14 amaretskiy: that's not wjhat ppl expect I believe 14:34:23 ok, sorry 14:35:04 and making people finding out password just to find out that there is no one exist does not look like good usability 14:35:15 amaretskiy: dont be)) 14:35:35 lets vote: add sudo, no password 14:35:37 +1 14:35:54 redixin: we've seen yours 14:35:56 i'm in doubts, no vote :( 14:36:02 andreykurilin: ? 14:36:11 any other vote? 14:36:49 I'm for "add sudo, add password" 14:36:52 :) 14:37:08 andreykurilin: how user will find out one? 14:37:19 docker -u root not asks password 14:37:21 rally.readthedocs 14:37:32 andreykurilin: r u serious? )) 14:37:33 dockerhub 14:37:49 yes, I'm serious) 14:38:31 If you look at https://answers.launchpad.net/rally/+question/273388 , user read the doc 14:39:06 ok, I'm not strictly for "add password" 14:39:35 well, I'd, personally, not to make user doing that 14:39:35 so let's do it without password and don't wast more meeting minutes for this question:) 14:39:45 ))) 14:39:47 good 14:40:06 @ikhudoshyn: >> andreykurilin: how user will find out one?; How about some shell banner insight docker? 14:40:09 we could change it back any way 14:40:35 oanufriev_: why bother? 14:41:02 it's like having yr password ona yellow sticker on yr monitor)) 14:41:26 no. Look at ciiros 14:41:39 Sorry guys, I need to go, bye 14:41:40 ok let's set it like 'add sudo, no passwd' and move on 14:41:51 andreykurilin: bye 14:42:05 #topic [rvasilets] Fix timeout for scenario runners: - https://review.openstack.org/#/c/235910/ 14:42:18 rvasilets: ur welcome 14:42:36 Hi 14:44:02 Currently I'm changing one of the most deep thing in Rally - runner. This change will affect to all code that would be running with rps and constant runner. So I invite you to review it. 14:44:33 rvasilets: could u elaborate more on what and why do u do it? 14:44:35 Its about add ability to terminate thread of scenario by timeout 14:44:46 Because now we have a bug 14:44:55 it attached in commit msg 14:46:16 If we specify timeout in config for runner. Scenario woudn't be terminated after timeout. In cause if it executed longer 14:46:18 rvasilets: I see redixin commented it a lot. Do you want to dicsuss it now? 14:46:50 Or just do you ask team to review for now? 14:46:52 redixin comment I have discuss with him previously 14:47:03 Just ask for review. 14:47:12 have you agreed? 14:47:30 ok, we'll do. I will at least) 14:47:38 rvasilets, did you see my last commends about 'deadline'? 14:47:46 yes 14:48:17 I don't understand how the snippet of code allows us to avoid 100% CPU usage 14:48:34 its the same as mine in term on usage CPU 14:48:35 qeue.get will block 14:48:55 cpu is not used when thread is blocked on queue.get(timeout=.... 14:50:02 But you get item in all cases. If we don;t need to get new item 14:50:39 we don't know if there is new items in queue 14:50:49 Ok. We could write so. Or just add time.sleep(0.001) 14:51:11 sleep-driven-development 14:51:19 Of cause I'm for adding simple sleep 14:51:56 why we should use sleep, and take unnecessary cycles? 14:52:08 we can avoid this 14:52:11 and what?) You solution is the same. Just sleep is hidden inside get() 14:52:23 there is no unnecessary cycles 14:52:46 hmmm. seems i wrong 14:53:02 Ok. We will discuss it late 14:53:41 if we use blocking queue.get then we need to wait additional time when waiting for thread.join 14:54:08 ill think more about it 14:54:19 ok 14:54:50 redixin, rvasilets : are we fine for a while, take it offline? 14:55:10 yes 14:55:16 ok 14:55:29 #topic Open discussion 14:55:39 we have couple minutes 14:55:48 and I forgot to update agenda 14:55:56 so here goes mine)) 14:56:26 https://review.openstack.org/#/c/239406/ -- it's about merging lists of task iteration results, now green 14:56:32 pls review 14:56:36 ok 14:56:39 ok 14:56:45 some doc is in a pipeline 14:56:54 tnx 14:57:12 anybody else to add something? 14:57:18 no 14:57:51 then we're done 14:57:57 no 14:58:16 bye everybody 14:58:23 #endofmeeting 14:58:31 #endmeeting