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