20:00:43 <david-lyle> #startmeeting horizondrivers
20:00:44 <openstack> Meeting started Wed Dec  9 20:00:43 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:00:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:48 <openstack> The meeting name has been set to 'horizondrivers'
20:01:12 <david-lyle> who's around?
20:01:17 <r1chardj0n3s> o/
20:01:21 <bpokorny> o/
20:01:27 <pkarikh_> o/
20:02:17 <tsufiev> o/
20:03:03 <david-lyle> there are some blueprints for review on the agenda for today
20:03:13 <david-lyle> #link https://wiki.openstack.org/wiki/Meetings/HorizonDrivers#Agenda_for_2015-12-09_2000UTC
20:03:19 <itxaka> o/
20:03:28 <david-lyle> #topic https://blueprints.launchpad.net/horizon/+spec/refactor-tables-templates
20:03:33 <david-lyle> #link https://blueprints.launchpad.net/horizon/+spec/refactor-tables-templates
20:03:50 <david-lyle> itxaka, robcresswell o/
20:05:38 <r1chardj0n3s> looks like a good bp, though s/less/fewer ;-)
20:05:40 <david-lyle> that seems like a reasonable proposal with a great goal. I posted my comments on the patch yesterday
20:05:48 <tsufiev> my point regarding bp/refactor-tables-templates is that we need more numbers
20:06:10 <tsufiev> I tested it with fake cinder volumes, no effect
20:06:30 <itxaka> Indeed, I retested with the volumes as well, the gains are minimal
20:06:40 <david-lyle> interesting
20:06:54 <tsufiev> haven't yet managed to test with pseudo instances, scheduled for tomorrow
20:06:56 <david-lyle> so what's the difference for users?
20:07:13 <itxaka> Seems that the less actions there are for each row, the speed ups are less
20:07:28 <itxaka> so the time consuming part is calling for 1000 rows, 5 actions for each
20:07:38 <itxaka> for 1000 rows with one action, there is no noticiable gain
20:08:00 <david-lyle> that doesn't preclude the advantage on tables with many actions
20:08:12 <tsufiev> itxaka, this refactoring won't affect themability, will it?
20:08:15 <david-lyle> it would be nice to better quantify
20:08:15 <itxaka> I also want to test with instances as they got a lot of actions, so it should be hte most extreme case of gains
20:08:25 <david-lyle> because listing 1000 items is never a good idea anyway
20:08:37 <itxaka> tsufiev I added blocks everywhere so they can be overriden :)
20:08:51 <itxaka> So Im thinking that it should not affect themability
20:09:07 <tsufiev> ok
20:11:37 <david-lyle> I'd like to see a better quantification
20:11:49 <david-lyle> maybe for 100-200 items
20:12:00 <itxaka> Also, this speeds up any dashboard that has a lot of actions per row in them, so could cover us from that
20:12:09 <itxaka> I know that I have suffer it myself :D
20:12:22 <david-lyle> this will break backward compatibility for those who have overridden the sub templates, I want there to be a good reason to break them
20:12:37 <itxaka> sure, will redo the tests with 150 items on several tables tomorrow
20:12:48 <david-lyle> itxaka: thank you
20:12:57 <itxaka> so we can see how it affects other tables (volumes/images/instances and so on)
20:13:04 <david-lyle> #info https://blueprints.launchpad.net/horizon/+spec/refactor-tables-templates moved to review
20:13:17 <david-lyle> pending more data, we'll revisit
20:13:24 <itxaka> great, thanks!
20:13:45 <david-lyle> #topic https://blueprints.launchpad.net/horizon/+spec/cache-templates
20:14:07 <david-lyle> ok, thought that looked familiar
20:14:13 <david-lyle> it's already merged
20:14:15 <tsufiev> 2-3 times speedup, nuff said :)
20:14:39 <david-lyle> #info https://blueprints.launchpad.net/horizon/+spec/cache-templates complete
20:14:57 <david-lyle> #topic https://blueprints.launchpad.net/horizon/+spec/sriov-support
20:15:25 <itxaka> Thats me too, sorry :D
20:15:38 <itxaka> let me read it again
20:16:23 <itxaka> ah yes, there is a patch ongoing for the new launch instance
20:16:26 <itxaka> still some work needed
20:16:46 <itxaka> not sure it it would be useful to have the same done on the django launch instance as well
20:16:54 <r1chardj0n3s> re the "missing text" note - is the help text something that the doc team could help with?
20:16:55 <itxaka> or are we moving forward full speed with angular
20:17:29 <itxaka> r1chardj0n3s: Indeed, that would be really helpful as Im kind of lost on how to write something decent ;D
20:19:08 <tsufiev> itxaka, IMO implementing new functionality in Launch Instance NG would be a good stimuli to switch to the new wizard :)
20:19:38 <david-lyle> I think support SR-IOV here makes sense. But I would like a check to see if the ML2 plugin supports it before exposing the option to the user.
20:20:17 <itxaka> Supposedly it supports it, there is configuration files and everything on the ml2 plugin
20:20:18 <tsufiev> itxaka, but as we were discussing implementing the same thing internally, our Nova/Neutron guys stood up and said that there were some pieces missing on their side
20:20:38 <tsufiev> cannot share more details :/
20:20:46 <itxaka> I have a machine running with it enabled but I cannot make it work, have to check with the neutron guys
20:21:01 <itxaka> so I cannot affirm that it works
20:21:10 <itxaka> it seems to :D
20:21:59 <david-lyle> itxaka: but there should be a call to determine if it's configured or not
20:22:51 <itxaka> In that I cant say anything becuase my knwowledge of that is basically 0
20:22:52 <david-lyle> or a setting similar to https://github.com/openstack/horizon/blob/master/openstack_dashboard/local/local_settings.py.example#L239
20:22:52 <itxaka> :D
20:23:34 <david-lyle> but there are points for the review, I don't have a problem with the bp
20:24:06 <itxaka> Its still a very early thing for me because until monday I knoew nothing about SR-IOV
20:24:17 <itxaka> so any help is welcomed in there, but it would go slow from my part
20:24:49 <david-lyle> we'll handle the rest in reviews
20:25:00 <david-lyle> does anyone have an issue with the bp itself?
20:25:12 <r1chardj0n3s> itxaka: I'll see if my neutron co-worker can help
20:25:34 <itxaka> thanks r1chardj0n3s :)
20:25:44 <r1chardj0n3s> (well, help me help you ;-)
20:26:03 <robcresswell> o/ Sorry, late.
20:26:22 <itxaka> o/
20:26:47 <tsufiev> o/
20:27:29 <david-lyle> going twice
20:28:06 <david-lyle> #info https://blueprints.launchpad.net/horizon/+spec/sriov-support approved
20:28:38 <david-lyle> #topic https://blueprints.launchpad.net/horizon/+spec/horizon-filtering-users-and-projects
20:28:54 <pkarikh_> yep, it's mine. :)
20:30:30 <tsufiev> so this is the famous bp/feature we've speaking about last several months :)
20:30:52 <robcresswell> Yes, I like this idea
20:31:44 <pkarikh_> it's not so easy to make it all together since keystone and keystone-client changes are needed too. and they are booth in progress
20:31:45 <david-lyle> I like it, I'm not sure if it goes far enough
20:32:23 <robcresswell> far enough?
20:32:25 <pkarikh_> but keystone guys said that their patches have good progress
20:32:54 <tsufiev> david-lyle, should we ask again for keystone pagination :)?
20:33:03 <david-lyle> oh no
20:33:07 <stevemar> robcresswell: do you have links to the keystone patches? i can put them at the top of my list
20:33:21 * stevemar picks up a rock and is ready to throw at tsufiev
20:33:23 * tsufiev trying to outline the contours of 'far enough'
20:33:43 <david-lyle> just wondering the value of listed the first 25 is useful at all
20:34:03 <david-lyle> I suppose for toy setups it is
20:34:04 <david-lyle> or single rack
20:34:08 <robcresswell> stevemar: https://review.openstack.org/#/c/250473/1 and https://review.openstack.org/#/c/234849/
20:34:13 <tsufiev> david-lyle, the first 25 that satisfy the filtering query
20:34:18 <doug-fish> david-lyle: probably useful for novices, first setups
20:34:36 <david-lyle> the table numbering on the bottom should be updated as well
20:34:37 <david-lyle> I don't see that called out in the UX
20:34:40 <stevemar> robcresswell: thanks, i'll make sure to target these patches accordingly
20:34:58 <robcresswell> stevemar: Excellent :)
20:36:11 <tsufiev> pkarikh, I think we should also discuss that with Piet from UX group
20:37:14 <pkarikh_> tsufiev: ok, looks like I need to find him :)
20:37:39 <tsufiev> pkarikh, try #openstack-ux channel or just an email
20:37:54 <david-lyle> any dissent on this one?
20:37:56 <pkarikh_> tsufiev: I'll try both
20:38:28 <tsufiev> david-lyle, btw, where was that number of 25?
20:39:35 <david-lyle> ok, I think there are a couple of UX pieces to fine tune, but looks good to me.
20:39:48 <david-lyle> #info https://blueprints.launchpad.net/horizon/+spec/horizon-filtering-users-and-projects approved
20:40:27 <david-lyle> would there be a separate patch for filtering users on project role addition ?
20:40:53 <pkarikh_> yep
20:41:05 <david-lyle> tsufiev: I made it up
20:41:14 <david-lyle> whatever page limit is set to
20:41:15 <pkarikh_> yesterday I've tried some kind of poc
20:41:46 <pkarikh_> was very glad Horizon has REST API for identity. :)
20:41:57 <tsufiev> david-lyle, I see. Well, it's always the tradeoff between usability vs. performance
20:42:35 <david-lyle> tsufiev: true, but even first 200 users will only be useable for a relatively small audience
20:42:52 <david-lyle> I most likely looking for user 201
20:43:22 <david-lyle> so unless I'm lucky, you've just pulled in a bunch of data that's no help to me
20:43:37 <tsufiev> david-lyle, if you narrow your search query enough, you won't need to display 201 users, this 201 user should become user #2
20:43:53 <tsufiev> and if we could use faceted search...
20:44:01 <david-lyle> tsufiev: right, the idea question is do you force the user to facet first
20:44:08 <david-lyle> s/idea//
20:44:22 <r1chardj0n3s> I think we have to, but that's a much bigger ux issue
20:44:42 <tsufiev> hmm... we definitely need to discuss it with UX community + I don't know if it's possible on Keystone side
20:44:48 <r1chardj0n3s> especially in some of the currently-cramped user listing interfaces
20:44:53 <david-lyle> or show the spinny and give them data they can't use and then implicitly force them to facet
20:45:05 <david-lyle> tsufiev: to search?
20:45:07 <david-lyle> sure it is
20:45:10 <tsufiev> r1chardj0n3s, aka Project->Manage Members?
20:45:16 <r1chardj0n3s> tsufiev: precisely
20:45:28 <tsufiev> david-lyle, to search against several criteria
20:45:45 <david-lyle> tsufiev: that I don't know
20:46:04 <david-lyle> looks like homework for tsufiev and pkarikh_
20:46:07 <david-lyle> :D
20:46:10 <tsufiev> neither do I :/...
20:46:24 * david-lyle adds to the mountain
20:46:26 <tsufiev> pkarikh, have fun ;)
20:46:40 <pkarikh_> sure :)
20:47:53 <robcresswell> I assume for small totals, you would just pull them all in anyway. No point mandating a search for 200 entries. May as well show all.
20:48:17 <david-lyle> robcresswell: but you don't know that before querying the API
20:48:27 <david-lyle> there could be 10 or 10000 out there
20:48:51 <david-lyle> maybe a configuration option down the road
20:48:58 <david-lyle> don't preload table data
20:49:00 <robcresswell> Ah, I see
20:49:01 <tsufiev> david-lyle, robcresswell we just trust in deployer's wisdom who is able to set this limit
20:49:22 <david-lyle> make me search
20:49:31 <david-lyle> pkarikh_'s work still needto happen
20:49:35 <david-lyle> *needs to
20:49:37 <tsufiev> ack!
20:49:43 <pkarikh_> if I got your concern right, keystone will have list_limit settings in its config
20:49:49 <david-lyle> #topic https://blueprints.launchpad.net/horizon/+spec/message-of-the-day
20:49:49 <pkarikh_> *setting
20:50:16 <david-lyle> pkarikh_: keystone has a value, horizon has another
20:50:24 <lhcheng> david-lyle: o/
20:50:36 <lhcheng> a lot of operators ask for this feature
20:50:43 <david-lyle> that is user settable
20:50:43 <david-lyle> see settings dashboard
20:50:49 <robcresswell> Do those messages show up once, or every time the user logs in?
20:50:53 <r1chardj0n3s> is there anything controversial about this one?
20:51:20 <david-lyle> does this just leverage the message system already in place?
20:51:20 <david-lyle> that was my only question
20:51:25 <robcresswell> r1chardj0n3s: No, but curious how its coded :)
20:51:26 <itxaka> Its great, but there is no way that I can see of removing the message
20:51:32 <lhcheng> robcresswell: everytime the user logs in
20:51:39 <itxaka> robcresswell exactly that
20:51:39 <tsufiev> r1chardj0n3s, besides it has been denied several times, I guess nothing controversial :)
20:51:53 <lhcheng> david-lyle: it just uses the django message
20:52:06 <lhcheng> david-lyle: horizon.message
20:52:46 <robcresswell> lhcheng: That would be *very* annoying, wouldn't it?
20:52:59 <tqtran> right, i was just thinking that
20:53:19 <lhcheng> robcresswell: there is no way to track if user have already seen the message though.
20:53:21 <tqtran> there should be a way to show it only once? or until user disables it
20:53:32 <david-lyle> tsufiev: what had been denied was adding it to the login page
20:53:32 <david-lyle> right, so the first page I go to after logging in gets 0* messages added to it
20:53:36 <tqtran> lhcheng: you can use localStorage to track
20:53:37 <robcresswell> lhcheng: Yeah, I know, thats why I was curious how you'd done it :)
20:53:45 <lhcheng> tqtran: depends how you intend to use the messaging
20:54:10 <david-lyle> robcresswell: how often will you log in to a production system?
20:54:10 <david-lyle> you're thinking as a developer
20:54:11 <tqtran> you can do something like, 1. fetch message, if message is the same, then dont show it
20:54:21 <tqtran> otherwise, display it inside the toast
20:54:22 * david-lyle makes assumption about robcresswell's thoughts
20:54:32 <lhcheng> toast?
20:54:38 <lhcheng> I'm not doing it in angular
20:54:40 <tqtran> horizon.message = toast
20:54:48 <tsufiev> messaging as a service?
20:55:00 <david-lyle> tqtran: if service cinder is down, it's useful to know that every time I login until it's resolved
20:55:02 <robcresswell> david-lyle: You're probably right. I was just picturing having to dismiss 10 messages every time I log in to Horizon
20:55:10 <david-lyle> otherwise I might assume it's fixed
20:55:19 <lhcheng> it is used for upcoming downtime
20:55:24 <lhcheng> or upgrade
20:55:47 <tqtran> you can flag all of that stuff, just have another param { level, message, duration }
20:56:02 <tqtran> duration where it can pop up everytime or just once
20:56:04 <lhcheng> tqtran: what is duration for?
20:56:13 <tqtran> duration might be bad name
20:56:18 <robcresswell> I assume length of time before auto dismiss?
20:56:27 <tqtran> but basically a counter to tell the front-end to display it or not
20:56:31 <david-lyle> lhcheng: the commit message says allow user to set MOTD, but with the patch, it's a file system operation by the operator, no?
20:57:18 <lhcheng> david-lyle: ah yes, they don't set the motd on the ui. It is just file system update
20:57:22 <tqtran> the fs would have to be shared between diff deploy of horizon as well for this to work in big deploys?
20:57:33 <david-lyle> let's step back a second and consider what the proposal is
20:57:59 <david-lyle> 1) the operator, who can log into the horizon server can set a MOTD
20:58:08 <david-lyle> 2) the MOTD is only supported if the option is enabled
20:59:26 <lhcheng> david-lyle: yeah
20:59:46 <lhcheng> basic stuff, doesn't have to be fancy
21:00:04 <lhcheng> I don't want to over-engineer it
21:00:06 <tqtran> how would it work if you have multiple deployment of horizon?
21:00:42 <lhcheng> you have a tool that manages updating that file
21:00:48 <tqtran> would you have to log into each and set the message? im assuming the fs arent shared right?
21:00:52 <lhcheng> could be chef
21:01:03 <david-lyle> 3) if the operator feels the message is important enough to show on all logins, it probably is
21:01:04 <david-lyle> 4) in production you likely won't login in very often
21:01:04 <david-lyle> lhcheng: fair summary?
21:01:04 <david-lyle> I'm just not sure any of that is egregious or needs to be prematurely optimized
21:01:05 <david-lyle> tqtran: likely have puppet or chef update to all horizon controllers
21:01:33 <alaski> o/
21:01:34 <lhcheng> tqtran: that's not in the scope of horizon, it would be up to the operators to figure that out.
21:01:37 <david-lyle> ok, we're at time
21:01:45 <robcresswell> Yeah, I don't have any issue with the proposal. If message spam is a non-issue, then its fine by me.
21:01:56 <robcresswell> :)
21:02:17 <lhcheng> david-lyle: yep, thanks!
21:02:29 <tqtran> ok, im fine with is as long as something like duration flag is added
21:02:31 <lhcheng> david-lyle: fair summary ^
21:03:56 <alaski> are y'all done?
21:04:00 <robcresswell> yep
21:04:04 <david-lyle> much like making sure the local_settings file is in sync on all horizon controllers
21:04:05 <david-lyle> I'm inclined to approve, but leave comments on the bp if you disagree
21:04:05 <david-lyle> Thanks everyone!
21:04:05 <david-lyle> #endmeeting