16:01:06 <david-lyle> #startmeeting Horizon
16:01:07 <openstack> Meeting started Tue Feb  4 16:01:06 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:01:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:10 <openstack> The meeting name has been set to 'horizon'
16:01:15 <david-lyle> Hello everyone
16:01:21 <lblanchard> hi all
16:01:32 <tmazur> hello o/
16:01:33 <akrivoka> hi everyone
16:01:47 <amotoki> hi
16:01:52 <doug-fish2> greetings
16:01:54 <mrunge> hey
16:01:56 <xazel> hey
16:02:10 <lcheng> hello
16:03:11 <david-lyle> The only general item I have today is that the gate is in great shape right now, so let's merge some patches before anything changes :)
16:03:24 <jcoufal> o/
16:03:52 <akrivoka> awesome :)
16:03:59 <david-lyle> #topic https://launchpad.net/horizon/+milestone/icehouse-3
16:04:28 <jomara> hello!
16:04:33 <jrist> o/
16:04:47 <david-lyle> lots of bps up for review right now.
16:05:08 <david-lyle> I think we're looking all right heading into a soft-freeze on Feb 18
16:05:39 <david-lyle> the RBAC support is still making progress
16:06:13 <jpich> david-lyle: I started testing the navigation patch, very nice!
16:06:36 <doug-fish2> david-lyle - can you share briefly what you mean by "soft-freeze"?  What things should we start excluding on the 18th?
16:06:50 <david-lyle> jpich: my css could use some help :)
16:06:57 <david-lyle> taking another pass
16:07:47 <david-lyle> doug-fish2: The service teams try to not consider anything that is not up for review by Feb 18 (this releases arbitrary deadline)
16:08:03 <doug-fish2> ok that helps.  thanks!
16:08:16 <david-lyle> I've stated before that I would be open to exceptions beyond that on a case by case basis
16:08:26 <doug-fish2> david-lyle - would that include bugs?  or are you thinking of blueprints?
16:08:33 <david-lyle> just bps
16:08:39 <doug-fish2> k great.
16:08:41 <david-lyle> bug fixes are outside of that
16:08:42 <amotoki> i see. "soft-freeze" means Feature proposed deadline.
16:08:57 <david-lyle> amotoki: yes, but with the code
16:09:15 <david-lyle> we'll always fix bugs
16:09:51 <jpich> until there aren't any left
16:09:57 <doug-fish2> :-)
16:10:00 <jpich> ... :-)
16:10:11 <david-lyle> once we hit March 5, the cut off for icehouse-3, there is a more formal feature exception process that can be utilized if we have to, but it would be nice to get things in order without resorting to that
16:10:51 <david-lyle> bug fixes still happen then too during the release candidate phases
16:11:37 <doug-fish2> do we have any concept of fixing only high priority bugs during RC phases?
16:11:57 <david-lyle> I'm working on one bp that I haven't added to the i-3 list yet, a smaller pass at a bigger RBAC item, and that's pulling out the identity dashboard with RBAC on the data loading as well
16:12:09 <jpich> doug-fish2: Yes. There's a stabilisation period between feature freeze and the first RC though
16:12:11 <david-lyle> so look for that today or tomorrow as well
16:13:05 <david-lyle> amotoki: are you able to handle the translation patches again?
16:13:15 <david-lyle> as we near the end
16:13:37 <amotoki> david-lyle: no. daisy is porposing jenkins job patch, but she is in chinese vacation.
16:13:57 <david-lyle> ok, so it will be automated this time around?
16:14:05 <jpich> The patch: https://review.openstack.org/#/c/68042/
16:14:08 <amotoki> i hope so.
16:14:13 <jpich> Hopefully
16:14:14 <david-lyle> +1
16:14:38 <david-lyle> ok, I'll keep an eye on that, thanks
16:15:22 <david-lyle> I have a couple of patches pending in django_openstack_auth that I would like to roll into a release before i-3
16:15:36 <david-lyle> one fixes keystone v3 auth issues
16:15:56 <david-lyle> https://review.openstack.org/#/c/70479/
16:16:14 <david-lyle> as well as moves the default API version to v3 as v2.0 is now deprecated
16:16:42 <david-lyle> the seconds is around django 1.6 support finalization https://review.openstack.org/#/c/70798/
16:17:00 <david-lyle> but that will require an openstack/requirements change
16:17:31 <david-lyle> is there any reason not to allow Django 1.6 at this point in Horizon
16:17:44 <david-lyle> I think this needs to be in for icehouse
16:18:01 <jpich> We'll probably want a tox django 1.5 job in Horizon too (or is there a patch up for this already?)
16:18:33 <david-lyle> jpich: I plan on posting one, but it will fail until the requirements patch lands (which I need to post too)
16:19:24 <jpich> david-lyle: I think it shouldn't fail since we already have access to django 1.5, it would simply duplicate the main test job for now?
16:19:53 <david-lyle> jpich: I see, we could do that separately sure
16:20:02 <david-lyle> and follow on with the requirements bump
16:20:11 <david-lyle> sure I'll do that
16:21:18 <david-lyle> those were my main concerns around i-3, anyone else? before we jump to Open
16:21:25 <jpich> No strong preference from me either way as long as we Test All The Things eventually :-) Thanks david-lyle, let me know if I can help with something around this
16:21:47 <david-lyle> jpich: thanks, will do
16:22:33 <david-lyle> Ah, I do have one more i-3 item...
16:23:03 <david-lyle> the bootstrap update bp https://blueprints.launchpad.net/horizon/+spec/bootstrap-update
16:23:54 <david-lyle> There is currently a patch pending on openstack/requirements to bump the lesscpy version to theoretically support this, I have not tested yet, but enykeev does not think it's anywhere close
16:24:12 <david-lyle> so this bp may be completely blocked until Juno
16:24:37 <david-lyle> enykeev: do you have more you would like to add
16:26:15 <david-lyle> I think we're going to have at least a session around less/css path forward at the summit in Atlanta
16:26:43 <david-lyle> #topic Open Discussion
16:26:46 <enykeev> no, except that i tried to run less.js tests on lesscpy and results were unpleasant. Even if author would be able to make it build, there are probably a bunch of small bugs
16:27:22 <enykeev> link on results is in bp
16:27:27 <david-lyle> enykeev: thanks, seems like we're further away than we thought
16:28:17 * tshirtman waves
16:29:02 <absubram> hi.. sorry am a bit late.. are we in open discussion?
16:29:12 <david-lyle> yeah, go ahead
16:29:39 <absubram> ah ko.. just going through the minutes from earlier on in today's meeting.. see the Feb-18th deadline for BPs
16:29:48 <absubram> this is not mine.. but just wanted to bring this up
16:29:50 <absubram> https://blueprints.launchpad.net/horizon/+spec/neutron-subnet-mode-support
16:30:02 <absubram> one of my teammates at work brought it up
16:30:06 <absubram> I'm new to it myself..
16:30:15 <absubram> there aren't any details at all.. just looking at it
16:30:25 <absubram> but I can help scope out what's there and add stuff into the whiteboard for it
16:31:12 <david-lyle> absubram: that would be great.  At this point it seems unlikely for icehouse as no one has picked it up.
16:31:14 <absubram> looks like there's new IPV6 additions in neutron and they want to reflect those in HOrizon
16:31:17 <amotoki> If it is a small one, it can be handled as a bug. IPv6 support is one of the important topics in neutron.
16:31:32 <absubram> right.. that's what I was afraid of and mentioned as much
16:31:49 <jpich> It doesn't look like it's implemented fully in Neutron yet either
16:31:55 <jrist> jtomasek: do you need help with the bootstrap conversion?
16:31:56 <absubram> but I'll try to add details to the BP at any rate..
16:32:05 <absubram> no it's not..
16:32:10 <absubram> they're still working on it
16:32:24 <amotoki> absubram: can you break down the working items? adding subnet mode is just small but IPv6 support is not small.
16:32:41 <david-lyle> that's late for us to support coming in at the end of i-3
16:33:01 <absubram> amotoki: will do.. will try to add that in within the next day or so
16:33:09 <david-lyle> small pieces could be handled in bugs as amotoki said
16:33:26 <absubram> ok.. at this point I'm not exactly sure what is involved
16:33:28 <david-lyle> but larger scale changes for items landing in i-3 are difficult
16:33:33 <absubram> I'll bring it back up when I find out more
16:33:42 <absubram> david-lyle: got it
16:33:44 <amotoki> I don't have much experince on IPv6, so I would like to kwow what we need to support IPv6.
16:33:47 <david-lyle> absubram: I appreciate you looking into it
16:34:03 <amotoki> it helps horizon folks understand if it is big or small :-)
16:34:20 <absubram> david-lyle: np.. we decided last minute we needed this done haha
16:34:58 <absubram> amotoki: yep.. understand and agree
16:35:06 <jomara> david-lyle: i wanted to modify priority on a couple of the heat BPs - i think topology should be bumped down, and the remaining ones should be bumped up
16:35:39 <david-lyle> jomara: looking
16:36:07 <david-lyle> so the validation goes down?
16:36:15 <jomara> david-lyle: the topology one is a lot "fluffier" than the others
16:36:31 <jomara> validation?
16:36:32 <jomara> one sec
16:36:34 <jomara> ill give you the exact names
16:36:43 <david-lyle> that would help, there are several
16:37:08 <jomara> + heat-stack-detail-resources-column  , +  heat-fix-status-column , +  heat-stack-list-paging,  -  heat-topology-improvements
16:37:20 <absubram> umm additionally.. if there's still time.. on a different issue,.. I'm having a little difficulty figuring out the horizon.membership.js file.. I'll send out an email to the mailer so it can be answered easier.. but was just hoping to figure out how some of the code works in generating the drop down for the member/roles
16:38:35 <jomara> absubram: check out the patch in review for the angularization of that code
16:38:38 <jomara> its quite a bit simpler
16:38:42 <absubram> I need to do something simlar but not exactly the same.. I'm trying to add a drop down with a list of profiles for each network at the time of launching an instance.. but my js just doesn't seem to work :(.. would appreciate a different pair of eyes
16:38:56 <jomara> i woudl recommend you write an angular directive
16:39:22 <absubram> jomara: thanks.. can you give me a pointer to the patch in review please?
16:39:29 <jomara> absubram: yeah one sec
16:39:53 <jomara> https://review.openstack.org/#/c/57456/
16:40:01 <absubram> jomara: thanks a bunch!
16:40:12 <david-lyle> on a general note regarding blueprints, when linking a commit to a blueprint, the blueprint name is the last part of the URL when on that blueprint's page, otherwise, the linking does not happen and is very hard to track.
16:40:18 <david-lyle> s/on/one
16:41:10 <david-lyle> jomara: all the bps you want bumped are on target for i-3?
16:41:25 <david-lyle> or just raised in priority for any release?
16:41:27 <jomara> david-lyle: yeah, but i would suggest topology is questionable
16:41:46 <jomara> its less specific and thus could fill up a lot more time
16:42:52 <jpich> It's usually ok to start small and have the rest as future bp / bugs for enhancements too (<- as a reply to review comments that try to expand the scope ;))
16:42:56 <david-lyle> jomara: the topology is not slated for icehouse, I think we're ok
16:43:06 <jomara> david-lyle: oh, cool :)
16:43:24 <jomara> david-lyle: the rest should be in based on my timeline, though
16:43:52 <david-lyle> jomara: that's great.  Thanks.  I think those will be great improvements/additions
16:44:07 <jomara> np!
16:45:44 <david-lyle> jpich: the integration tests are still WIP is that correct?
16:45:45 <lcheng> hi jomara, I'm planning to work on adding RBAC for heat. Can I bug you later for the devstack config? :-)
16:46:12 <jpich> david-lyle: The test runner theoretically could stand on its own, there's just no useful tests at the moment still
16:46:17 <jomara> lcheng: certainly! i have a working heat on devstack right now
16:46:45 <lcheng> jomara: cool, will ping you later.
16:46:54 <david-lyle> jpich: ok, just checking
16:47:06 <david-lyle> we could do it in pieces as well
16:47:19 <david-lyle> up to you
16:47:35 <jpich> david-lyle: I think so - get the general test running infrastructure in place then add tests forever more
16:47:50 <david-lyle> makes sense
16:48:25 <jpich> david-lyle: I would have liked to showcase a few tests that use the pattern we want to use (Page Object pattern) first - but if there's no progress on that front I'll work on getting the infra pieces well sorted first
16:49:43 <david-lyle> jpich: sure, I agree some sanity tests would help, but let's not miss icehouse because of it :)
16:50:35 <jpich> Yup! Initial piece at https://review.openstack.org/#/c/66012/ if anyone wants to take a peek
16:51:09 <david-lyle> thanks!
16:51:55 <david-lyle> any one have anything else?
16:52:16 <akrivoka> one thing that's been coming up a lot lately is inclusion of exception error message in the user facing UI
16:52:36 <david-lyle> sure
16:52:39 <akrivoka> e.g. https://review.openstack.org/#/c/62026/ https://review.openstack.org/#/c/70158/
16:52:56 <akrivoka> basically, people have tried to improve a vague error mesage by including exception details
16:53:29 <akrivoka> especially for new contributors, that approach seems intuitively like a valid solution (I've been guilty of that myself)
16:54:09 <akrivoka> I wonder if we should make an faq entry in the docs about it, so that we can refer people to it when it comes up
16:54:28 <akrivoka> or maybe add a paragraph about it here http://docs.openstack.org/developer/horizon/ref/exceptions.html
16:54:38 <akrivoka> to explain why it's a bad idea, etc
16:54:49 <david-lyle> akrivoka: that's a great idea
16:55:01 <akrivoka> just wanted to throw it out there and see if you guys have a better idea
16:55:19 <jpich> I don't think this page is meant to be blank
16:55:29 <lblanchard> akrivoka: +1 I think making this error messages clear to users is a huge improvement
16:55:43 <david-lyle> jpich: oops
16:55:54 * jpich files a new bug
16:56:03 <amotoki> regarding error message, personally it is okay to include an error messge from backend services to error message to horizon. it is done in several places already.
16:56:05 <david-lyle> we may want to look into that a bit :)
16:56:32 <david-lyle> amotoki: depends on your audience
16:56:35 <doug-fish2> I can't sort out the concern/question around this yet:  are we talking about getting back translated/displayable error messages from the services when they fail (which would be great), or are we talking about dumping exception details (which is not so great)?
16:56:44 <akrivoka> amotoki: it's been discussed extensively, and the consensus is it is not secure or user friendly to do that
16:57:02 <tshirtman> i think one way to improve things could be to separate "human readable" and "technical" info in errors, and horizon could only show the human readable part by default
16:57:03 <akrivoka> http://lists.openstack.org/pipermail/openstack/2014-January/004651.html
16:57:15 <david-lyle> languages read, understanding of the technology stack.  Essentially we could be sending them "PC LOAD LETTER"
16:57:24 <tshirtman> because users don't read a message if it contains cryptic parts, even if the beggining is perfectly readable
16:57:43 <lblanchard> david-lyle: lol
16:58:20 <david-lyle> The proper approach is to capture the errors and display a translated and rational message related to the error encountered
16:58:40 <lblanchard> Could we translate the messages to be user friendly? E.g: "This instance couldn't be created since it requires 2GB of RAM and your quota is 1GB"?
16:58:43 <doug-fish2> david-lyle: are you saying that should happen in Horizon?
16:58:48 <amotoki> I agree the general concern, but it is case by case.
16:58:56 <amotoki> IMO translation related issue should be addressed separately.
16:59:02 <tshirtman> so horizon has to know about all the potential errors in all openstack projects?
16:59:12 <tshirtman> to translate them smartly
16:59:29 <doug-fish2> tshirtman, yeah that's my concern
16:59:52 <doug-fish2> especially with an extensible architecture, I think that's impossible.
16:59:56 <david-lyle> Sure, it's not scalable, which is why we have generic messages and logging at this point
16:59:57 <tshirtman> yep
17:00:25 <peristeri> david-lyle to capture and display human readable messages we should stop using Exception and use the Exceptions classes provided by the API.
17:00:26 <tshirtman> i think the generic messages should be formed of an human, and a technical part
17:00:37 <lblanchard> Maybe we could push on having a standardized error message format which includes a human readable piece?
17:00:41 <tshirtman> but i guess convincing all the other projects may not be easy ^^
17:00:51 <tshirtman> lblanchard: +#
17:00:54 <tshirtman> lblanchard: +1*
17:00:56 <jpich> Btw while working on Cinder v2 I noticed projects are starting to add "Accept-Locale" to the clients and APIs - so we are going toward becoming able to get error messages in the correct locale
17:01:09 <amotoki> I think error message from backend projects should be human friendly because they are visible through CLI too.
17:01:27 <tshirtman> jpich: oh, that sounds good :)
17:01:36 <david-lyle> CLI users aren't human :)
17:01:49 <lblanchard> lol
17:01:50 <akrivoka> david-lyle: lol :)
17:02:00 <jpich> https://github.com/openstack/cinder/commit/681a898101f81dbe2317a84e4496bd1e000cf527 (That's Accept-Language, sorry)
17:02:11 <tshirtman> if they weren't they wouldn't need error messages at all :P
17:02:49 <jpich> We're over time...
17:03:13 <david-lyle> amotoki: but yes I agree, if we get usable strings back we'll have to make sure they are not harmful and we can display them.
17:03:27 <david-lyle> The solution may find us
17:03:32 <david-lyle> jpich: ack
17:03:39 <jpich> :-)
17:03:41 <david-lyle> Thanks everyone!
17:03:46 <amotoki> Using Accept-Language in API calls raises another problem. we still want english log messages....
17:03:46 <lblanchard> thanks all!!
17:03:47 <david-lyle> #endmeeting