09:00:00 #startmeeting qa 09:00:01 Meeting started Thu Jan 28 09:00:00 2016 UTC and is due to finish in 60 minutes. The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 09:00:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:00:05 The meeting name has been set to 'qa' 09:00:24 Hi, Who all here today? 09:00:35 Hi gmann o&/ 09:00:41 dmellado: hi 09:00:57 masayukig: will join little bit late 09:01:25 no worries, it's only us then? maybe we should wait a bit 09:01:55 dmellado: looks like only 2 of us, let's wait for some time to have others 09:01:59 dmellado: yea 09:05:26 dmellado: may be we can walk quickly and in between other join 09:05:46 #link https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_January_28st_2016_.280900_UTC.29 09:05:51 sure 09:05:54 ^^^ today's agenda 09:06:09 #topic QA Code Sprint 09:06:28 Nothing more on this, please add your name in list if panning to join 09:06:40 dmellado: anything you have on this? 09:06:53 gmann: this is about the mid-cycle, isn't it? 09:07:02 dmellado: yes 09:07:14 #link https://wiki.openstack.org/wiki/QA/CodeSprintMitakaBoston 09:07:22 is there any etherpad for this? maybe I can tackle some stuff 09:07:31 I'm still waiting for the ack but I'll check some stuff 09:07:33 let me open it 09:07:51 dmellado: yea we have 09:08:05 #link https://etherpad.openstack.org/p/mitaka-qa-code-sprint 09:08:19 gmann: just found it, I'll add my name to something ;) 09:08:22 all items for code sprint will be on this^^ 09:08:39 dmellado: ok 09:08:40 maybe we can migrate the keystone v2 client to tempest-lib, now that the split is dnoe 09:08:59 dmellado: yea but we need more i think on v3 also 09:09:27 dmellado: i also feel some of them were code duplication but i need to check 09:09:28 O/ 09:09:29 gmann: then I can re-do for v3, as well as clean up the duplicated options that was waiting for v3 to be done 09:09:34 if we can optimize more 09:09:36 johi 09:09:41 jordanP: hi 09:09:42 hi jordanP 09:09:46 hi guys 09:10:02 jordanP: we just talking about Code Sprint 09:10:19 I think on that, thats all 09:10:21 o/ w/ mobile device, though 09:10:28 hi masayukig_mob ;) 09:10:31 #topic Specs Reviews 09:10:35 masayukig_mob: hi 09:10:41 Hi all :) 09:11:00 #link https://review.openstack.org/#/q/status:open+project:openstack/qa-specs,n,z 09:11:44 anyone has any spec to discuss 09:13:03 ok let's move on 09:13:04 How about DDT one? 09:13:11 DDT? 09:13:28 masayukig_mob: ahh i see, 09:13:30 Yeah, removing the spec 09:13:34 #link https://review.openstack.org/#/c/271149/ 09:13:40 #link https://review.openstack.org/#/c/271149/ 09:13:43 jordanP: Thanks 09:13:54 thanks jordanP 09:14:09 so i think it was concluded not to implement that because of test renaming thing 09:14:25 do you have the policy that only PTL can merge/+A a spec ? 09:14:31 masayukig_mob: in that case, we should remove spec. 09:14:45 jordanP: no :) 09:15:04 jordanP: you can do or i will do. 09:15:05 yeah, true. so if you have an opinion, please put your comment 09:15:21 masayukig_mob: yea that will be nice 09:16:19 That's it from me 09:16:31 should we move to the next topic 09:16:37 let's move on 09:16:38 yea 09:16:43 #topic Priority Items 09:16:53 #link https://etherpad.openstack.org/p/mitaka-qa-priorities 09:17:13 first i want to discuss about M-1 which is microversion testing support 09:17:28 now all framewrok and nova v2.2 patches are merged 09:17:52 i will start migration to lib so that other project can use like Ironic is waiting for this 09:18:21 next one Service Client Migrations 09:18:37 so not all the clients migration is done in M-2 and its going on 09:18:44 I'll track keystonev3 split too so we can migrate it asap 09:18:47 main concentrate for neutron and keystone 09:18:53 dmellado: Thanks 09:19:04 I've seen that oomichi was also working on neutron/routers 09:19:07 after microversion migration i can also help on those 09:19:12 but it hsa been stalled for a while 09:19:23 dmellado: yea he is doing on neutron clients currently 09:19:28 I could get it if he's not going to work on that anymore 09:20:11 dmellado: this one ? https://review.openstack.org/#/c/260319/ 09:20:31 oh, I see, he was doing some work this morning 09:20:33 grat 09:20:35 great 09:20:37 dmellado: he is doing that, i saw patch update today 09:20:39 I saw that stalled for a while 09:20:47 checked before jan 26 09:20:48 ;) 09:21:09 dmellado: ok 09:21:14 next is Tempest Lib Migrations 09:21:24 jordanP: saw you need volunteer on this? 09:21:41 jordanP: what all was there on this? 09:21:49 other than cred and ssh 09:21:59 yes, I am quite busy and have no so much time for other stuff dans reviews 09:22:04 cred is done 09:22:15 ssh almost we need https://review.openstack.org/#/c/264323 09:22:15 jordanP: i see, no issue we will help 09:22:21 jordanP: maybe I can get you one xD, what would be the topics? 09:22:21 joyea 09:22:30 let's talk after the meeting 09:22:53 jordanP: cred are still pending right, we have in tempest itself 09:23:09 jordanP: but andreaf has removed almost conf dependency 09:23:13 * masayukig is at home now 09:23:16 the idea is to move evrything that is in tempest/common to tempest-lib 09:23:28 jordanP: i see 09:23:32 yes, cred is not done but it has been "decoupled" 09:24:32 jordanP: ok, i will check later if i can take any or find volunteer 09:24:40 great 09:24:54 it's not super critical though, imo 09:25:10 service spliting and service migration is more important I think 09:25:12 next is sshauth one which i think andreaf and jlanoux is working 09:25:15 jordanP: yea 09:25:26 jordanP: yea, that will be priority 09:25:33 and next one is Tempest CLI Improvements 09:25:49 masayukig: IT IS m-3 but anything you want to bring up? 09:26:39 #link https://etherpad.openstack.org/p/tempest-cli-improvements 09:26:40 so 09:27:08 not so much progress this time, I think. 09:27:29 legacy commands have been done. 09:28:05 but new commands seems not so good progress. 09:28:19 masayukig: yea, list-plugin is helpful for debugging 09:28:46 masayukig: ok, may be we will get fats progress in mid cycle :) 09:28:53 masayukig: Thanks 09:29:07 gmann: hope so 09:29:16 #topic Tempest 09:29:39 one is from mtreinish about cleanup tempest 09:29:41 #link https://etherpad.openstack.org/p/tempest-refactor-ideas 09:29:51 i saw this just before 1 hour. 09:30:05 so basically there are ideas about cleanup and refactor tempest 09:30:20 which we can start discussing and adding our points/comments on etherpad 09:30:26 gmann: sounds like a nice idea 09:30:47 dmellado: yea 09:30:49 +1 ! 09:31:00 not sure about last one, stress removal? 09:31:11 "The stress framework should be deprecated and then deleted" 09:31:25 and other interesting one is move back all into tempest from lib 09:31:36 +1 for improving it 09:31:47 I've heard people saying 'don't use tempest stress' use rally 09:31:51 "The stress framework should be deprecated and then deleted" Who is using it ? 09:31:52 cool! 09:31:58 anyways i do not have much on those but we will start discussing in etherpad and coming meetings 09:32:01 yes, Rally makes a better job at it 09:32:31 jordanP: in gate it is being tested, why it would not add much value 09:32:37 we could discuss either to improve or deprecate it 09:32:46 gmann, which job ? 09:32:56 jordanP: stress jobs 09:33:07 jordanP: i hope this is that one only 09:33:20 but the migration back to tempest makes me wonder if we should stop the initial one to tempest-lib xD 09:33:23 jordanP: those are experimental 09:33:51 dmellado, they obviously go together :) 09:33:59 dmellado: humm, i think not stop. in any case those will be moved under folder "lib" 09:34:30 gmann: I see your point, valid to me 09:34:33 jordanP: xD 09:34:37 moving to lib is one of the refactoring, IMO. 09:34:40 i think only issue we are trying to fix there is to avoid dependency and time for adding new stuff which is needed by new tests 09:34:50 which takes time currently due to lib release 09:35:27 masayukig: yea, those work still goes on as they makes common interfaces better 09:35:40 and we need those in lib or on tempest for external usage 09:36:18 I think its all not to have separate repo and keep in tempest for fast work 09:36:48 anyways we let's start adding our point there 09:36:52 Thanks for all nice inputs 09:37:00 anything else on this 09:38:00 ok, anything on Tempest side 09:38:17 yes 09:38:24 jordanP: please go ahead 09:38:26 I was planning to do some work on the plugin interface for neutron too 09:38:36 some reviews here: https://review.openstack.org/#/q/owner:apetrov%2540mirantis.com+status:open 09:38:43 dmellado: for lbaas or neutron repo? 09:38:54 for neutron, api tests and so on 09:39:10 dmellado: cool 09:39:38 I'll try to do some draft using the cookiecutter and will follow-up on the channels with you 09:39:46 jordanP: sure, i will take look tomorrow after migration of version stuff 09:40:03 dmellado: sure. Thanks 09:40:08 thanks 09:40:16 also I'd appretiate some input on this patch 09:40:18 https://review.openstack.org/#/c/259746/ 09:40:29 we can't really get the issue on the failures :\ 09:40:56 dmellado, this test doesn't seem super useful 09:41:04 I think it's already tested 09:41:09 jordanP: where? 09:41:33 everywhere, we have several tests that test security group and communication between servers 09:41:41 and we have a multinode job 09:41:51 or several, thus the feature is already tested implicitely 09:42:04 i have not checked that but if its kindda duplicate as per jordanP we should avoid that 09:42:09 as that is one of the items for cleanup tempest 09:42:28 this tests covers the functionaly of checking traffic between vms on different hosts 09:42:34 afaik, it wasn't really covered 09:43:06 * andreaf sneaks in 09:43:14 hi andreaf ;) 09:43:23 andreaf: hi 09:43:32 andreaf: o/ 09:43:32 hi all - sorry I'm late 09:43:39 anyways lets check that on review 09:43:44 andreaf: np :) 09:43:49 thanks gmann 09:43:55 dmellado, it is. The moment you have a test that boots 2 VMs, there's a chance these VMs are on different hosts and communication between VMs are already tested 09:44:00 jordanP: in any case let me get back to you after speaking with yfried 09:44:36 jordanP: hold on, he's joining ;) 09:44:37 dmellado: ping 09:44:49 dmellado: what did I miss 09:44:50 we have recently added new tests to boot VMs on diff host with sch hint 09:44:52 hi yfried_ we were discussing your patch: https://review.openstack.org/#/c/259746/ 09:45:25 and jordanP claims that it's already being tested, at when you run any test that boots 2 VMs, there's the chance that they get spawned on different hosts 09:45:34 so I was wondering if you thought about that too 09:46:18 dmellado: there's a chance. I'm looking for an explicit testing of traffic between compute nodes 09:47:15 jordanP: would that be enough for you? I was also thinking of that, that it might get tested but unless it's specifically there we won't be able to track when it happens 09:47:15 yfried_: your one is for multinode only right 09:47:16 yfried_, those kind of tests are super expensive like 2/3min and imo it's already tested (implicitely though) 09:47:39 gmann: yep 09:47:47 dmellado, jordanP: you can boot servers like http://git.openstack.org/cgit/openstack/tempest/tree/tempest/scenario/test_server_multinode.py#n70 to make sure they land on the right node 09:48:20 jordanP: but if it explicitly runs for mutlinode then it is ok 09:48:31 yes, but the question is: should we duplicate each and every test to also test the "multinode" case ? 09:48:32 as other tests we might not have boot on diff node 09:48:50 gmann: only tests for multiple VMs 09:48:54 jordanP: ^ 09:48:58 jordanP: not every test, but for things that are different on multiple VMs 09:49:01 imo the future of tempest is to have only multinode jobs 09:49:07 jordanP: I think there's value in yfried_ test 09:49:12 jordanP: not each and every specific of multinode one 09:49:36 ok guys, you +2 that patch, I won"t :) but I understand you 100% 09:49:49 jordanP :D 09:49:53 xD 09:49:55 jordanP: the traffic congestion is one of the key in case of diff host VMS 09:49:58 I am not opposed to it, it's okay 09:49:59 jordanP: I agree that in an avg MN env, the first segcroup test will duplicate the 2nd 09:50:14 jordanP: ok :) 09:50:25 jordanP: the alternative could be to change existing SG tests to ensure the boot VMs on different nodes if multiple nodes are available 09:50:27 ok lets put comments on that patch if any 09:51:17 andreaf: yea or if we can merge those with multinode tests 09:51:26 need to check on those 09:51:48 recheck experimental also 09:51:58 where all key functionality can be tested in specific multinode tests 09:52:44 ok. anything else on Tempest side 09:53:22 let's move on 09:53:42 skipping DevStack + Grenade if there is nothing on those ... 09:53:58 #topic Critical Reviews 09:54:16 one i have to unblock stress job - https://review.openstack.org/#/c/271195/ 09:54:37 currently experimental stress jobs are failing due to legacy cred 09:55:14 any others reviews? 09:56:15 Let's move on 09:56:18 #topic Open Discussion 09:56:29 anything else to discuss. 4 min left 09:56:54 I just want let you know about openstack-health. Now, it has parameters for the resolution, search word, period. 09:57:08 masayukig: cool 09:57:08 like this http://status.openstack.org/openstack-health/#/?groupKey=project&resolutionKey=day&searchProject=neutron 09:57:25 yes, it's crazy powerful 09:57:31 masayukig: oh I didn't realise 09:57:31 :) 09:57:42 jordanP: andreaf: yay :) 09:57:54 masayukig: there's another thing we were chatting about with mtreinish yesterday that would be cool to have 09:58:14 click on a point in a graph to open a table of the runs associated to that point, with links to logs 09:58:40 andreaf: yeah, there is a useless parameter, though :-P 09:58:50 andreaf: currently link to logs there? 09:59:24 gmann: there is a table with links to the last few runs 09:59:51 andreaf: yea, but log links also? 09:59:57 i did not find those 10:00:01 yes 10:00:10 it's the time 10:00:11 http://status.openstack.org/openstack-health/#/g/project/openstack~2Fpython-neutronclient?groupKey=project&resolutionKey=day 10:00:12 ok, time ups. lets discuss on qa channel 10:00:26 #endmeeting