14:02:45 #startmeeting Rally 14:02:50 Meeting started Mon Oct 12 14:02:45 2015 UTC and is due to finish in 60 minutes. The chair is boris-42. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:51 hi 14:02:52 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:53 ping everybody 14:02:55 The meeting name has been set to 'rally' 14:03:05 hi 14:03:07 hello 14:03:23 hi 14:03:51 redixin: oanufriev_ andreykurilin ping 14:04:04 \o/ 14:04:28 let's wait few more seconds 14:04:41 dzien dobry 14:04:55 hi 14:05:14 mbonell_: hi 14:05:22 hi all 14:05:34 okay GO GO GO GO 14:05:47 topic [mbonell] Blueprint discussion. New command to install Tempest's plugins in rally verify - https://blueprints.launchpad.net/rally/+spec/install-tempest-plugins 14:06:03 mbonell_: ^ so 14:06:31 #link https://blueprints.launchpad.net/rally/+spec/install-tempest-plugins 14:08:36 mbonell: So I believe that this is nice feature 14:08:48 mbonell: maybe we should call the command rally verify install-plugin 14:08:56 sorry problems with my connection 14:08:59 _matthias_: instead of just pluign* 14:09:09 _matthias_: sorry* 14:09:13 ok, yes sure! is a better name 14:09:14 mbonell: ^ 14:09:28 mbonell: we already have install command so it will be unfied 14:09:40 e.g. you can install tempest or it's plugins 14:09:40 yes 14:09:48 mbonell: otherwise it looks good to me 14:09:56 ylobankov: andreykurilin ^ what do you think guys? 14:10:01 tranks 14:10:05 thanks* 14:10:33 ` rally verify install-plugin` sounds good to me 14:10:57 I like `rally verify install-plugin` :) 14:11:05 :) 14:11:10 me too 14:11:28 Okay so let's just do the quick fix in BP and get it approved 14:11:46 ok! 14:12:01 mbonell: it's approved https://blueprints.launchpad.net/rally/+spec/install-tempest-plugins 14:12:10 let's move to next topic ? 14:12:22 and is my first BP, so what are the next steps? Just star working on it? 14:12:43 mbonell: actually you could just make a code even without BP =) 14:13:00 mbonell: so yep just make some code and do the git review 14:13:12 excellent! 14:13:51 mbonell: thanks for working on this=) 14:13:57 #topic [lcazares] Blueprint discussion. Add optional parameters at rally container creation to auto-register an Openstack deployment. 14:14:03 lcazares: hi there 14:14:07 yes 14:14:08 lcazares: so what is the case for this? 14:14:58 just to have a working container after it is up... I mean with a deployment already registered 14:15:57 that way if I need a quick test I can create/ destroy the container with less commands... 14:16:19 hi 14:16:43 lcazares: btw does docker image accept arguments? 14:16:49 lcazares, there is one problem 14:16:51 lcazares: didn't see that .. 14:16:55 boris-42, it accept 14:16:57 but 14:17:00 redixin: hm nice 14:17:14 yfried: hi 14:17:38 lcazares, where rally database will be stored? 14:17:47 redixin: so I have answer on this 14:17:55 redixin: we should refactor our Docker image 14:18:03 redixin: to use sqlite inside it 14:18:18 redixin: and provide instruction how to make persistance storage 14:18:32 ok. then we have other problem 14:18:40 redixin: what is the other problem?) 14:19:03 changes will not be saved after we exited container 14:19:14 and changes in rally.db will be lost 14:19:25 redixin: it's not the problem 14:19:37 redixin: as I said we will make the insturction how to make persistance storage 14:20:05 we already have docs how to make persistent storage 14:20:07 we already have that 14:20:22 redixin: stpierre I know 14:20:32 so what will be changed? 14:20:44 redixin: rally-manage db recreate called in container 14:20:50 we add "rally-manage db recreate" to Dockerfile? 14:20:55 redixin: Yep 14:21:11 you can't map volumes during container build 14:21:13 so that won't work 14:21:28 and if we use external volume, it will "overload" default storage, right? 14:22:27 yes 14:23:01 redixin: stpierre hm there is no way to create file in docker container? 14:23:06 so we have two options: built-in empty database (or not empty). this changes to this database are lost after exiting container (unless we commit them) 14:23:08 you can create a file in the container 14:23:08 that will contain DB? 14:23:22 and second option is what we have now 14:23:27 but if we create the db in the Dockerfile, then anyone using persistent storage will have to recreate it; and anyone not using persistent storage will lose any data they store in the database between invocations of the container 14:24:21 stpierre: those who are using persistance storage are already quite f**ed up by installation tutorial 14:24:33 and this still doesn't get us closer to the ultimate desired feature, to auto-register a deployment, since you can't pass arguments to 'docker build' 14:24:41 stpierre: and in most case people do not need results 14:24:47 stpierre: after termitnation of container 14:25:23 it's not just results, it's also things like deployments. without persistent storage you have to recreate your deployment(s) every time you run the container 14:25:24 lcazares: btw you can have persistance storage 14:25:47 stpierre: but why? 14:25:49 yeah, the solution to this feature request really seems to be persistent storage, which is already possible and documented 14:25:56 stpierre: you can register it during the build or not? 14:25:59 how? 14:26:05 you'd have to explicitly write it in to the dockerfile 14:26:13 because you can't pass arguments to the build 14:26:19 stpierre: ah 14:26:35 stpierre: in any case I was asked few times already 14:26:49 stpierre: to make docker image work without magic and persistance storage 14:26:58 stpierre: just to work out of box 14:27:05 this is nature of docker -_- 14:27:27 creating the database in the Dockerfile mostly does that, but in a way that I think is fairly unintuitive. 14:27:55 but it doesn't make things any worse for people who want to run with persistent storage, so it's not all bad 14:28:23 redixin: nature of docker is pain? 14:28:42 nature of docker is "be useless" 14:28:53 redixin: stpierre so let's just run rally-manage db recreate (if it does not use persistance storage) 14:29:00 redixin: stpierre can we check that on fly? 14:29:05 no 14:29:14 stpierre: we can 14:29:32 stpierre: we can check whatever DB exist or not 14:29:33 no, you can't. volume mapping is determined at container run time, not build time. 14:29:50 seeing message "run rally-manage db recreate" is enough as for me 14:30:04 we can just create the database during the build; if someone uses persistent storage, they'll mount a volume over it 14:30:14 stpierre: and it will work ? 14:30:21 fsvo "work" 14:30:22 stpierre: if so let's do it 14:30:40 stpierre: I mean it won't purge each time persistance storage 14:30:48 correct 14:30:54 so it all about just adding "rally-manage db recreate"? 14:31:07 also user can commit changes after each run 14:31:23 redixin: yep 14:31:36 redixin: so let's add this one line 14:32:01 lcazares: and in your case you should just create once persistance storage like in docs 14:32:09 is describe 14:32:13 stpierre, is it possible to access env during build? 14:32:30 i mean if we run '. openrc admin admin' and run 'docker build' 14:32:36 nope 14:32:39 sad 14:32:46 redixin: mreeeee pain 14:33:54 so we only can add tutorial 'how to create deploymet in docker images having only . openrc admin admin' 14:33:59 or something similar 14:35:34 redixin: hehe maybe 14:35:49 redixin: stpierre https://review.openstack.org/233665 14:35:55 okay let's move to next topic 14:36:04 just a quick comment 14:36:06 #topic [amaretskiy] What are the most critical bugs and features (required) in HTML reports? 14:36:13 lcazares: sure 14:36:22 lcazares: so? 14:36:23 the env could be passed at docker run instead of docker build 14:36:32 as already discussed with boris-42, there are 2 major tasks for html reports 14:36:41 amaretskiy: wait please 14:36:44 ok 14:37:14 lcazares: but it just opens console 14:37:18 so the idea would be to add the deployment data when doing the docker run 14:37:41 lcazares, it is possible already 14:37:59 ok, I'll take a look 14:38:04 thanks guys 14:38:06 lcazares: you can pass whole DB of Rally to docker 14:38:06 lcazares, we can do anything and commit changes, or we can do anything and use persistan storage 14:38:21 lcazares: from your disk 14:38:36 lcazares: or commit after you make proper changes like redixin is saying 14:39:08 boris-42, it opens console by default. you can pass any command and arguments to 'docker run' 14:39:34 ok :) 14:40:07 okay 14:40:07 docker run rallyforge/rally rally-manage db recreate # it will create db. and there is no need to commit if we use persistent storage 14:40:09 amaretskiy: your turn 14:41:09 it looks clear with html reports - 2 major tasks are 1) rework reports UI for new task format and 2) rework scenarios output 14:41:29 does any have anything to add? 14:41:34 amaretskiy: scenario output include the stuff related in scenario base 14:41:57 amaretskiy: I mean it should be refacotre do extend the schema of output 14:42:09 yes, I will add a new method to Scenario class 14:42:18 amaretskiy: I believe you should write spec before doing anything 14:42:28 boris-42: ok 14:42:31 will do 14:42:33 amaretskiy: because I am not sure that somebody is understanding about what you talking 14:42:37 amaretskiy: except me=) 14:42:42 okay 14:43:02 spec only for for reworking scenarios output charts? 14:43:10 amaretskiy: yep 14:43:19 amaretskiy: and not only charts 14:43:20 for UI for new task format? 14:43:24 amaretskiy: whole refactoring 14:43:34 amaretskiy: nope I don't care about that part * 14:43:39 okay 14:43:47 amaretskiy: just make it pretty 14:44:11 okay let's do the next topic 14:44:14 #topic [redixin] Docker pull downloads all tags by default 14:44:18 UI for new task format requires a lot of changes in template/JS 14:44:20 ok 14:46:08 redixin: are you arround? 14:46:17 yep 14:46:26 redixin: so any comments ideas I don't know 14:46:39 so amaretskiy confirmed that docker pull rallyforge/rally:latest download only latest 14:46:47 redixin: yep 14:46:57 redixin: and? 14:47:17 I was thinking do not use tags for releases 14:47:52 redixin: I do not understand you =( 14:47:56 but use different images instead. like 'docker pull rallyforge/rally-0.1.1' 14:48:13 redixin: that may be a good idea 14:48:29 and have rally-latest image 14:48:37 or just 'rally' 14:48:40 yep 14:48:57 because pepole usually are doing docker pull rallyforge/rally 14:49:11 and then it starts ........ using all your HD 14:49:18 or SSD =) 14:49:23 and all your internets 14:50:29 currently it takes 1.1 gigabytes 14:50:39 what will be later? 14:50:50 when someone run 'docker pull rallyforge/rally' 14:51:03 and download all 24 releases 14:51:10 4G 14:51:18 redixin: ya that sux 14:51:34 can't we delete old tags and only maintain the last 2 or 3 or N releases? 14:51:34 redixin: so I like your idea 14:51:44 stpierre: nope 14:51:49 :( 14:51:50 stpierre: people is using old releases 14:51:59 stpierre: I know people that are using rally0.0.3 14:52:09 but that would be included in the last 2 releases 14:54:01 boris-42: `people is using old releases`. people uses old releases because they are supported 14:54:16 andreykurilin: it is not supported LOL 14:54:20 andreykurilin: it just exist LOL 14:54:36 stpierre: andreykurilin so in any case even if we support like 5 releases 14:54:52 it will be more then 1 GB to download each time 14:55:01 which is really bad 14:55:44 meh, docker eats disk like crazy. anyone running docker needs to be willing to deal with that, IMO. we can limit how much disk it eats, but that's pretty much what docker does best. 14:56:27 stpierre: so why not just having X images 14:56:56 afaik that's not The Docker Way™ 14:56:59 stpierre: we can actually have for each release branch like 0.1, 0.2, .... single image with bunch of tags 14:57:09 stpierre: but in rallyforge/rally there will be only one image 14:57:18 stpierre: latest master 14:57:21 so it'd be a little strange. not necessarily bad. 14:57:30 stpierre: and in rallyforge/rally-stable the latest release 14:58:04 stpierre: or we can have rally-all to put all the shit inside it 14:58:15 we can do nothing for now, but back to this topic later :] 14:58:17 right, i understand the proposal, it's just not The Docker Way. that's precisely what tags are for. we're reinventing tags with image names to save disk space 14:58:30 which, like i said, isn't necessarily *bad*, just strange. 14:58:41 ok 14:58:49 I have some small update as well 14:58:55 probably they change default behavior 14:59:04 #topic ceritification task 14:59:15 we are working on this https://github.com/openstack/rally/tree/master/certification/openstack 14:59:25 One single task that can do the properl load for YOUR cloud 14:59:39 so please join us in this effort * 14:59:46 #endmeeting