20:03:59 <david-lyle> #startmeeting horizondrivers
20:04:00 <openstack> Meeting started Wed Nov 11 20:03:59 2015 UTC and is due to finish in 60 minutes.  The chair is david-lyle. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:04:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:04:03 <openstack> The meeting name has been set to 'horizondrivers'
20:04:04 <TravT> yeah, i just went in and updated my meeting reminders to be based on utc
20:04:55 * david-lyle tries to refocus
20:05:21 <david-lyle> aha, no agenda
20:05:56 <david-lyle> #topic priorities
20:06:01 <david-lyle> #link https://etherpad.openstack.org/p/mitaka-horizon-priorities
20:06:25 <david-lyle> for anyone who missed it, or forgot, those were the priorities we arrived at for mitaka
20:06:53 <david-lyle> tqtran: I started working on you plugin doc patch today
20:07:37 <david-lyle> which was up there and the other doc patches are moving forward so that's half the critical items in progress
20:07:54 <david-lyle> a couple more weeks and we can go home for 5 months
20:08:19 <robcresswell> Dont we all workm from home anyway?
20:08:41 <tqtran> home is where he heart is
20:08:52 <david-lyle> alright then
20:09:00 <david-lyle> #topic midcycle
20:09:17 <david-lyle> we discussed briefly the possibility of a midcycle this morning
20:09:35 <david-lyle> most people seem to be interested based on conversations
20:09:50 <david-lyle> I will privately be soliciting potential hosts
20:10:04 <david-lyle> I can offer Santa Clara and Portland
20:10:22 <TravT> I'm sure I can get an HP site somewhere.
20:10:43 <tqtran> same here, can host at an IBM site somewhere as well
20:10:58 <david-lyle> so places and dates are needed, since this is my second day back, I haven't gotten far :)
20:11:19 <TravT> i think we should try for southern california, florida, etc
20:11:30 <TravT> somewhere warm...
20:11:37 <tqtran> yes, warm weather will be nice
20:11:37 <mrunge> +1
20:11:40 <david-lyle> r1chardj0n3s has his heart set on San Diego
20:11:50 <david-lyle> not sure who could host there though
20:11:54 <TravT> yeah, i kinda placed that bug in his ear...
20:12:02 <david-lyle> some unlucky airbnb?
20:12:15 <mrunge> which makes it a bit more expensive for Europeans
20:12:29 <TravT> Maybe southern italy, then?
20:12:44 <robcresswell> A bit expensive for the Europeans employers* ;)
20:12:46 <mrunge> I guess, I could find a conference room in Brno (Czech republic)
20:12:59 <david-lyle> I will start compiling a list
20:13:22 <david-lyle> ping me if you realistically have a hosting offer :)
20:13:36 <tqtran> so... southern Italy then?
20:13:52 <robcresswell> tqtran: +1
20:14:22 <TravT> You can write down Fort Collins, Seattle, Sunnyvale for HPE.  I don't think I have to even ask about those. Just need time to schedule.
20:14:51 <david-lyle> I think we could get 5 companies in the SJC area
20:15:20 <david-lyle> #topic summit feedback
20:15:21 <tqtran> yeah, theres two IBM sites in SJ, and Im sure Austin will also be open for grabs
20:15:41 <david-lyle> I asked this morning as well but any feedback on the summit?
20:15:57 <doug-fish> probably can skip Austin for the midcycle since the summit will be there
20:15:58 <david-lyle> to either feed up or just in general for next time
20:16:21 <mrunge> I found it quite productive
20:16:35 <tqtran> yes, arrived at priorities pretty quick
20:16:57 <TravT> i thought it was good, except i didn't like that the design summit overlapped more with the main conference than normal.
20:17:16 <TravT> felt like there was less opportunity to go to other sessions.
20:17:22 <tqtran> less days, i dont think it could hav ebeen avoided
20:17:28 <TravT> yeah
20:17:33 <mrunge> yeah, I had to skip at least 2 horizon sessions due to parallel other sessions
20:17:41 <robcresswell> Its going back to 5 next time
20:18:08 <david-lyle> some this morning mentioned that the more rapid convergence may have been in part due to the midcycle
20:18:32 <david-lyle> so I think that illustrates some value
20:18:40 <mrunge> it seems we all were more on the same side
20:18:45 <tqtran> good point.... that seems likely
20:19:15 <tqtran> that was for david's comment btw lol
20:19:36 <mrunge> would end of january to late for midcycle?
20:19:54 <david-lyle> I wouldn't think so
20:19:56 <robcresswell> No, that sounds about right
20:20:03 <mrunge> just a silly idea, as there is FOSDEM in Brussels, which is a AWESOME conference
20:20:06 <tqtran> it should be sometime in jan i think, nov and dec are mostly american holidays
20:20:46 <david-lyle> Austin is April 25-29
20:21:29 <david-lyle> and release is april 7
20:22:07 <TravT> https://wiki.openstack.org/wiki/Mitaka_Release_Schedule
20:22:09 <mrunge> so, 2 months before release might be a bit too late for *mid* cycle...
20:22:19 <david-lyle> won't FOSDEM already be too busy
20:22:34 <TravT> Maybe last week of Mitaka-2?
20:22:39 <TravT> Jan 16th?
20:23:07 <mrunge> I was just trying to talk you to visiting Brussels ;-)
20:23:27 <mrunge> but it's *cold* there
20:23:43 <TravT> i'd happily go to europe... probably have same problem as you coming the US.  much harder to get approval for mid-cycles.
20:24:10 <david-lyle> let me find some option and we can vote
20:24:15 <david-lyle> *options
20:24:21 <david-lyle> any other summit feedback
20:24:22 <david-lyle> ?
20:24:35 <mrunge> yeah. makes sense
20:25:06 <david-lyle> the later the better for me this time around, but that's just me
20:25:28 <mrunge> would it be possible to get some tables in the hall next time?
20:25:47 <david-lyle> mrunge: in which hall?
20:25:51 <mrunge> I found those more informal meeting points (outside of sessions) quite useful in the past
20:26:06 <tqtran> ah yes, great idea
20:26:07 <david-lyle> there was the dev lounge room/lunch room
20:26:10 <mrunge> like in Vancouver, there were several possibilities
20:26:12 <robcresswell> Ohhh, like the tables in Paris?
20:26:19 <mrunge> oh yes
20:26:24 <mrunge> someting like that
20:26:36 <tqtran> we need a horizon sign somewhere though, the dev lounge was too scattered
20:26:52 <robcresswell> We could just make ourselves a little sign :)
20:26:52 <doug-fish> Maybe we can fly one of those t-shirts
20:26:58 <robcresswell> doug-fish: Excellent idea
20:27:06 <david-lyle> doug-fish: you beat me too it
20:27:21 <mrunge> this time, we had meetings all days, but barely a chance to do something in smaller groups
20:27:26 <mrunge> just an idea...
20:27:29 <david-lyle> or ducttape_'s shirt
20:27:51 <david-lyle> mrunge: I agree
20:28:05 <TravT> i actually think contributors meetup might be better with several smaller tables than one giant table
20:28:16 <mrunge> maybe we could even reduce sessions for horizon by one or two?
20:28:36 <robcresswell> I think the extra day will help
20:28:46 <david-lyle> mrunge: I'd be fine with that
20:28:50 <mrunge> this time, we talked 3-4 times about angular in general
20:29:01 <robcresswell> Heh :p
20:29:04 <david-lyle> mrunge: I expected it to take more time :P
20:29:12 <mrunge> heh ;-)
20:29:22 <mrunge> not saying, it wasn't useful
20:30:14 <david-lyle> want to review the new crop of bps ? :-D
20:31:06 <mrunge> first one, fresh from today: https://blueprints.launchpad.net/horizon/+spec/local-settings-override-mechanism
20:31:16 <david-lyle> #topic https://blueprints.launchpad.net/horizon/+spec/local-settings-override-mechanism
20:31:31 * david-lyle was digging them up
20:31:54 <robcresswell> Oh yeah, I was discussing this with him this morning
20:31:56 <mrunge> I think, we started discussing something like this at the summit
20:32:38 * doug-fish is confused
20:32:40 <david-lyle> I was discussing this yesterday and this deviates from the approach I would prefer
20:33:02 <tqtran> what is the approach you prefer?
20:33:03 <TravT> david-lyle: was this the rambling going on in the room yesterday?
20:33:13 <TravT> with enabled files?
20:33:22 <robcresswell> TravT: Sounds about right
20:33:22 <david-lyle> not to mention it's already covered in the blanket https://blueprints.launchpad.net/horizon/+spec/plugin-sanity bp
20:33:29 <david-lyle> TravT: yeah
20:33:38 <TravT> ok, i tried to follow, but go a bit lost
20:34:23 <TravT> do you have a summary?
20:34:39 <david-lyle> essentially, for the themes, you need a setting to indicate the path to the theme
20:35:23 <david-lyle> when installing a package containing the theme, it's not in the packages scope to go and edit the horizon settings file
20:35:31 <mrunge> yeah, one can not override theme path
20:35:55 <david-lyle> currently with the plugin mechanism we don't support adding/overriding settings either
20:36:01 <david-lyle> but that is planned behavior
20:36:04 <mrunge> that makes themes unusable in packages
20:36:22 <david-lyle> without manual intervention
20:36:50 <david-lyle> so there are two proposals
20:37:01 <david-lyle> although 1 has variants
20:37:14 <TravT> So the ability to do this, sounds like a +1
20:37:20 <tqtran> question..... when installing a package containing the theme, couldnt it just import horizon setting and override?
20:37:31 <david-lyle> 1st add the ability to override settings in plugins
20:38:14 <david-lyle> I think the ability to add settings is a given, but they should be namespaced to the plugin generally
20:38:32 <david-lyle> tqtran: no
20:38:44 <david-lyle> packages shouldn't alter other packages when installed
20:38:55 <david-lyle> otherwise the second package is corrupted
20:39:11 <david-lyle> and not reliable or updatable generally
20:39:16 <tqtran> taking a step back, why would you install a theme package if there is no intention to use it?
20:39:17 <david-lyle> or removable, etc
20:39:40 <robcresswell> tqtran: ?
20:39:47 <david-lyle> tqtran: that's not really the point
20:39:54 <david-lyle> but you could install several
20:40:16 <tqtran> i think theme and plugins arent two different things. not really seeing the reason for mixing them
20:40:21 <tqtran> *are
20:40:46 <david-lyle> tqtran: I don't see the need to create another random python file loading system
20:41:03 <david-lyle> and plugins now can add/remove or move content
20:41:07 <TravT> i think only allowing one theme package to be installed would not be good.
20:41:13 <tqtran> we dont have to, im making the assumption that only one theme package will get install
20:41:19 <TravT> we'd want to be able to toggle which one is active independently
20:41:43 <tqtran> hm.... thats true...
20:41:44 <david-lyle> tqtran: that's not a fair assumption when considering the per user theme selection
20:41:59 <david-lyle> which is proposed
20:42:15 <tqtran> ok never then :D
20:42:21 <tqtran> *never mind
20:42:28 <mrunge> tqtran, it's more a general issue, not even connected to theme packages
20:42:47 <mrunge> it affects all plugins
20:42:50 <tqtran> mrunge: yep, i think i am starting to get it
20:43:13 <mrunge> but yes, you're right, it started from a theme plugin
20:43:49 <tqtran> so help me understand how we are going allow overriding of themes? or is that the problem we dont have a good answer for yet?
20:43:57 <tqtran> *overrding of settings
20:44:06 <mrunge> exactly
20:44:08 <robcresswell> That's what is up for discussion
20:44:10 <robcresswell> :)
20:44:32 <tqtran> gotcha... huhuhu
20:44:32 <TravT> well, david-lyle mentioned per user... a settings file override wouldn't achieve that
20:45:08 <mrunge> currently you can not override CUSTOM_THEME_PATH
20:45:37 <david-lyle> TravT: that's a slightly different issue, but demonstrates the multi-theme requirement
20:45:43 <tqtran> what if you want to override CUSTOM_THEME_PATH but are not installing any plugins?
20:45:51 <TravT> that would be some other mechanism, yes?  unless you allow settings with group by something else like project or domain...
20:46:16 <mrunge> tqtran, same issue
20:46:24 <tqtran> TravT er... that would be bad, I am thinking that user settings should be stored client-side
20:46:57 <mrunge> in package world, you can not change local_settings file depending on installed plugins
20:47:01 <TravT> so, is there a competing blueprint?
20:47:25 <tqtran> no, i think the per user settings should be handled differently
20:47:33 <doug-fish> shouldn't the local_settings file always be the last word in what a setting should be?
20:47:33 <robcresswell> It's kind of two distinct issues, IMO. You can't do settings via enabled, and you cant have enabled files without content (i.e. settings only)
20:47:50 <doug-fish> otherwise how does an admin know how to update?
20:48:09 <doug-fish> very_local_settings.py maybe
20:48:16 <david-lyle> competing is the larger plugin bp
20:48:21 <robcresswell> doug-fish: lol
20:48:28 <tqtran> plus, if you have 2 plugins competing for the same setting, that would then depend on load order, which could be bad?
20:48:28 <david-lyle> but it's light on details, just has a task
20:48:45 <david-lyle> but I expected it to be incorporated into the enabled files
20:48:58 <david-lyle> that's why there is a load order
20:49:09 <david-lyle> a clearly defined one
20:49:39 <tqtran> but now, the user is force to look through all the enabled files to locate which plugin loaded SETTING_A last
20:49:59 <david-lyle> but a general theme plugin, I would not expect to use the enabled files or even a plugin necessarily
20:50:05 <tqtran> and if you have 10 different settings you are looking out for, it could get very messy
20:50:22 <david-lyle> maybe a plugin and a manual edit of settings
20:50:37 <doug-fish> I'd think local_settings should always remain the final authority on what a setting should be
20:50:39 <mrunge> tqtran, but that's still better than 'you can't modify'?
20:50:44 <david-lyle> for a company based theme, that's where setting the default becomes valuable
20:51:04 <doug-fish> and we should be selective about what we provide in that file
20:51:24 <doug-fish> so the priority is settings->enabled files->local_settings
20:51:37 <tqtran> mrunge: i'm still not understanding why a packager cant modify local_settings?
20:51:48 <david-lyle> doug-fish: not entirely sure that works
20:52:04 <mrunge> doug-fish, that would make overriding impossible
20:52:11 <doug-fish> tqtran: it's because a file needs to belong to one package
20:52:22 <doug-fish> how so?
20:52:48 <doug-fish> We should only have things in local_settings that the user has explicitly chosen
20:52:58 <doug-fish> defaults should be in settings
20:53:01 <mrunge> tqtran, changing a config file due to context of installed combinations of other packages becomes messy
20:53:30 <mrunge> and it's clearly defined, a file belongs to a *single* package
20:54:15 <mrunge> besides, changing a config file would involve most probably a shell script (or so)
20:54:32 <doug-fish> mrunge: does local_settings belong to any package?
20:54:39 <mrunge> yes, it does
20:54:43 <mrunge> to openstack-dashbard
20:54:50 <mrunge> +o somewhere
20:55:12 <mrunge> one would change local_settings by installing a plugin
20:55:14 <david-lyle> doug-fish: these are distribution packages, not pure upstream
20:55:23 <doug-fish> yep understood
20:55:39 <mrunge> the last installed plugin would then dictate the contents of local_settings?
20:55:57 <doug-fish> I'd expect local_Settings to be a user editable file - wasn't sure that would belong to a package
20:55:57 <david-lyle> mrunge: I think there are two things
20:56:16 <mrunge> doug-fish, that is a config file
20:56:40 <mrunge> and nothing has to change that file, other than the user of something like puppet
20:56:50 <mrunge> (IMHO)
20:57:04 <mrunge> s/of/or/
20:57:23 <doug-fish> mrunge: got it - thx
20:57:26 * david-lyle about to stomp on his own point
20:57:32 <doug-fish> don't other projects with plugins have the same issue?
20:57:42 <doug-fish> is there a known solution/pattern that would work better?
20:57:42 <david-lyle> mrunge: where does the apache config for horizon come from in rpms?
20:58:07 <mrunge> from horizon package
20:58:08 <david-lyle> actually, those are just drop in files
20:58:11 <david-lyle> nevermind
20:58:20 <mrunge> and it's placed in a .d config dir
20:58:22 * david-lyle lucky illustrates own point
20:58:30 <david-lyle> :D
20:58:53 <mrunge> the Thomas idea with a local_settings.d is quite straightforward then
20:59:15 <david-lyle> just not sure the need of another mechanism :/
20:59:34 <david-lyle> we have 20 now
20:59:49 <mrunge> if we can enable updating local_settings by enabled files, there you go
20:59:58 <mrunge> or some other documented mechanism
21:00:08 <david-lyle> mrunge: either takes new code
21:00:28 <robcresswell> Do we want to allow plugins to override any setting?
21:00:37 <tqtran> I like the local_settings.d more, having many places to place your settings is confusing
21:00:41 <mrunge> yes we should...
21:00:51 <mrunge> tqtran, +1
21:01:09 <robcresswell> tqtran: Isn't this *more* places than just using enabled?
21:01:21 <david-lyle> so now my plugin needs to drop the enabled file and the local_settings.d file?
21:01:32 <tqtran> if i installed 10 plugins, and they all are overriding settings.... its a complete mess for me to trace down which ones had the last load
21:01:33 <mrunge> robcresswell, think about a networking plugin, which requires new/changed neutron settings...
21:01:49 <mrunge> that would require a manual config change otherwise
21:01:54 <david-lyle> with it's own precedence scheme that should match the plugin
21:02:15 <doug-fish> but again - I think local_settings needs to be the final authority on a settings value
21:02:28 <robcresswell> Yeah the settings would have a different load order than enabled/
21:02:31 <doug-fish> and maybe we need fewer values there
21:02:36 <robcresswell> if we had two mechanisms
21:02:38 <mrunge> doug-fish, in that case, you can not override settings defined in local_settings
21:02:47 <doug-fish> yep
21:02:49 <david-lyle> doug-fish: that doesn't even hold for INSTALLED_APPS
21:02:57 <david-lyle> which is why plugins work :D
21:03:09 <doug-fish> maybe INSTALLED_APPS shouldn't be in local_settings by default
21:03:18 <alaski> sorry to interrupt, are ya'll just about finished in here?
21:03:26 <david-lyle> ahh over time
21:03:41 <david-lyle> thanks everyone we'll pick this up in #openstack-horizn
21:03:46 <david-lyle> +o
21:03:51 <david-lyle> #endmeeting