20:00:01 <david-lyle> #startmeeting Horizon
20:00:02 <openstack> Meeting started Wed Dec  3 20:00:01 2014 UTC and is due to finish in 60 minutes.  The chair is david-lyle. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:06 <openstack> The meeting name has been set to 'horizon'
20:00:12 <david-lyle> did anyone make the new time?
20:00:24 <mrunge> morning
20:00:29 <rbertram> hey
20:00:29 <TravT> Hello!
20:00:33 <neillc> I did :)
20:00:33 <r1chardj0n3s> hi david-lyle :)
20:00:34 <mrunge> and no, nobody made it ;-)
20:00:51 <r1chardj0n3s> coffee's on the stove :)
20:00:58 <rbertram> r1chardj0n3s is on a bit earlier than usual
20:01:00 <mrunge> anybody tea?
20:01:02 <clu_> hi!
20:01:04 <lhcheng> o/
20:01:15 <clu_> (not looking forward to waking up at 4 am next week ;p)
20:01:16 <david-lyle> let a few more roll in
20:01:40 <TravT> mrunge: I'll take some.
20:02:38 <david-lyle> I see tqtran is still good with time
20:02:57 <david-lyle> alright, let's get rolling
20:03:40 <david-lyle> First a general announcement, I've heard back from a majority of cores and would like to formally welcome Thai and Cindy to horizon-core
20:03:53 <david-lyle> Thank you for all your efforts!
20:03:59 <r1chardj0n3s> \o/
20:04:04 <clu_> thanks david-lyle!
20:04:09 <neillc> congrats Thai and Cindy!
20:04:14 <doug-fish> congrats clu_ and Thai!
20:04:16 <clu_> i'm accepting on behalf of tqtran because he's traveling right now :)
20:04:18 <TravT> Congratulations!
20:04:27 <rbertram> congrats!
20:04:29 <asahlin> Congrats!
20:04:34 <lhcheng> congrats!
20:05:04 <david-lyle> I'll make all the appropriate group, role, list, etc changes in the next day or so
20:05:28 <clu_> :)
20:06:10 <david-lyle> Beyond that, I still have a stable branch liaison slot open for the #link https://wiki.openstack.org/wiki/CrossProjectLiaisons
20:06:22 <david-lyle> I and many others were thinking mrunge you might be interested
20:06:31 <david-lyle> do you have time and interest
20:06:40 <mrunge> heh
20:06:42 <david-lyle> and what it entails, I don't full know
20:06:46 <mrunge> yes, I can do that
20:07:06 <david-lyle> can you pencil yourself in on the wiki page please?
20:07:12 <david-lyle> and thank you
20:07:29 <david-lyle> I think you're the only other stable team member we have on Horizon, so it makes sense
20:07:30 <mrunge> david-lyle, yes, will do that
20:07:57 <david-lyle> Beyond that, Kilo-1 is on Dec 18
20:08:21 <david-lyle> #link https://launchpad.net/horizon/+milestone/kilo-1
20:08:52 <david-lyle> I think everything is on track, except maybe the split
20:09:05 <david-lyle> but I think we have an agenda item to dig into that in a bit
20:09:13 <mrunge> yes, exactly
20:09:20 <david-lyle> so we'll hold off on diving in yet
20:09:23 <r1chardj0n3s> we still haven't settled on a colour
20:10:22 <david-lyle> it will only take approx 90 emails to narrow it down
20:10:32 <david-lyle> want to start that one too r1chardj0n3s?
20:10:46 <r1chardj0n3s> david-lyle: for k-1, I think tqtran wanted to try to get the identity rework in
20:11:14 <david-lyle> r1chardj0n3s: doesn't it involve new dependencies?
20:11:29 <r1chardj0n3s> david-lyle: not yet
20:11:43 <r1chardj0n3s> david-lyle: (and unlikely to)
20:11:49 <david-lyle> what about the external js reference
20:11:55 <david-lyle> or did that get removed?
20:12:10 <r1chardj0n3s> david-lyle: though we haven't got a solid outcome from the bower discussion which would involve new deps
20:12:33 <david-lyle> I can't merge in links to random js from the web
20:12:40 <r1chardj0n3s> right, ok
20:12:45 <r1chardj0n3s> so yes, new deps
20:12:57 <david-lyle> a lot of people run behind firewalls that prevent such things
20:13:03 <r1chardj0n3s> yep
20:13:22 <mrunge> or build systems not connected to the net
20:13:28 <mrunge> ;-)
20:13:29 <david-lyle> ok, we'll hope for K-1, if not k-2 is just the next day :)
20:13:41 <r1chardj0n3s> :)
20:13:47 <r1chardj0n3s> fine by me
20:13:51 <david-lyle> OpenStack where the milestones are meaningless, but help keep time
20:14:06 <r1chardj0n3s> (I was wondering what they were for :)
20:14:06 <david-lyle> well, meaningless is an overstatement
20:14:16 <david-lyle> but fairly apt
20:14:43 <david-lyle> I don't have any other general items
20:15:32 <david-lyle> so the agenda for today can be found at #link https://wiki.openstack.org/wiki/Meetings/Horizon
20:15:52 <david-lyle> #topic Moved blueprint review list
20:15:56 <david-lyle> That's mine
20:16:08 <david-lyle> I created a wiki page to track bps for review
20:16:12 <david-lyle> that's the good news
20:16:26 <david-lyle> the second part with adding a new list didn't happen yet
20:16:30 <david-lyle> so stay tuned
20:16:59 <david-lyle> i think most of those on the current list are ready to approve and schedule
20:17:05 <david-lyle> so I'll start doing that
20:17:17 <rbertram> I've been thinking about basing filtered-client-side-table BP on the Angular work by tqtran and r1chardj0n3s, but I noticed that there is no angular BP. Thoughts?
20:18:02 <r1chardj0n3s> rbertram: the angular work is tied into the identity bp ... https://blueprints.launchpad.net/horizon/+spec/angularize-identity-tables
20:18:07 <mrunge> is it still too early for a bp for all that angular stuff?
20:18:12 <r1chardj0n3s> david-lyle: that should be added to the list pls
20:18:59 <r1chardj0n3s> (or should go through whatever process is appropriate to get onto the list pls :)
20:19:00 <rbertram> r1chardj0n3s: tqtran suggested I start with users rather than instances, since it is easier. Still considering.
20:19:17 <r1chardj0n3s> rbertram: yep, that BP is users
20:19:34 <david-lyle> added to the page
20:19:53 <r1chardj0n3s> rbertram: there's a half-dozen changesets already hanging off that bp, and will likely be a few more before we're done
20:19:53 <david-lyle> forgot to link the page #link https://wiki.openstack.org/wiki/Horizon/Blueprint_Reviews
20:20:50 <TravT_> It would be great if we could land that sooner than later
20:21:08 <rbertram> r1chardj0n3s: what's your point? that it won't stabilize soon enough?
20:21:10 <r1chardj0n3s> agreed
20:21:12 <TravT_> because right now your rest utlitity is in that patch
20:21:30 <r1chardj0n3s> but the individual changes can be merged along the way, yes?
20:21:40 <david-lyle> separate patches on the same bp can merge at any time
20:21:52 <david-lyle> so the rest work should go first
20:21:59 <r1chardj0n3s> rbertram: it's partly that, but also that there's a couple of puzzle pieces missing, most notably the packaging
20:22:04 <david-lyle> that unblocks several others
20:22:12 <rbertram> The rest utility will be very handy for the fitlered-client-side-table
20:22:16 <r1chardj0n3s> agreed, hence I've an agenda item to discuss it ;)
20:22:30 <david-lyle> +1 foresight
20:22:43 <TravT_> ok, will digress until then
20:23:33 <david-lyle> alright, just to close on the current topic, the best way to get your bp for review is to schedule it for a milestone
20:23:53 <david-lyle> moving on
20:24:06 <david-lyle> #topic Repo split and names
20:24:29 <david-lyle> mrunge: was that yours?
20:24:34 <mrunge> ah yes, that'll be me, I guess
20:24:37 <mrunge> ;-)
20:24:42 <david-lyle> lucky you
20:24:46 <mrunge> we still don't have names
20:24:57 <TravT_> Maybe a dumb question, but won't this repo split mean we can't have dependent patches in Gerrit across them?
20:25:04 <r1chardj0n3s> use the github random name generator
20:25:09 <david-lyle> TravT_: yes
20:25:12 <mrunge> TravT_, you're right
20:25:30 <TravT_> uggh
20:25:38 <mrunge> and when splitting the repo, we will have to sync contributions to horizon and openstack_dashboard
20:25:45 <mrunge> meaning: slowing down the process
20:26:20 <TravT_> to be that annoying guy asking yet again... why are we doing this?  just to simplify packaging?
20:26:30 <mrunge> when we decided to split, we thought, horizon (the module) is settled
20:26:55 <david-lyle> mrunge: I ultimately think splitting the repo is the right thing to do, but I worry we'll cause more turmoil than it's worth
20:26:56 <mrunge> TravT_, we're doing this, because horizon (the module) is useful outside of OpenStack
20:27:19 <mrunge> david-lyle, I have two issues with the split currently
20:27:22 <mrunge> or even more
20:27:28 <david-lyle> and I like to waffle on things
20:27:30 <r1chardj0n3s> has anyone proposed an alternative, which is to just merge them? is anyone actually using horizon-the-module outside of openstack?
20:28:00 <david-lyle> r1chardj0n3s: used to be they wanted to, but had to pull on openstack_dashboard too
20:28:05 <mrunge> r1chardj0n3s, we had so many folks coming up, saying: this is useful
20:28:08 <david-lyle> s/on/in/
20:28:26 <r1chardj0n3s> cool, was just wondering :)
20:28:44 <mrunge> when continuing on the route having a django app, this is just the right thing to do
20:29:04 <mrunge> but: given we're throwing everything away, I could use my time better
20:29:35 <david-lyle> option 3, fork horizon-lib onto github and continue dismantling the part remaining in horizon.git
20:29:53 <r1chardj0n3s> ooh, I like the sound of that
20:30:09 <mrunge> hmm, sounds good.
20:30:21 <mrunge> how would that part be updated?
20:30:37 <david-lyle> which part?
20:30:48 <mrunge> or do we accept, horizon-lib and integrated horizon-lib diverting?
20:31:03 <mrunge> I mean, forked off horizon-lib?
20:31:18 <r1chardj0n3s> I do have a concern about the new angular work landing in the horizon "lib" ... if they're truly independent components (independent of openstack_dashboard) then I believe they should be truly separate things out of horizon-lib otherwise no-one in the angular space will ever consider using them
20:31:19 <david-lyle> I think we accept divergence and if something useful goes into horizon-lib, we create a patch by hand
20:31:47 <mrunge> ugh.
20:32:05 <mrunge> I fear, we will just loose interest in horizon-lib
20:32:18 <mrunge> and that part becomes abandoned more sooner than later
20:33:16 <mrunge> so, to make a plan here:
20:33:22 <mrunge> 1. do we still want this?
20:33:44 <mrunge> 2. names? everybody ok with horizon (for horizon lib) and openstack_dashboard?
20:33:50 <mrunge> 3. when?
20:34:27 <david-lyle> I take 2. sure
20:34:27 <doug-fish> with regard to 1, I haven't seen the need for this.  Everyone I interact with who wants to extend Horizon wants some/all of the dashboard panels as well.
20:34:48 <doug-fish> but that could just be me and the sort of people I interact with.
20:34:56 <david-lyle> doug-fish: the need in the past was greater because we didn't have the plugin story worked out yet
20:35:15 <TravT_> on 1), I'd ask what is the primary intent of the dashboard program?  Is it to provide a framework for other UIs or to provide a dashboard for Horizon?  Or maybe that's too much of a simplification.
20:35:26 <david-lyle> and extending horizon was take the code and heavily edit openstack_dashboard or replace it
20:35:29 <mrunge> yes, the request to split was louder in the past
20:35:45 <mrunge> now those folks moved on (or so)
20:36:04 <doug-fish> IMO providing a framework is a big job by itself.  I feel like we are stretched thin already.
20:36:12 <david-lyle> mrunge: have you tried using horizon-lib outside of Horizon?
20:36:27 <mrunge> david-lyle, nope, I haven't
20:36:34 <david-lyle> I'm wondering if there are actually enough pieces there
20:36:43 <mrunge> due lack of time :(
20:36:51 <david-lyle> understood
20:37:55 <david-lyle> I think my vote is to drop the split
20:38:33 <mrunge> I wouldn't be sad or unhappy, if we just drop it
20:38:42 <david-lyle> I think doing the split could be beneficial to some people, but ultimately will hurt us more than it helps them
20:39:05 <david-lyle> anyone else?
20:39:19 <TravT_> so, we've used the horizon framework in HP a few times and it keeps coming up... but TBH I don't know that status on a clear statement of intent on using it as a standalone framework.
20:40:05 <david-lyle> anymore, I think it's just a framework to operate inside OpenStack
20:40:19 <david-lyle> like an oslo library
20:40:38 <david-lyle> I don't think competing OpenStack UIs will be using horizon-lib
20:40:41 <mrunge> david-lyle, it was intended to provide a framework to build a dashboard based on restful services
20:41:02 <david-lyle> mrunge: I understand that, but that was why I asked if anyone had tried
20:41:08 <david-lyle> I'm wondering if you really can
20:41:11 <mrunge> it's not necessarily connected to OpenStack at all...
20:41:18 <david-lyle> as written
20:41:19 <mrunge> agreed.
20:41:47 <david-lyle> then you start a ton of refactoring to make it work as such which ripples through the openstack_dashboard
20:41:50 <mrunge> I think Gabriel had a demo
20:41:53 <TravT_> to that point, a lot of the current movement is putting RESTful APIs into OpenStack Dashboard.
20:42:21 <david-lyle> of extending horizon.git
20:42:24 <TravT_> and a clear pattern is just emerging.
20:42:58 <mrunge> putting restful apis into openstack_dashboard is just... silly
20:43:21 <r1chardj0n3s> mrunge: could you explain that pls?
20:43:46 <mrunge> r1chardj0n3s, we already have apis in place, why do we write software to access them?
20:44:20 <mrunge> or to provide those restful apis another time?
20:44:24 <r1chardj0n3s> the APIs are ... imperfect :)  openstack_dashboard has a bunch of code that makes the underlying APIs far nicer to consume
20:44:59 <mrunge> so, you're hacking around those imperfect apis rather than fixing them?
20:45:01 <r1chardj0n3s> so it made sense to leverage that and provide a new API on top, rather than rewrite everything in the consumer layer (ie javascript)
20:45:04 <mrunge> wow.
20:45:31 <r1chardj0n3s> mrunge: I don't control those apis, and the imperfections often have been fixed through versioning, but old versions still exist in production
20:45:53 <r1chardj0n3s> openstack_dashboard's api code often just smooths over differences between api versions
20:45:58 <mrunge> r1chardj0n3s, I understand your issue. still I don't like the solution
20:46:08 <mrunge> as it's not that clean as I'd like it
20:46:13 <r1chardj0n3s> mrunge: oh, I'm not thrilled by it either
20:46:35 <r1chardj0n3s> mrunge: but in the interest of being practical about it, and choosing battles etc...
20:46:48 <r1chardj0n3s> we have enough to do already :)
20:46:59 <mrunge> r1chardj0n3s, or anyone else: I'm not saying, anyone is doing a bad job
20:47:13 <mrunge> on the other side, I would try to prevent those compromises
20:47:22 <rbertram> I think the existing APIs are consuming REST from keystone and other services. r1chardj0n3s is providing REST to browser. Seems like they APIs are looking in different directions. r1chardj0n3s: true?
20:47:59 <neillc> mrunge: unfortunately compromises seem to be unavoidable
20:48:09 <mrunge> rbertram, something which could be fixed by a proxy, right?
20:48:12 <neillc> It's perhaps a matter of picking the least worst option :)
20:48:38 <mrunge> neillc, I'm expecting those compromises to live forever
20:48:42 <r1chardj0n3s> there existing code in openstack_dashboard (ok, that's a *lot* to keep typing ;) is client code over the service APIs (keystone, nova) and the REST API in "Horizon" (aka openstack_dashboard) is built over that client code
20:49:05 <r1chardj0n3s> you can't just "fix if with a proxy" .. go have a look at the complexity in the openstack_dashboard/api directory
20:49:19 <mrunge> r1chardj0n3s, I did
20:49:22 <rbertram> mrunge: yeah - we are winding up w/ a proxy, which does more than passthrough - does processing between keystone and browser
20:49:36 <r1chardj0n3s> if you replace that code with a proxy, you have to rewrite all that code in Javascript, which we're trying to avoid
20:49:59 <r1chardj0n3s> and the proxy still has to do some processing, as anyone who's written one finds out :)
20:50:07 <TravT_> There is also the whole notion of making incremental progress in client side code which can be done each release.
20:50:43 <mrunge> are we slowly progressing to the next topic?
20:50:52 <mrunge> david-lyle, ?
20:51:08 <david-lyle> we seemed to have jumped yes
20:51:18 <david-lyle> so we'll skip one and
20:51:34 <mrunge> shortly back to split: it's cancelled?
20:51:42 <david-lyle> #topci State of REST API - how much should be implemented
20:51:48 <david-lyle> #topic State of REST API - how much should be implemented
20:51:55 <david-lyle> and go
20:52:05 <TravT_> mrunge: maybe "tenatively postponed"?
20:52:28 <r1chardj0n3s> current REST API WIP is at https://review.openstack.org/#/c/136676/19
20:52:29 <david-lyle> I don't think we can take another postponement
20:52:35 <mrunge> TravT_, well, up to the point, that it doesn't make sense any more?
20:53:11 <david-lyle> mrunge: unless you really want to drive it, I think we should forget it
20:53:16 <r1chardj0n3s> at this point, it seems uncontroversial, and it implements enough to support the identity angular work, but it's obviously not a "complete" API  and certainly doesn't have a complete unit test coverage
20:53:30 <doug-fish> +1 on cancelling the split
20:53:32 <r1chardj0n3s> so, how much more should be done on it before it's merged so others can start work on fleshing it out to their needs?
20:54:42 <david-lyle> r1chardj0n3s: certainly needs tests before merging, but beyond that it doesn't need to be complete
20:55:10 <r1chardj0n3s> david-lyle: so, full test coverage of the code as-is
20:55:42 <r1chardj0n3s> I was also mulling over how this new API is to be documented
20:56:39 <doug-fish> just to be clear, we aren't really going to create an "API" are we?  Like with stability?  We just want an interface for our code.
20:57:02 <TravT_> doug-fish: +1
20:57:02 <mrunge> :D
20:57:05 <mrunge> my point!
20:57:10 <rbertram> doug-fish: meaning we don't want 3rd parties to use it?
20:57:15 <doug-fish> right
20:57:21 <r1chardj0n3s> hm
20:57:30 <TravT_> mrunge: ahh! now I see your point.
20:57:35 <doug-fish> we want to retain full rights to change this often and without warning
20:57:55 <r1chardj0n3s> yep
20:58:13 <r1chardj0n3s> sorry mrunge I totally didn't catch that from what you were saying!
20:58:32 <r1chardj0n3s> yes, the intention is that this API exists to support Horizon-the-angular-application
20:58:50 <r1chardj0n3s> and should be free to change to suit that purpose without repurcussion
20:58:50 <david-lyle> nothing else
20:58:56 <r1chardj0n3s> yep
20:59:01 <TravT_> +100
20:59:09 <david-lyle> yes, we're not publishing an API
20:59:17 <DuncanT> Apologies for butting in, but there's only a few minutes left. We added an API to cinder to allow the policy for the current tenant to be cheacked via REST. This was suggested by a Horizon dev at the cinder mid-cycle meetup. The link is in the minutes, and there's a discussion thread on openstack-dev but no feedback yet. We believe it is good enough to allow
20:59:17 <DuncanT> the CLI to offer better help etc, but wondered if you guys could cast an eye over it before we merged it?
20:59:53 <david-lyle> DuncanT: I will take a look
20:59:59 <DuncanT> Thanks
21:00:17 <DuncanT> I'm thinking about proposing it for other projects if it seems useful
21:00:20 <david-lyle> DuncanT: my main concern would be fragmentation across services, but let me look in more detail
21:00:29 <r1chardj0n3s> ok, so in terms of documenting the API, how about I try to set some good docstring pracises in the patch I'm authoring and we'll try to hold people to that?
21:00:31 <david-lyle> ah, seems you're on the same page
21:00:42 <david-lyle> r1chardj0n3s: +1
21:01:59 <r1chardj0n3s> ok, I think I have a clear path forward for that. I should be able to knock those remaining tasks off pretty quickly
21:02:07 <david-lyle> great
21:02:33 <TravT_> thanks r1chardj0n3s
21:02:34 <david-lyle> out of time and missed the third party item, apologies
21:02:42 <david-lyle> Thanks everyone!
21:02:47 <david-lyle> #endmeeting