20:00:33 <lhcheng> #startmeeting Horizon
20:00:33 <openstack> Meeting started Wed Aug 12 20:00:33 2015 UTC and is due to finish in 60 minutes.  The chair is lhcheng. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:38 <openstack> The meeting name has been set to 'horizon'
20:00:47 <robcresswell> o/
20:00:48 <lhcheng> anyone around to talk about horizon?
20:00:49 <crobertsrh> hello/
20:00:51 <matt-borland> o/
20:00:56 <lhcheng> o/
20:00:57 <hurgleburgler> (◠‿◠✿)ノ
20:01:01 <rhagarty> o/
20:01:08 <lhcheng> hello everyone
20:01:12 <doug-fish> hi
20:01:14 <lhcheng> david-lyle have a conflict
20:01:16 <tqtran> [-__-]/
20:01:16 <mwhagedorn> hello
20:01:18 <jwy> hi
20:01:31 <hurgleburgler> nice tqtran!
20:01:35 <lhcheng> I'm going to host the meeting for today
20:01:51 <robcresswell> It's a mutiny!
20:01:51 <lhcheng> tqtran stepping it up
20:02:21 * tqtran isn't here.
20:02:39 <lhcheng> #topic Agenda
20:02:53 <lhcheng> #link https://wiki.openstack.org/wiki/Meetings/Horizon
20:03:23 <lhcheng> just a quick update before we start the agenda
20:03:38 <lhcheng> #link https://wiki.openstack.org/wiki/Meetings/HorizonDrivers
20:04:31 <lhcheng> BP review meeting to cut down the open BP we have in launchpad
20:04:49 <lhcheng> we'll be having the meeting until we get into a sizeable amount
20:05:12 <jwy> oops, didn't realize there was a separate meeting for bps. i can take my bp off today's horizon meeting agenda
20:05:13 <robcresswell> I'm putting together a list of angular bps for next week; ping me if you have an important one that has not been reviewed/ prioritised.
20:05:46 <robcresswell> jwy: There may be time, so we can look over it anyway. The other meeting is just *specifically* for bps. This a general meeting.
20:05:50 <lhcheng> robcresswell: I see you already had an agenda for Aug 12?
20:06:03 <jwy> robcresswell: ok thanks
20:06:09 <lhcheng> robcresswell: was there a meeting happened today?
20:06:09 <robcresswell> For this meeting? Yeah a couple of things, may I start?
20:06:22 <robcresswell> The first horizon drivers meeting was earlier today.
20:06:46 <lhcheng> robcresswell: oh.. the time is 2000 UTC
20:06:48 <lhcheng> :P
20:07:14 <robcresswell> ha, so I have a couple of agenda items for this meeting too
20:07:23 <lhcheng> okay
20:07:31 <lhcheng> just one more update
20:07:46 <lhcheng> django1.8 tests are now all passing
20:08:09 <lhcheng> I think the pending work is to cleanup the job for old django version
20:08:18 <lhcheng> and start having django18 job
20:08:31 <lhcheng> I think mrunge already have some patch up for that.
20:08:31 <doug-fish> excellent!
20:08:48 <lhcheng> #link https://launchpad.net/horizon/+milestone/liberty-3
20:09:04 <lhcheng> End of milestone-3 is coming up soon
20:09:21 <ducttape_> did DOA get tagged / released then as well?
20:09:36 <ducttape_> to support django1.8
20:09:37 <lhcheng> so if you have any critical bugs make sure it is tag for L-3 so we can prioritize it for reviews
20:10:21 <rhagarty> lhcheng: what about normal patches? (non-bugs)
20:10:50 <lhcheng> ducttape_: there is a 1.3.1, but that doesn't include the django1.8 yet
20:11:16 <lhcheng> #action david-lyle to tag DOA
20:11:35 <ducttape_> yep, doa needs a new tag for sure, thanks lhcheng
20:11:38 <lhcheng> it is easy to volunteer people when they're not around lol
20:11:54 <ducttape_> todo: dave should fix the bugs
20:12:32 <lhcheng> rhagarty: is it a new feature? maybe you can add it in the meeting agenda for today?
20:12:52 <ducttape_> https://review.openstack.org/#/c/184776/  is a bug I'd like fixed asap, its a fix not from me, but I really could use that patch vs carrying it locally
20:13:06 <rhagarty> lhcheng: it's been around since Kilo-3... I will add
20:13:39 <lhcheng> rhagarty: ugh.. sorry about that.. add me as reviewer, I'll try to look at it
20:14:04 <lhcheng> ducttape_: sounds like to have for L, tag it too
20:14:09 <rhagarty> thank you
20:14:12 <lhcheng> okay, I'm done with the updates
20:14:23 <lhcheng> #topic Discuss desire for multiple overrides, temporary fixes and long term plans
20:14:40 <lhcheng> robcresswell o/
20:14:42 <robcresswell> First item is a small notice: There has been a big effort to make Horizon more "bootstrap compliant" for theming and responsive purposes. When adding new HTML/ CSS please attempt to use the bootstrap styling/ elements/ classes etc. where possible. Same when reviewing designs on invision, make sure to refer to the framework :)
20:14:54 <robcresswell> Oops, I'm messing up your agenda ordering :p
20:15:15 <robcresswell> Small notice aside, on to the topic
20:15:29 <hurgleburgler> robcresswell +1 !
20:15:50 <robcresswell> A lot of Horizon plugins use overrides.py to make deeper customisations
20:15:59 <robcresswell> with the customisation module
20:16:06 <lhcheng> #undo
20:16:07 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0xa245f10>
20:16:10 <lhcheng> #topoc Small notice about using Bootstrap components where possible
20:16:14 <lhcheng> there you go
20:16:20 <robcresswell> haha
20:16:23 <lhcheng> oops
20:16:37 <robcresswell> ...redo?
20:16:47 <lhcheng> I messed it up
20:16:48 <lhcheng> #undo
20:16:49 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0xa007590>
20:16:55 <ducttape_> goto: -5 minutes
20:16:55 <lhcheng> #topic Discuss desire for multiple overrides, temporary fixes and long term plans
20:17:00 <hurgleburgler> lol
20:17:04 <robcresswell> right
20:17:05 <robcresswell> so
20:17:26 <robcresswell> Multiple customisation modules cannot work together, meaning multiple plugins is not viable
20:17:43 <ducttape_> only when they both use overrides - right?
20:17:54 <ducttape_> b/c I have like 3 or 4 plugins running right now, all working
20:17:58 <rhagarty> correct
20:18:01 <robcresswell> Yes
20:18:04 <lhcheng> robcresswell: so that's when mixing overrides and pligins?
20:18:04 <doug-fish> they must all be new panels/dashboards?
20:18:14 <robcresswell> So adding new panels is straightforward and fairly well supported.
20:18:26 <robcresswell> But say two plugins want to override existing workflow steps
20:18:46 <robcresswell> That cannot really be done, as the second plugin overrides the initial plugins overrides.
20:18:57 <rhagarty> the last one to set 'customization_module' wins
20:19:09 <ducttape_> are the enabled files going to remain python?   they could move to just placing customization code in there
20:19:15 <lhcheng> robcresswell: oh..it does not apply on top of it?
20:19:38 <robcresswell> lhcheng: As far as I am aware, we set a key in the Horizon config and it is overriden
20:19:44 <ducttape_> I think of overrides as one / deployment... and not so much for plugin enablement
20:20:03 <robcresswell> Indeed
20:20:08 <lhcheng> ducttape_: I think the enabled files should eventually move to ini files, radomir had a patch up for that.
20:20:25 <doug-fish> yes - I think letting openstack UI components use the overrides is not a good approach
20:20:30 <robcresswell> But it still gets used for other features. For example, in our Cisco stuff, we customise Launch Instance and Firewalls.
20:20:36 <ducttape_> ok. I'd say you still need some type of python plugin __init__.py or something
20:20:46 <robcresswell> through overrides, currently.
20:21:22 <robcresswell> So I was curious about more straightforward methods for customising things like workflows and tables.
20:21:33 <robcresswell> rhagarty, could you discuss your use case too?
20:21:43 <ducttape_> deployers will definitely use overrides to carry a lot of ugly patches in there, or at least I sure would.  I'd vote to keep plugins from using that
20:22:04 <doug-fish> ducttape_: agreed
20:22:34 <doug-fish> I think we covered what this might look like for angular at the mid cycle meetup, right?
20:22:59 <doug-fish> and tqtran captured it in a blueprint for us
20:23:02 <rhagarty> so there is currently an alternative solution for plug-ins to use?
20:23:16 <rhagarty> other than "overrides"?
20:23:22 <doug-fish> no. not current.
20:23:42 <lhcheng> add support to allow plugin to add their hooks/overrides
20:23:43 <ducttape_> there is, but not documented
20:23:44 <lhcheng> ?
20:23:52 <ducttape_> If we move to ini formated plugin config files, I think that is the first decision.  then we can move onto how to do this type of stuff
20:24:00 <rhagarty> so short term can we just fix init to handle multiple overrides?
20:24:04 <robcresswell> So overrides is not the solution, and I agree we should not use it, but I *think* we lack better options.
20:24:36 <ducttape_> I don't think we want to add multiple overrides
20:25:08 <rhagarty> manila_ui currently uses this
20:25:43 <ducttape_> where is the code for this, maybe we can provide some other ideas ?
20:26:10 <rhagarty> https://pypi.python.org/pypi/manila-ui/1.1.0
20:26:16 <ducttape_> thanks
20:26:47 <rhagarty> I also have a plug-in that uses this, so if manila is installed, I'm out of luck
20:27:17 * david-lyle heavily distracted
20:27:19 <ducttape_> and I'd like to use manila eventually, but I wouldn't want it taking away my other overrides
20:27:30 <david-lyle> but overrides.py is wrong another mechanism is necessary
20:27:43 <robcresswell> david-lyle: +1
20:28:18 <rhagarty> we like the behavior it allows, but we just don't the overrides mechanism?
20:28:31 <rhagarty> don't/don't like
20:28:41 <doug-fish> the problem is that overrides allows *everything* in Horizon to be touched
20:28:45 <doug-fish> we need an API
20:28:50 <doug-fish> that can be somewhat stablized
20:29:17 <ducttape_> yep, so like the manila stuff changes quotas... it would be better to add a general api for extending quotas etc
20:29:18 <doug-fish> otherwise we'll be perpetually breaking exensions
20:29:53 <mwhagedorn> does the oslo project have anything like this?
20:30:32 <mwhagedorn> tools to allow some sort of controlled monkey patching...
20:31:07 <doug-fish> I think that's an oxymoron - monkey patching isn't controlled ... by definition I think
20:31:13 <ducttape_> they are pretty early on I think, in adding pluggable extensibility   (I think)
20:31:16 <mwhagedorn> true
20:31:26 <mwhagedorn> you get my point though
20:31:42 <mwhagedorn> has this been looked at before…. by others.. etc
20:32:11 <david-lyle> this is the fine grained extensions we've been discussing
20:32:20 <ducttape_> horizon is somewhat plugable, cinder is too I think.... lots of stuff have extension points, but they usually try to have a particular api to use
20:32:31 <doug-fish> https://blueprints.launchpad.net/horizon/+spec/angular-workflow-plugin
20:33:08 <doug-fish> I know jpomeroy has been experiementing with actually implementing that blueprint
20:33:17 <doug-fish> and his initial experiments looks quite promising
20:33:18 <lhcheng> mwhagedorn: there is stevedore in oslo, it is library for managing plugins
20:33:27 <david-lyle> needs support outside angular too  doug-fish
20:33:34 <robcresswell> Would multiple overrides be bad as a temporary measure? I imagine at this point it is too late in the cycle to have a more cohesive system in place. For Liberty, would multiple overrides help?
20:33:35 <doug-fish> outside angular?
20:33:37 <david-lyle> or of no use to manila-ui
20:33:53 <robcresswell> doug-fish: As in, workflows in python and angular need a plugin system.
20:34:01 <doug-fish> yeah, I know. I think I'm funny.
20:34:08 <robcresswell> ahh
20:34:11 <robcresswell> I'm tired :)
20:34:26 <doug-fish> Wouldn't a similar mechanism be appropriate - a way to define explicit, needed extension points in Horizon
20:34:31 <lhcheng> robcresswell: if we support multiple overrides, we won't be able to remove again without breaking backward compatibility.. :P
20:34:44 <ducttape_> yeah, let's not go down that path
20:34:44 <lhcheng> robcresswell: no such thing as temporary
20:34:50 <robcresswell> That is true, and not something I had considered.
20:34:59 <ducttape_> and what happens when you have multiple overrides, and order matter?
20:35:10 <robcresswell> ducttape_: explosions
20:35:17 <ducttape_> overrides are meant as a home to ugly code
20:35:19 <lhcheng> robcresswell: everything that goes in openstack, never comes out :p
20:35:32 <ducttape_> which is needed, but let's not promote it too widely
20:36:04 <david-lyle> sounds like table column addition/removal is desired as an extension point
20:36:19 <rhagarty> and table/row actions
20:36:21 <david-lyle> or table action addition/deletion
20:36:24 <david-lyle> yup
20:36:32 <ducttape_> so like for manila.... that entire overrides could go into a single __init__.py file and would still work ok
20:36:35 <doug-fish> deletion?  or strictly addition?
20:36:52 <robcresswell> Yeah, the main demands I've had is workflow steps and table columns.
20:36:57 <david-lyle> well, if you are replacing functionality, I would imagine remove
20:36:59 <lhcheng> table/column extension points - thought clu_ had some proposal about that before
20:37:38 <david-lyle> but there's a question of how much power to give to plugins
20:37:49 <ducttape_> rhagarty - have you tried moving the overrides into https://github.com/openstack/manila-ui/blob/master/manila_ui/dashboards/project/shares/__init__.py  ?
20:38:02 <ducttape_> and then removing your overrides altogether ?
20:38:22 <rhagarty> ducttape_: no, but I will try that
20:38:43 <rhagarty> ducttape_: remove my overrides? how does that help my plugin?
20:39:16 <ducttape_> b/c you don't need to use overrides, right?  that is the problem, overrides will still be open then
20:39:41 <lhcheng> ducttape_, rhagarty adding support for extending the quota might not be a bad idea, I imagine other services would also have the same requirements
20:39:42 <rhagarty> sorry, my plug-in does use overrides
20:40:04 <ducttape_> that is fine, at least then manila would not allow it
20:40:11 <ducttape_> not need it, I mean
20:40:17 <rhagarty> gotchar
20:40:23 <rhagarty> gotcha
20:40:45 <ducttape_> lhcheng - yeah, you could redo the existing quotas page to be more plugable too
20:40:56 <ducttape_> and use that as the proof point for this
20:41:24 <ducttape_> I think most projects have the concept of quotas.   limits if you are old
20:41:28 <doug-fish> right - because this is going to break if another project want to monkey patch quotas https://github.com/openstack/manila-ui/blob/master/manila_ui/overrides.py#L187 .... or maybe even if we change quota code
20:41:31 * ducttape_ is old
20:42:18 * doug-fish is maybe jumping ahead a bit about what might break
20:42:31 <ducttape_> I know designate also has quotas, we'd use that too... the extensible quotas thing.
20:42:39 <rhagarty> will the final solution be based on adding hooks to every page?
20:43:04 <ducttape_> rhagarty - not every page, but certainly to common service type things
20:43:47 <ducttape_> doug-fish - you are correct in your concern on how that might work when the quotas page changes
20:43:51 <lhcheng> robcresswell: so for short term plan, maybe the workaround from ducttape_ would work
20:43:58 <doug-fish> this is where multiple overrides for quota will break https://github.com/openstack/manila-ui/blob/master/manila_ui/overrides.py#L267
20:43:59 <robcresswell> ducttape_: Would you have time to add your init suggestion to the docs?
20:44:05 <lhcheng> robcresswell: and for long term, look at providing more extension points
20:44:13 <robcresswell> lhcheng: beat me to it :)
20:44:14 <doug-fish> there can be only one workflow class
20:44:54 <lhcheng> and don't recommend to operators to use the overrides in their plugin
20:44:55 <rhagarty> or maybe leave the plug-in model alone and have some type of certification for plug-ins?
20:45:15 <robcresswell> That sounds time consuming :/
20:45:18 <mwhagedorn> I am missing something.. how does the future existence of extention points help the use case of “pluginA and pluginB both want to mutate default behavior?"
20:45:21 <ducttape_> here is the thing for overrides:  <operators place all your garbage in here/>
20:45:22 <mwhagedorn> who wins?
20:45:24 <mwhagedorn> last?
20:45:32 <mwhagedorn> is that better?
20:45:53 <doug-fish> if there is an addQuotaStep mechanism we can all win
20:46:03 <robcresswell> precisely
20:46:04 <rhagarty> robcresswell: more work than adding entry points to all potential pages that may be extended?
20:46:37 <robcresswell> rhagarty: Realistically it would be one piece of code replicated, like a mixin or something. It's not like every table in Horizon is unique.
20:46:56 <ducttape_> right now with monkey patching and creative use of __init__.py etc... you could have two plugins modify the same thing, if they are both  good citizens
20:47:17 <ducttape_> and if they are both lucky
20:47:19 <robcresswell> Whereas certifying plugins work puts another blocker on plugins, which we wanted to avoid in the first place, and takes a lot of time in understanding plugin code for cores (which we also wanted to avoid)
20:47:20 <doug-fish> ducttape_: how could they both resolve this https://github.com/openstack/manila-ui/blob/master/manila_ui/overrides.py#L267
20:47:22 <ducttape_> luck always helps
20:47:27 <lhcheng> robcresswell: it doesn't sounds like we can address all concerns now
20:47:43 <lhcheng> *can't
20:47:53 <robcresswell> lhcheng: No, agreed. It also sounds like people are resistant to the idea of multiple overrides, which is fine too.
20:48:04 <robcresswell> Just wanted to see what was suggested :)
20:48:09 <ducttape_> doug-fish - hopefully they extend the base class, and the base class might be patched already... and you'd get the super and super versions
20:48:12 <lhcheng> yup, at least we know something for the short term :)
20:48:21 <robcresswell> If we could get the init ideas doc'd somewhere, that would be handy.
20:48:30 <lhcheng> robcresswell: 12 mins - ready to move to the next item?
20:48:48 <ducttape_> I can add docs robcresswell
20:48:54 <robcresswell> Sure, go ahead lhcheng
20:49:01 <robcresswell> ducttape_: Ah, awesome!
20:49:07 <robcresswell> Thanks!
20:49:08 <lhcheng> cool
20:49:21 * ducttape_ not shure aboute my zpellings for docs
20:49:41 <lhcheng> #action ducttape_ to add init docs ideas
20:49:43 <lhcheng> :)
20:49:44 <robcresswell> Well I spell everything with Britlish and get told off for it :(
20:49:44 <lhcheng> #topic Small notice about using Bootstrap components where possible
20:50:01 * robcresswell copy paste time
20:50:17 <lhcheng> robcresswell: you got 3 mins, to give some time to the other two items :)
20:50:22 * lhcheng bad at time management
20:50:36 <robcresswell> pass it along, I mentioned it earlier, but for convenience at topic time: There has been a big effort to make Horizon more "bootstrap compliant" for theming and responsive purposes. When adding new HTML/ CSS please attempt to use the bootstrap styling/ elements/ classes etc. where possible. Same when reviewing designs on invision, make sure to refer to the framework :)
20:50:45 <robcresswell> neeext.
20:51:06 <lhcheng> robcresswell: cool thanks for the reminder
20:51:19 <lhcheng> #topic Add option for users to import images
20:51:25 <lhcheng> jwy: o/
20:51:39 <jwy> here's the blueprint #link https://blueprints.launchpad.net/horizon/+spec/import-images
20:52:00 <jwy> my colleague Sabari (smurugesan) had presented it at the glance midcycle summit and folks there were on board
20:52:09 <jwy> i have some screenshots in there
20:52:32 <ducttape_> how is this different from the current glance image from a url ?
20:52:33 <jwy> basically, i want to put the existing images table in a tab and add a tab to show a table of glance tasks
20:52:45 <jwy> it's a different way of creating images
20:52:58 <jwy> there's some introspection done during the creation
20:53:26 <lhcheng> jwy: would this require a new release of glanceclient?
20:53:58 <robcresswell> jwy: If you get chance, fill out the bp a little more according to the template: https://blueprints.launchpad.net/horizon/+spec/template
20:53:58 <jwy> all the code for the glance side is already there, they just need support in horizon to allow users to use it
20:54:05 <jwy> sure
20:54:06 <lhcheng> robcresswell: ++
20:54:10 <robcresswell> Makes it easier for us to review.
20:54:13 <robcresswell> Thanks!
20:54:23 <jwy> a question about making changes in the Create Image form -
20:54:37 <ducttape_> image management and importing, if this helps automate some of that it would be awesome.  If we can make the user experience obvious of this mode vs the old mode that would be nice
20:54:46 <jwy> there's a currently a "copy data" option, and in my screenshot, i've changed it to "import data"
20:54:50 <jwy> the new way of image creation is preferred
20:55:00 <jwy> do i need to keep the old option around?
20:55:35 <doug-fish> yes, please
20:55:46 <lhcheng> jwy: yes
20:55:47 <ducttape_> what happens when new horizon encounters an older version of glance?
20:55:48 <doug-fish> I added that after getting a consumer requirement for it
20:56:13 <jwy> doug-fish: that = ?
20:56:25 <jwy> ducttape_: hm good question
20:56:42 <jwy> how do we handle that normally in horizon, different client versions
20:56:42 <doug-fish> that = "copy data" option, - I think you are saying this isn't just a rename of the same function, right?
20:56:44 <lhcheng> ducttape_: horizon should check if that extension is available or have a config to hide the import task by default
20:57:02 <david-lyle> what did I miss ;)
20:57:07 <ducttape_> you might want to make a upload form that extends from the current form, and make a config file to switch between versions... or what lhcheng said
20:57:20 <jwy> lhcheng: it's not an extension, though, a new api added in v2 of glanceclient
20:57:39 <lhcheng> I think we can discuss the implementation details
20:57:44 <lhcheng> later
20:57:48 <jwy> doug-fish: right, it would be replacing "copy data". i'll let users pick from "import" or "copy" then
20:58:14 <lhcheng> this sounds good for L-3, it is not intrusive and just add new feature
20:58:47 <lhcheng> jwy: sorry have to move to last item
20:58:50 <david-lyle> we already check for glance API version, so you can use that
20:58:51 <doug-fish> jwy: doesn't that exclude the option to not import or copy?
20:58:55 <lhcheng> #topic Added volume type description for volume type
20:59:02 <rhagarty> I would appreciate any core reviews for https://review.openstack.org/#/c/133872/
20:59:22 <lhcheng> doug-fish, jway: we can continue the discussion on the horizon room
20:59:24 <rhagarty> it's been out there since Kilo-3, but needed a cinder client
20:59:42 <rhagarty> so it was held back till liberty
20:59:54 <lhcheng> rhagarty: is the cinderclient requirement bump available now?
20:59:59 <rhagarty> anyway, hoping to get some core reviewers
21:00:16 <rhagarty> lhcheng: yes, it is in Kilo
21:00:40 <lhcheng> rhagarty: let's try to get it into L-3
21:00:44 <lhcheng> thanks
21:00:48 <lhcheng> time's up
21:00:49 <rhagarty> really appreciate it.
21:00:54 <lhcheng> thanks everyone
21:00:58 <rhagarty> bye
21:00:59 <lhcheng> #endmeeting