22:02:40 #startmeeting horizon 22:02:41 Meeting started Tue Jul 9 22:02:40 2013 UTC. The chair is gabrielhurley. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:02:42 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:02:44 The meeting name has been set to 'horizon' 22:02:47 #topic overview 22:03:13 Forgive me if I'm a little distracted, I'm also talking to the infra guys about fixing the gate now that we broke it by requiring keystoneclient 0.3.0 22:03:30 :) 22:03:41 hey, np :) 22:06:16 bah 22:06:19 this isn't working... 22:06:23 quick version: 22:06:28 H2 gets cut next week 22:06:35 we need to review review review 22:06:42 Heat landed today, that's awesome 22:07:46 would really like to see Ceilometer get merged ASAP too 22:07:52 #topic blueprints 22:08:06 I'm gonna let y'all give updates, so feel free to just blurt out where things are at 22:09:15 Inline table editing: https://blueprints.launchpad.net/horizon/+spec/inline-table-editing 22:09:16 - I've designed multiple variants and there is ongoing discussions on G+ about visualization 22:09:16 - discussion: https://plus.google.com/u/0/115177641540718537778/posts/HxgHdpmiUcG 22:09:16 - last version of designs: http://people.redhat.com/~jcoufal/openstack/2013-07-08_os-inline_editation.pdf 22:09:16 - feel free to discuss on G+ if you have some feedback for it 22:11:38 still waiting on a review for https://blueprints.launchpad.net/horizon/+spec/domain-context 22:12:38 point of protocol, is there a point where bp's can just get bumped with one +2 after being left unreviewed? 22:12:39 Navigation UX Enhancements: https://blueprints.launchpad.net/horizon/+spec/navigation-enhancement 22:12:39 - newly opened one 22:12:39 - on mailing list, I started 1st phase - gathering issues from all developers 22:12:39 - mailing list thread: http://lists.openstack.org/pipermail/openstack-dev/2013-July/011509.html 22:12:39 - if you have any issue with Horizon's navigation, now is good time to speak up, we will be very happy to get each of your issues reflected in proposed enhancements 22:13:07 jcoufal: thanks for starting that btw 22:13:28 david-lyle: np 22:14:02 david-lyle: I am happy we move forward and there is interest in that issue 22:14:10 o/ 22:14:48 https://blueprints.launchpad.net/horizon/+spec/login-domain-support has been implemented. Gabriel released openstack_auth 1.1.0, and it requires keystoneclient 0.3.0 for the Keystone V3 Auth support. 22:15:23 The requirement for keystoneclient 0.3.0 broke the horizon gating job and keeping gabrielhurley busy in the infra room. :-) 22:16:13 I have something to discuss about openstack_auth, but will leave that under general discussion 22:18:08 Stylesheets breakdown: https://blueprints.launchpad.net/horizon/+spec/css-breakdown 22:18:08 - new blueprint opened&approved for future ("next") milestone which is helping to increase maintainability of stylesheets and improve cooperation in development by splitting one big file into logical parts 22:20:04 david-lyle: generally not recommended. sometimes I abuse my PTL power when I know something's had significant review and there's a deadline looming. 22:20:31 jcoufal: good call on that BP 22:20:41 #topic open discussion 22:20:44 talk freely. lol 22:20:57 gabrielhurley: thanks 22:21:09 that's what I figured. my worry is there aren't a lot of public cloud scale providers looking to Horizon, so topics specific to that aren't popular for review 22:21:37 of course in general reviews are lagging 22:23:29 gabrielhurley: one question regarding openstack_auth library - I am wondering why this is not part of Horizon. We addressed this with bug #1185713 (Focus on the first visible input at Login screen) and if we want to implement clean solution it needs to change the form attributes (HTML5 autofocus works the best). However the form is defined in openstack_auth instead of Horizon itself. Shouldn't it be part of it? 22:23:31 Launchpad bug 1185713 in horizon "When login screen is loaded, put focus on first input field (User Name)" [Low,In progress] https://launchpad.net/bugs/1185713 22:24:55 it certainly would simplify the change process to have it integrated 22:25:04 I was chatting with Daisy and amotoki about translations last week. Daisy (the translation coordinator) was asking why we don't update Transifex automatically, it seems they would prefer it that way. I either am not familiar with the reason, or forgot it 22:25:13 Also there was an interesting question about whether to update from stable or master, and if for stable for how long (e.g. we did a translation update with the first grizzly point release) 22:25:17 uvirtbot: will comment on that bug tomorrow, however there is issue with the "first visible input focus" function, doesn't work well in general use 22:25:17 jcoufal: because it's generically useful 22:25:19 jcoufal: Error: "will" is not a valid command. 22:25:39 the goal is to eventually split out the generic django parts of Horizon from the openstack-specific parts 22:25:55 same reason that the clients are no longer part of their project repos 22:26:08 you shouldn't have to install all of nova to use novaclient 22:26:14 these things are building blocks 22:26:50 ok. And the source is in your github? so that if I want to address the bug, I need to do PR to your repo? 22:27:05 problem is Horizon has to change it to adjust to keystone changes 22:27:25 openstack_auth that is 22:27:38 the coupling is a little tight at this point 22:27:59 david-lyle: has to or wants to? if has to, then that sounds like a bug in keystone/keystoneclient 22:28:42 dolphm: perhaps wants bordering on needs 22:28:46 david-lyle: understood 22:29:42 david-lyle: if I need to do change there (openstack_auth), is Gabriel's github the right place? 22:29:42 but as it stands, it authenticates against a keystone (API compatible) backend 22:30:03 so seems like being part of openstack makes sense 22:31:28 jcoufal: yes 22:31:38 issue a pull request 22:33:18 UX discussing tool: I am sorry for the later answers in mail thread about this topic. Anyway, when conversations about UX are getting bigger, the limitations of G+ starts to flash out. I hope we will not get stuck in discussions about discussions for long and we move forward. Mostly because I feel that UX conversations are suffering by G+ limitations. So... I put together my thoughts about expectations, tried few tools, 22:33:18 and if I can help with moving forward anyhow else, just let me know guys (mordred, or others). 22:33:23 david-lyle: thanks 22:34:37 jcoufal: david-lyle: yes, historically I owned it 'cuz I wrote it and I was the only one that knew anything about it. It allowed me to iterate rapidly. that's no longer the case nor necessary 22:34:44 it's about to be absorbed by openstack 22:34:54 the infra team is working on it currently 22:35:01 gabrielhurley: perfect 22:35:12 who will own it? 22:35:54 it'll be the purview of the Horizon core team 22:36:03 I have the keys to PyPI still, along with openstack-ci 22:36:14 ok, great 22:36:17 it'll just be subject to the gerrit process 22:39:05 so when that happens, are we still blocked on keystone v 0.3+, my understanding from the infra room is yes 22:39:27 yes 22:39:41 it's gonna take another couple days of yelling at the other projects to get this through 22:39:53 it sounds like keystone is the main holdup, but 0.3.1 may fix things for them 22:40:05 ok 22:40:07 no one is entirely sure if there are other projects unable to use a 0.3.x keystoneclient 22:40:46 gabrielhurley: no one else has pursued 0.3.x yet, to my knowledge 22:42:05 (3:39:40 PM) clarkb: I don't think keystone is the only one 22:42:05 (3:41:01 PM) clarkb: gabrielhurley: horizon also explicitly depends on keystoneclient <0.3 22:42:05 (3:41:25 PM) gabrielhurley: clarkb: d'oh! 22:42:28 david-lyle, lcheng: we'll need to fix that 22:43:07 (3:42:17 PM) sdague: python-heatclient/requirements.txt:python-keystoneclient>=0.2,<0.3 22:43:07 (3:42:23 PM) sdague: python-ceilometerclient/requirements.txt:python-keystoneclient>=0.2,<0.3 22:43:07 (3:42:34 PM) sdague: ceilometer/requirements.txt:python-keystoneclient>=0.2,<0.3 22:43:07 (3:42:34 PM) sdague: cinder/requirements.txt:python-keystoneclient>=0.2,<0.3 22:43:07 (3:42:48 PM) sdague: horizon/requirements.txt:python-keystoneclient>=0.2,<0.3 22:43:29 https://review.openstack.org/#/c/36343/ 22:43:36 in review 22:44:09 okay, so basically we need patches to all these projects in order to get to 0.3.x for our purposes 22:44:23 we generally wait until the openstack-auth changes go through before trying to pull it in into Horizon 22:45:22 cinder- https://review.openstack.org/#/c/35844/1 22:45:26 ceilometer- https://review.openstack.org/#/c/35842/ 22:45:42 because the flow is a little nutty right now... openstack-auth -> openstack-requirements -> horizon 22:45:59 :) 22:47:03 It's the same than with any client update, though 22:47:44 true, just convoluted 22:55:08 okay. I think we've mostly got a plan of action now 22:56:23 just to reca:, django-openstack-auth will become part of gerrit and be gated with everything else. for today we're gonna pin to a version of openstack_auth prior to the new client dependency. in the coming days we need to get patches into all the other projects to upgrade to the new keystoneclient. barring any major problems we can still land v3 auth in H2. 22:57:19 On the plus side, breaking everyone actually made this a much faster process. 22:57:35 anyhow. 22:57:37 this week 22:57:40 review review review! 22:57:41 lesson learned break things 22:57:50 we're looking good for H2 as long as we stay on it 22:57:57 fyi, I've just raised this so it has visiblity for h2 https://bugs.launchpad.net/horizon/+bug/1199549 22:58:00 Launchpad bug 1199549 in horizon "Heat stack create fails due to extra password validation" [Undecided,New] 22:58:17 stevebaker: thanks 22:58:47 thanks Gabriel! 22:59:01 set the priorities and such on that bug. If we can fix that this week that'd be great. 22:59:12 anyhow, I think that's it for this meeting 22:59:14 thanks everyone! 22:59:17 #endmeeting