16:02:03 #startmeeting Horizon 16:02:04 Meeting started Tue Mar 18 16:02:03 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:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:07 The meeting name has been set to 'horizon' 16:02:22 Hello everyone 16:02:26 o/ 16:02:29 hello 16:02:29 hi all 16:02:35 hello o/ 16:02:36 Hello! 16:03:01 hi, good night 16:03:11 hi! 16:03:16 hi all 16:04:02 Let's dive in 16:04:06 #topic Icehouse RC1 16:04:16 https://launchpad.net/horizon/+milestone/icehouse-rc1 16:04:40 so many of you may be getting emails that your bug was moved from rc1 to next 16:05:01 this does not mean that it can't go into RC1, it merely means that we can cut RC1 without it 16:05:31 The distinction was pointed out to me this morning 16:06:03 so I will continue to prune the bugs down to items that are blockers to cutting the RC1 branch 16:06:29 questions on that part? 16:06:37 We have two unassinged bugs. 16:06:48 yes those are also bad :) 16:06:49 I can take the fist one. it is related to neutronclient. 16:07:17 david-lyle - I think the mox import bug that I've been bothing people about should be on that list too 16:07:31 other than mentioning it to you know how do we have that discussion? 16:07:57 can you post a link? 16:08:12 https://bugs.launchpad.net/horizon/+bug/1288245 16:08:21 https://review.openstack.org/#/c/79378/ 16:09:05 I think that should be in RC1 16:09:09 I added it 16:09:15 thx 16:09:56 anything else not on the RC1 list that people feel is essential? 16:10:22 for bug 1292937, can anyone familiar with ceilometer take a look at it? 16:10:41 I am not sure it is visible or not. 16:11:23 I assigned someone to take a look 16:11:40 He's been working on ceilometer 16:11:44 in Horizon 16:13:07 I have on item in django-openstack-auth that I need to add. So, I've been pushing to move our default keystone API version to v3. We merge a patch in django_openstack_auth, turns out that although keystone v2 is deprecated, we can't use a v3 token to do anything other than identity management in Horizon 16:13:57 so I'm going to move the default back to v2 for icehouse and we need to address broader support at the summit 16:14:47 I'm tempted to go so far as to disable v3 altogether in Horizon, but I think there may be some groups out there that have hacks in place to make v2 and v3 work 16:15:09 so I'm going to leave it in, and add documentation for the problem 16:15:17 other ideas around that? 16:15:39 Will this disable the ability for a user to change their own password? V3 was required for that right? 16:16:25 I'd have to check that v3 is required, but if so then yes 16:16:56 v3 tokens used to work through a bug in keystoneclient which has since been closed, hence the belief that all was well 16:17:14 afaik, the own password thing works only on v2 16:17:45 because such a support was forgotten or left out of keystone, but I may be wrong here 16:18:10 agree on mrunge, it was the other way around. 16:18:27 change own password? 16:18:37 there is a patch on-going to add to add the change password on keystone v3 in keystoneclient 16:18:39 I don't think that's supported in either unless you are admin 16:18:53 change own password 16:19:45 david-lyle: yes 16:19:57 what you said :-) 16:19:58 david-lyle, it was supported, but led to the cool situation, that you didn't had to provide your old password. keystone didnd't check, if your old password matched 16:20:47 so we (I) disabled that *feature* in horizon in that condition. 16:21:01 need to check, if it was v2 or v3 16:21:02 mrunge for v3 though, correct? 16:21:11 just one. 16:21:15 let me check 16:21:28 looking at code, v2 may support user updating password, was looking at wrong api call before 16:22:11 you can only set your password on v2 16:22:16 https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/settings/password/panel.py 16:22:25 l.31 16:22:36 jthopkin: there we go 16:22:43 awesome, thanks all 16:23:22 Any other issues regarding RC1? 16:24:03 We did merge 4 of the 6 FFE we had, so that's great 16:24:30 :) 16:24:42 what are we doing about the mox thing? 16:25:07 the IPv6 neutron side got merged late last night.. but it essentially added only the attributes.. but they don't do anything.. so good that we moved the Horizon BP to J 16:25:26 mrunge: I agree that we should not depend on mox in a non-dev situation 16:25:39 I added it to RC1 16:25:59 amotoki: do you have anything you want to comment on regarding translation and string freeze? 16:26:34 david-lyle: I18N need to know the planned date of RC1 . 16:26:58 I would like to propose the first import before RC1 but i am not sure when it is better to do. 16:27:12 amotoki: hmm, I don't know a date, I would imagine we have at least a week 16:27:42 I'll work on coming up with a better date 16:27:50 or a date ;) 16:28:36 thanks. the first milestone in i18n team is set to Mar 24 but someone needs more time. 16:29:03 ok, thanks 16:29:19 #topic Design Summit Session Topics 16:29:34 http://summit.openstack.org/ 16:29:47 So only two topics so far 16:30:41 OK, Jacki and I have some ideas. I'll get those into there as well 16:31:04 I have a couple to add: "Node toolchain for development" and "Approach for localized API error messages/logging" 16:31:08 I'd have some ideas in the queue 16:31:36 revisiting the project split might be worth rehashing a bit 16:31:44 We have many gaps in CLI and Horizon. IMO we need to list the gaps and prioritize them in Juno. It is not a session proposal but we need to do it as a project. 16:32:02 sure 16:32:08 better error reporting, separate dashboard, and something like messaging support through marconi would be great 16:32:24 amotoki, great idea! 16:32:35 amotoki, yes, and that should be a session 16:32:37 My other big topic is "A Launch Instance that makes sense/works" 16:32:41 paper and pencil session 16:33:03 amotoki: +1 I've heard users say they don't use Horizon since they have to switch back and forth to CLI…they say "May as well just stick with CLI for now." 16:33:44 amotoki +1 16:33:47 david-lyle: :) We have a lot of feedback from the usability tests on that flow…it will probably be a big topic in the session I proposed too…maybe if you propose one it can be a deeper dive into the code discussion? 16:34:00 ah, and support many users? it seems keystone got support for limiting user lists 16:34:13 something like paging support 16:34:14 lblanchard: A big request I have heard and we've provided some feedback on is the ability to better do capacity management. We've been providing feedback to some of the work lblanchard is doing 16:34:47 david-lyle: We are currently working on an implementation of http://ask-openstackux.rhcloud.com/question/12/enhance-the-selection-of-a-flavor-and-an-image/ 16:35:01 jthopkin: capacity as in number of controllers? 16:35:18 quotas, ? 16:35:20 MaxV: It would be awesome if we could track down some users at summit and do some user testing of the work you've done so far 16:35:24 david-lyle: partially but not controllers specifically 16:35:42 i.e. - who is using all the resources in my cloud and how much hardware will I need in the future 16:35:53 lblanchard: a patch will be released in a few weeks 16:36:04 what does "capacity management" mean? It may be a part of tuskar-ui. 16:36:20 sounds like heat 16:36:23 there's two pieces to it, but it is better understanding how your cloud is being used 16:36:23 MaxV: awesome 16:36:39 MaxV: I'll take a look, and thanks 16:36:43 the ceilometer visualization gives some of that, but it needs to be better implemented 16:36:47 jthopkin: more on the monitoring side of things, right? 16:36:50 yes 16:37:15 problem is OpenStack doesn't have a monitoring solution today 16:37:15 mrunge: really…a better way of visualizing how resources are used 16:37:26 ceilometer is only part of the solution 16:37:54 david-lyle: correct, this wouldn't just be about monitoring (that would be further down the road). More about how my resources are being used and who is using them 16:38:21 sure 16:38:25 http://ask-openstackux.rhcloud.com/question/132/improvements-to-horizon-admin-overview/ 16:38:47 that is the work lblanchard has been doing and jackibauer has also proposed some alternate concepts 16:39:08 we are internally doing something similar too.. to monitor the usage of the hardware resources.. still working on development.. was going to being it up at the summit 16:39:25 as amotoki mentioned.. wasn't sure if it is already addressed in Tuskar? 16:39:47 but would love to learn more about how you guys went about it jthopkin :) 16:39:54 jthopkin: are the other concepts somewhere to review? 16:40:16 lblanchard: yes, Jacki added them in the comments. I'll post them here too. One sec 16:40:26 http://tvpnk4.axshare.com/#p=admin_overview 16:40:26 jthopkin: thanks 16:40:27 http://tvpnk4.axshare.com/#p=admin_overview_-_text 16:40:28 http://tvpnk4.axshare.com/#p=user_overview 16:40:29 http://tvpnk4.axshare.com/#p=user_overview_-_text 16:41:13 We'll need to rework them a bit to conform to the Horizon design pattern though 16:42:07 seems like we have much to talk about :) 16:42:08 anyway, submit your session ideas 16:42:21 jthopkin: very nice though! Thanks for sharing :) 16:42:25 It looks great. Doesn't ceilometer provide such information? If it provides them, all works should be in Horizon side. 16:42:57 amotoki: I believe it does, but I'm working on identifying any gaps 16:43:13 mrunge: what is the status of https://blueprints.launchpad.net/horizon/+spec/separate-horizon-from-dashboard? 16:43:47 I think we're here anyway. 16:43:53 #topic Open Discussion 16:44:59 In the dev list, we heard muranodashboard needs openstack_dashboard release to PyPI. 16:45:11 Can we push the release to PyPI or should we wait for splitting horizon and dashboard? 16:46:33 I think the idea was to autorelease to pypi as a wheel, I'll look into where that is at, otherwise we could probably release it. 16:47:04 I think the stance before was not to release any of the openstack services to PyPi 16:47:41 mostly because just giving someone a nova .tar.gz isn't enough 16:47:55 I see. only client libs are released to PyPI. 16:47:59 Horizon may be a little different in that respect 16:48:16 Something about wheels was supposed to change that policy 16:48:19 let me follow up 16:48:22 I think tarball should work for the case murano team asked. 16:48:41 yes, Horizon is a simpler case for sure 16:52:59 amotoki: saw your email response to Radomir and me.. regarding the ip_version in the EditSubnet class.. thanks.. will respond to the thread.. we won't be able to do away with it because we need it for the IPv6 identification and corresponding v6 fields.. 16:53:54 absubram: thanks for raising it. Such cleanup will be appreciated :) 16:53:57 david-lyle: Should we add Horizon to this list? https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-sessions 16:54:38 * david-lyle reading 16:54:42 glad to help :) 16:55:36 lblanchard: absolutely 16:56:50 david-lyle: cool, I will add 16:57:03 thanks 16:57:47 umm just a review request for https://review.openstack.org/#/c/76653/ https://review.openstack.org/#/c/78708/ and https://review.openstack.org/#/c/76787/ please :) 16:59:50 regarding string freeze, it is just a soft freeze. Please keep on your eyes if a patch changes strings much or not. I believe small changes does not matter. 17:00:05 mrunge: and others (amotoki) thanks for the approval earlier this morning for the head of my dependency list!.. appreciate it 17:00:40 as you've mentioned.. the above reviews I have do have small string changes.. 17:00:48 Thanks everyone! Have a great week. 17:00:53 #endmeeting