16:01:06 #startmeeting Horizon 16:01:07 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:10 The meeting name has been set to 'horizon' 16:01:15 Hello everyone 16:01:21 hi all 16:01:32 hello o/ 16:01:33 hi everyone 16:01:47 hi 16:01:52 greetings 16:01:54 hey 16:01:56 hey 16:02:10 hello 16:03:11 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 o/ 16:03:52 awesome :) 16:03:59 #topic https://launchpad.net/horizon/+milestone/icehouse-3 16:04:28 hello! 16:04:33 o/ 16:04:47 lots of bps up for review right now. 16:05:08 I think we're looking all right heading into a soft-freeze on Feb 18 16:05:39 the RBAC support is still making progress 16:06:13 david-lyle: I started testing the navigation patch, very nice! 16:06:36 david-lyle - can you share briefly what you mean by "soft-freeze"? What things should we start excluding on the 18th? 16:06:50 jpich: my css could use some help :) 16:06:57 taking another pass 16:07:47 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 ok that helps. thanks! 16:08:16 I've stated before that I would be open to exceptions beyond that on a case by case basis 16:08:26 david-lyle - would that include bugs? or are you thinking of blueprints? 16:08:33 just bps 16:08:39 k great. 16:08:41 bug fixes are outside of that 16:08:42 i see. "soft-freeze" means Feature proposed deadline. 16:08:57 amotoki: yes, but with the code 16:09:15 we'll always fix bugs 16:09:51 until there aren't any left 16:09:57 :-) 16:10:00 ... :-) 16:10:11 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 bug fixes still happen then too during the release candidate phases 16:11:37 do we have any concept of fixing only high priority bugs during RC phases? 16:11:57 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 doug-fish2: Yes. There's a stabilisation period between feature freeze and the first RC though 16:12:11 so look for that today or tomorrow as well 16:13:05 amotoki: are you able to handle the translation patches again? 16:13:15 as we near the end 16:13:37 david-lyle: no. daisy is porposing jenkins job patch, but she is in chinese vacation. 16:13:57 ok, so it will be automated this time around? 16:14:05 The patch: https://review.openstack.org/#/c/68042/ 16:14:08 i hope so. 16:14:13 Hopefully 16:14:14 +1 16:14:38 ok, I'll keep an eye on that, thanks 16:15:22 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 one fixes keystone v3 auth issues 16:15:56 https://review.openstack.org/#/c/70479/ 16:16:14 as well as moves the default API version to v3 as v2.0 is now deprecated 16:16:42 the seconds is around django 1.6 support finalization https://review.openstack.org/#/c/70798/ 16:17:00 but that will require an openstack/requirements change 16:17:31 is there any reason not to allow Django 1.6 at this point in Horizon 16:17:44 I think this needs to be in for icehouse 16:18:01 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 jpich: I plan on posting one, but it will fail until the requirements patch lands (which I need to post too) 16:19:24 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 jpich: I see, we could do that separately sure 16:20:02 and follow on with the requirements bump 16:20:11 sure I'll do that 16:21:18 those were my main concerns around i-3, anyone else? before we jump to Open 16:21:25 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 jpich: thanks, will do 16:22:33 Ah, I do have one more i-3 item... 16:23:03 the bootstrap update bp https://blueprints.launchpad.net/horizon/+spec/bootstrap-update 16:23:54 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 so this bp may be completely blocked until Juno 16:24:37 enykeev: do you have more you would like to add 16:26:15 I think we're going to have at least a session around less/css path forward at the summit in Atlanta 16:26:43 #topic Open Discussion 16:26:46 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 link on results is in bp 16:27:27 enykeev: thanks, seems like we're further away than we thought 16:28:17 * tshirtman waves 16:29:02 hi.. sorry am a bit late.. are we in open discussion? 16:29:12 yeah, go ahead 16:29:39 ah ko.. just going through the minutes from earlier on in today's meeting.. see the Feb-18th deadline for BPs 16:29:48 this is not mine.. but just wanted to bring this up 16:29:50 https://blueprints.launchpad.net/horizon/+spec/neutron-subnet-mode-support 16:30:02 one of my teammates at work brought it up 16:30:06 I'm new to it myself.. 16:30:15 there aren't any details at all.. just looking at it 16:30:25 but I can help scope out what's there and add stuff into the whiteboard for it 16:31:12 absubram: that would be great. At this point it seems unlikely for icehouse as no one has picked it up. 16:31:14 looks like there's new IPV6 additions in neutron and they want to reflect those in HOrizon 16:31:17 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 right.. that's what I was afraid of and mentioned as much 16:31:49 It doesn't look like it's implemented fully in Neutron yet either 16:31:55 jtomasek: do you need help with the bootstrap conversion? 16:31:56 but I'll try to add details to the BP at any rate.. 16:32:05 no it's not.. 16:32:10 they're still working on it 16:32:24 absubram: can you break down the working items? adding subnet mode is just small but IPv6 support is not small. 16:32:41 that's late for us to support coming in at the end of i-3 16:33:01 amotoki: will do.. will try to add that in within the next day or so 16:33:09 small pieces could be handled in bugs as amotoki said 16:33:26 ok.. at this point I'm not exactly sure what is involved 16:33:28 but larger scale changes for items landing in i-3 are difficult 16:33:33 I'll bring it back up when I find out more 16:33:42 david-lyle: got it 16:33:44 I don't have much experince on IPv6, so I would like to kwow what we need to support IPv6. 16:33:47 absubram: I appreciate you looking into it 16:34:03 it helps horizon folks understand if it is big or small :-) 16:34:20 david-lyle: np.. we decided last minute we needed this done haha 16:34:58 amotoki: yep.. understand and agree 16:35:06 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 jomara: looking 16:36:07 so the validation goes down? 16:36:15 david-lyle: the topology one is a lot "fluffier" than the others 16:36:31 validation? 16:36:32 one sec 16:36:34 ill give you the exact names 16:36:43 that would help, there are several 16:37:08 + heat-stack-detail-resources-column , + heat-fix-status-column , + heat-stack-list-paging, - heat-topology-improvements 16:37:20 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 absubram: check out the patch in review for the angularization of that code 16:38:38 its quite a bit simpler 16:38:42 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 i woudl recommend you write an angular directive 16:39:22 jomara: thanks.. can you give me a pointer to the patch in review please? 16:39:29 absubram: yeah one sec 16:39:53 https://review.openstack.org/#/c/57456/ 16:40:01 jomara: thanks a bunch! 16:40:12 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 s/on/one 16:41:10 jomara: all the bps you want bumped are on target for i-3? 16:41:25 or just raised in priority for any release? 16:41:27 david-lyle: yeah, but i would suggest topology is questionable 16:41:46 its less specific and thus could fill up a lot more time 16:42:52 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 jomara: the topology is not slated for icehouse, I think we're ok 16:43:06 david-lyle: oh, cool :) 16:43:24 david-lyle: the rest should be in based on my timeline, though 16:43:52 jomara: that's great. Thanks. I think those will be great improvements/additions 16:44:07 np! 16:45:44 jpich: the integration tests are still WIP is that correct? 16:45:45 hi jomara, I'm planning to work on adding RBAC for heat. Can I bug you later for the devstack config? :-) 16:46:12 david-lyle: The test runner theoretically could stand on its own, there's just no useful tests at the moment still 16:46:17 lcheng: certainly! i have a working heat on devstack right now 16:46:45 jomara: cool, will ping you later. 16:46:54 jpich: ok, just checking 16:47:06 we could do it in pieces as well 16:47:19 up to you 16:47:35 david-lyle: I think so - get the general test running infrastructure in place then add tests forever more 16:47:50 makes sense 16:48:25 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 jpich: sure, I agree some sanity tests would help, but let's not miss icehouse because of it :) 16:50:35 Yup! Initial piece at https://review.openstack.org/#/c/66012/ if anyone wants to take a peek 16:51:09 thanks! 16:51:55 any one have anything else? 16:52:16 one thing that's been coming up a lot lately is inclusion of exception error message in the user facing UI 16:52:36 sure 16:52:39 e.g. https://review.openstack.org/#/c/62026/ https://review.openstack.org/#/c/70158/ 16:52:56 basically, people have tried to improve a vague error mesage by including exception details 16:53:29 especially for new contributors, that approach seems intuitively like a valid solution (I've been guilty of that myself) 16:54:09 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 or maybe add a paragraph about it here http://docs.openstack.org/developer/horizon/ref/exceptions.html 16:54:38 to explain why it's a bad idea, etc 16:54:49 akrivoka: that's a great idea 16:55:01 just wanted to throw it out there and see if you guys have a better idea 16:55:19 I don't think this page is meant to be blank 16:55:29 akrivoka: +1 I think making this error messages clear to users is a huge improvement 16:55:43 jpich: oops 16:55:54 * jpich files a new bug 16:56:03 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 we may want to look into that a bit :) 16:56:32 amotoki: depends on your audience 16:56:35 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 amotoki: it's been discussed extensively, and the consensus is it is not secure or user friendly to do that 16:57:02 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 http://lists.openstack.org/pipermail/openstack/2014-January/004651.html 16:57:15 languages read, understanding of the technology stack. Essentially we could be sending them "PC LOAD LETTER" 16:57:24 because users don't read a message if it contains cryptic parts, even if the beggining is perfectly readable 16:57:43 david-lyle: lol 16:58:20 The proper approach is to capture the errors and display a translated and rational message related to the error encountered 16:58:40 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 david-lyle: are you saying that should happen in Horizon? 16:58:48 I agree the general concern, but it is case by case. 16:58:56 IMO translation related issue should be addressed separately. 16:59:02 so horizon has to know about all the potential errors in all openstack projects? 16:59:12 to translate them smartly 16:59:29 tshirtman, yeah that's my concern 16:59:52 especially with an extensible architecture, I think that's impossible. 16:59:56 Sure, it's not scalable, which is why we have generic messages and logging at this point 16:59:57 yep 17:00:25 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 i think the generic messages should be formed of an human, and a technical part 17:00:37 Maybe we could push on having a standardized error message format which includes a human readable piece? 17:00:41 but i guess convincing all the other projects may not be easy ^^ 17:00:51 lblanchard: +# 17:00:54 lblanchard: +1* 17:00:56 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 I think error message from backend projects should be human friendly because they are visible through CLI too. 17:01:27 jpich: oh, that sounds good :) 17:01:36 CLI users aren't human :) 17:01:49 lol 17:01:50 david-lyle: lol :) 17:02:00 https://github.com/openstack/cinder/commit/681a898101f81dbe2317a84e4496bd1e000cf527 (That's Accept-Language, sorry) 17:02:11 if they weren't they wouldn't need error messages at all :P 17:02:49 We're over time... 17:03:13 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 The solution may find us 17:03:32 jpich: ack 17:03:39 :-) 17:03:41 Thanks everyone! 17:03:46 Using Accept-Language in API calls raises another problem. we still want english log messages.... 17:03:46 thanks all!! 17:03:47 #endmeeting