14:01:48 <andreykurilin> #startmeeting Rally
14:01:49 <openstack> Meeting started Mon Nov  7 14:01:48 2016 UTC and is due to finish in 60 minutes.  The chair is andreykurilin. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:52 <openstack> The meeting name has been set to 'rally'
14:01:57 <andreykurilin> o/
14:03:06 <chenhb_> hi
14:03:25 <astarove> hi
14:04:12 <andreykurilin> #topic [andreykurilin] updates from summit
14:05:03 <andreykurilin> while I was as summit, I heard several negative comments about communications and involvement in Rally
14:05:37 <andreykurilin> mirantis inner discussions are invisible for community and community doesn't know anything about in-progress stuff
14:05:54 <andreykurilin> so first of all, we need to increase our visability
14:06:15 <andreykurilin> move all discussions to official channel
14:06:28 <andreykurilin> here is a sub-topic : irc vs slack
14:06:38 <andreykurilin> #topic IRC vs Slack
14:06:44 <andreykurilin> it is a hard topic
14:07:03 <andreykurilin> OpenStack governence forces to use IRC
14:07:31 <andreykurilin> BUT, if most of our contributors would like to switch to slack, we can try to do it
14:07:38 <andreykurilin> What do you think about this?
14:07:46 <andreykurilin> Who is for IRC and who is for Slack?
14:08:12 <amaretskiy> afaik participation in slack channel requires invitation
14:08:20 <amaretskiy> i like slack a lot
14:08:52 <andreykurilin> hi stpierre
14:09:36 <stpierre> hey
14:10:02 <andreykurilin> amaretskiy: yes, but I found openstack-community team, which can be used, possibly for many projects and all folks will be there soon:)
14:10:22 <astarove> we need something w/o authorization
14:10:30 <amaretskiy> minuses of slack: 1) does not fit OpenStack gov requirements 2) participators must sign-up in slack 3) invitation is required ( not sure )
14:10:45 <andreykurilin> stpierre: are you familiar with slack? we are discussing the best tool for communication process :)
14:10:58 <amaretskiy> pluses of slack: its cool in all aspects
14:11:13 <andreykurilin> amaretskiy: 1) we can try to discuss it with governence team.
14:11:33 <astarove> plus of slack: easy to setup voice call
14:12:03 <andreykurilin> astarove: yep, we can switch to voice meeting in future
14:13:15 <andreykurilin> ok, it looks like no enough opinions/voices from our community :(
14:13:21 <amaretskiy> voice calls is not a point for community
14:13:38 <andreykurilin> amaretskiy: kubernetes community has voice meetings
14:14:14 <andreykurilin> not sure that we need it know, but it is cool feature)
14:14:34 <astudenov> invitation is not required if slack is public. everyone can sign in.
14:15:11 <amaretskiy> it's would be great to use slack
14:15:13 <stpierre> andreykurilin: yeah, and as long as the IRC gateway is enabled I don't hate it :)
14:15:22 <andreykurilin> heh
14:15:28 <andreykurilin> so you like IRC more
14:15:29 <amaretskiy> if this does not make troubles
14:15:38 <astarove> as i remember, the public version of slack has some limitations on history, isn't?
14:15:54 <stpierre> yeah, i'm old and cranky. I like IRC.
14:15:59 <andreykurilin> lol
14:16:13 <andreykurilin> astarove: yes. you can search only last 10k messages
14:16:38 <andreykurilin> but you still can download whole history and use another service for searching in it:)
14:16:56 <andreykurilin> several days ago I saw a post with examples for doing it :)
14:17:18 <andreykurilin> ok, I'll send an email and will make a final decision next meeting
14:17:25 <andreykurilin> #topic task board
14:17:55 <andreykurilin> 1) it is hard to find "easy" tasks for newcomes
14:18:31 <andreykurilin> 2) launchpad su*ks == is not user-friednly for any kind of tasks
14:19:02 <andreykurilin> 3) it would be nice to show all in-progress things
14:19:14 <andreykurilin> 4) it would be nice to show some-where release-blockers
14:19:40 <andreykurilin> to fix all these points, I think we need to return to use some kind of task tracker
14:20:27 <andreykurilin> it can be trello board(we used it some time ago) or openstack story board (own wheel. the same as trello)
14:20:35 <andreykurilin> or bitbucker issue tracker
14:21:02 <andreykurilin> each of these 3 trackers is good enough.
14:21:39 <andreykurilin> trello and bitbucker are well known tools, so it will be easier to use them for new comes from outside of OpenStack
14:22:23 <andreykurilin> openstack story board - I heard at Summit that openstack story board will replace launchpad in future
14:22:41 <andreykurilin> I do not when this plan will happen
14:22:58 <andreykurilin> So what do you prefer? folks?
14:23:13 <andreykurilin> trello sounds ok for me...
14:23:15 <amaretskiy> i like all. doubts
14:23:20 <astarove> I have experience with Trello board, so +1 for Trello
14:23:22 <astudenov> +1 for trello
14:23:33 <amaretskiy> let it be +1 to trello
14:23:48 <andreykurilin> chenhb_ ?
14:24:06 <andreykurilin> stpierre: Do you like launchpad as much as IRC?) lol
14:24:09 <stpierre> i can see the value of using openstack story board, but otoh it doesn't seem like it's gotten much traction with other projects
14:24:13 <stpierre> heh, no
14:24:45 <stpierre> i'm fine with trello, but we should be open to switching to story board if it becomes more standard use
14:25:31 <andreykurilin> stpierre: I'm ok about story board, but in case of big task "rally for testing everything" which can be finished in several months, it would be nice to use broad things :)
14:25:45 <chenhb_> I am not sure
14:26:10 <andreykurilin> stpierre: but, again, I do not know when we finish that big task:)
14:26:34 <andreykurilin> so it looks like we have votes for trello and storyboard
14:27:57 <amaretskiy> important point: board of choice must have mobile application
14:28:11 <amaretskiy> trello must have one
14:28:17 <andreykurilin> it has:)
14:28:48 <amaretskiy> #vote trello +2
14:29:22 <andreykurilin> ok, let's return to trello board(I'll create new one and post align link to our channel) and move to storyboard if we will need to do it:)
14:29:43 <andreykurilin> let's move to the next topic
14:29:56 <andreykurilin> #topic [andreykurilin] rally plugins versioning
14:30:03 <andreykurilin> it is my topic, again:)
14:31:33 <andreykurilin> basically, some of scenarios have updates each half year
14:31:52 <andreykurilin> so results of old scenario and new one can be different on similar system
14:32:41 <andreykurilin> What about adding new metavar - version to plugins, and keep some notes at plugin docstings
14:32:42 <andreykurilin> like
14:32:48 <andreykurilin> 1.0 - basic plugin
14:32:55 <andreykurilin> 1.1 - switch to use keystone v3
14:33:03 <andreykurilin> 1.2 - add bla bla bla
14:33:04 <andreykurilin> )
14:33:23 <andreykurilin> Ideas?
14:34:08 <amaretskiy> as far as I understand this closer to "history"
14:34:37 <astudenov> is it just for notes? or there should be some compatibility checks based on versions?
14:34:38 <amaretskiy> or "versions",  "changelog"
14:34:49 <astarove> no, it's closer to supported features
14:35:10 <andreykurilin> I think it relates to all of these things :)
14:35:54 <amaretskiy> so changelog is stored in docstring in some format, right ?
14:36:00 <andreykurilin> yes
14:36:18 <andreykurilin> + additional var here -> @configure(name="some", version="asd")
14:36:20 <amaretskiy> syntax is expected to be validated?
14:37:20 <andreykurilin> @amaretskiy: yes. maybe it is better to store changelog at separate class variable like __changelog__ = ""
14:37:28 <andreykurilin> it will add ability to parse it separately
14:37:53 <amaretskiy> this feature looks reasonable to me
14:38:26 <andreykurilin> also, we can align such version to testing system
14:38:39 <amaretskiy> __changelog__ = ["latest version - blah blah...", "pre-latest version - ...",  ...]
14:38:58 <andreykurilin> for example one scenario can have several versions for "openstack/newton", "openstack/ocata" and etc
14:39:43 <andreykurilin> ok, I'll add this to trello board, maybe we will find somebody who want to implement this feature:)
14:40:03 <andreykurilin> #topic [andreykurilin] backward incompatible change in Rally Verification component
14:40:20 <andreykurilin> I have totally backward incompatible change for Verification component
14:40:24 <andreykurilin> it is PoC
14:40:30 <andreykurilin> but you can already try it
14:40:46 <andreykurilin> #link https://review.openstack.org/#/c/372334/23
14:40:55 <andreykurilin> it is an implementation for https://github.com/openstack/rally/blob/master/doc/specs/in-progress/verification_refactoring.rst
14:41:07 <amaretskiy> verification have been asking for great update for a long time :)
14:41:11 <andreykurilin> yes
14:41:27 <andreykurilin> so the question is next - how we should process such backward incompatible changes?
14:41:41 <ylobankov> andreykurilin: I have free time to continue this work
14:42:14 <andreykurilin> Here I see two options: 1) do it without backward compatibility and make pain for users while upgrading to latest rally release
14:42:39 <ylobankov> I think users should just use olteder rally version
14:42:43 <andreykurilin> 2) create separate command `rally verify_new` which will work in parallel with old behaviour
14:43:03 <andreykurilin> the second choice is a pain for developers and code-maintainers :)
14:43:09 <ylobankov> the second version sounds interesting as well :)
14:43:09 <amaretskiy> "2)" looks nice to me
14:43:13 <andreykurilin> ;(
14:43:26 <ylobankov> option*
14:43:29 <andreykurilin> f*ck
14:43:40 <andreykurilin> why I noted it?
14:44:02 <andreykurilin> ok, ylobankov, as you said you have free time now
14:44:02 <andreykurilin> lol
14:44:03 <amaretskiy> there is a "3)"
14:44:41 <amaretskiy> 3) remove rally verify stuff but keep this command saying "use rally verify_new" :) with detailed instructions
14:44:48 <andreykurilin> lol
14:44:50 <ylobankov> andreykurilin: qa guys need the new version of verify by the end of this year
14:45:36 <andreykurilin> so let's use 1) since it is easiest way and we already have several incompatible changes in reports:)
14:46:18 <andreykurilin> and, again, I'll send an email to warn our community)
14:46:22 <andreykurilin> #topic [andreykurilin] blockers for 0.8.0 release aka planning
14:46:28 <amaretskiy> ok, even with pain of "1)" this would be a great step forward
14:46:30 <andreykurilin> :)
14:47:04 <andreykurilin> as I said before, we already have one backward incompatible changes with verify reports
14:47:16 <andreykurilin> so let's try to finish verification stuff at this release
14:47:24 <ylobankov> andreykurilin, amaretskiy: anyway users can use the old version of verify and will be able to adopt theit stuff for the new version
14:47:28 <andreykurilin> sure
14:47:56 <andreykurilin> also, I want to see atomic refactoring at this release
14:48:49 <andreykurilin> and we merged recently base for openstack services (refactoring of wrappers and utils)
14:49:17 <andreykurilin> so It would be nice to finish KeystoneService and make all scenarios support Keystone V3
14:49:21 <andreykurilin> Anything else?
14:50:41 <rvasilets___> HI)
14:50:50 <andreykurilin> stpierre: Will you have time to revise your cleanup-work and finish it in near future? or at least revise it and add tasks to finish at our trello board
14:50:58 <andreykurilin> rvasilets__: you just in time:)
14:51:02 <stpierre> that latter one, yes definitely
14:51:21 <andreykurilin> nice
14:51:31 <andreykurilin> stpierre: and moew reviews plz :)
14:51:33 <andreykurilin> *more
14:51:46 <andreykurilin> ok, move to the next topic
14:51:55 <andreykurilin> # topic [rvasilets] What does an atomic action should return?
14:52:03 <andreykurilin> #topic [rvasilets] What does an atomic action should return?
14:52:10 <andreykurilin> What do you mean?)
14:52:11 <ylobankov> rvasilets___: hi :)
14:52:15 <andreykurilin> db format ?
14:52:49 <rvasilets___> No)
14:52:52 <rvasilets___> typing
14:53:45 <rvasilets___> Lets look at 412 line https://review.openstack.org/#/c/388617/6/rally/plugins/openstack/scenarios/cinder/utils.py
14:54:38 <rvasilets___> As I member we was agreed that simple atomics like that should return the same as client function. Did something changed?
14:54:49 <amaretskiy> this is not about atomic action
14:55:12 <rvasilets___> Alex suggested to return bool, but this is not what the client return
14:55:30 <amaretskiy> atomics save timing metrics
14:55:49 <amaretskiy> this is abotu specific utility method
14:55:53 <amaretskiy> *about
14:55:53 <rvasilets___> So I want to know common approach, to use it it in other patches
14:56:05 <andreykurilin> in case of delete, I thing we should call wait_for method and ensure that delete was successful
14:56:33 <amaretskiy> i guess this question is about "what typical delete_smth() shoudl return?"
14:56:43 <rvasilets___> not only delete
14:56:47 <rvasilets___> any atomic
14:56:57 <amaretskiy> bool result of deletion or some detailed structure
14:57:02 <rvasilets___> is it good to change return value?
14:57:15 <andreykurilin> it should return whatever he want, but it should be documented:)
14:57:20 <amaretskiy> atomic is not related to return value of this method, i think
14:57:47 <rvasilets___> do we need just to pass what was return from the client or we could wrap it as we want?
14:57:50 <amaretskiy> atomic data is saved separately
14:58:06 <andreykurilin> rvasilets__: the second choice - as we want
14:58:20 <amaretskiy> #vote for "as we want"
14:58:40 <andreykurilin> base of concept of Rally - make things as much as possible user-friendly
14:58:43 <rvasilets___> andreykurilin: Okey, thx. I just thought that used will expect to get the same as client return from atomic
14:59:07 <andreykurilin> so if wrapping is makes things simplier - it is ok
14:59:29 <andreykurilin> ok, guys, we have one more topic from amaretkiy
14:59:35 <andreykurilin> but we have not enough time
14:59:40 <andreykurilin> let's move to #openstack-rally channel
14:59:44 <amaretskiy> small topic about flat menu in report
14:59:49 <amaretskiy> ok
14:59:51 <andreykurilin> and discuss last topic
14:59:56 <andreykurilin> #endmeeting