08:59:56 <gmann> #startmeeting qa 08:59:57 <openstack> Meeting started Thu Sep 17 08:59:56 2015 UTC and is due to finish in 60 minutes. The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:59:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:00:00 <openstack> The meeting name has been set to 'qa' 09:00:17 <gmann> who all here today? 09:00:26 <dmellado> \o Hi gmann ;) 09:00:34 <gmann> dmellado: hi 09:01:18 <gmann> hi jordanP 09:01:22 <jordanP> hi gmann 09:01:34 <jordanP> and everybody :) 09:01:58 <gmann> looks like we 3 only today, dmellado jordanP 09:02:05 <jordanP> :( 09:02:09 <dmellado> quite sad :( 09:02:19 <jordanP> the QA sprint has started right ? 09:02:24 <gmann> let's wait for 2-3 min otherwise we will finish quickly 09:02:39 <gmann> jordanP: yea most of them are in QA sprint 09:02:52 <dmellado> where is it being held? 09:02:58 <jordanP> no, I think it's over. I was from 14 to 16 sept 09:03:00 <gmann> or connecting remotely 09:03:04 <oomichi> hi 09:03:15 <dmellado> hi oomichi hope it's not 4am for you today too :) 09:03:16 <oomichi> I was in the sprint and here is 3am 09:03:18 <gmann> oomichi: hi, good morning in night :) 09:03:23 <oomichi> yeah 09:03:42 <oomichi> in the sprint, mtreinish and me only from tempest cores 09:03:52 <oomichi> so I guessed the others can join this meeting 09:04:04 <gmann> dmellado: its in Fort Collins 09:04:05 <jordanP> if they are not asleep :) 09:04:15 <gmann> ok let's start meeting 09:04:24 <dmellado> Oh, it's trye, now I recall it, it was going to be held in hp premises ;) 09:04:33 <gmann> # link https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_September_17rd_2015_.280900_UTC.29 09:04:41 <gmann> ^^^ Today's agenda 09:04:54 <gmann> #topic Specs Reviews 09:05:04 <gmann> #link https://review.openstack.org/#/q/status:open+project:openstack/qa-specs,n,z 09:05:26 <gmann> i think most of them under -1 means less for review 09:05:41 <gmann> oomichi: i saw your reply on microversion one 09:05:44 <gmann> #link https://review.openstack.org/#/c/169126/3 09:05:51 <gmann> oomichi: I will check that tomorrow 09:05:57 <oomichi> gmann: thanks ;) 09:06:22 <dmellado> I wanted to check the status from this https://review.openstack.org/#/c/101232/ 09:06:24 <gmann> it will helpful if all can have a look into that. 09:06:53 <dmellado> I'll be commenting there later but wanted to know if there has been any further discussion besides the gerrit link ;) 09:07:26 <gmann> dmellado: ahh thats quite old 09:07:28 <jordanP> I like the proposal 09:07:44 <jordanP> the number of scenarios is growing 09:07:48 <gmann> dmellado: i do not remember any other discussion 09:07:52 <gmann> jordanP: ture 09:07:55 <dmellado> +1 on that 09:07:59 <jordanP> we will need to refactor eventually 09:08:10 <gmann> but we can start review that if that seems useful 09:08:13 <jordanP> that's a good starting point then, if we all aree 09:08:16 <oomichi> jordanP: yeah, I agree 09:08:40 <dmellado> sounds fine for me, as it'd be great to have it due the growing scenarios 09:09:02 <gmann> ok So let's review https://review.openstack.org/#/c/101232/ 09:09:09 <gmann> dmellado: Thanks for pointing that 09:09:16 <dmellado> gmann: np ;) 09:09:37 <oomichi> gmann: now or later? 09:09:59 <gmann> oomichi: any plan on microversion spec in sprint? 09:10:18 <gmann> oomichi: when you get time may be next week for you :) 09:10:28 <oomichi> gmann: not anything because we concentrated on tempest-lib service client dev 09:10:31 <gmann> oomichi: i saw that as topic on agenda 09:10:44 <gmann> oomichi: yea that is big one and priority 09:10:50 <oomichi> gmann: ok, will review it later :) 09:11:08 <gmann> anything else on spec thing ? 09:11:20 <oomichi> gmann: yeah, some projects have copy&paste service client code from tempest now 09:11:35 <oomichi> and we can remove them after tempest-lib's ones 09:11:43 <gmann> oomichi: yea, agree 09:12:10 <gmann> Let's move on to next topic 09:12:13 <gmann> #topic Tempest 09:12:25 <gmann> oomichi: your turn 09:12:27 <oomichi> gmann: nothing from me 09:12:46 <jordanP> I've seen several "fix typos in code comment" patches lately 09:13:06 <jordanP> I don"t disapprove them but they are a bit boring 09:13:20 <oomichi> jordanP: big +1 09:13:23 <jordanP> maybe it's silly but they consume Gate resources 09:13:35 <gmann> jordanP: yea i saw those and bugs also 09:13:42 <dmellado> jordanP: might be because openstack summit's coming? xD 09:13:55 <oomichi> jordanP: nice point and sometimes I ignore them 09:14:04 <jordanP> so, my solution/recommendation is too-1 patches if we see some typos 09:14:05 <gmann> may be we can keep asking them to log bug and fix those in 1 patch 09:14:06 <oomichi> dmellado: hehe, maybe right 09:14:11 <jordanP> to avoid a latter "fix typo" patch 09:14:19 <dmellado> +1 on that 09:14:28 <jordanP> we are quite reactive so we can afford to -1, and then +2 quickly after it's been fixed 09:14:42 <gmann> jordanP: but we should have much strong reason to -1 :) 09:14:56 <jordanP> gmann, why ? 09:15:09 <gmann> jordanP: you mean hold for some time and later +2 09:15:13 <jordanP> you -1, the guys update the patch, it take 20 sec and then we approve 09:15:26 <oomichi> gmann: or it is great to avoid consuming gate resource for fixing typos 09:15:32 <jordanP> ok, maybe don't -1 but leave a comment and dont +2 09:15:49 <dmellado> I've also a question about tempest tests. I've been working in IPv6 scenarios lately and would like to know if there's any way to run them in a different gate (which would use a different image, like manila) in order to avoid CirrOS limitations (sorry for the offtopic here) 09:15:51 <gmann> jordanP: i see your point 09:16:10 <jordanP> yeah -1 could be a bit hard, just leave a comment pointing at the typo and don"t +2 09:16:25 <gmann> jordanP: yea comment would be better one. 09:16:34 <oomichi> if changed code which is on after of #, the gate cannot run against the patch 09:16:42 <oomichi> just one idea 09:17:01 <dmellado> oomichi: that's a nice one 09:17:06 <gmann> oomichi: that nice idea . just run doc thing 09:17:10 <jordanP> oomichi, I think we can"t do that with zuul at the moment 09:17:21 <oomichi> gmann: yeah, right 09:17:26 <oomichi> jordanP: true for current zuul 09:17:38 <jordanP> because Zuul nows which files are touched but not what is touched within files 09:17:41 <jordanP> *knows 09:17:52 <oomichi> jordanP: now zuul just distinguishes based on file path 09:17:56 <jordanP> yep 09:17:59 <oomichi> jordanP: yeah, right 09:18:06 <gmann> jordanP: yea 09:18:15 <jordanP> dmellado, had a question :) 09:18:25 <dmellado> thanks jordanP ;) 09:18:35 <gmann> anyways we can keep that idea for next proposal may be in summit for infra session 09:18:39 <oomichi> but maybe most projects are facing this kind of problems, so it is nice if zuul can do it ;) 09:18:53 <oomichi> gmann: that is reasonable 09:18:53 <jordanP> dmellado, you would need a different job in the Gate, which would export a different set of images 09:18:58 <gmann> oomichi: +1 09:19:22 <jordanP> +1 I know someone from Infra wants to dedicate more time to Zuul, that would be a great feature, im 09:19:24 <jordanP> imo 09:19:25 <dmellado> jordanP: but would that be approved? I mean, I don't want to split tempest between (ipv6 dhcp and not dhcp ipv6) 09:19:42 <dmellado> so I don't really know how to address that 09:19:54 <jordanP> dmellado, I am not sure. Though there is precedency: neutron dvr vs neutron not dvr 09:20:09 <jordanP> tempest ssh vs tempest non ssh 09:20:28 <jordanP> but imo, it's not the best idea ever... 09:20:35 <dmellado> that's it... 09:20:47 <dmellado> I've tried for cirros to implement that, with no luck until now 09:20:51 <gmann> # Action oomichi/gmann needs to add the idea of "not running gate job for comments line" in summit session- infra 09:21:05 <dmellado> so I might try the other approach and ask around here later, 09:21:08 <dmellado> thanks jordanP ;) 09:21:19 <gmann> dmellado: ok 09:21:38 <gmann> oomichi: back to service clients to lib 09:21:43 <jordanP> (dmellado, at least you could ask this new job to be added in the experimental queue) 09:21:52 <gmann> oomichi: i found some schema are missing for example update agent 09:22:16 <oomichi> gmann: thanks, can you -1 on that? 09:22:18 <gmann> oomichi: i am going through those and if i find anything more should we do it in tempest or lib ? 09:22:31 <gmann> oomichi: but agent cleitn one is merged in lib 09:22:59 <oomichi> gmann: ah, yeah. I am writing how to do that on the etherpad 09:23:01 <gmann> I thought of fixing that in lib 09:23:02 <jordanP> I think now is a good time to move to -lib. 09:23:11 <jordanP> we delayed this for quite a while... 09:23:17 * andreaf is joining the meeting late 09:23:29 <jordanP> andreaf, \o/ 09:23:30 <oomichi> #link https://etherpad.openstack.org/p/tempest-lib-service-client-migration 09:23:40 <gmann> oomichi: I will check all bu tomorrow and fix if there is any more 09:23:54 <oomichi> gmann: thanks again :) 09:24:00 <gmann> oomichi: so agent one i can fix directly on lib as it would not change any interface 09:24:04 <oomichi> andreaf: hi :) 09:24:06 <gmann> oomichi: Thanks 09:24:14 <gmann> andreaf: hi :) 09:24:15 <andreaf> oomichi, jordanP: hi 09:24:21 <dmellado> hi andreaf ;) 09:24:31 <andreaf> hello everyone :) 09:24:38 <gmann> for response return value, only 1 patch left to merge 09:24:41 <oomichi> gmann: ok, please let me know later 09:24:42 <gmann> # link https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:bp/method-return-value-and-move-service-clients-to-lib,n,z 09:25:20 <gmann> anything else on service clients ? 09:25:53 <jordanP> I feel we are going to break the world soon :p 09:26:08 <masayukig> sorry for joining the meeting late. 09:26:09 <gmann> jordanP: heh how ? 09:26:13 <gmann> masayukig: hi 09:26:27 <jordanP> gmann, I don't know, it feels scary to me, changing all these imports 09:26:30 <jlanoux> o/ 09:26:49 <gmann> jordanP: humm , let's see. we will find hidden bugs. 09:26:50 <oomichi> jordanP: yeah, right. at least, neutron-XXaas will be broken 09:26:53 <gmann> jlanoux: hi 09:27:17 <gmann> oomichi: thats worth for neutron client, its going in good shape now 09:27:22 <oomichi> in short-time, I hope ;) 09:27:34 <gmann> oomichi: jordanP: anyways hope for the best :) 09:27:41 <jordanP> yep ! 09:27:44 <oomichi> gmann: yeah, neutron clients should be the next step after nova 09:27:51 <gmann> oomichi: +1 09:28:20 <gmann> ok let's move on 09:28:25 <gmann> # topic DevStack 09:28:27 <oomichi> keystone clients also are nice choice because neutron repo contain neutron clients and keystone clients only now 09:28:51 <gmann> oomichi: yea, nice point 09:29:08 <gmann> oomichi: so after neutron we can have keystone 09:29:24 <oomichi> gmann: that is a nice idea 09:29:53 <dmellado> I'd like to help on that, is there any client I can take as an example? 09:30:33 <oomichi> dmellado: ok, could you check https://etherpad.openstack.org/p/tempest-lib-service-client-migration ? 09:30:44 <gmann> dmellado: Thanks, that will be good help. 09:31:06 <gmann> and oomichi we keep updating this etherpad for other client also right? 09:31:06 <oomichi> dmellado: after finishing writting how to, I am glad if you also join into the work ;) 09:31:15 <dmellado> oomichi: I'll check those that you did for now (might also get back with some questions ;)) 09:31:17 <oomichi> gmann: yeah, right. 09:31:30 <gmann> so that we have all migration bits together 09:31:32 <gmann> oomichi: Thanks 09:31:34 <oomichi> dmellado: thanks :) 09:31:40 <gmann> dmellado: thanks 09:31:43 <dmellado> ;) 09:32:18 <gmann> let's jump on next topic 09:32:22 <gmann> #topic DevStack 09:33:13 <gmann> jamielennox added some point to discuss about https://review.openstack.org/#/c/220846/ 09:33:54 <gmann> but not sure he is available here. 09:34:09 <gmann> I do not have much to talk about that one. Ned to look. 09:34:36 <gmann> does anyone has anything on this or we skip it for next meeting ( with jamielennox) 09:35:09 <dmellado> nothing from my side 09:35:26 <gmann> ok, let's move to next one then 09:35:29 <gmann> #topic Grenade 09:35:37 <gmann> anything on grenade ? 09:36:12 <gmann> is gate up now? 09:36:20 <gmann> i saw grenade job failing... 09:36:48 <gmann> but anyways let's move to next topic 09:36:50 <gmann> #topic Critical Reviews 09:37:24 <gmann> anyone has reviews to look on priority ? 09:37:55 <oomichi> I have ;) 09:38:24 <oomichi> #link https://review.openstack.org/#/c/224210/ 09:38:40 <oomichi> #link https://review.openstack.org/#/c/217468/ 09:38:45 <oomichi> that is 09:38:48 <gmann> oomichi: ok, that nice patch 09:39:01 <oomichi> thanks ;) 09:39:07 <gmann> oomichi: yea those are needed for lib migration 09:39:29 <masayukig> oomichi: it seems nice :) 09:39:29 <oomichi> yes, right. after that, I can finish writing the etherpad 09:39:39 <oomichi> as concrete how-to 09:39:47 <dmellado> oomichi: great ;) 09:39:54 <gmann> oomichi: yea :) 09:40:03 <masayukig> oomichi: I'll look at them later. 09:40:15 <oomichi> masayukig, dmellado: thanks 09:40:18 <gmann> I also have one which will be needed for lib migration 09:40:20 <gmann> #link https://review.openstack.org/#/c/222983/ 09:40:27 <gmann> may be simple one 09:40:28 <vgridnev> Hello folks! I have one review that totally missed for reviews, I wrote about that in mailing list: #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/074200.html 09:40:39 <gmann> masayukig: Thanks for reviewing that 09:41:11 <gmann> vgridnev: this one 09:41:13 <gmann> #link https://review.openstack.org/#/c/214194/ 09:41:19 <jordanP> ( vgridnev have a look at https://review.openstack.org/#/c/187635/ ) 09:41:29 <vgridnev> yep, this one 09:41:46 <gmann> vgridnev: Thanks, we will take a look 09:41:46 <jordanP> I am not sure devstack is the best place for this, you can easily have plugins 09:42:08 <jordanP> plus this cinder driver is in a weird state 09:42:31 <vgridnev> jordanP, this plugin would helps us to make CI for that 09:42:38 <gmann> jordanP: yea, nice point. currently cinder has devstack plugin ? 09:42:57 <gmann> ahh not yet 09:43:04 <jordanP> vgridnev, cinder has 60 drivers, and most of them don"t have a piece inside devstack to do the job 09:43:20 <jordanP> vgridnev, take a look at ceph for instance 09:44:29 <vgridnev> ok, but what should I do in such case? Just give up? 09:44:40 <andreaf> I also have a devstack review: #link https://review.openstack.org/#/c/222038/1 09:44:53 <gmann> vgridnev: : may be add those in plugin on cinder side 09:45:22 <gmann> andreaf: ok 09:45:53 <gmann> vgridnev: let's discuss the best approach on review. jordanP has good point if as there are lot of drivers 09:46:26 <gmann> any other review 09:46:41 <gmann> or lets move 09:46:49 <gmann> #topic open discussion 09:47:06 <gmann> anything else other than mentioned topics? 09:47:31 <vgridnev> gmann, I can put that to cinder, but it looks like there is no devstack plugin in cinder 09:48:11 <vgridnev> If I am wrong, please give me a link for that 09:48:34 <gmann> vgridnev: yea currently it is not there. i do not remember exactly about the initial discussion about core component plugin 09:48:47 <jordanP> no,, you only need a devstack plugin 09:48:51 <jordanP> which devstack suppots 09:49:37 <gmann> jordanP: you mean core scripts in devstack and have plugin for drivers in cinder? 09:49:59 <jordanP> no, plugin for drivers should sit on a dedicated repo, not related to cinder 09:50:05 <jordanP> lemm find you an example 09:50:30 <gmann> I think its all together would be good , means all cinder devstack stuff in cinder 09:50:48 <gmann> jordanP: oh i see 09:51:45 <jordanP> example: https://github.com/stackforge/devstack-plugin-glusterfs 09:52:04 <jordanP> the how to use section is important 09:52:11 <jordanP> Add "enable_plugin glusterfs https://github.com/stackforge/devstack-plugin-glusterfs" to localrc file inside devstack. 09:52:14 <jordanP> et voila your done 09:52:18 <jordanP> this is the recommended way now 09:52:44 <jordanP> devstack team has been working on this plugin thing for months, it works now 09:52:54 <gmann> jordanP: Thanks 09:52:58 <gmann> Thats good, 09:53:12 <gmann> vgridnev: ^^ 09:53:21 <vgridnev> gmann, I see 09:53:31 <jordanP> vgridnev, in particular: https://github.com/stackforge/devstack-plugin-glusterfs/blob/master/devstack/plugin.sh 09:53:40 <vgridnev> yep, I see 09:53:54 <jordanP> imo, it's 1 day of work for you, maximum 09:54:02 <vgridnev> so, I need to create new repo in stackforge? 09:54:04 <jordanP> and you don"t need devstack core reviewers 09:54:13 <jordanP> you manage your plugin on your own :) 09:54:29 <jordanP> vgridnev, I think so yes.. for now... that's the downside 09:54:49 <gmann> vgridnev: yea, like for glusterfs 09:54:50 <vgridnev> jordanP, Is it hard to make that? 09:55:18 <vgridnev> I am unfamiliar with such process 09:55:29 <jordanP> vgridnev, it's easy and documented somewhere, I am sure of it. But as stackforge is being deprecated I am not sure what's the best way now to ask for a repositoty 09:55:37 <jordanP> #openstack-infra is the best place to ask 09:55:55 <gmann> vgridnev: yea, lets discuss there more. 09:55:59 <gmann> Thanks jordanP 09:56:12 <gmann> anything else to discuss ? 09:56:13 <vgridnev> jordanP, ok, thanks, I will try such way 09:56:24 <jordanP> vgridnev, np. That's your best option, imo 09:57:06 <gmann> ok, we are almost on time 09:57:21 <gmann> Thanks all for attending. 09:57:32 <dmellado> thanks ;) 09:57:43 <gmann> #endmeeting