16:02:14 #startmeeting Horizon 16:02:15 Meeting started Tue May 20 16:02:14 2014 UTC and is due to finish in 60 minutes. The chair is david-lyle. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:19 The meeting name has been set to 'horizon' 16:02:33 Hello everyone, welcome back from the summit 16:02:41 hi everyone 16:02:44 hello 16:02:52 hi guys 16:03:11 Hi all 16:03:30 hello 16:04:01 hi all! 16:04:17 hello 16:04:20 Hello 16:04:57 I feel the key take aways from the summit for Horizon were, we need to improve the user experience and we want to accelerate client side development to accomplish that 16:05:25 very much a simplification, of course 16:05:48 agreed - that's a clear take away. 16:05:55 +1 16:06:41 There are other items for Juno that we did not discuss that we need to accomplish like Sahara support 16:07:20 I think the improving error messages blueprint should definitely be on the roadmap as well 16:08:06 +1 16:08:08 my take-aways are that there is general agreement accessibility is important, internationalization needs some fixes, and we should invest more in our horizon (non tempest) integration testing that is already started. 16:08:27 jpich: +1 I will get the work I've done around a suggestion for UI guidelines on Error Messaging up on the wiki today and share 16:08:52 doug-fish, agreed, I implicitly lumped the first two into user experience :) 16:09:01 :-) sounds good. 16:09:20 for those who werent able to attend the summit, is there a place where we can go to get a summary of the sessions or topics discussed? 16:09:39 yes the etherpads 16:09:45 https://wiki.openstack.org/wiki/Summit/Juno/Etherpads#Horizon 16:09:46 johnma: Looking through the etherpads should be a good initial first step, I think. I'm not sure anything more formal has been posted elsewhere 16:10:06 though if someone has blogged about the sessions I'd love to read it :) 16:10:10 hi guys, about improving the error messages, there are a bunch of cases where we are duplicating logic in horizon in order to show an appropriate error message to the users 16:10:21 jpich: Sure, sounds good. Thanks 16:10:58 was there any discussion about that? I mean duplicating logic in horizon 16:11:07 santib: are you talking about the fact that Horizon generally doesn't trust messages from the APIs? 16:11:20 Thanks clu_ 16:11:29 santib: I think in this case duplication is appropriate, if it's necessary to provide a better experience for the user 16:11:45 not a trust issue but a precision issue 16:12:07 jpich: i would agree but what if the logic changed? 16:12:09 I don't think there's been a discussion per se or not recently, it just seems to be the status quo 16:12:31 The status code on the response should not change meaning 16:12:46 santib: I don't think we really got into the internal detail about _why_ the messages are they way they are. (at least, not while I was paying attention!) 16:12:52 we just agreed they needed improvement 16:13:07 we would have to be very careful to make sure that the change in the logic is appropriately propagated 16:13:31 santib: I'm still not following which logic? 16:14:00 around showing message 'a' if 401 and 'b' if 409? 16:14:20 example....we are making sure that when the user extend a volume, the new size does not exceed the user quota 16:14:28 that check is done in horizon and in cinder as well 16:15:25 david-lyle: IMO that isn't granular enough...the error codes show only what class of error occurred by any detail the API response might have included about why the error occured in lost 16:15:30 what if cinder changes the way they validate that? what if they suddenly decide that users could extend the volume no matter what their quota is 16:15:31 at least as far as I've seen 16:16:16 in that case we would have to propagate that logic change to horizon 16:16:17 It would be ideal in santib 's case that we just trust the API response from cinder to tell us not only that there was a failure, but it happened because of a quota problem 16:16:33 exactly 16:16:57 are the openstack community aware of the error messaging issue...? 16:17:02 doug-fish: without localized, user consumable error messages coming back from the services, this is difficult to do 16:17:18 david-lyle - agreed 16:17:27 because you have to duplicate the laundry list of possible errors 16:17:50 this is something we need to work on cross-project 16:18:03 I guess my vision (half baked idea?) is that we go API call by API call, sort out which ones really need more detail, work with the API people, and then trust the message that comes back for that API call 16:18:12 there are a bunch of cases like this in horizon. We are duplicating logic from nova, cinder, glance, etc. I'm not against it but we need to be sure that we are consistent across modules 16:18:14 santib: advanced logic changes like that are going to be reactionary 16:18:43 we can monitor the services, but at some point they break us, and we make a fix 16:18:54 hazard of being at the top of the stack 16:19:15 Maybe we can even get certain well defined error scenarios into tempest? 16:19:28 to make sure when we create certain failures we get a reliable message back? 16:19:38 under penalty of not passing gate! 16:19:46 once we have integration tests running in tempest yes, that would be a great use of them 16:19:54 agree 16:19:59 Not sure we even need to test that through horizon 16:20:05 which is why that's a high priority 16:20:06 we could set that up with the related API calls 16:20:55 I though the Horizon integration tests could/would never be in Tempest? 16:21:17 The long term goal is to merge them back 16:21:29 for now we're trying to figure them out and make sure they're stable 16:21:40 then the feedback from the Tempest folks was that they'd be open to considering it 16:22:10 also we could have a separate job for the horizon integration tests that runs on all commits, possibly - but that's too be discussed when we have a larger, well honed test suite 16:22:29 yeah - that 2nd thing makes more sense to me 16:22:52 People interested in writing integration tests, feel free to add yourself to https://wiki.openstack.org/wiki/Horizon/Testing/UI#Test_areas_breakdown and start submitting patches :-) 16:23:20 we are in a unique position to test integration of all the clients, which IMO adds a lot of value across the stack 16:23:20 the problem with putting UI tests in Tempest is that when the UI changes, the tests need to as well. I'm not sure we can ever put out changes to the UI that would require an update to the Tempest tests 16:23:28 so we should all work on the stuff jpich linked! 16:23:37 how those integration tests get wired into the gate, is TBD 16:23:55 david-lyle do you think it will happen? 16:23:56 doug-fish: the page object pattern helps a lot with this. The "page" would still live in Horizon but the tests themselves could move into Tempest 16:24:14 doug-fish: That's certainly one of my goals :) 16:24:15 jpich ah interesting. Yeah, I could see that. 16:25:36 openstack does like CI testing, so I think there's a very good chance, if we approach it right 16:27:47 This week I will be going through the blueprints to create a tentative release plan for Juno. So if there are items that you plan to work on, please assign yourself or ask a core to assign you 16:28:15 I don't add many items that don't have an assignee, due to odds of it getting done are low 16:29:21 we did have one agenda topic 16:29:48 #topic Drop Django 1.4 support? (kspear, in absentia) 16:30:08 Icehouse is the last release supported by Ubuntu 12.04 LTS. 16:30:09 This might mean less resistance to dropping Django 1.4 support in Juno. 16:30:09 It would be good to reach a consensus at the meeting and then canvas the mailing lists for support. 16:30:15 was the text included 16:30:39 Is Django 1.4 causing problems? 16:30:58 there are branches where we check for 1.5 16:31:03 and greater 16:31:15 My thinking would be that since it's supported upstream as a LTS it makes sense to try and keep supporting it for Horizon too, unless it's causing huge issues 16:31:26 ( https://docs.djangoproject.com/en/dev/internals/release-process/#long-term-support-lts-releases ) 16:31:43 the move to 1.6 was slowed by methods disappearing between 1.4 and 1.6 16:31:53 there are issues, not overwhelming issues 16:32:36 since we won't be able to transition to 1.7 until the K cycle, I am ok with keeping 1.4 until that point 16:33:02 https://docs.djangoproject.com/en/dev/releases/1.7/ 16:33:26 1.7 requires python >= 2.7 16:34:58 Dropping 1.4 support at K seems reasonable to me. Is there some way that we share that plan so people can let us know if its going to cause a problem? 16:36:13 oh nevermind - canvas the mailing lists 16:36:17 good plan. 16:36:22 like all things, we'll need to ping the mailing list 16:37:02 Sounds reasonable to me 16:37:02 I dropped an email to Kieran to see if he could summarise his concerns about Django 1.4 on the list 16:37:40 jpich, thanks 16:38:06 we'll come back to this next week then 16:38:12 #topic Open Discussion 16:38:35 Np 16:38:41 I had a question - would people be interesting in looking at the tuskar-ui code to see if there are any divergences from the proper horizon way of doing things? 16:38:49 er "interested" 16:39:09 tzumainn: sure! 16:39:30 that would be awesome : ) Is there any sort of guidance the tuskar-ui folks could provide to help with that? 16:39:54 Ideally we should all get familiar with the code well ahead of it merging later, make the process as painless as possible :) 16:40:09 jpich, lol, yeah, I admit that fear was lurking in the back of my mind 16:40:38 we also do a few things slightly differently - off the top of my head, we use mock instead of mox for tests, and we have a @handle_errors decorator for our api calls 16:40:52 Does it give helpful error messages by default? 16:41:13 (helpful as in specific) 16:41:34 I am not entirely sure, but it does reduce code duplication 16:42:12 Sounds like something we might want to borrow from you! 16:42:18 and doing it at the level of the api call means that it's less likely that potential error cases are less likely to get missed when writing the view code 16:42:22 mock is the new recommended test framework right? 16:42:48 lsmola, that sounds correct 16:43:00 We should cross-pollinate solutions and synergise our efforts across repo boundaries (<-- do I win the bingo?) 16:43:02 but yeah, overall, I'd be interested in ways to help making sure that tuskar-ui converges toward horizon rather than away 16:43:07 lol 16:43:26 almost, except my card had 'synergize' instead of 'synergise' 16:44:32 I think support to mock frameworks may be a requirement going forward 16:44:41 I'm not clear on whether the mock vs mox3 debate was ever resolved but both sound good to me (I prefer mock personally) - don't think that'll be a problem 16:45:48 s/to/two 16:46:36 ah! 16:48:51 any thing else, we just spent a week together, so ending early is just fine :) 16:49:56 going twice... 16:50:49 Have a great week everyone. See you here next week. 16:50:52 #endmeeting