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