16:00:52 <david-lyle> #startmeeting Horizon
16:00:53 <openstack> Meeting started Tue Apr  1 16:00:52 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:00:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:56 <openstack> The meeting name has been set to 'horizon'
16:01:07 <david-lyle> Hello horizon minded folks
16:01:08 <jcoufal> o/ hello
16:01:11 <jpich> Hello!
16:01:12 <tzumainn> hiya
16:01:13 <devlaps> o/
16:01:18 <clu_> hello!
16:01:19 <doug-fish> Hi
16:01:22 <akrivoka> hiya o/
16:01:24 <lsmola> hello
16:01:26 <lblanchard> hi all!
16:01:31 <lcheng> hello
16:02:37 <david-lyle> RC1 was but on Monday \o/
16:02:50 <david-lyle> s/but/cut/
16:03:10 <david-lyle> master is open for Juno
16:03:10 <akrivoka> yay :)
16:03:10 <doug-fish> :-D  hooray for us!
16:03:18 <lblanchard> great job to you all!
16:03:19 <jpich> Go us!
16:03:42 <david-lyle> lot's of great stuff went into Icehouse and a lot of good stuff just missed
16:04:05 <david-lyle> I expect Juno-1 to pull in a lot of things that just didn't work out timing wise
16:04:29 <david-lyle> If you had a patch that got -2'd for Icehouse, it mostly likely was abandoned by gerrit
16:04:37 <julim> hi all
16:04:54 <jpich> Cool. (Do other cores have a secret gerrit query to easily find the patch one -2d?)
16:05:03 <david-lyle> Please revitalize your patches and the person that -2'd it will remove the -2
16:05:30 <david-lyle> jpich, unfortunately no, and unless it's in an active state, you can't remove the patch
16:05:43 <jpich> david-lyle: Ok!
16:05:57 <jpich> Please feel free to ping the person that left it if the -2 isn't going away, sometimes people miss things......
16:06:06 <jpich> :-)
16:06:47 <david-lyle> So one large item that is not in RC1 is a translation import, we will need an RC2 to pull those in
16:07:19 <david-lyle> we want to limit what goes into RC2 to critical and very low risk fixes
16:07:48 <jpich> I'd really like to see https://review.openstack.org/#/c/79456/ go into rc2 FWIW, the current way of updating host aggregates isn't safe
16:08:00 <david-lyle> There is not an RC2 window yet, so just tag the bugs with rc-potential
16:08:17 * david-lyle should verify actual tag
16:08:21 <jpich> There's a pending question about the tests in that review (which I was planning on bringing up) but the fix itself looks fine
16:08:34 <jpich> I've seen icehouse-rc-potential  used
16:08:39 <jpich> so I've been using it too :-)
16:09:16 <david-lyle> icehouse-rc-potential yes
16:10:09 <david-lyle> I don't see any agenda items for today, so let's jump in
16:10:16 <david-lyle> #topic Open Discussion
16:10:30 <david-lyle> jpich, what was the question?
16:11:00 <jpich> About the tests on https://review.openstack.org/#/c/79456/, would people have objections to switching the openstack_dashboards logging handler to 'null' for the tests? (https://github.com/openstack/horizon/blob/master/openstack_dashboard/test/settings.py#L151 ). It can cause issues with unwanted output in the tests when testing failure paths. We do need to log the different clients for e.g. missing mocked calls, but I'm not sure of the value for
16:11:00 <jpich> this one (I could be missing it though)
16:11:32 <jpich> It's a fix I'd really like to see ideally in the RC in my ideal world, or otherwise in the first stable icehouse point release. I appreciate your feedback :)
16:12:55 <david-lyle> are we missing an Exception type being caught?
16:13:50 <jpich> david-lyle: I think it's because of using LOG.exception() instead of LOG.error() - which I had suggested in order to keep the details of the exception but perhaps it wasn't the best solution
16:14:01 <david-lyle> ah, ok
16:14:46 <jpich> Without the fix, we currently delete all the aggregates whenever the "Save" button is hit instead of only updating the list
16:15:26 <jpich> I think this could be a real problem if Nova happened to become unreachable in the middle of this operation
16:15:38 <david-lyle> why not exceptions.handle?
16:16:08 <akrivoka> the tests still pass, right? the only issue is that the traceback is displayed is the logs, but that's kinda the point of logging.exception()
16:16:24 <david-lyle> agree, the problem should be fixed
16:16:27 <jpich> david-lyle: It causes 2 message notifications to pop up instead of one
16:16:49 <jpich> akrivoka: Yes, it's just a notification message in the output, the tests are correct and pass
16:17:18 <david-lyle> we don't want noise in the test output though, or things like missing mocks get overlooked
16:17:21 <amotoki> exceptions.handle leads to another popup menu. LOG.error looks good now and we need to investigate more about LOG.exception later.
16:18:03 <jpich> amotoki: You do lose some details though, exception() keeps the strack trace
16:18:44 <jpich> From what I understand the same problem should happen using LOG.error since they log at the same level (I will test)
16:19:19 <amotoki> jpich: yes. After chekcing the code, exception.handle with ignore=True suppress error popup.
16:19:19 <jpich> Anyhow I don't mean to hijack the meeting with this, I would appreciate feedback on the review and I'll keep trying to look for a better solution myself as well
16:19:22 <jpich> Thank you
16:19:50 <jpich> amotoki: it doesn't log the exception at all when ignore is True, which isn't ideal either
16:20:56 <amotoki> jpich: I might miss something... i will check it later if i have time.
16:21:16 <jpich> amotoki: Thank you!
16:22:58 <david-lyle> quiet today, post RC haze
16:23:52 <doug-fish> :-)  so what's our string freeze state today, now that we've reached rc1?
16:24:05 <jpich> amotoki: (I just confirmed that the log output is also shown when using LOG.error())
16:24:17 <jpich> doug-fish: Definitely hard freeze :)
16:24:48 <david-lyle> and we plan to import the strings to master/RC2 on Monday
16:24:49 <doug-fish> so ... no string changes unless I have a signed note from jpich?  (I'm not planning any)
16:24:56 <david-lyle> translated strings that is
16:25:11 <doug-fish> wow, that's fast!
16:25:11 <jpich> doug-fish: A blessing in writing from the good folks at http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n :)
16:25:42 <david-lyle> amotoki, previously discussed plan still works
16:26:25 <amotoki> david-lyle: thanks. most lang team do the great job and there seems no problem so far.
16:26:32 <akrivoka> jpich: amotoki: found this, might be useful http://stackoverflow.com/questions/5255657/how-can-i-disable-logging-while-running-unit-tests-in-python-django
16:26:35 <david-lyle> excellent
16:27:59 <jpich> akrivoka: That kind of looks like the hammer solution, switching the one handler to null would avoid losing the missing mocked calls that pop up from time to time
16:28:04 <jpich> that disable all logging
16:28:07 <david-lyle> regarding lang, the above would also hide unmocked api calls
16:28:52 <david-lyle> maybe have to filter the log calls somehow when testing, but that wouldn't be an RC change
16:29:16 <akrivoka> hm right. seems like it needs further investigation.
16:29:41 <jpich> Right. I'll play some more with exception.handle() as well
16:31:54 <david-lyle> Any other items?
16:33:32 <jpich> While I'm out here making requests... It'd be lovely if a non-Red Hat core could look at helping the initial integration tests patch to move along: https://review.openstack.org/#/c/77425/ . At this stage it doesn't need to be perfect, I think, we'll figure out best practices as we go. There are 4 people from 3 different companies who reached out to contribute integration tests, but everyone is blocked until that first patch that lays out the fou
16:33:32 <jpich> ndations merges
16:33:52 <jpich> Thank you for your consideration!
16:34:29 <david-lyle> jpich, thanks, got lost in the release shuffle, that is a high priority for me
16:34:35 <david-lyle> added to my list
16:34:46 <jpich> david-lyle: Cheers!
16:34:57 <jpich> I'm done asking for stuffs :-)
16:35:41 <amotoki> we have several number of new bugs now. i think it is time to check and classify all bugs. Bug day?
16:36:15 <david-lyle> amotoki, good idea
16:37:00 <david-lyle> we're fortunate to have a lot of new people looking at Horizon and submitting bugs
16:37:39 <david-lyle> amotoki, have a day to propose?
16:37:59 <amotoki> i have no exact date.
16:38:57 <amotoki> Or we can check bugs this week.
16:39:50 <amotoki> some of bugs are not directly related to horizon and need to be forwarded to backend projects and some are feature requests.
16:40:11 <david-lyle> we have over 100 bugs in the New state
16:40:52 <david-lyle> I'll try to catch up on some of those this week, if others will do the same maybe we can get that number down quite a bit by next week
16:41:12 <david-lyle> then access if we want to schedule a bug day
16:41:26 <doug-fish> as a still new-ish person here I'm not certain how to contribute to bug handling
16:41:30 <akrivoka> +1, I'll try to help out more on that front
16:41:34 <amotoki> i believe it works.
16:41:34 <doug-fish> is there a triage wiki?
16:42:07 <david-lyle> doug-fish, the biggest assistance would be verifying that it is indeed a problem
16:42:14 <amotoki> doug-fish: do you mean a wiki page describing tagging policy ?
16:42:21 <david-lyle> as in can you reproduce it
16:42:26 <doug-fish> david-lyle - good to know
16:42:32 <jpich> doug-fish: Not sure if you've seen https://wiki.openstack.org/wiki/BugTriage ?
16:42:48 <david-lyle> if you can, and you consider it a bug then you can mark it confirmed
16:43:03 <david-lyle> so items are reproducible, but may be a matter of opinion
16:43:28 <david-lyle> leaving notes as to your findings is also very helpful, especially if you narrow down a cause
16:43:36 <amotoki> i found https://wiki.openstack.org/wiki/BugTags yesterday.
16:44:01 <david-lyle> I believe only Horizon-Driver can set the importance
16:44:44 <doug-fish> jpich:  that wiki is generally quite helpful.  Thanks!
16:44:48 <amotoki> nova and neutron have a good list of tags. I think adding tags for horizon is a good idea.
16:44:56 <jpich> doug-fish: You're welcome!
16:45:18 <doug-fish> I may become a Task 10 specialist.  :-)
16:45:35 <david-lyle> always good to jump to Task 10 first
16:45:50 <amotoki> :-)
16:46:00 <jpich> amotoki: Yes. I find tagging by component can help people who favour another project to fix the related bugs (like you do with "neutron" related bugs for example)
16:47:03 <amotoki> AFAIK we don't have concrete policy on tagging now. let's add to the list. it must be helpful and we can improve it.
16:47:34 <amotoki> i will add some tags tomorrow.
16:47:40 <clu_> hi everyone, i have an unrelated question: https://review.openstack.org/#/c/76107/
16:47:57 <clu_> what are thoughts on validation on the front end?
16:48:24 <clu_> for example, if the api checks for whether there is an existing name or not
16:48:38 <clu_> should the front end do a check first?
16:49:45 <doug-fish> great question clu_.  I've seen some confusion on that in other reviews.
16:50:30 <amotoki> clu_: Apart from that a name is a good example, it sounds good as long as it works.
16:50:42 <david-lyle> If we can perform a sane check beforehand and provide a meaningful validation error, I think that's the best we can hope for, as long as it's not a non-deterministic check
16:50:59 <jpich> clu_: I thought you meant doing a Javascript check first. I think we do this kind of checks usually when it can help showing a better error message
16:51:06 <lblanchard> clu_: I don't know much about the feature here, but IMO it's always nice to let the user know about any errors or potential errors as soon as possible. This way they don't fill out an entire form only to find out that there was an error and they can't complete their task.
16:51:40 <clu_> jpich: yes, this is what i'm referring to
16:52:21 <david-lyle> The hope with angular is we'll be able to provide that validation on the client side, the generalized framework for that is not in place yet though, I believe
16:53:12 <jpich> Will that include making API calls?
16:53:38 <clu_> david-lyle: are there any blueprints about the angular client side validation? i'd like to check that out
16:54:10 <david-lyle> clu_, https://blueprints.launchpad.net/horizon/+spec/django-angular-integration
16:54:39 <clu_> cool thanks david-lyle
16:55:25 <david-lyle> jpich, not entirely clear to me, need to dig back into that topic
16:56:10 <jpich> Ok
16:57:55 <david-lyle> clu_, in the short term, I don't think we should block improving server side validation to wait for better client side validation, we can rework once we have a more generalized framework
16:58:45 <clu_> david-lyle: thanks
16:59:06 <amotoki> server side and client side validations can co-exists. if we have duplicated check, we can remove it later.
16:59:36 <david-lyle> exactly
16:59:56 <amotoki> btw, my patch for milestone-proposed https://review.openstack.org/#/c/84204/ hits the same error on swift...... hope someone check it.
17:00:36 <david-lyle> We're out of time.  Thanks everyone for all your hard work to get RC1.
17:00:44 <david-lyle> Have a great week.
17:00:46 <david-lyle> #endmeeting