20:01:58 <david-lyle> #startmeeting horizon-drivers
20:01:59 <openstack> Meeting started Wed Aug 19 20:01:58 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:02:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:03 <openstack> The meeting name has been set to 'horizon_drivers'
20:02:18 <david-lyle> was looking up name to use, forgot
20:02:24 <david-lyle> anyone here?
20:02:27 <robcresswell> o/
20:02:29 <robcresswell> sleepily
20:02:35 <bpokorny> o/
20:02:36 <TravT> o/
20:02:41 <tsufiev> o/
20:02:58 <crobertsrh> hello/
20:03:16 <clu_> hi
20:03:19 <tqtran> [=_=]?
20:03:24 <tqtran> [=_=]/
20:03:44 <tsufiev> tqtran, is it a sleepy smile?
20:04:01 <tqtran> hehe cat like face
20:04:40 <david-lyle> Alright, to rehash purpose briefly for those who don't bounce timezones
20:05:02 <david-lyle> We voted and created this meeting to clean up the bp backlog
20:05:16 <david-lyle> it's too big for one person to manage and there are many that are stale
20:05:58 <david-lyle> we will use this meeting to review/update bps and help align the developers/reviewers
20:06:09 <david-lyle> that's my summary
20:06:19 <david-lyle> we held the first on last week at 1200 UTC
20:06:31 <david-lyle> and went through approx 10 bps
20:06:41 <david-lyle> culling some and approving others
20:06:51 <david-lyle> which I forgot to #info in the logs
20:06:56 <david-lyle> remind me this week
20:07:17 <david-lyle> Wanted to tackle the mound of angular bps this week
20:07:21 <robcresswell> Agenda: https://wiki.openstack.org/wiki/Meetings/HorizonDrivers#Agenda_for_August_19_2000_UTC
20:07:27 <david-lyle> robcresswell: put together a nice list
20:07:39 <david-lyle> #link https://wiki.openstack.org/wiki/Meetings/HorizonDrivers#Agenda_for_August_19_2000_UTC
20:07:50 <robcresswell> It's not exhaustive, so feel free to volunteer others, but I just thought it would get us started
20:07:54 <robcresswell> oops, forgot the link.
20:07:59 <david-lyle> no worries
20:08:24 <david-lyle> I cleaned up a couple of those this morning because they were already completed :)
20:08:27 <tqtran> ty robcresswell!
20:08:47 <david-lyle> #info https://blueprints.launchpad.net/horizon/+spec/jscs-cleanup completed
20:09:02 <david-lyle> #info https://blueprints.launchpad.net/horizon/+spec/babel-translate-inner-tags completed
20:09:07 <tqtran> yep yep
20:09:11 <TravT> :)
20:09:15 <david-lyle> no point in talking about those now
20:09:49 <david-lyle> not sure about order, so we'll just start at the top
20:10:04 <david-lyle> I do have one greater question regarding the angular work
20:10:09 <TravT> Thai, this is the one that you filed as a result of our brainstorming at the mid-cycle right?
20:10:40 <david-lyle> https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/rest/__init__.py#L17
20:11:33 <david-lyle> if we are creating a plugin environment and encouraging devs to use angular for plugins, how can this hold true?
20:11:42 <tqtran> TravT: yes
20:12:05 <TravT> david-lyle: i remember when we add that... similar statement here: https://wiki.openstack.org/wiki/Horizon/RESTAPI
20:12:23 <TravT> back when we did it, i believe there was the following reasoning:
20:12:27 <tqtran> david-lyle: are horizon plugins are still consider part of horizon?
20:12:42 <david-lyle> I remember it being added
20:12:50 <david-lyle> tqtran: good question
20:13:05 <tqtran> wow that was super bad grammar lol
20:13:07 <TravT> 1) The work was early and we weren't sure if we were putting in the right APIs.
20:13:21 <david-lyle> if not should we expect the plugin to duplicate say all the keystone logic it needs?
20:13:31 <david-lyle> that seems silly
20:13:42 <david-lyle> two APIs for the same thing
20:14:19 <david-lyle> same holds true for widget structure
20:14:31 <TravT> 2) We were worried about how long we'd have to keep the API constant, because things like Nova API can't ever go away.
20:14:51 <david-lyle> I take kfox1111 as a example
20:15:24 <tqtran> i think we can just remove the message? i don't think there is any code out there that is 100% fool proof
20:15:43 <david-lyle> well it becomes a question of support
20:15:46 <TravT> I think we need to start considering versioning then
20:15:54 <tqtran> >< i see......
20:16:01 <TravT> additive changes aren't generally a problem.
20:16:04 <david-lyle> what versions of horizon will the plugin work with
20:16:16 <david-lyle> no additive changes are fine
20:16:23 <tqtran> so versioning atm is controlled by horizon's python layer
20:16:26 <david-lyle> but they should probably be versioned
20:16:47 <tqtran> and the REST simply taps into that same python layer, does it need its own?
20:16:48 <david-lyle> microversioned, but versioned
20:16:53 <TravT> but once an API is supported, if you change how it behaves, then you have ramifications.
20:17:05 <david-lyle> tqtran: and API is a contract
20:17:09 <david-lyle> s/and/an
20:17:15 <david-lyle> it will do this when I do this
20:17:37 <david-lyle> change the behavior randomly and noone has any idea what's going on
20:17:48 <david-lyle> and what to trust
20:18:12 <david-lyle> of all the angular supporting code, fortunately that has been the most stable
20:18:20 <TravT> these APIs already will have some differences in data based on the deployment environment (e.g. diff service version)
20:18:22 <david-lyle> but I think we should make a plan
20:18:37 <TravT> so, that makes this already a little bit of a different beast to talk through
20:19:13 <tqtran> hold on, our REST api atm is dependent on the python layer, which does version control
20:19:34 <tqtran> are we doing to have to modify that python layer for versioning as well?
20:19:56 <david-lyle> that's different
20:20:28 <tqtran> ok i see what you're saying....
20:20:56 <david-lyle> we just need to make sure a plugin can figure out if it can talk to the Horizon REST layer
20:21:12 <david-lyle> or if it's speaking something different
20:21:30 <david-lyle> but let's get back to the main review, and revisit in the regular meeting, just wanted to plant the notion in peoples' minds
20:21:34 <tqtran> ok then our REST layer is tightly coupled with whatever version of horizon you are using
20:21:39 <tqtran> ok
20:21:49 <david-lyle> tqtran: yes or no :)
20:21:56 <tqtran> yes
20:22:01 <david-lyle> no?
20:22:10 <tqtran> i just wanted to understand a bit better :P
20:22:15 <david-lyle> ok, reviewing https://blueprints.launchpad.net/horizon/+spec/angular-workflow-plugin
20:22:30 <TravT> it wouldn't hurt to do a real review of all these and make sure they are written in an extensible way.  I think there might be a few spots on the angular side where the functions take positional arguments rather than an object with options.
20:23:16 <TravT> david-lyle: re: https://blueprints.launchpad.net/horizon/+spec/angular-workflow-plugin
20:23:25 <david-lyle> here's a case where WIP on the code means I have no f'n clue what's going on
20:23:41 <tqtran> looks like justin has started work on it alreay
20:23:45 <TravT> that is the result of about 6 of us brainstorming at the whiteboard at the mid-cycle
20:24:11 <jpomeroy> yup, have something you can look at, just don't have anything documented, that's the only reason for the WIP
20:24:26 <tsufiev> tqtran, I have a question about priorities thing in this BP
20:24:35 <jpomeroy> i assume we will want some developer doc with examples i mean
20:24:37 <tqtran> tsufiev: shoot
20:24:39 <david-lyle> jpomeroy: that's fine
20:24:47 <david-lyle> just always confuses me
20:24:52 * david-lyle is easily confused
20:25:00 <tsufiev> tqtran, you aren't going to reuse the contribute-depends concept from pythonic horizon workflows, are you?
20:25:38 <tqtran> 0_0 i have no idea what "contribute-depends concept from pythonic horizon workflows" is, you mean like inheritance?
20:25:55 <david-lyle> I actually think the bp is reasonable, but I feel like it's definitely an M item
20:26:04 <tqtran> yes agree
20:26:06 <tsufiev> because this priorities seem pretty arbitrary for the different steps of the same workflows... perhaps I missing how the new Angular workflows are going to work...
20:26:28 <david-lyle> #info only 2 weeks in L-3
20:26:46 <tqtran> basically, it lets you "inherit" and override/add/edit workflow steps
20:27:25 <robcresswell> tqtran: I have a lot of +2s for code that does that
20:27:29 <david-lyle> tqtran: I'm guess tsufiev is saying two plugins could have priority 2
20:27:41 <david-lyle> depending on source
20:27:45 <tsufiev> tqtran, okay, I was thinking about workflows as a thing that pipelines steps so that a successive step is dependent on the data provided by previous
20:27:52 <tsufiev> and here the ordering comes
20:28:23 <tqtran> ah gotcha
20:28:25 <david-lyle> blue and red may both be third parties
20:28:33 <tsufiev> david-lyle, and yes, nobody could restrict to declare the same priority )
20:29:16 <tqtran> yes, so the load order is important, so need to name your files in a way to ensure this load order
20:29:27 <tqtran> much like our enabled files today
20:30:14 <tqtran> as for dependent steps, angular has event propagation like DOM event propagation via $emit
20:30:22 <TravT> the data aspect is very interesting actually.  why the contribute depends is a good concept is that the steps may change in the base workflow you are extending, but often it is some data that you need to ensure is available.
20:30:51 <tqtran> so dependent steps would get a chance to do something, it shouldn't be an issue
20:31:31 <tqtran> well, if the base step changes, you'd have to update your code.... thats just how it goes i think
20:31:51 <jpomeroy> can't dependent steps just set up a $watch on the data?
20:32:00 <tsufiev> tqtran, I got your point, need to examine it more carefullly - atm I'm not very familiar with modern angularized Horizon
20:32:08 <TravT> here's my question: will this be far enough along in a few weeks that we'd want to support it forever?  Or should it delay to M?
20:32:19 <tqtran> i vote for delay
20:32:25 <david-lyle> delay
20:32:31 <tqtran> its too rushed, 2 weeks is not enough time to hash out stuff
20:32:35 <david-lyle> which I already added to the comments
20:33:14 <TravT> i vote that too, mainly because I know I won't personally have time to put a lot of thought into it in the next few weeks.
20:33:27 <david-lyle> do we want to approve or move to discussion?
20:33:36 <david-lyle> I think the majority is in place
20:33:39 <david-lyle> bp wise
20:33:56 <david-lyle> some implementation details are left to be figured out
20:34:02 <TravT> jpomeroy, dissent?
20:34:22 <jpomeroy> i did not realistically expect it to make L
20:34:23 <robcresswell> agree with delay, I think the bp idea is okay, but implementation may need discussion...?
20:34:42 <david-lyle> I ranked it High
20:34:43 <jpomeroy> delay to M makes sense to me
20:35:05 <david-lyle> but will approve unless there are objections
20:35:13 <robcresswell> go ahead
20:35:30 <TravT> no, we'll figure out more details during code review.
20:35:45 <tqtran> no objection
20:35:56 <david-lyle> #info https://blueprints.launchpad.net/horizon/+spec/angular-workflow-plugin approved for Mitaka
20:36:04 <david-lyle> ok, next
20:36:22 <TravT> i don't see a series goal on it?
20:36:32 <david-lyle> #link https://blueprints.launchpad.net/horizon/+spec/angularize-identity-projects
20:36:46 <david-lyle> TravT: on whiteboard, mitaka isn't a choice yet
20:36:48 <tqtran> M isn't on the list yet
20:38:33 <david-lyle> So I don't think we have a reusable pattern fully in place yet to approve the projects panel angularization
20:39:36 <tqtran> yeah, still working on that, i'm close to having something for review, we're close but not quite there yet
20:40:58 <david-lyle> I favor pushing this bp until we have the standard
20:41:03 <pauloewerton> maybe we could consider pushing through the code for the panel enablement and table?
20:41:13 <pauloewerton> in a same fashion as the users and images table
20:41:20 <TravT> i'm not sure what all is missing from projects panel?
20:41:36 <pauloewerton> TravT, the workflows basically
20:41:44 <tqtran> right, the table code is all there
20:41:50 <tqtran> just the actions is missing
20:42:06 <david-lyle> so what do I do with the table code?
20:42:10 <TravT> have you looked at using the existing actions?
20:42:58 <pauloewerton> yeah, I'm following the same pattern in https://review.openstack.org/#/c/202315/ for the actions
20:43:02 <david-lyle> the big push for angular in tables was uniform filtering, sorting and pagination. Is that supported?
20:43:26 <david-lyle> acknowledging that for v3 projects pagination is not possible
20:44:03 <tqtran> yes, filtering sorting and paging all supported but also all client-side atm
20:44:21 <david-lyle> when I drop the 800 lines of code into the tree what do I get?
20:45:39 <david-lyle> I go back to this because there are few people doing active maintenance on horizon currently, and as one of them, I'm not excited about more work for uncertain gains
20:46:04 <david-lyle> I think we've lost some focus on what we were doing and went all shotgun approach
20:46:21 <tqtran> so we gave a demo of this a while back, the actions that you perform are extremely fast
20:46:35 <david-lyle> all over the place and not really hitting the mark
20:46:36 <tsufiev> david-lyle, users, iirc
20:46:49 <tqtran> right now, it doesn't seem like we're gaining much, but that is because of the infra and design work we are putting in to ensure quality
20:46:51 <TravT> responsive table, table drawers with extra info, etc
20:47:16 <TravT> but, my question goes back to what you asked david-lyle, can we use existing django actions / details pages
20:47:24 <TravT> and then replace them gradually
20:47:25 <tqtran> as i said, by the end of the week, i'll have something you can test out and see for yourself
20:47:45 <david-lyle> TravT, it's just routing, I wouldn't see why not
20:47:54 <TravT> so we focus on table without having to do complete panel.
20:48:12 <david-lyle> tqtran: and that's fine, I think the users table was already approved as a bp
20:48:29 <david-lyle> and that was it's purpose to define the pattern and infrastructure
20:48:43 <tqtran> ok i see what you're getting at
20:48:53 <ducttape_> is the responsive table thing a css thing?  will css styles be the same across both?
20:49:24 <david-lyle> it hides columns on resize
20:49:42 <david-lyle> collapses the view, but leaves the actions available
20:49:43 <TravT> it also has the hidden data show up in the table drawer when expanded
20:49:55 <TravT> images table does anyway...
20:50:01 <TravT> users table actually does not.
20:50:13 <ducttape_> seems helpful for all the tables, maybe a can of worms.  but having two different experiences on pages is going to be wonky w users
20:50:14 <david-lyle> there is no more data for users
20:50:24 <TravT> I'm talking when resizing.
20:50:37 <TravT> so if you have columns A - G
20:50:56 <TravT> you put a responsive priority on say EFG to disappear first.
20:51:18 <TravT> and in the table drawer, you have that same data remain hidden with the same responsive priority
20:51:39 <ducttape_> I guess that css could be added to older pages too?  stuff where responsive is more important than going through the angular rewrite pain
20:51:41 <TravT> so, when you resize the screen, columns EFG go away, but the data is still visible by expanding the table drawer.
20:51:46 <tqtran> so going back, i guess the question is, do we want to wait on approval until the pattern and infra work are in place? or is it ok to allow other works to go in parallel?
20:52:28 <david-lyle> tqtran: other work can progress, but I don't really want it in tree until we have a baked format
20:52:47 <david-lyle> or we'll lose another release to moving all the files and refactoring again
20:52:47 <tqtran> so going back to the feature branch idea?
20:53:42 <david-lyle> it can remain straight patches too, but I think the functionality should forklift in when ready
20:54:08 <david-lyle> that could be at the view level even
20:54:26 <tqtran> sorry im not following, what do you mean by straight patches? and forklift?
20:54:43 <TravT> patch dependencies
20:54:50 <david-lyle> tqtran: normal patch vs feature branch
20:55:04 <tqtran> ok
20:55:06 <david-lyle> and complete feature dropped in
20:55:27 <david-lyle> not an approximation
20:55:36 <david-lyle> that hits and misses
20:56:02 <tqtran> got it
20:56:07 <david-lyle> I have an almost ready launch instance workflow to demonstrate what I don't want to happen
20:56:25 <robcresswell> heh
20:56:34 <TravT> progress?
20:56:34 <robcresswell> Is Launch Instance going to be ready for L?
20:56:57 <david-lyle> because there is a ton of great work in there, that isn't quite ready to use
20:57:04 <david-lyle> and it's idle
20:57:10 <lhcheng> Is anyone looking at the bugs reported?
20:57:29 <TravT> speaking of which robcresswell, did you open a BP on the add network workflow?
20:57:34 <TravT> is that on your list?
20:58:12 <david-lyle> My vote is to push projects panel angularization to M too until we are relatively sure we have a solid framework and example to build from
20:58:24 <tqtran> I'm fine with that
20:59:02 <robcresswell> TravT: It is, Matt spoke to me about it last week
20:59:07 <david-lyle> doesn't mean there's not good work in it and that it won't be valuable, but I want to set up a path for greater progress and success
20:59:14 <robcresswell> david-lyle: Agreed
20:59:20 <tqtran> so how will review for it work, do we hold off until the complete feature is there?
20:59:59 <robcresswell> Have we agreed to use feature branches now btw?
21:00:25 <TravT> no
21:00:26 <david-lyle> tqtran: if people want to review and provide feedback, even if it's looks like you're on the right track, there's value in that
21:00:28 <tqtran> that depends on dave's answer to he question above lol
21:00:38 <TravT> robcresswell, we discussed at mid cycle
21:00:46 <robcresswell> Ah, okay
21:00:51 <david-lyle> but I don't want to merge it until done
21:00:53 <TravT> feature branches didn't seem necessary, yet
21:01:05 <david-lyle> robcresswell: I'm in favor others aren't, both are workable
21:01:22 <robcresswell> Interesting
21:01:27 <david-lyle> bygones
21:01:33 <robcresswell> sure
21:01:37 <robcresswell> we're out of time
21:01:50 <robcresswell> I've carried over the other bps to next weeks agenda, if that seems okay?
21:02:27 <david-lyle> #info https://blueprints.launchpad.net/horizon/+spec/angularize-identity-projects approved but pushed to Mitaka pending the finalized users panel as example
21:02:31 <tqtran> lol we only covered like 3 bps? hahaha
21:02:53 <robcresswell> psh :p
21:03:06 <robcresswell> Last week we managed about 15 haha
21:03:21 <TravT> they were more about things that were old, though right?
21:03:26 <TravT> not active development ones
21:03:29 <robcresswell> Yeah
21:03:35 <david-lyle> but most of those were stale or less controversial yea
21:04:03 <TravT> end of release is always hard.
21:04:05 <robcresswell> I've updated list for next week.
21:04:12 <robcresswell> Oh yeah. Its review mania time now.
21:04:15 <david-lyle> Thanks everyone! I hope people find this useful. It is much better than just me trying to walk through all of them on my own
21:04:21 <TravT> +1
21:04:27 <david-lyle> 2 weeks people for L
21:04:29 <tqtran> Thanks for going over them!
21:04:36 <david-lyle> did I say that already
21:04:37 <david-lyle> ?
21:04:41 <david-lyle> #endmeeting