20:00:23 #startmeeting horizon 20:00:24 Meeting started Wed Dec 7 20:00:23 2016 UTC and is due to finish in 60 minutes. The chair is r1chardj0n3s. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:28 The meeting name has been set to 'horizon' 20:00:30 o/ 20:00:37 o/ 20:00:46 o/ 20:01:40 0/ 20:01:50 o/ 20:01:57 so, Ocata-2 is next week (ohmygosh) 20:02:05 #topic Priority patches for review 20:02:12 #link https://review.openstack.org/#/q/starredby:r1chardj0n3s%20AND%20status:open now has some angularjs panels listed, will add more 20:02:14 o/ 20:02:57 I've started adding the priority angularjs panels to that list, and will add some more. Trying to limit it to just the ones that are most likely to be completed in this release. 20:03:18 ie. the ones that have table, create, delete and edit actions at least partially implemented 20:03:23 Check this https://review.openstack.org/#/c/366957/ 20:03:27 o/ 20:03:55 r1chardj0n3s: Nothing on Users? 20:04:19 ediardo - would like to follow up on that link later 20:04:20 robcresswell: which user patches? 20:04:47 https://review.openstack.org/#/c/336394/ 20:05:09 Just that I would imagine there is more demand for Users to be functional than Roles, no? 20:05:44 o/ 20:05:52 I'd agree that users and projects are more heavily used than roles robcresswell 20:05:56 robcresswell: yep, absolutely. I just somehow didn't see that patch when I skimmed ... will add to the priorities etherpad :/ 20:06:06 Cool 20:06:28 starred! 20:06:29 There's also a whole instances implementation sat in searchlight ui if someone wants to look at porting that 20:06:46 Would also be a good panel to improve *hint hint* 20:06:49 :) 20:06:55 agreed 20:07:18 any other users patches i've omitted from the priority list? 20:07:38 Not sure atm, I threw a tantrum at everyone using identity-tables blueprint and -1'd them all 20:07:54 It had like 100 patches so I've no idea what was relevant 20:08:10 https://review.openstack.org/#/c/342170/ perhaps 20:08:50 I have a cinder patch that is old as dirt, around quotas 20:08:57 and https://review.openstack.org/#/c/361529/ 20:09:02 yeah, looks like there are a few on there. Either way, it would be great to focus on getting Users in a good position especially while we have the Keystone meeting each week 20:09:05 but the quota rework is probably the thing to focus on 20:09:23 ducttape_: Yeah, has quota reworks gone stale? Or is that still a thing? 20:09:35 we still need a solution for search-first to replace the user listings in other parts of our UI 20:09:59 I think I was throwing ediardo or lcastell at that problem tho 20:10:08 \o/ 20:10:16 \o/ 20:10:17 quota rework is a thing, just can't get enough time to work on it. welcome any all help 20:10:24 (https://blueprints.launchpad.net/horizon/+spec/ng-users exists, so we can link to that instead) 20:10:25 ducttape_: got links? 20:10:41 https://review.openstack.org/#/c/309204/ is the old one 20:10:54 it is ready for review, could be merged 20:11:07 well, except jenkins, but it is close to done / ready 20:11:14 ducttape_: I'm pretty swamped right now, freed myself up and immediately got a ton of work. Plus internally I've got Kubernetes work. My career plan has just become "follow david-lyle" 20:11:19 Can review though 20:11:24 k 20:11:43 clu_: Thanks for that! 20:11:50 quota rework needs to be rebased and redo all the tests still https://review.openstack.org/#/c/356605/ 20:12:09 if anyone feels like a patch should be priority please let me know even outside of this meeting :-) 20:12:29 ducttape_: ack 20:12:40 #topic Integration tests are broken, getting no attention at all, and should be removed altogether 20:12:56 ... discuss 20:13:11 I think the out right broken things have been corrected pretty quickly (in the last few weeks), we have master - 5 days in our lab right now 20:13:37 even the simple tests we have are still useful 20:13:49 I found a bug with one yesterday 20:14:02 the problem is, nobody knows how they work or how to run them locally 20:14:25 we don't have a plan for stability in the gate 20:14:29 we don't have anyone in the community who has fixing them as a priority 20:14:30 rdopiera: They've been failing and non-voting for months 20:14:39 robcresswell: one is voting 20:14:50 rdopiera: do you mean tempest? 20:14:52 if they can pass along the knowledge to us, we have some hands available 20:14:57 r1chardj0n3s: yes 20:15:09 rdopiera: that's not really a test ;-) it just checks the login screen appears 20:15:27 r1chardj0n3s: well, it's a test if it finds bugs, and it found one yesterday 20:15:28 r1chardj0n3s: it does a bit more 20:15:37 it's still worth having, sure 20:15:40 it tests that login work 20:15:50 david-lyle: by the way, I will ask you for some help with that later 20:16:00 david-lyle: if you don't mind 20:16:13 Yeah, it also runs through static collecting and compressing as part of the setup, so settings issues will be caught too. 20:16:18 whatever help I can provide 20:16:23 lcastell: perhaps, if we can get you and timur talking 20:16:35 r1chardj0n3s: I'd like to try and get that to work 20:16:38 yep 20:16:47 r1chardj0n3s: the non-voting tests, I mean 20:16:54 r1chardj0n3s: if I fail, we can revisit the issue 20:16:56 the basic issue though isn't with any specific tests, it's with the fragility of the whole setup 20:17:09 Yes, let me know , I can help too 20:17:10 we are constantly being broken by some new release of firefox or selenium 20:17:25 or some timeout 20:17:29 or some timeout 20:17:32 well, that's modern software development :) 20:17:43 or leftpad.js 20:18:08 node.js programming language issues don't tend to be the cause of breaking our selenium tests 20:18:08 but the noise to signal ratio is much too high for anyone to actually think their new code may have broken something 20:18:11 No, this was next level stuff 20:18:33 We had like a 25% pass rate on functioning code before we disabled them 20:18:38 and thats when they were "working" 20:18:59 I'd prefer we focused on getting unit tests passing on xenial first 20:19:06 ediardo / lcastell I will put you in touch with timur to discuss a way forward 20:19:16 sounds good 20:19:17 It's pretty cryptic syntax too, which doesnt help a great deal. 20:19:28 david-lyle: UTs fail on Xenial? 20:19:31 ok, ty 20:19:34 david-lyle: our tests don't pass on xenial?? 20:19:34 we already talk about it las mid cycle so... 20:19:47 0/ sorry im late, just caught up with the script 20:20:17 r1chardj0n3s: nope 20:20:35 david-lyle: I'm confused, becuase I see tests passing 20:20:42 two failing non-voting runs at the bottom of every patch 20:21:18 david-lyle: but that's the selenium tests we've been talking about 20:21:27 thats the integration tests 20:21:40 selenium and integration tests are two very different things 20:21:51 the selenium tests pass generally 20:22:16 not in xenial because the xvfb lib is not installed by default 20:22:31 any more 20:22:51 david-lyle: that's part of the whole mess of issues around ubuntu breaking selenium with firefox/selenium (And now xvfb) releases that break us, yes 20:23:15 oh nevermind 20:23:25 Yeah, the xenial issue might be new, but those integration test runs were set to non-voting before that point 20:23:32 the tests are different but I didn't see the xenial was integration 20:23:34 sure, the selenium and integration suites are two separate things, but they both *use* selenium and that's the fragility we have 20:23:45 right 20:24:12 ok, I'm gonna see if we can get ediardo and lcastell to fix it, working with timur to extract all his knowledge :-) 20:24:12 the alternative is to go blind, which is even more fragility 20:24:15 moving on? 20:24:25 (to something much simpler) 20:24:28 #topic Microversion support 20:24:29 :) 20:24:31 personally I think that test suite is a waste of time 20:24:43 #link https://etherpad.openstack.org/p/horizon-microversion-support is where we’ve been discussing the approach 20:24:57 once it's patched it will break and it's limited in time duration 20:25:06 it's half sleep calls 20:25:08 rdopiera: Well, they are non-voting, so we are already blind 20:25:12 so nothing would change 20:25:15 ok done 20:25:32 robcresswell: I agree that setting anything to non-voting doesn't make any sense -- just disable it 20:25:51 r1chardj0n3s: On microversions, I realised we've gone full circle with the approach now 20:25:58 robcresswell: \o/ 20:26:00 so... do we have a replacement in mind? or will horizon not be doing tests at all? 20:26:07 3rd system syndrome? 20:26:13 tqtran: it's only integration tests 20:26:23 ok, putting microversions discussion on hold 20:26:30 tqtran: Well, we need someone to work on it, and noone is 20:26:36 no, no-one has proposed an alternative to selenium tests 20:26:36 So... thats kinda all there is to it 20:26:38 ok thats fair enough, i cant get those to run locally, so testing them was a PITA to begin with 20:26:59 we have to have that level of testing to have confidence, but only if we can make it work 20:27:02 selenium works, integration tests use of selenium does not 20:27:11 Right 20:27:24 perhaps we should consider more tempest scenarios? 20:28:01 I'd prefer that to integration test suite 20:28:10 sounds reasonable 20:28:57 without massive rework I just don't see the integration tests being useful 20:29:12 they've been flaking for 4+ releases 20:29:17 david-lyle: what is it in our integration / selenium test suite use of selenium that differs from the tempest use of it? 20:29:21 that's not going to change with a few days of love 20:29:46 r1chardj0n3s: good question 20:29:49 :) 20:30:12 The selenium tests are launched the same as any unit test but happen to use selenium 20:30:13 david-lyle: 'cos if we don't know that then it's pointless moving everything to tempest if it's just going to be as unstable without fixing the root cause 20:30:32 well the login test never fails 20:30:40 unless it really should :) 20:30:43 which is rare 20:30:56 r1chardj0n3s: Either way, I think there would be more value in having new people look into other options at this stage. The learning curve with the current setup is quite high 20:31:08 Also, I rarely see the tempest test randomly fail :p 20:31:22 thats because we have like one test in tempest 20:31:33 best test ever 20:31:33 we have precisely one test in tempest ;-) 20:31:42 a scenario test yes 20:31:46 My point was that the setup doesnt collapse 20:32:19 ok, we have a couple of folks who are willing to get up to speed on our setup to try to fix it, can we agree to leave the disucssion until they've had a look at it? 20:32:22 people maintain tempest, rolling our own demon spawn testing suite is silly 20:32:29 no 20:32:34 And there's likely to be more support on adding tempest tests, that hz integration tests, which has precisely one support person right now 20:32:36 you're wasting their time 20:33:17 Agree with Dave here 20:33:20 I previously was a huge advocate of the integration tests, but the reality has proven it's a lost cause 20:33:36 ok, so delete our current integration and selenium tests and start from scratch 20:33:41 Mirantis had half a dozen people on them at the start of last(?) cycle 20:33:44 +1 20:33:47 that work started before either of you even started on horizon and they have never been stable for any duration 20:34:01 selenium is different 20:34:05 scrap it and start new, i like that plan 20:34:10 don't conflate the two 20:34:12 tqtran: >.< 20:34:17 david-lyle: aren't we the only consumers of selenium in tempest? 20:34:47 david-lyle: the integration tests and selenium tests in our code use the same testing framework 20:35:00 but one is stable and one is not 20:35:15 becase? 20:35:16 plus we have unit tests that run in selenium and those don't fail either 20:35:35 yep 20:35:45 removing integration tests will effect sahara 20:35:51 I think they have one or two 20:36:19 unless they have removed them already 20:37:06 so our Selenium tests in the unit tests will hit mocked API calls 20:37:18 the tempest one should hit a devstack instance 20:37:25 yes 20:37:30 tempest and integration are the closest parallel 20:38:02 ok, so it sounds like there's general enthusiasm for deleting that set of deck chairs and creating some new tempest ones :-) 20:38:23 At the very least, have a look at tempest before throwing bodies at the current build. 20:38:32 question, so if we go down the tempest route, are we going to bring selenium with us? or will tempest provide all the things we need? 20:38:43 since we have the plugin now, we can add tests without worrying about breaking the world 20:39:03 selenium is present in tempest I believe 20:39:06 david-lyle: are you able to get ediardo and lcastell up to speed on tempesting? 20:39:23 oh neato 20:39:27 yes my knowledge runs very deep :P 20:39:32 erm, you've been asserting that sleenium is in tempest... 20:39:40 I think so 20:40:49 I created the plugin and maintain the test, so yes I'm the closest thing we have to an expert 20:40:58 \o/ 20:41:02 btw, is the horizon tempest repo own by horizon drivers? 20:41:08 bring the knowledge 20:41:08 yes 20:41:16 tqtran: ^^ 20:41:22 david-lyle: do you have a quick linky to that repos pls? 20:41:28 but I just +2+A stuff I put in there 20:41:37 cause 20:41:42 hm ok, im not seeing it on launchpad (but i trust you) 20:42:26 https://github.com/openstack/tempest-horizon 20:42:52 thanks david-lyle 20:43:11 so, microversions? 20:43:18 Right 20:43:34 I can't really read the word microversion without getting angry any more 20:43:36 tqtran: https://review.openstack.org/#/admin/projects/openstack/tempest-horizon,access 20:43:49 haha 20:43:55 you're welcome robcresswell 20:44:04 I'm personally still voting for fixed versions in a list in Horizon 20:44:27 one of the big issues is that we were considering allowing version exclusions in our local specification of versions that work 20:44:37 i also think a fixed version is going to make life easier for us down the stretch 20:44:40 Because microversions are designed for users to know what version they want, and just hit that version 20:45:00 * ducttape_ is looking forward to tempest having microversions 20:45:05 so range may break randomly, and range/exclude is troublesome for the reasons you outlined in the etherpad r1chardj0n3s 20:45:35 So, I think we should just stick to a list of known functional versions 20:45:43 like [3.11, 3.18] 20:45:49 but you were arguing against that because maintenance? 20:46:02 Indeed 20:46:15 I've transcended arguing to the point where I can just argue myself into a corner alone now 20:46:25 whereas we can just get the version range from the target service's source code 20:46:29 But I think that list of fixed versions is least shit situation 20:47:18 er 20:47:21 * robcresswell thinks 20:47:25 version each resource? 20:47:39 rhagarty_: sorry, expand on that idea please? 20:47:48 rhagarty_: It goes way beyond that, we need to version every feature. 20:47:52 most resources will always continue to work, with latest 20:47:56 I think we should be naive and let it fail 20:48:13 unless we find something breaking then put some logic in 20:48:25 +1 20:48:41 we don't keep up with the APIs now 20:48:49 david-lyle: could you be more explicit? how should we be naive? 20:48:53 this is not all that different from policy 20:48:59 and now we're going to validate every nuance of microversion role? 20:49:18 assume API calls will work :) 20:49:24 write / ship code with little to no checks on micro versions 20:49:34 there will be a min version for some 20:49:43 but latest should work in almost all cases 20:49:49 ducttape_: ++ 20:50:01 but we need to handle new features introduced in microversions... or we just don't suport? 20:50:06 the glaring exception will require code changes via bug fixes 20:50:10 the only problem, is that this will build up over time, on the min versions etc 20:50:43 rhagarty_: Well, that would be accounted for by a minimum 20:50:53 most now don't have a min 20:50:57 david-lyle - what if someone is adding a new horizon thing, and they place a min check, on something that is not in a released service yet ? 20:51:05 As in, if service.latest is > minimum, show it, and pray it still works 20:51:06 just the newest additions (in our code base) 20:51:20 ducttape_: Well, it just wouldnt show up 20:51:29 I think the reviewers might want to have a rule on that tho 20:51:29 the result wouldn't show 20:51:33 log it 20:51:46 The problem with this is that Horizon could break in fun and unnoticed ways 20:51:47 like don't merge code unless this feature is in a release somewhere 20:51:51 resullt would show... with errors 20:51:57 ducttape_: ++ 20:51:59 a problem with ignoring microversions is that it means we could probably never implement something https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/migrate_server.py#L65 20:52:52 nah we can add new things, and have them use a min --- this is fine / ok I think 20:52:52 that looks like a disaster 20:52:52 not that I dream of implementing against an API that mutates every few versions... 20:52:53 ARGH WHO THOUGHT THIS WAS SMART 20:52:57 fuck sake. 20:53:15 nova... 20:53:24 holy shit that link is hurrible 20:53:36 "someone else's problem" 20:53:42 r1chardj0n3s we now feel very bad about ourselves ;) 20:53:49 stability is hard, lets push this on to the users and consumers. 20:54:14 so, the point is, that for *some* API calls, we will need mivroversion support 20:54:20 agree 20:54:25 or say this is too stupid 20:54:34 we abstain 20:54:37 hahaha 20:54:39 I have proposed that we pull the version ranges directly from the service itself (we can grep to find most of the information) 20:54:39 lol 20:54:40 cinder likes it... it forces user to specify version in CLI calls, which they can live with. They didn't think through/care about Horizon 20:54:41 I think david-lyle and I are saying - avoid the micro version stuff unless you are really painted in a corner 20:54:53 ducttape_: and I'm agreeing 20:55:00 I am painted in a corner 20:55:01 we already have one patch up that needs microversion support 20:55:03 rhagarty_: Or about anyone not using a CLI 20:55:26 so we need to make sure our approach is sensible (or at least starts out with something that we think is sensible) 20:55:39 r1chardj0n3s: So, minimum and *optional* maximum? 20:55:40 we are not starting from a sensible place ;) 20:55:46 robcresswell: yes 20:56:01 we still have the vague concept of an integrated release 20:56:04 I added cinder consistency groups, which goes away in 4.0. It is being replaced by generic groups, added in 3.13, 3.14 and generic group snapshots added in 3.15 20:56:24 as long as we support the latest MV in those releases, I think that handles most of it 20:56:25 we have four minutes to go 20:56:32 #topic Mascot 20:56:35 just quickly 20:56:45 Right, I'll update the bp to specify minimum and optional maximum 20:56:47 Very Mascot 20:56:47 the legacy of backward compatibility may be lost to microversion purgatory 20:56:50 did robcresswell get images ? 20:57:03 ducttape_: on the MML 20:57:03 did I what now 20:57:04 I really like rdopiera's reworking of the mascot, and weill be feeding that back to them 20:57:05 *ML 20:57:16 r1chardj0n3s: ++ 20:57:20 Yeah, it should be orange and white 20:57:21 * ducttape_ avoids the ml, heads there now 20:57:24 not a husky 20:57:27 yep 20:57:29 rdopiera: did you provide that as feedback on the link? 20:57:32 its basically identical to the release one I think 20:57:40 ducttape_: sorry 20:58:08 david-lyle: what link? 20:58:25 Oh, I threw another tantrum on twitter at the foundation and the updated me on the logo's to say it'll still be another few weeks to make an svg -.- so I'll probably do it myself 20:58:28 feedback link for the mascot 20:58:35 robcresswell: \o/ 20:58:52 david-lyle: I saw no feedback link, just the image as an attachment 20:59:15 I didn't include the feedback link in my message because I actually don't know what it is ;-) 20:59:24 oh r1chardj0n3s didn't include that part of the email 20:59:42 I bet he will now 20:59:42 so in short, no 20:59:45 :) 20:59:47 www.tinyurl.com/OSmascot 20:59:54 is the feedback link 20:59:59 thanks everyone! time's up 21:00:03 #endmeeting