16:02:14 <david-lyle> #startmeeting Horizon
16:02:15 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:19 <openstack> The meeting name has been set to 'horizon'
16:02:33 <david-lyle> Hello everyone, welcome back from the summit
16:02:41 <akrivoka> hi everyone
16:02:44 <gary-smith> hello
16:02:52 <santib> hi guys
16:03:11 <doug-fish> Hi all
16:03:30 <jpich> hello
16:04:01 <lblanchard> hi all!
16:04:17 <lcheng> hello
16:04:20 <johnma> Hello
16:04:57 <david-lyle> 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 <david-lyle> very much a simplification, of course
16:05:48 <doug-fish> agreed - that's a clear take away.
16:05:55 <lblanchard> +1
16:06:41 <david-lyle> There are other items for Juno that we did not discuss that we need to accomplish like Sahara support
16:07:20 <jpich> I think the improving error messages blueprint should definitely be on the roadmap as well
16:08:06 <crobertsrh> +1
16:08:08 <doug-fish> 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 <lblanchard> 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 <david-lyle> doug-fish, agreed, I implicitly lumped the first two into user experience :)
16:09:01 <doug-fish> :-)  sounds good.
16:09:20 <johnma> 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 <clu_> yes the etherpads
16:09:45 <david-lyle> https://wiki.openstack.org/wiki/Summit/Juno/Etherpads#Horizon
16:09:46 <jpich> 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 <jpich> though if someone has blogged about the sessions I'd love to read it :)
16:10:10 <santib> 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 <johnma> jpich: Sure, sounds good. Thanks
16:10:58 <santib> was there any discussion about that? I mean duplicating logic in horizon
16:11:07 <doug-fish> santib:  are you talking about the fact that Horizon generally doesn't trust messages from the APIs?
16:11:20 <johnma> Thanks clu_
16:11:29 <jpich> santib: I think in this case duplication is appropriate, if it's necessary to provide a better experience for the user
16:11:45 <santib> not a trust issue but a precision issue
16:12:07 <santib> jpich: i would agree but what if the logic changed?
16:12:09 <jpich> 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 <david-lyle> The status code on the response should not change meaning
16:12:46 <doug-fish> 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 <doug-fish> we just agreed they needed improvement
16:13:07 <santib> we would have to be very careful to make sure that the change in the logic is appropriately propagated
16:13:31 <david-lyle> santib: I'm still not following which logic?
16:14:00 <david-lyle> around showing message 'a' if 401 and 'b' if 409?
16:14:20 <santib> example....we are making sure that when the user extend a volume, the new size does not exceed the user quota
16:14:28 <santib> that check is done in horizon and in cinder as well
16:15:25 <doug-fish> 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 <santib> 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 <doug-fish> at least as far as I've seen
16:16:16 <santib> in that case we would have to propagate that logic change to horizon
16:16:17 <doug-fish> 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 <santib> exactly
16:16:57 <clu_> are the openstack community aware of the error messaging issue...?
16:17:02 <david-lyle> doug-fish: without localized, user consumable error messages coming back from the services, this is difficult to do
16:17:18 <doug-fish> david-lyle - agreed
16:17:27 <david-lyle> because you have to duplicate the laundry list of possible errors
16:17:50 <david-lyle> this is something we need to work on cross-project
16:18:03 <doug-fish> 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 <santib> 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 <david-lyle> santib: advanced logic changes like that are going to be reactionary
16:18:43 <david-lyle> we can monitor the services, but at some point they break us, and we make a fix
16:18:54 <david-lyle> hazard of being at the top of the stack
16:19:15 <doug-fish> Maybe we can even get certain well defined error scenarios into tempest?
16:19:28 <doug-fish> to make sure when we create certain failures we get a reliable message back?
16:19:38 <doug-fish> under penalty of not passing gate!
16:19:46 <david-lyle> once we have integration tests running in tempest yes, that would be a great use of them
16:19:54 <santib> agree
16:19:59 <doug-fish> Not sure we even need to test that through horizon
16:20:05 <david-lyle> which is why that's a high priority
16:20:06 <doug-fish> we could set that up with the related API calls
16:20:55 <doug-fish> I though the Horizon integration tests could/would never be in Tempest?
16:21:17 <jpich> The long term goal is to merge them back
16:21:29 <jpich> for now we're trying to figure them out and make sure they're stable
16:21:40 <jpich> then the feedback from the Tempest folks was that they'd be open to considering it
16:22:10 <jpich> 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 <doug-fish> yeah - that 2nd thing makes more sense to me
16:22:52 <jpich> 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 <david-lyle> 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 <doug-fish> 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 <doug-fish> so we should all work on the stuff jpich linked!
16:23:37 <david-lyle> how those integration tests get wired into the gate, is TBD
16:23:55 <doug-fish> david-lyle  do you think it will happen?
16:23:56 <jpich> 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 <jpich> doug-fish: That's certainly one of my goals :)
16:24:15 <doug-fish> jpich ah interesting.  Yeah, I could see that.
16:25:36 <david-lyle> openstack does like CI testing, so I think there's a very good chance, if we approach it right
16:27:47 <david-lyle> 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 <david-lyle> I don't add many items that don't have an assignee, due to odds of it getting done are low
16:29:21 <david-lyle> we did have one agenda topic
16:29:48 <david-lyle> #topic Drop Django 1.4 support? (kspear, in absentia)
16:30:08 <david-lyle> Icehouse is the last release supported by Ubuntu 12.04 LTS.
16:30:09 <david-lyle> This might mean less resistance to dropping Django 1.4 support in Juno.
16:30:09 <david-lyle> It would be good to reach a consensus at the meeting and then canvas the mailing lists for support.
16:30:15 <david-lyle> was the text included
16:30:39 <jpich> Is Django 1.4 causing problems?
16:30:58 <david-lyle> there are branches where we check for 1.5
16:31:03 <david-lyle> and greater
16:31:15 <jpich> 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 <jpich> ( https://docs.djangoproject.com/en/dev/internals/release-process/#long-term-support-lts-releases )
16:31:43 <david-lyle> the move to 1.6 was slowed by methods disappearing between 1.4 and 1.6
16:31:53 <david-lyle> there are issues, not overwhelming issues
16:32:36 <david-lyle> 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 <david-lyle> https://docs.djangoproject.com/en/dev/releases/1.7/
16:33:26 <david-lyle> 1.7 requires python >= 2.7
16:34:58 <doug-fish> 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 <doug-fish> oh nevermind - canvas the mailing lists
16:36:17 <doug-fish> good plan.
16:36:22 <david-lyle> like all things, we'll need to ping the mailing list
16:37:02 <jpich> Sounds reasonable to me
16:37:02 <jpich> I dropped an email to Kieran to see if he could summarise his concerns about Django 1.4 on the list
16:37:40 <david-lyle> jpich, thanks
16:38:06 <david-lyle> we'll come back to this next week then
16:38:12 <david-lyle> #topic Open Discussion
16:38:35 <jpich> Np
16:38:41 <tzumainn> 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 <tzumainn> er "interested"
16:39:09 <clu_> tzumainn: sure!
16:39:30 <tzumainn> that would be awesome : )  Is there any sort of guidance the tuskar-ui folks could provide to help with that?
16:39:54 <jpich> 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 <tzumainn> jpich, lol, yeah, I admit that fear was lurking in the back of my mind
16:40:38 <tzumainn> 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 <jpich> Does it give helpful error messages by default?
16:41:13 <jpich> (helpful as in specific)
16:41:34 <tzumainn> I am not entirely sure, but it does reduce code duplication
16:42:12 <jpich> Sounds like something we might want to borrow from you!
16:42:18 <tzumainn> 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 <lsmola> mock is the new recommended test framework right?
16:42:48 <david-lyle> lsmola, that sounds correct
16:43:00 <jpich> We should cross-pollinate solutions and synergise our efforts across repo boundaries         (<-- do I win the bingo?)
16:43:02 <tzumainn> 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 <tzumainn> lol
16:43:26 <tzumainn> almost, except my card had 'synergize' instead of 'synergise'
16:44:32 <david-lyle> I think support to mock frameworks may be a requirement going forward
16:44:41 <jpich> 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 <david-lyle> s/to/two
16:46:36 <jpich> ah!
16:48:51 <david-lyle> any thing else, we just spent a week together, so ending early is just fine :)
16:49:56 <david-lyle> going twice...
16:50:49 <david-lyle> Have a great week everyone. See you here next week.
16:50:52 <david-lyle> #endmeeting