20:00:00 #startmeeting horizon 20:00:01 Meeting started Wed Aug 24 20:00:00 2016 UTC and is due to finish in 60 minutes. The chair is robcresswell. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:04 The meeting name has been set to 'horizon' 20:00:37 Anyone around for Horizon meeting? 20:00:38 o/ 20:00:50 o/ 20:02:00 Lets get started 20:02:15 #topic Notices 20:02:34 #info Feature Freeze tomorrow! (2016-08-25) 20:02:45 I've started blocking feature patches 20:03:00 currently all that is open is images, filtering, and django 1.10 compatibility. 20:03:36 Just to see where they can get to in the next 24 hours or so 20:03:36 If anyone would like to apply for an FFE (Feature Freeze Exception) please send an email to the dev mailer for discussion. 20:04:26 o/ 20:04:29 For those going through the release cycle for the first time, we now freeze all feature work and fix bugs until Newton release. 20:04:43 #link https://releases.openstack.org/newton/schedule.html 20:04:54 o/ 20:04:56 There are a couple of important dates to keep in mind 20:06:02 Soft string freeze is the week after feature freeze, with hard string freeze two weeks after that 20:06:14 This is especially important in Horizon given the volume of translatable strings 20:06:33 Please keep this in mind when modifying strings in bugfixes (both contributors and reviewers) 20:06:58 quiet room today... 20:07:28 RC1 target is September 15th, so thats our next major milestone. 20:07:36 lcastell: Well, I'm just talk at people right now :) 20:07:41 talking* 20:07:50 Any questions? 20:08:22 #topic Agenda 20:08:32 #link https://wiki.openstack.org/wiki/Meetings/Horizon#Agenda_for_2016-08-24 20:08:52 #topic Passthrough API 20:08:57 TravT: o/ 20:09:01 yep 20:09:02 so, 20:09:15 tyr is working on the designate panel for newton 20:09:28 it is being converted to v2 designate (v1 is deprecated) 20:09:34 and it is angular 20:10:03 he found that the horizon python layers aren't providing him value right now 20:10:38 services that use CORS now can get the token from horizon 20:10:46 this was put in by kevin fox 20:10:50 and discussed on the mailing list 20:11:09 which allows the client side to form API requests and talk directly to the service. 20:11:14 if CORS is enabled 20:11:26 if not, it proxies via horizon ? 20:11:40 great lead in ducttape_ 20:11:52 if CORS is not enabled, they'd have to still go through horizon 20:12:16 and this patch allows that to happen without a bunch of massaging 20:12:23 TravT: the Horizon wrappers still do things like version negotiation 20:12:31 that's true and is fine 20:12:37 like in case of Glance v1/v2 20:12:39 but in this case, we don't care or use those. 20:12:59 all the logic is in js, sounds like, including version switches 20:13:13 the horizon wrapper layers are their own layers of indirection 20:13:42 for new panels or code that prefers to send api requests formulated by the JS code 20:13:55 the horizon wrapper code just means double the work 20:14:01 if CORS is enabled vs not enabled 20:14:52 so, this is proposing to put this patch in. 20:15:09 To me it Seems like clientside horizon needs to be split from its server counterpatt 20:15:11 it won't force glance v1 /v2 cinder v.x to move to it 20:15:16 the patch is a api passthrough, then 20:15:28 but for plugins that do want the ability to passthrough, they can use this. 20:15:36 instead of implementing it on their own. 20:16:06 tsufiev: - the move is to eliminate horizon server side, it would seem 20:16:14 ducttape_: yes 20:16:15 just a small passthrough 20:16:21 In the long term 20:16:41 i suspect that is a very long term. 20:16:55 I was looking in a future too far, maybe :) 20:17:11 it seems sensible to me 20:17:26 the patch itself is ~200 lines 20:17:51 Will look into it this week 20:17:52 the passthrough is all services? or just for designate 20:18:00 that's a good question. 20:18:03 one i've pondered 20:18:26 so this one would allow passthrough to any service 20:18:38 if it's all services, then you could just split all the python code out 20:18:52 most I mean 20:18:56 #link https://review.openstack.org/#/c/357600 20:19:20 if security is a concern, possibly it could be agumented to force base url passthrough to a specific service's public endpoint and only enabled services via config could be "passed through" 20:20:00 so we're becoming an open attach vector? 20:20:24 there are a couple of things to figure out / more detail I'd think 20:21:03 i think we'd probably have to do something like the above. 20:21:05 like public_url might not be appropriate, does horizon have some responsiblity to do policy enforcement etc 20:21:39 client side API requests already have policy checks when required. 20:21:53 policy is sprinkled around 20:21:55 I dont know that it would affect policy, since most of that is done in the UI, not the API layer 20:22:02 so, "horizon" is really whoever writes the code 20:22:03 you're basically passing any request to any url from an internal network 20:22:15 david-lyle: yes, that is why i brought that up 20:22:31 right, and policy is missing in this case 20:22:36 i'm not saying this should go in as-is. but bringing up the concept 20:22:44 policy on the client means very little, in this case 20:23:02 you will note 20:23:03 yep, we are just floating ideas 20:23:05 line 71 here 20:23:06 https://review.openstack.org/#/c/357600/7/openstack_dashboard/api/rest/passthrough.py 20:23:21 it already is doing some base url lookup 20:23:22 TravT, ok, multistreaming ,so missing bits 20:23:39 but configuring which services can be allowed access is not in here 20:23:56 TravT - you will want the url type to be configurable 20:24:03 ducttape_: agreed 20:24:04 do not assume public url 20:25:14 seems like it would need some dict setting mapping service requested to a policy and to the endpoint type 20:25:17 I don't have a problem with the concept. A lot of the REST APIs are basically just passing data through multiple python functions 20:26:55 basically, if this goes into horizon this release, the designate panel being released will use it 20:26:59 should you do token validation too for each call? 20:27:14 This release? 20:27:34 just to filter out tokens that are no longer valid, that is / filter out junk without impacting services 20:27:45 so, i need to actually read through the patch further myself. 20:27:50 i'm just representing the concept 20:28:28 I don't think we should be looking to do this for this release. The initial patch went up 4 days ago, and there's a lot of questions 20:28:36 for searchlight we already do this, but just for searchlight. it is in the searchlight plugin 20:29:03 Plus, the API layers are a bit verbose, but as far as I can tell other than it being a couple hundred lines of code its not a big problem. 20:29:43 this will mean that the new designate panel will have a version of this patch, but just for designate. 20:29:44 FYI 20:29:57 inside of its plugin 20:30:46 Yeah, thats fine with me. I don't have any desire to jump this to the top of the pile. Its useful, but its really just a code cleanup rather than bug fix or performance enhancement, from what I can see. 20:31:32 well, it would be good to get eyes on it and feedback. like ducttape_'s policy concern 20:31:43 Sure 20:32:45 Ready to move on? 20:33:02 i don't have much more to say now. tyr is out today, but if he really thinks we need it this release he'll follow up. 20:33:16 Cool, sounds good 20:33:26 thanks for raising that TravT 20:34:05 #topic Summit Session Planning 20:34:33 So the summit room planning is underway 20:35:11 Everyone has been asked to reduce room ask, as its a 4 day summit and the tent continues to be bigger 20:35:34 * ducttape_ wonders when we started having meetings in tents 20:35:42 lol 20:35:54 For reference, last cycle we had 1 fishbowl, 7 working room sessions, and the contrib meetup 20:36:11 digital nomads, digital tents 20:36:20 I was considering a 1fb, 5wr, and the contributor meetup as a reasonable request. 20:37:00 My feeling being that priorities seem relatively clear, and that we don't need that many working sessions to debate what to solve. 20:37:11 Any thoughts? 20:37:35 I would vote for less than past for sure 20:37:58 maybe not even 5 wr? 20:38:12 On another note, if anyone is considering standing for PTL, please ping me so that I can forward the summit planning emails on to include you :) 20:38:31 I nominate david-lyle 20:38:34 ;) 20:38:39 :) 20:38:47 * david-lyle runs screaming 20:39:00 robcresswell are you implying that you may not? 20:39:10 but robcresswell should totally still do it, it's really its own reward 20:39:12 * ducttape_ doesn't like david-lyle, looking for punishment 20:39:27 david-lyle: Yeah, the working rooms is the bit I'm most uncertain about. I'd like to keep the meetup and use fishbowl for feedback session again. 20:39:50 TravT: I'm planning on standing again, but I'd like to keep it open. 20:39:57 the contributors meetup has a max of 1/2 day this time 20:40:00 i believe. 20:40:25 agree w working room stuff. those are fluid things that happen anywhere 20:40:28 Yep, it does. We had a half day last time too. 20:40:32 TravT: that is correct. the second half of friday, the first half is sessions 20:41:11 I'll request 5 and add a note that we can be flexible if another project has greater demand. 20:42:13 #topic Open Discussion 20:42:59 If anyone has any general queries, bugs, terrible dad-jokes (ducttape_) , fire away 20:43:05 :) 20:43:14 quotas are almost less terrible again 20:43:21 TravT: since today you're on behalf of tyr, could you please ask him to review a patch on behalf of us )? 20:43:38 https://review.openstack.org/#/c/359850/ 20:43:40 sure 20:44:18 I had another feature idea, around instant grant access to project, and switch to that project 20:44:33 Seems i fixed weird things taht kzaitsev_mb was experiencing, but still don't understand why 20:44:35 would help us out, I see it as generally useful to operators 20:45:03 yeah, we need tyr and hurgleburgler to look at that patch 20:45:14 ducttape_: we're currently discussing an idea to push qouta limits to keystone 20:45:24 I'm not convinved entirely by just shifting that theme key around. It seems like it might be fixing the symptoms, not the cause. 20:45:31 (yet internally) 20:45:49 tsufiev: that will take years to work out. I need stuff 6 months ago 20:46:44 duly noted 20:47:23 redoing where quotas live would be a huge migration, I'm skeptical at best 20:47:31 robcresswell: the cause is that don't understand django-compressor well enough ;p 20:48:16 i mean, all we except hurgleburgler and tyr 20:48:22 tsufiev: Yes. I'll have a go recreating that bug tomorrow, didnt manage attempt no. 3 today 20:48:29 tsufiev: the issue does not reproduce if you use offline compression, since THEME var would be set then 20:48:39 and devstack hardcodes offline compression 20:48:53 so we never saw the bug in any of our dsvm tests 20:49:03 kzaitsev_mb: I run with compression off in dev all the time 20:49:14 That's still a mystery to me, kzaitsev_mb 20:49:15 kzaitsev_mb: Still haven't seen it 20:49:33 I dont understand why that would alter the presence of that key anyway 20:50:13 well, honestly I'm devising that from hurgleburgler's comment on offline compression and my quick test with it 20:50:36 ducttape_: the proposal to move quota limits originated during discussing how to implement domain quotas 20:50:53 Keystone seemed quite a logical place for it 20:51:05 sure, but it's an idea that doesn't have a large team signed up for it, migration, etc 20:51:19 it seems like it is just idea phase 20:51:27 yeah 20:51:29 and thats fine, but I need to run stuff right now 20:51:47 which has been broken for a while, or at least not quite right 20:51:50 quota suicide squad ;) 20:52:16 I'd rather watch that movie than work on quotas, which is a sad statement 20:52:34 it's not such bad ;) 20:53:14 ducttape_: Are there specific patches you're referring to right now? I know there's a couple bouncing around, but wasnt sure any were at the ready to go phase. 20:53:15 anyone grok my instance project switcher idea ? 20:53:55 https://review.openstack.org/#/c/309204/ is the orig quotas patch, which we need, but it seems like we need to redo all the quotas first 20:54:12 that is the patch I need, not the we in the room 20:54:55 I see 20:55:05 robcresswell: if you want, I can write a short shell script, that reproduces the error for me on clean checkout 20:55:12 also sorry for hijacking the meeting 20:55:16 So, we have small improvement vs total rewrite 20:55:29 kzaitsev_mb: I think tsufiev posted his steps earlier, so I can use those 20:55:30 it's like throwing a man into space - you need more than just a man in a spacesuit, ducttape_ ;) 20:55:36 no worries kzaitsev_mb, I bet this issue is real. compressor stuff needs more docs / understanding 20:56:56 robcresswell: small improvement featurewise vs degradation of a codebase 20:57:45 not mentioning that this part had degraded years ago 20:57:57 was it ever really great, then ? 20:58:06 make-quotas-great-once 20:58:40 Maybe, it was - when it was in 'an idea phase' :) 20:58:48 I dont think we should be piling on to poor code. Its asking for trouble. 20:58:59 k. I'm kinda excited about this project switcher thing. will take it into horizon room / almost out of time 20:59:23 I'd rather we hold feature development and fix/rewrite than just keep adding small features in an unmaintainable way 20:59:42 We're at time, lets continue in #openstack-horizon 20:59:46 thanks everyone! 20:59:56 #endmeeting