14:06:47 <boris-42> #startmeeting Rally
14:06:48 <openstack> Meeting started Mon Jan  4 14:06:47 2016 UTC and is due to finish in 60 minutes.  The chair is boris-42. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:06:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:06:51 <openstack> The meeting name has been set to 'rally'
14:07:00 <boris-42> ping amaretskiy andreykurilin
14:07:06 <boris-42> ping oanufriev
14:07:07 <amaretskiy> hi
14:07:08 <oanufriev> hi a;;
14:07:08 <andreykurilin> o/
14:07:12 <oanufriev> *all
14:07:12 <andreykurilin> \o
14:07:14 <andreykurilin> ~o~
14:07:33 <boris-42> ping rvasilets
14:08:02 <rvasilets> o?
14:08:15 <rvasilets> boris-42, pong
14:09:44 <boris-42> rvasilets: meeting time
14:09:50 <rvasilets> Yes
14:10:02 <boris-42> so let's start
14:10:34 <boris-42> #topic  Laucnhpad & Google Docs & Project management
14:11:26 <boris-42> So redixin is against the google docs approach
14:11:32 <boris-42> and yep it has some issues
14:11:50 <boris-42> however we need to keep google docs because it's simple for any manager to understand what is happening in project
14:11:58 <boris-42> so I would suggest to do next thing:
14:12:04 <boris-42> move all data to blueprints
14:12:16 <boris-42> we will have 2 types of blueprints essential (which will show direction of works)
14:12:29 <boris-42> and blueprints with actual actions
14:12:56 <boris-42> we will put all information inside those blueprints & make simpler script that will generate google doc page
14:13:00 <boris-42> ^ ideas?
14:13:41 <andreykurilin> Why you are against etherpad? :P
14:13:52 <rvasilets> Specs is another sort of management?
14:14:35 <boris-42> andreykurilin: lol
14:14:44 <boris-42> rvasilets: so spec will be linkend in bp
14:14:59 <rvasilets> Half-year  ago we have fefused from blueprints to specs
14:15:08 <andreykurilin> rvasilets: I suppose specs are not about management and not about current status of feature. specs are more about design of feature
14:15:10 <rvasilets> *refused
14:15:24 <boris-42> rvasilets: we didn't refuse anything
14:15:42 <rvasilets> So we will maintain specs, g-docs,  blueprints...
14:15:44 <boris-42> rvasilets: I didn't like bp since begging and they were optional for developers since begging
14:15:50 <rvasilets> Is it too much?)
14:15:59 <boris-42> rvasilets: we won't maange g-gocs
14:16:09 <boris-42> g-docs it will be done by automatical script
14:16:29 <rvasilets> If you don't like blue-t why we will return to them?)
14:16:31 <boris-42> rvasilets: bp will just contain high-level information about feature (that will be used as description of task)
14:16:57 <boris-42> rvasilets: I don't like to use blueprints as a place for discussion
14:17:11 <boris-42> rvasilets: and they are useless for management level
14:17:35 <rvasilets> I suppose we will get to much discussion what information should be moved to spec and what shouldn't
14:17:39 <boris-42> rvasilets: however they are very useful to in dev process to show what patches are related to what feature
14:17:45 <boris-42> rvasilets: ?
14:17:55 <boris-42> rvasilets: specs are part of blueprint
14:18:12 <boris-42> blueprint contains in description (what is this work about)
14:18:18 <boris-42> in spec all technical details
14:18:45 <boris-42> rvasilets: so currently what we have in g-docs description field will move to the BP
14:18:57 <amaretskiy> boris-42: am i right in this case: if someone want to propose a new feature, he should create blueprint -> get approval on it -> submit & merge a spec -> link bp to spec, correct?
14:19:06 <boris-42> amaretskiy: nope
14:19:21 <boris-42> amaretskiy: bleuprint do not require and specs
14:19:24 <boris-42> any specs*
14:19:35 <rvasilets> Ideally to keep g-docs inside blut-ts)
14:19:39 <boris-42> amaretskiy: specs are used only when the feature is hard and it's unclear for me how to do it
14:19:50 <boris-42> blut-ts?
14:19:58 <rvasilets> To use blue-ts only as containers of links g-docs
14:20:41 <boris-42> blue-ts?
14:20:50 <amaretskiy> boris-42: should we use approvals for blueprints?
14:20:52 <boris-42> ah blueprints holly ....
14:20:59 <redixin> "script for visualising blueprints" stackalytics?
14:21:12 <boris-42> rvasilets: that is very bad idea
14:21:20 <rvasilets> (
14:21:22 <rvasilets> ok
14:21:25 <boris-42> rvasilets: did you read what I said?
14:21:33 <rvasilets> of cause
14:21:36 <boris-42> rvasilets: create a script that will parse BP and generate google docs
14:21:43 <boris-42> rvasilets: why we need to keep links to something?
14:22:19 <rvasilets> Because the main reason why we don't like g-docs was ability to lose the link
14:22:24 <rvasilets> that is all
14:23:15 <boris-42> rvasilets: nope
14:23:21 <rvasilets> ok
14:23:23 <boris-42> rvasilets: it was not
14:23:30 <boris-42> rvasilets: I am not sure why you think so?
14:24:08 <boris-42> rvasilets: the major reason is that we can't assign patches to the items in that google docs
14:24:20 <redixin> gdocs is trying to show papers on my screen. without sorting of filtering. just papers
14:24:30 <redixin> without linking to patches/bugs
14:24:43 <redixin> without work items and assigings
14:24:51 <redixin> just papers
14:24:52 <boris-42> rvasilets: yep it's just for managemnt like this is the list of things that we are working on with short descrtipion
14:25:03 <boris-42> redixin: ^
14:25:19 <boris-42> redixin: and blueprints will link everything together
14:25:35 <boris-42> so if manager wants to see what exactly is done for specific feature
14:25:43 <boris-42> he will click on link in google doc go to the BP
14:25:50 <boris-42> and find all realted patches to it
14:26:33 <redixin> i believe it is possible to write some macros in gdocs
14:27:04 <redixin> like macro for retrieving data from launchpad and generate fancy pictures
14:27:36 <boris-42> redixin: maybe it's better to have just phthon script
14:27:47 <boris-42> rvasilets: it will be much simpler then to write the same on javascript
14:27:54 <boris-42> redixin: ^
14:27:55 <boris-42> rvasilets: sorry
14:29:36 <boris-42> I will try to make today such script
14:30:19 <andreykurilin> nice
14:30:23 <boris-42> #topic [amaretskiy] Chain of patches for improvements of scenario output (spec improve_scenario_output_format.rst)
14:30:29 <boris-42> amaretskiy: so okay okay
14:30:36 <boris-42> let's move to the next topic?
14:30:43 <andreykurilin> yes:)
14:30:47 <amaretskiy> https://review.openstack.org/#/c/254851/  <--- first patch in the chain
14:30:50 <boris-42> #topic  [amaretskiy] Do we plan to make a resources cleanup check affecting job status? (https://goo.gl/5m80qC)
14:31:29 <boris-42> amaretskiy: so it will be nice to do this check
14:31:32 <amaretskiy> we have tests.ci.osresources buy it does not play its role in determining job status
14:31:47 <amaretskiy> this check must be improved by extra filter
14:32:05 <amaretskiy> since there are some *expected* objects after cleanup
14:32:35 <amaretskiy> okay, so I can write a filter and propose the patch
14:33:15 <boris-42> amaretskiy: yep
14:33:23 <amaretskiy> because I wrote osresources so I worry that mission is incomplete :)
14:33:30 <amaretskiy> okay, eom
14:33:42 <boris-42> topic * [amaretskiy] Idea: how about filling task tag with input file name by default?
14:33:47 <boris-42> hm could you explain?
14:34:12 <amaretskiy> we usually do not pass --tag <smth> while starting scenario
14:34:19 <amaretskiy> so tag record is empry
14:34:22 <amaretskiy> *empty
14:34:25 <boris-42> amaretskiy: why do you think that we don't pass it usually
14:34:37 <boris-42> amaretskiy: people is using this feature
14:34:58 <amaretskiy> I do not sure about most cases, but what if --tag is omitted
14:35:01 <boris-42> amaretskiy: I believe if it is empty it should stay emtpy
14:35:14 <amaretskiy> okay
14:35:20 <amaretskiy> eom
14:35:29 <boris-42> amaretskiy: because its clear behaviour that sholdn't be documented
14:35:32 <boris-42> amaretskiy: which is nice
14:35:42 <amaretskiy> sounds reasonable
14:35:48 <boris-42> okay
14:35:53 <boris-42> #topic open discussion
14:35:59 <boris-42> anything to discuss?
14:36:02 <andreykurilin> I have a topic:)
14:36:14 <boris-42> andreykurilin: why it's not in agenda?)
14:36:24 <andreykurilin> I have no time to add it
14:36:36 <andreykurilin> btw, I have several topics
14:36:52 <redixin> when rally will be able to work without openstack cloud?
14:37:15 <boris-42> #topic when rally will be able to work without openstack cloud?
14:37:29 <boris-42> so this will happen after few things happen
14:37:39 <boris-42> first we need to get oanufriev specs about deployment merged
14:37:43 <boris-42> after that fix rally code
14:37:51 <boris-42> and make deployment generic (not only openstack)
14:38:32 <boris-42> after that we should fix the rally.task.validation
14:38:38 <boris-42> and a bit rally.task.types
14:38:58 <boris-42> redixin:  ^
14:39:04 <redixin> thanks
14:39:11 <boris-42> redixin: so it will take some time
14:39:17 <boris-42> andreykurilin: what are your topics ?
14:39:24 <andreykurilin> #topic rally docker image + rally docs
14:39:32 <boris-42> #topic rally docker image + rally docs
14:39:35 <boris-42> hm?
14:39:39 <andreykurilin> #link https://github.com/openstack/rally/blob/master/Dockerfile#L25
14:39:52 <andreykurilin> we already have rally docs in docker image
14:40:17 <boris-42> andreykurilin: it's unclear for me why they are there
14:40:21 <andreykurilin> but 1) our docs contains images
14:40:51 <andreykurilin> 2) our docs contains autogenerated pages(plugins references)
14:41:17 <boris-42> andreykurilin: maybe we should just remove them from docker image?
14:41:35 <andreykurilin> I suppose we need to generate some "man " docs
14:41:35 <redixin> rvasilets: ^ >_<
14:42:19 <andreykurilin> it would be nice, if users will able to write `man rally` in our image and get access to some docs
14:42:21 <redixin> andreykurilin: +1 for generating man and include it into rally package
14:43:13 <rvasilets> redixin, yes its funny)
14:43:15 <boris-42> redixin: +1
14:43:16 <redixin> andreykurilin: i mean not only docker image, but rally python package. to be able to run 'pip install rally && man rally'
14:43:43 <boris-42> redixin: does pip allow to do that?
14:43:48 <andreykurilin> so we need to decide which pages(sections) from our base docs should be included in man
14:44:07 <boris-42> andreykurilin: I am only afraid about docs duplication
14:44:07 <redixin> boris-42: it's ok. pip can work with resources
14:45:17 <boris-42> andreykurilin: everything else sounds reasonable
14:45:31 <andreykurilin> redixin: how it should work in case of venvs?
14:45:41 <boris-42> andreykurilin: hard
14:45:42 <boris-42> =)
14:46:26 <redixin> andreykurilin: venv/share/man/......
14:46:32 <andreykurilin> hm...
14:46:50 <andreykurilin> redixin: Can you assign this task to yourself? :)
14:47:15 <redixin> -_-
14:47:18 <boris-42> lol
14:47:24 <boris-42> andreykurilin: redixin is busy for now a bit
14:47:37 <boris-42> andreykurilin: we need to get done VM Workloads as fast as possible
14:48:13 <boris-42> andreykurilin: okay so what is the next topic?
14:48:13 <andreykurilin> redixin boris-42 : I can help with generation man for us, but I need help with putting it to correct place:)
14:48:26 <redixin> maybe we can find someone who familiar with man pages
14:48:28 <boris-42> andreykurilin: ok it shouldn't be hard to do if you know
14:48:47 <boris-42> andreykurilin: ok so what is the next topic? seems like we are getting out of time
14:48:54 <andreykurilin> boris-42: I already spend a lot of time with docutils and sphinx
14:49:03 <andreykurilin> so it should not be hard
14:49:16 <boris-42> andreykurilin: ?
14:49:22 <boris-42> andreykurilin: you mean man pages ?
14:49:57 <andreykurilin> boris-42: man pages can be generated via sphinx based on our rst files, so we can include to it some separate sections from our docs
14:50:26 <boris-42> andreykurilin: ok ok
14:50:28 <andreykurilin> ok, next topic: our cli is bad... bad documented.
14:50:42 <boris-42> topic: our cli is bad... bad documented and not only documented
14:50:45 <boris-42> #topic: our cli is bad... bad documented and not only documented
14:50:56 <boris-42> andreykurilin: yep that is the sad thing
14:50:58 <amaretskiy> do you mean docstrings and argparse?
14:51:08 <boris-42> amaretskiy: everything
14:51:11 <andreykurilin> I spend my holidays to add reference about our cli to docs
14:51:13 <boris-42> amaretskiy: even code is bad
14:51:16 <andreykurilin> #link http://docs-draft.openstack.org/68/262568/13/check/gate-rally-docs/a3961df//doc/build/html/cli/cli_reference.html
14:51:37 <boris-42> andreykurilin: amaretskiy I don't know any part in cli/ module that is done at least on the "ok" level
14:51:59 <andreykurilin> After patch will be merged, docstring fro separate command will be equal to our docs
14:52:24 <andreykurilin> so we need to fix all docstring and write good descriptions
14:52:30 <andreykurilin> boris-42: you are wrong
14:52:38 <boris-42> andreykurilin: about what?)
14:52:55 <andreykurilin> boris-42: we have one nice documented command
14:52:57 <andreykurilin> https://github.com/openstack/rally/blob/master/rally/cli/manage.py#L30
14:53:03 <andreykurilin> lol
14:53:12 <boris-42> andreykurilin: lol
14:53:24 <andreykurilin> and code is not so bad:)
14:53:33 <boris-42> andreykurilin: code is very bad=)
14:53:48 <andreykurilin> Because it uses db api directly?:)
14:53:56 <boris-42> andreykurilin: it should use it
14:54:00 <boris-42> andreykurilin: that's ok
14:54:31 <redixin> it should be plugin based?
14:54:32 <andreykurilin> I raised this topic, because we need to pay more attenstion to quility of docstrings.
14:54:48 <boris-42> redixin: btw it may be
14:54:59 <andreykurilin> redixin: it should have at least one decorator. lol
14:55:01 <boris-42> redixin: then users will be able to extend it and put their commands
14:55:26 <boris-42> redixin: which is actually real use case
14:56:00 <redixin> rally plugin should be able to add own cli commands ok
14:56:16 <andreykurilin> boris-42: redixin: btw, novaclient supports extensions for cli :)
14:56:28 <redixin> via stevedore?
14:56:30 <boris-42> redixin: nope rally cli classes should be plugin based
14:56:45 <boris-42> redixin: and rally CLI should be able to work with these plugins
14:57:11 <boris-42> redixin: so this shouldn't be hardacoded https://github.com/openstack/rally/blob/master/rally/cli/main.py#L31-L38
14:57:15 <boris-42> redixin: and that is all
14:57:28 <andreykurilin> redixin: nope. just python code. but you can find there a comment about porting code to stevedore:)
14:57:36 <boris-42> andreykurilin: omg
14:58:08 <andreykurilin> boris-42:
14:58:11 <boris-42> so in any case making plugable CLI sounds like a good plan=)
14:58:20 <boris-42> and it's quite simple to do..
14:58:21 <andreykurilin> boris-42: https://github.com/openstack/python-novaclient/blob/master/novaclient/utils.py#L415-L418
14:58:51 <boris-42> andreykurilin: ggg
14:59:00 <boris-42> andreykurilin: okay see you next week
14:59:11 <boris-42> seems like we should finish meeting
14:59:14 <boris-42> #endmeeting