14:00:21 <andreykurilin__> #startmeeting Rally
14:00:22 <openstack> Meeting started Mon Apr  4 14:00:21 2016 UTC and is due to finish in 60 minutes.  The chair is andreykurilin__. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:26 <openstack> The meeting name has been set to 'rally'
14:00:35 <ikhudoshyn> hi there
14:00:44 <andreykurilin__> o/
14:00:51 <stpierre> hi all
14:00:56 <andreykurilin__> hi hih
14:01:12 <andreykurilin__> boris-42 amaretskiy rvasilets ping
14:01:20 <boris-42> hi
14:01:48 <andreykurilin__> #link https://wiki.openstack.org/wiki/Meetings/Rally
14:01:51 <andreykurilin__> aour agenda
14:02:11 <andreykurilin__> #topic [stpierre] Unsticking https://review.openstack.org/#/c/277225/15
14:02:15 <stpierre> #link https://review.openstack.org/#/c/277225/15
14:02:25 <stpierre> keystone v3 support is super important to us, and i'm sure to other people
14:02:44 <stpierre> but that review got hung up even before the services spec merged, and with the services spec merged i'm not sure if there's anything at all that we can do to move it forward
14:03:00 <boris-42> stpierre: make a code?
14:03:08 <stpierre> make a code?
14:03:21 <boris-42> stpierre: for services instead of utils
14:03:25 <stpierre> ok
14:03:27 <boris-42> stpierre: and validator for versions
14:03:33 <stpierre> i was afraid you'd say that
14:03:37 <andreykurilin__> :)
14:03:41 <boris-42> stpierre: so I will try to do code
14:03:47 <boris-42> fianlly I got some time for Rally
14:03:50 <stpierre> unfortunately we just don't have the bandwidth right now to invest in kicking off the services work
14:04:06 <boris-42> stpierre: so we need to find otherwise rally as a project will die
14:04:19 <stpierre> feel free to talk to my boss :)
14:04:22 <boris-42> stpierre: because we will get at the point where we have to many to refactor
14:04:24 <rvasilets> hi
14:04:32 <boris-42> stpierre: to many loc
14:04:53 <boris-42> stpierre: so I will try to make the base
14:05:03 <boris-42> stpierre: and let's do all together a bit of work
14:05:10 <boris-42> rvasilets: amaretskiy andreykurilin__ ^
14:05:20 <andreykurilin__> ok ok
14:06:09 <rvasilets> Yes, i'm agree=)
14:06:14 <andreykurilin__> lol
14:06:47 <redixin> Talofa!
14:07:15 <andreykurilin__> stpierre: anything else?
14:07:19 <stpierre> nope
14:07:28 <andreykurilin__> ok
14:07:38 <andreykurilin__> #topic status of next release
14:07:49 <boris-42> andreykurilin__: so I believe we have one blocker
14:07:55 <boris-42> quite nasty bug
14:08:06 <boris-42> andreykurilin__: https://review.openstack.org/#/c/298591/
14:08:09 <andreykurilin__> yes
14:08:14 <boris-42> amaretskiy: is helping to finish it ^
14:08:24 <amaretskiy> i'm working on thi patch
14:08:42 <andreykurilin__> let's give several more days to this release
14:08:43 <amaretskiy> the most of work is done, I'm writing unit tests right now
14:08:51 <boris-42> andreykurilin__: and we have like few more bugs with cleanups
14:09:05 <amaretskiy> the patch set will be submitted soon (2 hours I believe)
14:09:07 <boris-42> andreykurilin__: default security groups are not deleted
14:09:08 <andreykurilin__> btw, it will be 0.4.0.
14:09:16 <rvasilets> And bug in load chart that I work on
14:09:28 <andreykurilin__> we have too many bugs :(
14:09:31 <andreykurilin__> it is sad
14:09:48 <boris-42> andreykurilin__: so we need to address them
14:09:58 <andreykurilin__> should we schedule release for only bug-fixes?
14:10:08 <boris-42> andreykurilin__:   ^ not sure
14:10:10 <boris-42> stpierre: ^
14:10:27 <boris-42> stpierre: I think we need to start work on services
14:10:38 <rvasilets> Agree
14:10:38 <boris-42> which means not a bug-fixes only release
14:10:54 <rvasilets> We have too much patches for the last time about wrappers)
14:10:57 <stpierre> you think we can get that into this release?
14:11:09 <andreykurilin__> stpierre: services - no
14:11:09 <rvasilets> We spend on them too much unneeded efforts
14:11:15 <andreykurilin__> probably in next release
14:11:18 <stpierre> andreykurilin__++
14:12:35 <boris-42> stpierre: so next release should be tomorrow
14:12:38 <boris-42> stpierre: so no services
14:12:48 <boris-42> stpierre: however we can introduce them and replace current wrappers
14:12:55 <boris-42> stpierre: for the next release in 2 weeks
14:13:00 <andreykurilin__> so what about make the next release after base service implementation merged only for bug fixes? also it means that we will able to work on porting utils/wrapers to new services, since them contain a lot of bugs
14:13:13 <stpierre> that's wildly, incredibly optimistic
14:13:23 <stpierre> i think we should shoot for having the keystone service implemented for the next release
14:13:31 <boris-42> stpierre: +1
14:13:44 <boris-42> stpierre: so let's put some effort on services for next 2 weeks
14:13:56 <andreykurilin__> +1
14:14:00 <amaretskiy> +1
14:14:00 <boris-42> so they will got highest priority
14:14:06 <boris-42> and we will review them like a crazy
14:15:00 <rvasilets> syre
14:15:04 <rvasilets> *sure
14:15:05 <andreykurilin__> btw, we can ask breton to help with it, since he is interested with Keystone and Rally :)
14:15:24 <boris-42> andreykurilin__: he is ill as far as I know
14:15:43 <andreykurilin__> :(
14:15:43 <boris-42> andreykurilin__: so let's just do the basis for service and move wrappers we will call him a bit later
14:15:51 <andreykurilin__> ok ok
14:16:08 <boris-42> andreykurilin__: so what about bug related to the fact that security groups are not deleted
14:16:18 <andreykurilin__> I don't know
14:16:22 <andreykurilin__> let's change the topic
14:16:22 <boris-42> andreykurilin__: we have hack in users context that deletes them and it doesn't work =(
14:16:43 <andreykurilin__> #topic bug related to the fact that "default" security groups are not deleted
14:17:18 <andreykurilin__> #link https://review.openstack.org/#/c/296402/
14:17:21 <boris-42> https://github.com/openstack/rally/blob/master/rally/plugins/openstack/context/keystone/users.py#L132-L139
14:17:21 <andreykurilin__> proposed fix ^
14:17:40 <boris-42> andreykurilin__: actually this is not a fix
14:17:57 <boris-42> andreykurilin__: so yep it will reduce amount of traces in gates
14:18:12 <boris-42> andreykurilin__: however we will still have a bunch of not deleted default security groups
14:18:17 <boris-42> andreykurilin__: that should be deleted by this code https://github.com/openstack/rally/blob/master/rally/plugins/openstack/context/keystone/users.py#L132-L139
14:18:19 <stpierre> we only have one that doesn't get deleted
14:18:23 <stpierre> and rally doesn't even create it
14:18:28 <stpierre> it's for the 'service' tenant
14:18:40 <stpierre> i don't understand why it's in the osresources report
14:18:51 <stpierre> but rally seems to working correctly, despite all of the tracebacks
14:19:36 <boris-42> stpierre: so "default" security group is created automatically by neutron
14:19:42 <boris-42> stpierre: when you are booting first vm
14:20:05 <stpierre> that's what i was wondering. although i still don't know why a vm boots in the 'service' tenant
14:20:08 <smurke> Just wanted to jump in wanted some feedback on https://review.openstack.org/#/c/296022/ i have added gnocchi client and as it requires keystoneauth. Keystoneauth has ability to load version-agnostic plugin
14:20:52 <smurke> so maybe we can use keystoneauth (instead of keystoneclient v3)
14:21:08 <boris-42> stpierre: so that's standard behavior for nova/neutron
14:21:17 <boris-42> stpierre: so we need to do hacks to cleanup that
14:21:17 <stpierre> yeah, so that makes sense
14:21:27 <andreykurilin__> smurke: lets discuss your topic after we finish this one:0
14:21:34 <stpierre> i'm not sure we do, though. why is something getting booted in the 'service' tenant at all?
14:21:53 <boris-42> stpierre: it's strange I do not know anything..
14:21:53 <smurke> andreykurilin__ : sure, thanx!
14:22:07 <andreykurilin__> stpierre: are you sure that non-deleted sg are from "service" tenant?
14:22:11 <stpierre> yep
14:22:28 <stpierre> osresources.py tells you the tenant id, and you can cross-reference that with the devstack logs
14:22:58 <boris-42> stpierre: could you point to logs?
14:22:59 <andreykurilin__> stpierre: but sometimes it have too much non-deleted sg
14:23:05 <andreykurilin__> stpierre: for example http://logs.openstack.org/19/299919/4/check/gate-rally-dsvm-rally-nova/923db30/rally-plot/resources_diff.txt.gz
14:23:22 <stpierre> nova 'default' secgroups cannot be deleted
14:23:25 <stpierre> full stop, end of story, that's it
14:23:31 <andreykurilin__> oh
14:23:37 <stpierre> yeah :(
14:23:37 <boris-42> stpierre: but in neutron you can do that
14:23:56 <stpierre> yes, we should clean up neutron secgroups, but with nova we just have to grin and bear it
14:24:04 <boris-42> stpierre: +1
14:24:13 <boris-42> stpierre: so I will ask today kevinbenton about that
14:24:23 <boris-42> stpierre: maybe he knows something that we don't know
14:24:26 <stpierre> i'll try to find the logs that i looked at earlier
14:24:38 <boris-42> stpierre: let's move to next topic for now?
14:24:41 <stpierre> +1
14:24:48 <rvasilets> +
14:24:50 <boris-42> andreykurilin__: ^
14:24:53 <andreykurilin__> ok
14:25:10 <andreykurilin__> #topic gnocchi integration with rally
14:25:12 <andreykurilin__> :)
14:25:26 <andreykurilin__> #link https://review.openstack.org/#/c/296022/
14:25:35 <boris-42> so I am not big expert of 1000 ways to init keystone client
14:26:08 <andreykurilin__> boris-42: all our code fore keystoncelinet uses deprecated methods
14:26:12 <andreykurilin__> lol
14:26:21 <andreykurilin__> *keystoneclient
14:26:39 <smurke> just wanted feedback on the patch. also i have added keystoneauth loader plugin which get version-agnostic plugin
14:26:52 <boris-42> oldfag=)
14:27:04 <andreykurilin__> heh
14:27:19 <boris-42> smurke: we will take a look and test it
14:27:27 <andreykurilin__> so I'm +2 for all new _get_keystoneauth_session method
14:27:34 <smurke> sure thanx boris-42
14:27:39 <andreykurilin__> but it should replace old _get_session
14:27:40 <boris-42> smurke: btw what about gnocchi dsvm job?
14:28:10 <smurke> boris-42 : do you mean the benchmarking scenarios ?
14:28:27 <smurke> i am in process of adding scenarios for it.
14:29:24 <andreykurilin__> smurke: boris-42 is talking about a separate job for gnocchi which will run gnocchi sceanrios
14:29:39 <redixin> we need a working scenarios first, right?
14:30:20 <redixin> new keystoneauth -> gnocchi client -> gnocchi scenario -> rally-gnocchi-dsvm-job
14:30:25 <smurke> once i have running scenarios i can look into the rally gates job
14:30:27 <boris-42> smurke: so I mean dsvm job
14:30:33 <andreykurilin__> redixin: agreed
14:31:06 <boris-42> redixin: so I think these are parallel tasks
14:31:13 <boris-42> redixin: you can start adding job even now
14:31:28 <boris-42> redixin: so it will test the code of new patch and help us not merge non working code
14:31:56 <redixin> okay
14:31:58 <boris-42> I have to sleep
14:32:02 <boris-42> to tired
14:32:06 <redixin> goodnight =)
14:32:23 <smurke> boris-42: gntc :)
14:32:36 <rvasilets> bye)
14:33:38 <redixin> is there a bug at launchpad about deprecated keystone usage in rally.osclients?
14:33:48 <andreykurilin__> redixin: no
14:34:02 <andreykurilin__> redixin: but I can create it
14:34:15 <redixin> we need someone to assing
14:34:29 <rvasilets> there is the same problem with ading senlin
14:34:44 <rvasilets> https://review.openstack.org/#/c/298109/
14:34:58 <rvasilets> I mean the sequence of action)
14:35:01 <andreykurilin__> redixin: smurke's patch fixes a big part of deprecated methods
14:36:13 <redixin> we can merge it first, and then fix the rest
14:36:35 <andreykurilin__> sure
14:37:05 <redixin> so we will use keystone in correct way soon
14:37:19 <andreykurilin__> smurke: Can you split your patch to two? So first one will be about keystoneauth and second one - support of gnocchiclient
14:40:00 <andreykurilin__> anything else to discuss?
14:40:03 <smurke> andreykurilin__ : its already a small patch :P
14:40:33 <redixin> smurke: do you want to help us with fixing all the clients? Like make the first patch not only for keystone+gnocchi, but keystone+everyting?
14:40:51 <redixin> or we can merge it as is and ask someone else to fix the rest
14:41:44 <rvasilets> I can help with it later possibly
14:41:47 <smurke> redixin: may be we can merge and then work on fixing it
14:43:27 <rvasilets> ok
14:43:54 <rvasilets> it sounds good for me
14:44:22 <rvasilets> first keystone+gnocchi, other later
14:44:48 <andreykurilin__> noce
14:44:51 <andreykurilin__> nice
14:45:29 <rvasilets> Move next?
14:45:30 <smurke> yup, sounds good
14:45:51 <andreykurilin__> do we have next topic?)
14:46:38 <rvasilets> нуы
14:46:40 <rvasilets> yep
14:46:45 <rvasilets> One more from me
14:46:53 <rvasilets> adding SenLin to Rally
14:47:03 <rvasilets> #link https://review.openstack.org/#/c/298109/
14:47:38 <rvasilets> How we will work on it? client, scenario, dsvm job?
14:48:13 <andreykurilin__> rvasilets: it sounds the same as for gnocchi. base part we can merge without new job
14:48:34 <rvasilets> Should it be experimental?
14:49:41 <andreykurilin__> we should talk with senlin cores and discuss our plans about integaration
14:49:51 <rvasilets> okey
14:50:05 <andreykurilin__> rvasilets: but, imo, we should not use experimental jobs at all
14:50:43 <andreykurilin__> it is better to configure normal jobs with rules to launch them
14:51:12 <rvasilets> at Rally gates?)
14:51:19 <andreykurilin__> yes
14:51:35 <rvasilets> for every project separate job)
14:51:53 <rvasilets> okey)
14:52:23 <rvasilets> I will talk to senlin guys
14:52:41 <andreykurilin__> rvasilets: I mean that we can do as same as for only doc and unittests related changes - we don't run dsvm jobs for them. so we can configure new "senlin" job which will be launched only if senlin folder are modified
14:54:06 <andreykurilin__> anything else?
14:54:11 <rvasilets> Okey lets discuss it later
14:55:10 <andreykurilin__> lets finish
14:55:17 <andreykurilin__> #endmeeting