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