20:00:28 <mrunge> #startmeeting Horizon
20:00:29 <openstack> Meeting started Wed Jan 14 20:00:28 2015 UTC and is due to finish in 60 minutes.  The chair is mrunge. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:32 <openstack> The meeting name has been set to 'horizon'
20:00:37 <mrunge> hello there
20:00:45 <ericpeterson> hello
20:00:50 <rbertram> hi
20:00:55 <rhagarty> hello
20:00:57 <jgravel> hi
20:01:00 <gary-smith> hello
20:01:10 <crobertsrh> hello/
20:01:24 <bradjones> o/
20:01:29 <mrunge> #chair mrunge david-lyle_
20:01:29 <openstack> Current chairs: david-lyle_ mrunge
20:01:33 <mrunge> :D
20:01:42 <clu_> hi
20:01:49 <mrunge> David will show up in a few mins
20:01:57 <TravT> o/
20:02:23 <mrunge> we don't have an agenda for today
20:02:58 <gary-smith> is it a hidden agenda? :-)
20:03:30 <mrunge> so, if I remember right, we did not finish last weeks meeting
20:03:38 <sambetts> o/
20:04:06 <mrunge> I'll leave announcements for David, when he'll show up
20:04:32 <mrunge> #topic Angular work blockers
20:05:26 <mrunge> Richard Jones, are you there, by any chance?
20:05:32 <mrunge> or tqtran ?
20:05:33 <TravT> well, we got the version upgrade in as well as angular-bootstrap
20:05:46 <tqtran> actually, i have something i wanted to bring up, just to gauge community interest
20:06:13 <tqtran> so kelly from HP have been working on the new angular table stuff
20:06:18 <tqtran> its available here: https://github.com/ongk/responsive-smart-table
20:06:37 <tqtran> just wanted to know if people are generally ok with the newer tables looking a bit different
20:07:04 <mrunge> tqtran, thanks for sharing!
20:07:05 <david-lyle_> different how?
20:07:20 <tqtran> its similar to what piet has shown on envision
20:07:36 <tqtran> well, similar is the wrong word, its basically the implementation of what piet showed
20:07:58 <TravT> So, you can see the look and feel in the launch instance mocks.
20:08:02 <TravT> http://invis.io/SG1YAG2WC
20:09:22 <tqtran> ok silence means we're in the green? haha
20:09:50 <rbertram> My general answer is I like it, though I'm still thinking about some of the details. I am involved in discussions on this.
20:10:15 <rbertram> The question may be: can we break consistency with the existing tables for Kilo?
20:10:15 <gary-smith> Am I seeing correctly that all row actions are hidden inside of the + ?
20:10:29 <TravT> gary-smith:
20:10:31 <TravT> no
20:10:37 <mrunge> #chair mrunge david-lyle david-lyle_
20:10:38 <openstack> Current chairs: david-lyle david-lyle_ mrunge
20:10:38 <TravT> that is actually specific to launch instance
20:10:56 <david-lyle_> #chair david-lyle
20:10:56 <Piet> Did I hear my name?
20:10:57 <openstack> Current chairs: david-lyle david-lyle_ mrunge
20:10:59 <TravT> it is how you select one.  This was the result of several weeks of usability testing
20:11:15 <tqtran> gary-smith: i high recommend that you download the repo above, it has several examples
20:11:25 <gary-smith> I am looking at the example
20:11:36 <david-lyle> tqtran: can you repost the link for invision?
20:11:43 <david-lyle> on real screen now
20:11:43 <tqtran> the one in the invision is a bit different
20:12:21 <tqtran> piet: do you have a link to the one kelly implemented?
20:12:23 <david-lyle> oops, that was TravT
20:12:35 <tqtran> http://invis.io/SG1YAG2WC
20:12:52 <TravT> ok, so that is launch instance
20:12:53 <Piet> Final Design for Launch Instance http://invis.io/DW1XZIUH2
20:13:13 <TravT> here is an alternate one that shows actions in more of a standard listing table (not a selection table)
20:13:15 <TravT> http://invis.io/YA1KV4VTP
20:13:20 * david-lyle munging topics
20:13:31 <TravT> Piet: if there is a newer one, please share.
20:13:37 <robcresswell> Why hide the first row action? Normally the first is shown, usually edit. Seems that would be faster, less clicks, than hiding them all.
20:13:44 <tqtran> yes, the latest one TravT showed is what kelly implemented
20:13:58 <Piet> Just shared most recent Launch Instance - http://invis.io/DW1XZIUH2
20:14:44 <david-lyle> in that case is create flavor the only table action?
20:14:59 <TravT> david-lyle: which one are you referencing?
20:15:11 <tqtran> https://openstack.invisionapp.com/share/YA1KV4VTP#/screens
20:15:57 <tqtran> im sure we can add more batch actions as needed, its just a mock up
20:16:27 <david-lyle> tqtran: my concern is layout
20:16:59 <TravT> robcroswell: i think you are referencing the launch instance mocks.  In that one, if you click the + button, it selects it and pops it to the selected ones.
20:17:01 <david-lyle> I've talked to Piet and he and seeing examples has convinced me that we can put filtering and actions on different lines
20:17:10 <david-lyle> allowing us to expose more actoins
20:17:22 <TravT> robcrosswell: this one may make it more obvious how that one works: https://openstack.invisionapp.com/share/SG1YAG2WC#/screens/55177821?maintainScrollPosition=false
20:17:31 <tqtran> understood, basically, the question is: are we ok with moving new angular table in this direction? theres still time for us to determine the actual layout, but we can begin work down this road
20:18:25 <rbertram> tqtran: you want us to focus on the table only, not the overal context?
20:18:40 <tqtran> yes just focus on the table styling primarily
20:18:44 <david-lyle> we're changing technology stack, there isn't a better time to change look and feel
20:18:53 <TravT> david-lyle: +1
20:19:00 <david-lyle> if we can improve usability, we should
20:19:00 <tqtran> ok perfect, thats all i needed to hear
20:19:18 <david-lyle> additionally forcing new tools to look like old is a waste of time IMO
20:19:28 <mrunge> yes!
20:19:35 <wchrisj> david-lyle: +1
20:19:43 <mrunge> and we were changing that anyways
20:19:49 <david-lyle> yes
20:20:03 <david-lyle> So yeah, move forward
20:20:26 <rbertram> I agree. So Kilo will have some tables of the old style that have not been converted yet, right?
20:20:26 <david-lyle> I want to point out for launch instance
20:21:19 <david-lyle> rbertram: yes, but I'm thinking there won't be more than 1 or two in the new format
20:21:26 <david-lyle> and those would likely be in the wizard
20:21:33 <rbertram> david-lyle: good, making sure we have right expectation
20:21:53 <rbertram> (foreseeing concerns raised about consistency at end of kilo)
20:22:11 <david-lyle> rbertram: it's never been a concern before ;)
20:22:20 <rbertram> ah, ok
20:22:37 <david-lyle> back to launch
20:22:44 <david-lyle> we need to close on the design
20:22:50 <david-lyle> and move the bp to approved
20:23:12 <TravT> yes, this will be very helpful. today we had a review with Piet on the in progress styling.
20:23:19 <david-lyle> unless there is amazing concerns raised in the next day or two, I'm going to move to approved
20:23:31 <Piet> Agreed
20:23:58 <TravT> btw, for reference: https://blueprints.launchpad.net/horizon/+spec/launch-instance-redesign
20:24:37 <Piet> Some of the questions I'm seeing are around implementation of the design.  Fully anticipate some compromises due to constraints
20:24:47 <david-lyle> I feel it's a strong improvement and we can move incrementally from there if necessary
20:25:15 <david-lyle> Piet: that's always a concern when doing design divorced from implementation
20:25:22 <rbertram> TravT & Piet: is there a central place for input on the new table design? separate from the contexts of the tables.
20:25:28 <david-lyle> there will be compromises to make
20:26:16 <Piet> Just as an FYI, I'm trying to set the high level vision for the design.  Try to motivate the group to see the where we can go...
20:26:35 <tqtran> when we're done discussing this, i do have another topic to bring up, this one concerns consolidating javascripts.
20:26:55 <TravT> rbertram:  this project for now: http://invis.io/YA1KV4VTP
20:27:07 <rbertram> TravT: thx
20:27:19 <TravT> I also would like to talk about the base REST API patch, even if r1chardj0n3s isn't here
20:27:39 <tqtran> you can go first TravT
20:27:44 <TravT> thx.
20:27:56 <Piet> Real quick thanks to all of you that helped with the UX design process!
20:28:04 <TravT> so, we have a lot of dependencies between the launch instance and table designs.
20:28:15 <TravT> one of them is at least getting the base rest API utility patch landed
20:28:16 <TravT> https://review.openstack.org/#/c/136676
20:28:35 <TravT> current debate seems to be a final question on validation with lhcheng and david-lyle
20:28:53 <david-lyle> TravT: I talked to Richard about that, I'm trying to get back to it
20:28:53 <TravT> i put up a potential compromise solution, so would like feedback on that.
20:29:42 <TravT> david-lyle: okay.
20:30:03 <TravT> then we can focus more on the actual API's and hopefully iterate there
20:30:24 <david-lyle> I think his point is valid that out interactions with the clients could be made consistent, contracts with the client wrappers
20:30:43 <david-lyle> I'll try to hit again today
20:30:50 <TravT> ok.  thanks
20:30:57 <TravT> tqtran: over to you.
20:31:04 <tqtran> thanks TravT
20:31:18 <tqtran> so basically, we're going to end up with angular code in openstack_dashboard
20:31:34 <tqtran> they belong there because its specific to each panel
20:31:50 <tqtran> so user identity will have its own js controller file, etc...
20:32:04 <tqtran> the way we have it right now, all of your js is in horizon
20:32:09 <tqtran> *our js
20:32:42 <tqtran> the idea was that we only incorporate js libs in horizon, and for panel specific js, we have it in openstack_dashboard
20:33:25 <tqtran> i have tried pulling most things from horizon, but that doesnt work because we have selenium tests using those js in horizon
20:33:52 <tqtran> so we're actually stuck with putting most of our legacy js files in horizon
20:34:19 <tqtran> but for the new angular js stuff, i propose that we start moving them to openstack_dashboard, wanted to get a consensus on this
20:34:25 <rbertram> tqtran: what about general directives & even controllers that are used in multiple panels? still in openstack_dashboard?
20:34:26 <mrunge> tqtran, but, if someone would use horizon as framework, he would re-use that js code anyways?
20:34:33 <tqtran> https://review.openstack.org/#/c/141457/ here is the patch
20:35:11 <tqtran> mrunge: its possible, but the js code is very specific to each panel
20:35:29 <tqtran> mrunge: its like arguing that our panel code in python today can be reuse as well
20:35:40 <mrunge> darn, I hoped, it would be a bit more maintainable
20:35:58 <TravT> well, some things still will be in horizon
20:36:03 <mattfarina> tqtran putting the angular code that's specific to a panel in openstack_dashboard makes sense.
20:36:15 <tqtran> mrunge: https://review.openstack.org/#/c/133767/25/horizon/static/horizon/js/angular/dashboards/hz.identity.users.js here is an example of a controller in js specifically for the users panel
20:36:41 <tqtran> rbertram, TravT: yes, reusable things like wizard, tables, will still stay in horizon
20:36:48 <david-lyle> tqtran: there will be wizard framework and step content
20:36:51 <mrunge> tqtran, and why the heck can't we put that to openstack_dashboard?
20:37:04 <david-lyle> those two could be logically split horizon and openstack_dashboard
20:37:07 <tqtran> mrunge: we could, i wouldnt be oppose to that either
20:37:28 <david-lyle> I think mrunge is referring to those common base wdigets
20:37:43 <mrunge> david-lyle, yes and no
20:37:58 <david-lyle> specific panel content and steps certainly lives in openstack_dashboard, as it does today
20:38:07 <mrunge> I would like to have stuff separated as much as possible
20:38:19 <mrunge> this makes it easier to maintain it
20:38:41 <david-lyle> I could see, more things in openstack_dashboard like usage
20:39:03 <david-lyle> things used in multiple views
20:40:41 <tqtran> mrunge: just to clarify, so you're saying that you like it better if the reusable JS components live in horizon, and the panel-specific JS code lives in dashboard?
20:41:07 <mrunge> tqtran, I'd say: yes
20:41:21 <tqtran> mrunge: ok, then i guess we're all pretty much in agreement
20:41:26 <mrunge> :D
20:41:52 <tqtran> one last thing, does it make sense to combine _conf and _scripts?
20:42:06 <mrunge> tqtran, nope.
20:42:08 <tqtran> i think it makes its easier to have all of our js dependencies in one place
20:42:17 <mrunge> tqtran, I added a comment to that patch
20:42:19 <tqtran> not sure i understand why we need 2
20:42:35 <mrunge> easier to read?
20:43:00 <mrunge> smaller files for a dedicated reason rather than a large file with everything mixed up?
20:43:20 <tqtran> yes, but its very confusing for newer developers. we're generally use to having a single index.html where all of our scripts are loaded
20:43:35 <tqtran> the only thing in there are script tags
20:43:38 <mrunge> new developers are python developers.
20:43:47 <tqtran> i would argue that its easier to read when all scripts are in one place
20:43:54 <mrunge> so, almost *everything* is new
20:44:15 <mrunge> I'm not a friend of huge spaghetti-like files
20:44:17 <rhagarty> hello
20:45:27 <tqtran> the way we have it right now, we have import statements for angular modules in two different places
20:45:50 <tqtran> its very confusing even to me where i should put my js script
20:46:01 <david-lyle> I need to look at the content of each again, but unless they serve different purposes, I'm not sure I see the need for a split
20:46:22 <david-lyle> is one in horizon and one in openstack_dashboard?
20:46:37 <tqtran> none in openstack atm
20:46:42 <mrunge> david-lyle, it's this patch here: https://review.openstack.org/#/c/141457/
20:46:44 <tqtran> all the js scripts are in horizon
20:47:02 <mrunge> and I was arguing: no need to move all stuff from one file to another
20:47:32 <david-lyle> I know I looked at this before, trying to resync
20:47:49 <tqtran> yes, i also introduced the idea in the ML
20:49:52 <david-lyle> tqtran: I recall
20:51:25 <david-lyle> ok, I have to look more
20:52:00 <tqtran> ok, just wanted to bring it up so people are aware. im open to feedback and if there is a good reason, im all ears.
20:52:13 <gugl2> tqtran, TravT question if I have a change which has some js code...I am required to use angularjs now?
20:52:48 <TravT> Actually, we are looking to move to COBOL.
20:53:00 <mrunge> TravT, +1
20:53:19 <tqtran> gugl2: depends on the change, is it to legacy js code? if it is, then just stick with jquery. but the newer stuff should be angular.
20:53:20 <TravT> we are looking at angular for new development and tqtran is working on updating some older things to angular
20:53:42 <tqtran> TravT: lol COBOL yes, my favorite
20:53:42 <rbertram> travt: bet you have an angboard alternative called cobboard
20:53:51 <gugl2> tqtran, ok, thanks
20:53:53 <TravT> lol
20:53:53 <tqtran> rbertram: lol
20:54:27 * david-lyle is regretting finding wifi
20:54:38 <mrunge> we had a patch set celebrating it's first birthday.
20:54:50 <mrunge> could we get another core to approve https://review.openstack.org/#/c/65793/ ?
20:54:59 <tqtran> gugl2: http://campus.codeschool.com/courses/shaping-up-with-angular-js/intro interactive tutorial if you're interested
20:55:19 <gugl2> tqtran, sounds good, thanks.
20:55:41 <rbertram> If we are in that part of the meeting - Serial Console https://review.openstack.org/#/c/144659/ is ready for review. But the BP has not gotten any attention.
20:55:53 <tqtran> mrunge: sounds like you should bug akihiro
20:55:53 <rbertram> Does BP have to be approved for patch to merge?
20:56:19 <mrunge> tqtran, yes, but he's not here at the moment
20:56:45 <mrunge> rbertram, I thought it was already approved?
20:56:51 <david-lyle> rbertram: it should be, but it doesn't always happen that way
20:56:59 <rbertram> :-)
20:57:12 <bradjones> Quick update on Curvature topology BP, would really appreciate some UX feedback https://review.openstack.org/#/c/141078/ need to clean up code this afternoon and will remove the -1 workflow tomorrow
20:57:20 <mrunge> rbertram, I mean, the bp should already have been approved?
20:58:21 <rbertram> https://blueprints.launchpad.net/horizon/+spec/serial-console - marked as "needs approval"
20:58:38 <TravT> bradjones: i do have a question.  will that topology be easy to include in a number of pages?
20:58:38 <david-lyle> devlaps: around?
20:59:29 <bradjones> TravT: yeah it should be as long as the page calls the init function and the json is rendered I don't see why not
21:00:15 <TravT> bradjones: great, because there is some interest in being able to bring it up within context on a few places.
21:00:22 <TravT> e.g. instance details
21:00:51 <david-lyle> time's up. Thanks mrunge for leading. Have a great week and I should back in a more full capacity late next week. Thanks everyone.
21:00:54 <bradjones> TravT: awesome that sounds good
21:00:58 <david-lyle> #endmeeting