22:01:24 #startmeeting Horizon 22:01:25 Meeting started Tue Oct 15 22:01:24 2013 UTC and is due to finish in 60 minutes. The chair is david-lyle_. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:01:26 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:01:28 The meeting name has been set to 'horizon' 22:01:32 hello 22:01:42 Hello everyone 22:01:44 _o/ hey folks 22:01:46 Hello! 22:01:46 hello 22:01:59 hello 22:02:10 I'll just really quickly lay out the official business: Horizon RC2 was cut as of last night/this morning, and that looks to be the final candidate. Unless an exceptionally critical bug comes up before Thursday that's when the stable/havana branches will be cut and Havana is officially done! 22:02:36 Havana is an excellent release and everyone should feel proud of it. 22:02:45 Yay 22:02:59 \o/ 22:03:10 that's basically all I had, and I have to shift my focus now. I'll try and keep an eye out on IRC here, but david-lyle take it away! :-) 22:03:36 \m/ 22:03:56 ok, I just wanted to thank everyone for the last minute work on RC2 to get the final issues out the door 22:04:49 Note that there is https://bugs.launchpad.net/horizon/+bug/1239896 which was reported against the milestone-proposed branch 22:04:49 #topic bugs 22:04:50 Launchpad bug 1239896 in horizon "Launching Instance Boot from image (creates a new volume)" [High,Triaged] 22:05:09 That works under that topic too :) 22:05:14 ha 22:06:07 I marked it as backport-proposal rather than as rc-potential for a RC3 since IMO it's not the critical path, nor a regression since (AFAICT?) it was a new feature added during Havana... We're very close to the release date at this point 22:06:40 I agree that particular case shouldn't be enough for an RC 22:06:56 legacy main path still works 22:07:21 Cool. Hopefully we get it fixed soon and can backport it for the first stable point release 22:07:42 That would be great 22:08:14 Any other bugs concerning the RC that anyone wants to call attention to? 22:09:06 @jpich I tried reproducing the bug, aside from the rendering of the table error the instance creation was also failing. This might take some time to fix. 22:09:56 Ok, since I don't have an agenda... :) 22:10:02 #topic Open Discussion 22:10:04 lcheng: Ah, ok. Thank you! I reproduced but didn't look into how to fix, I was hoping it may simply be the table display demanding an image_id 22:10:24 haha 22:10:25 Hi, can anyone provide any guidance to move forward with blueprint horizon-routerrules 22:10:51 ktbenton: last I looked it was being actively reviewed 22:11:02 can you give a link? 22:11:04 Link? 22:11:33 https://blueprints.launchpad.net/horizon/+spec/horizon-routerrules 22:11:42 here is the gerrit review 22:11:43 https://review.openstack.org/#/c/35528/ 22:11:55 jpich: I was hoping that too when I saw the bug. :) I'll try to spend a bit more time on it. 22:12:01 I think we just need more core reviewers 22:12:27 very actively reviewed :) I'll take a look this evening 22:13:01 david-lyle_: thanks, that will be very helpful 22:13:27 lcheng: Great! Thank you. Keep us posted :) 22:13:48 ktbenton: thanks for sticking with the changes 22:14:40 I was hoping to ask about the summit and how many design sessions there are for Horizon - gabrielhurley, if you're around, do you know? Does anyone else? 22:14:59 jpich: I believe we are allocated 8 sessions, and currently we have 8 proposals... 22:14:59 I though he said 7 22:15:04 oops 22:15:21 Close enough :) Thanks, gabrielhurley, david-lyle 22:15:27 actually, I think we have 9 proposed now 22:15:40 but 8 slots is what summit.openstack.org shows me for "available" 22:16:17 It doesn't look like anyone proposed any integration session for/with new projects this time around 22:16:50 jpich: incubated projects? 22:17:03 There is one for UX 22:17:14 and it is connected a bit to one update I have here 22:18:17 UX community has officially proposed new separate OpenStack program for the whole user experience 22:18:29 you can see more details here: http://lists.openstack.org/pipermail/openstack-dev/2013-October/016571.html 22:18:32 david-lyle_: Yeah, I found these sessions really really interesting last time. I guess we already have Trove in, and Savana also already has their dashboard project on stackforge 22:18:47 jcoufal: Great :D 22:19:13 jpich: designate also has some preliminary Horizon work as does Tuskar 22:19:18 jcoufal: +1 22:19:27 just smaller mistakes - it's not incubation application, it's program proposal, was corrected in the thread 2 mails later :) 22:20:05 jpich: There is also expected to be one session for Tuskar UI and it might include part of Horizon integration 22:20:16 but it should be under TripleO project 22:20:18 jcoufal: Oh, that'd be neat! 22:20:27 any Tuskar folks wanting to demo? talk integration? could be part of the IA session 22:20:51 since it is a bit of an odd-ball as far as the current IA is concerned 22:21:15 david-lyle_: I think we can cover the integration with Tuskar in Horizon IA slot and the TripleO slot for Tuskar UI 22:21:54 jcoufal, +1 22:22:20 jcoufal: I didn't realize there was a TripleO session regarding Tuskar UI, we'll crash that :) 22:22:56 but I do think it ties into the IA talk well 22:22:58 david-lyle: not officially proposed yet, I am putting a concept together in these days :) 22:23:30 david-lyle there will be also tuskar-ui and tripleo demo :-) 22:24:16 I look forward to it 22:24:39 * lsmola_ working even harder now 22:24:51 Another short update from UX point of view, since we discussed it here last time 22:25:17 jcoufal: any update on an IA proposal? or do we start at the summit and build from there? 22:25:40 askbot for ux related discussions is up on special temporary openshift account 22:25:50 it just needs few customizations and it can go out 22:25:59 jcoufal: +1 on both 22:26:17 david-lyle_: regarding the IA 22:26:21 jcoufal: Looking forward to it :) 22:26:51 I definitely want to sent something out at least one week before the summit 22:27:18 so everybody can put their heads around the issue and think about some other approaches or how to improve that 22:28:10 still trying to put together first draft of options with couple of people who are interested in 22:28:47 thanks jcoufal, I think it will help to let people bring ideas rather than just reactions 22:29:00 definitely 22:29:16 if there is anybody who want to jump in into brainstorming, he is definitely welcome 22:29:41 I will start some thread about that in UX group so you can follow the discussion there 22:30:16 great 22:31:40 kspear: are you here? 22:31:55 david-lyle_: o/ 22:32:33 any thoughts on policy checks... project scope and default rules that check project ownership? 22:33:40 not sure how to address that, other than a rather vacuous check 22:33:56 ah i neglected your review 22:34:08 well, just in general 22:34:39 I don't feel neglected, just hoping for some insight :) 22:34:40 my main concern is getting away from the "admin or nothing" state of permissions 22:34:59 well, role checks will still work too 22:35:00 we have some more complicated rules in our deployment 22:35:38 i thought the idea was to replace the role checks? 22:35:56 eventually... 22:36:18 well role grants are how you define user capabilities 22:36:42 not just admin and member, but operator defined roles 22:37:07 domain_admininstrator for instance 22:37:21 wow, spelled the heck out of that 22:37:35 haha 22:38:13 we likewise have a ProjectManager role 22:38:48 the operator updates their policy file to check for that role, then the policy engine validates that role is in the user's token 22:39:55 i guess the current issue is where we talk about target policies 22:40:24 yes, because the services have a different frame of reference than Horizon does 22:40:25 so one of our policies is that a ProjectManager can add a certain role (target) to a user 22:41:28 so the target would be {role:} 22:41:44 ah, I see 22:41:52 something like that. keystone has just added support for this 22:42:02 we're still running based on custom patches to keystone v2 api 22:42:16 but the idea would be to support this through policy definitions only 22:42:56 I agree, that's the goal, but you installation would have to alter the policy.json files 22:44:06 that's fine. for v2 we needed to create specific code checkpoints that hardcoded a policy name. v3 allows more flexibility than that 22:44:06 let me think about it and I'll see if what we have works for that, because I think your example of a target may be different 22:45:05 my example might be a little contrived, since there are other limitations in the system that interfere with what i want to do with this 22:45:28 another example i had was a deployment where users shared tenants 22:45:52 but each user could only modify objects that they own explicitly 22:46:01 e.g., instances they created 22:46:12 this would be a target user_id check 22:46:48 where do we get the user_id from? 22:46:54 the instance object 22:47:05 one side of the check needs to be hardcoded 22:48:53 ok, I'll hit ping you offline 22:48:58 s/hit// 22:49:20 david-lyle_: sure 22:49:31 david-lyle_: :) 22:49:45 anyone else still around and have anything to raise? 22:50:08 * david-lyle_ takes wide detour 22:50:18 * kspear grins 22:52:22 Alright, Havana's seemingly in the bag, time to focus on Icehouse. 22:52:42 #endmeeting