15:59:55 <david-lyle> #startmeeting Horizon
15:59:56 <openstack> Meeting started Tue May 27 15:59:55 2014 UTC and is due to finish in 60 minutes.  The chair is david-lyle. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:59:59 <openstack> The meeting name has been set to 'horizon'
16:00:05 <david-lyle> Hello everyone!
16:00:08 <lsmola> hello
16:00:10 <gary-smith> hi
16:00:11 <akrivoka> hi everyone
16:00:12 <jcoufal> o/
16:00:14 <devlaps> hi all!
16:00:14 <doug-fish> hello!
16:00:16 <jpich> Hello
16:00:18 <santib> hi all
16:00:29 <jrist> what do we call many Horizon-ers
16:00:32 <jrist> horizonites?
16:00:33 <jrist> o/
16:00:49 <jrist> horizonizers
16:00:57 <jrist> horizinians
16:01:02 <jtomasek> hi
16:01:43 <tzumainn> hiya!
16:01:52 <david-lyle> We'll we've almost hit Juno-1, surprise
16:02:01 <david-lyle> June 12 is the date for Juno-1
16:02:11 <david-lyle> first one always sneaks up on me
16:02:27 <david-lyle> https://launchpad.net/horizon/+milestone/juno-1
16:02:40 <jcoufal> doug-fish: that was fast
16:02:47 <jcoufal> doug-fish: sorry :)
16:02:48 <david-lyle> is not cleaned up yet and I have to put together 2 and 3
16:02:57 <david-lyle> will work on that this week
16:03:20 <david-lyle> anyway, just a heads up on that
16:03:56 <david-lyle> Second general item, I attended the TC meeting last week and we discussed the integration gap analysis for Horizon
16:04:08 <david-lyle> https://etherpad.openstack.org/p/horizon-gap-analysis
16:05:01 <david-lyle> This is a process to make sure that Horizon meets the current criteria for exiting incubation to become part of openstack, so that new projects are not being asked to achieve something above and beyond what integrated projects have done
16:05:16 <david-lyle> We have just a few issues to address
16:05:37 <david-lyle> the first and most glaring is a mission statement
16:05:58 <david-lyle> We do UI   wasn't enough
16:06:02 <doug-fish> lol
16:06:25 <jcoufal> lol
16:06:27 <jcoufal> nice :)
16:06:38 <david-lyle> So I'm putting together a plan to address the rest of the short-comings and will present that to the TC today
16:06:47 <jrist> "A unified user interface that exposes most of the OpenStack infrastructure to users and operators"?
16:07:04 <lsmola> david-lyle: I would say it was enough :-D
16:07:42 <jcoufal> jrist: where is that?
16:07:51 <jrist> jcoufal: I just made it up
16:07:57 <jrist> should I add a TM ?
16:07:57 <jrist> :)
16:07:58 <lsmola> jrist: you forgot graphical
16:08:11 <jrist> lsmola: or I purposefully omitted it!
16:08:16 <lsmola> jrist: user interface can be also like command line, bananas, etc.
16:08:27 <jcoufal> jrist: why OpenStack infrastructure?
16:08:27 <tzumainn> "bananas"?
16:08:38 <lsmola> tzumainn: you know, for monkeys..
16:08:41 <jrist> jcoufal: what is another way to put it
16:08:45 <david-lyle> To provide an extensible unified web based user interface for all integrated OpenStack services.
16:08:53 <jrist> david-lyle++
16:08:54 <ericpeterson> yep, remove infrastructure
16:08:55 <david-lyle> was my attempt
16:08:57 <jcoufal> david-lyle: +1
16:09:07 <doug-fish> yeah that's us  +1
16:09:21 <jtomasek> +1
16:09:24 <lsmola> david-lyle: sounds good
16:09:26 <david-lyle> extensibility is a core value of Horizon and should be in there
16:09:28 <jpich> +1 to to a mission statement that includes supporting integrated projects and extensibility as goals
16:09:58 <santib> david-lyle: +1
16:09:58 <david-lyle> jpich: should there be more?
16:10:12 <tqtran> im thinking something along of the line of managing stuff....
16:10:14 <david-lyle> I think quality and usability should be implied from the core values
16:10:21 <jrist> +1
16:10:25 <jrist> agreed to that
16:10:28 <david-lyle> not explicitly stated
16:10:45 <ericpeterson> could add the tagline :  now with 20% more quality ?
16:10:49 <jcoufal> david-lyle: that sounds reasonable
16:10:58 <david-lyle> 20% seems high
16:11:08 <david-lyle> maybe 12.5%
16:11:22 <jpich> david-lyle: Your proposal sounds good to me
16:11:23 <jrist> Now with approximately 12% more quality!
16:11:37 <doug-fish> now with nearly 20% more quality
16:11:44 <ericpeterson> floating point -    11.9999999999%
16:11:45 <jpich> Is it a pain to tweak / update the mission statement if we find the Perfect Way To Phrase It later?
16:11:52 <tqtran> lol !!! +1 doug
16:12:29 <david-lyle> jpich: I don't believe so, it just lives in https://github.com/openstack/governance/blob/master/reference/programs.yaml
16:12:36 <jrist> oh man
16:12:51 <lsmola> lol
16:12:56 <david-lyle> so a patch and vote by TC is all it takes
16:13:11 * doug-fish is way off track testing out mission statement generators.
16:13:32 * david-lyle fearful of results
16:13:32 <jpich> david-lyle: Ok thank you
16:13:44 <doug-fish> "To enthusiastically supply viral methods to allow us to continue to competently integrate graphical interface materials while maintaining the highest standards."  (slightly edited)
16:14:06 <david-lyle> other items were around integration testing and the upcoming repo split
16:14:31 <david-lyle> no real red flags just questions about timelines and goals
16:14:43 <doug-fish> david-lyle - is integration testing a new topic, or part of the TC needs?
16:15:08 <david-lyle> for projects integrating it is a graduation requirement to have tempest integration
16:15:12 <david-lyle> we have 1 test
16:15:17 <david-lyle> not a banner effort
16:15:18 <ericpeterson> I found an issue to consider around repo split...   the APIBaseResource type classes..... might want to consider moving those into a horizon location ?????
16:15:30 <lsmola> doug-fish: I miss like web>2.0, drag & drop and look & feel in that statement :-)
16:16:00 <doug-fish> :-)  Drag & Drop present accessibility challenges.  I left it out on purpose!
16:17:05 <jcoufal> lsmola: and nicely colored unicorns :)
16:17:21 <lsmola> oh yeah and those
16:17:32 <doug-fish> david-lyle - I talked with ... the PTL for Tempest (name?) ... about UI integration testing at the summit.  It seems that it is explicitly kept very light in tempest because its hard to coordinate intentional changes to the UI with changes to the tests.  I know the test architecture jpich has started on helps with that
16:18:18 <jpich> Yup, the page object pattern with separate pages and tests should take care of that. dkorn should get the credit :)
16:18:32 <doug-fish> well thought out dkorn!
16:18:41 <jpich> More exciting reading on the page object pattern: https://wiki.openstack.org/wiki/Horizon/Testing/UI#Page_Object_Pattern_.28Selected_Approach.29
16:19:48 <david-lyle> I didn't have any more general items
16:19:55 <david-lyle> #topic Open Discussion
16:20:12 <doug-fish> I'm on integrations tests still - is it required that we keep our integration tests in tempest?
16:20:25 <david-lyle> doug-fish: no
16:20:29 <nlahouti_> how can we find a horizon BP is approved for juno-1?
16:21:13 <david-lyle> nlahouti_: link?
16:21:22 <jpich> doug-fish: It'd be a nice end goal but we're starting them in our own repo till we figure it all out and see if it makes sense to merge them back into Tempest
16:21:33 <nlahouti_> david-lyle: link to BP?
16:21:40 <david-lyle> yes, please
16:21:42 <doug-fish> I'd suggest keeping the tests in our project if we can then.  its not hard to image we'll have refactors that change the page a particular function should be performed on
16:21:47 <nlahouti_> david-lyle: https://blueprints.launchpad.net/horizon/+spec/horizon-cisco-dfa-support
16:22:17 <clu_> is there a way to test if the layout "looks" right - like if there is text overflowing out of a div, or something...
16:22:55 <ericpeterson> tqtran and I have some ajax table stuff to share: https://blueprints.launchpad.net/horizon/+spec/table-client-rendering   too
16:23:03 <doug-fish> clu_:  do you mean as part of the integration test?
16:23:22 <clu_> yes
16:23:30 <doug-fish> no
16:23:54 <doug-fish> I don't know of a framework that does that sort of testing in an automated basis -- do you know of one?
16:24:03 <tqtran> clu_: i think it will be hard to test those kind of stuff, human eye?
16:24:07 <jpich> doug-fish: Most projects have their tests in Tempest, it'd give us the advantage that they'd be automatically part of every project's gate so breaking changes would be caught before they get to us. Though once we have a stable integration gate we could also see if it can be run for the other projects but that'll be later either way
16:24:56 <clu_> doug-fish, tqtran: don't know any framework like that... only the "human eye" test
16:25:31 <doug-fish> jpich - right.  I understand we need the UI driven integration tests to gate the other projects one day.  I just doing think UI tests seem very much like the other tempest stuff - which is very stable/API driven.
16:25:51 <doug-fish> s/I just doing think UI tests seem/I just doing think UI tests doesn't seem
16:25:58 <doug-fish> wow
16:26:07 <doug-fish> can't type today anymore can I
16:26:11 <tqtran> lol
16:26:43 <doug-fish> UI != API
16:26:49 <jpich> doug-fish: I suspect these tests are not as stable as one might expect :-) but yeah I get your point, we can rediscuss later either way, it's very much "future" discussion
16:27:24 <doug-fish> jpich - agreed this is a future discussion.  I'd rather get some written first then decide what to do with them
16:27:45 <jcoufal> One quick announcement: Next week on Monday (June 2) there is going to be the first UX meeting at 1700 UTC (#openstack-meeting-3). Everybody is welcome and if you plan to join, please, fill yourself into this etheprad: https://etherpad.openstack.org/p/ux-meetings so we can arrange meeting times for the most convenient time slot for everyone.
16:27:58 <jpich> doug-fish: Yup!
16:28:28 <david-lyle> nlahouti_: so re: your bp, I'm trying to get a better handle on how we can effectively support 3rd party extensions, the current model of a flag per setting/device is not scalable
16:28:37 <jpich> Woohoo UX meetings \o/ I can't make the first one but hope to attend in the future, thanks for setting these up jcoufal
16:28:57 <amotoki> jpich: doug-fish: in the neutron summit session there is a siimlar discussion about having functional tests in its own repo for better testing coverage.
16:29:01 <amotoki> imo cross-project testing requiring API calls to backend projects (nvoa, cinder, ..) is better to be in tempest.
16:29:29 <clu_> jcoufal: nice!
16:29:39 <david-lyle> the benefit of Horizon tests is exercising the python-*clients so they don't break us and heat as they change
16:30:03 <nlahouti_> david-lyle: I replied to comments in the review. For instance for avoiding the flag... There is existing api (list_extensions()) that can be used instead of flag
16:30:24 <david-lyle> nlahouti_: that's new in Juno?
16:30:46 <nlahouti_> david-lyle: The API exists in api/neutron.py
16:31:01 <david-lyle> does neutronclient support it?
16:31:10 <nlahouti_> david-lyle: yes.
16:31:32 <nlahouti_> david-lyle: Basically it returns all the supported exstension.
16:31:44 <david-lyle> nlahouti_: that is a much better way to approach the problem. We should be triggering off that
16:31:49 <jpich> amotoki: I agree, and I think people get annoyed when Horizon requires yet again Special Snowflake treatment, but either way we can revisit the conversation when we have a stable and stronger suite of integration tests actually implemented
16:31:55 <nlahouti_> david-lyle: I think security group using it If I'm not mistaken.
16:32:58 <nlahouti_> david-lyle: But again, using the list_extension API we still need to have if...else in the code in workflow, forms... to display a vendor specific options in the GUI
16:33:09 <amotoki> jpich: agree. (i am catching up with the meeting log now)
16:33:27 <david-lyle> nlahouti_: let's use that in your patch rather than the settings flag, and I think we'll have a workable solution
16:33:35 <jpich> amotoki: No worries! Your input from a consistency-across-projects perspective is definitely appreciated :)
16:34:06 <david-lyle> ericpeterson: you had a table on the table?
16:34:17 <nlahouti_> david-lyle: Ok, I'll update the patch based on this solution and post it for review.
16:34:24 <ericpeterson> yep... tqtran and I have a method to add json versions of data tables
16:34:50 <ericpeterson> https://review.openstack.org/#/c/94706/6/openstack_dashboard/dashboards/project/instances/views.py   see line 50  for how to plug this into a view
16:34:55 <amotoki> david-lyle: nlahouti_: related to cisco DFA bp, the correponsing neturon feature is proposed for juno too and not implemented yet.
16:35:26 <amotoki> david-lyle: nlahouti_: is it better to wait horizon patch unitl neutron feature is implemented?
16:35:27 <david-lyle> amotoki: that would change things :)
16:35:30 <nlahouti_> amotoki: what feature?
16:36:03 <amotoki> nlahouti_: i think DFA feature is not implemeted yet. am i wrong?
16:36:25 <amotoki> nlahouti_:  *in neutron
16:36:25 <ericpeterson> and that table mixin.... adds the ability to get a json-ified table   via https://review.openstack.org/#/c/94706/6/horizon/tables/views.py .   this stuff is WIP very clearly.... but am wondering the interest level of the more web 2.0 version of table rendering
16:36:42 <david-lyle> OSAPIJSONEncoder not the best camel case name :)
16:36:42 <nlahouti_> amotoki: Yes. It is not implemented. But what I'm referring to is the list_extensions() in neutron API which exist today.
16:37:33 <ericpeterson> yeah, tqtran and I really like capital letters
16:37:42 <david-lyle> nlahouti_: the concern is turning on support for a feature in Horizon, cfa that is not yet supported in neutron
16:38:01 <david-lyle> for many reasons, it may change, it may not make it, it may make it in K
16:38:07 <amotoki> nlahouti_: ok... what i have in my mind is a feature depedency between hroizon and backend project. horizon team needs to consider merge timing even if the bp is approved.
16:38:13 <david-lyle> that leaves broken/dead code in Horizon
16:38:34 <nlahouti_> david-lyle: It won't cause any issue as  the extensions does not return the dfa.
16:38:34 <david-lyle> which we're not excited to bring in
16:38:51 <jpich> I agree with amotoki and david-lyle, in general it's better to wait for the Neutron (or whatever project's) code to be merged before the Neutron feature is implemented. At least make sure to mark the Horizon code as Work In Progress
16:38:52 <david-lyle> nlahouti_: but it's code you can't exercise
16:38:59 <doug-fish> nlahouti_  dead code creates issues
16:39:04 <nlahouti_> david-lyle: so code is not gtting exercise.
16:39:09 <david-lyle> and thus not necessary until neutron integrates
16:39:25 <nlahouti_> david-lyle: only the if ... statement is executed.
16:39:26 <jpich> nlahouti_: and the Neutron implementation may change before it gets merged making the horizon part broken
16:39:37 <doug-fish> dead code creates extra work for translators, unnecessary work for reviews, and confusion among new developers
16:39:38 <david-lyle> nlahouti_: we will not merge before neutron does
16:39:46 <david-lyle> end of story
16:40:38 <jpich> lsmola is multiplying...
16:40:45 <nlahouti_> david-lyle: so first the feature has to be implemented in neutron?
16:40:54 <david-lyle> yes
16:41:05 <amotoki> nlahouti_: of course it is no problem that horizon patch is upload for review even before merging neutron feature (in parallel). we are just talking about the merge timing. no worries.
16:41:28 <david-lyle> yes the patch can progress, just not merge
16:41:33 <amotoki> but we need to have a clear criteria to merge features into hoirzon repo.
16:41:47 <lsmola3> jpich, hehe
16:41:50 <doug-fish> like a working integration test!
16:42:08 <david-lyle> ericpeterson, how are actions handled with the client side rendering?
16:42:24 <david-lyle> do action classes in the table view need to be rewritten, or used as is?
16:42:30 <nlahouti_> david-lyle: david-lyle, amotoki: yes it is merge timing. In my case the feautre in neutron is related to changes in horizon and they are related together.
16:42:55 <david-lyle> nlahouti_: neutron does not depend on Horizon
16:43:00 <ericpeterson> I am working on the actions right now..... those should get encoded to json as well..... so you will have something like actions : [  {type: link, href: 'http://..."}   ]
16:43:36 <ericpeterson> so actions will be in the json.... and those will be at both the table level and the row level..... just like what we have right now
16:43:41 <david-lyle> and where does allowed come into play, whether it gets added to the JSON to ship to the client
16:43:42 <david-lyle> ?
16:43:55 <ericpeterson> those get eval'd on the server
16:44:20 <ericpeterson> table.get_row_actions(datum)
16:44:31 <nlahouti_> david-lyle: I understand. I wasn't clear. I was refering the whole solution.
16:44:31 <ericpeterson> I think that should do that for me
16:45:20 <nlahouti_> david-lyle: anyhow, I'll update the patch to get comment on the implementaion. not to use flag ...
16:45:30 <ericpeterson> the approach with the json stuff is the continue using the horzion table classes / constructs..... and have a quick switch to add, to add the json version of your table
16:45:41 <david-lyle> nlahouti_: I understand, let's keep iterating on the patch in Horizon get it ready to merge, once the feature support goes into neutron the horizon patch can quickly follow
16:46:01 <ericpeterson> and stuff should continue to work in the same way
16:46:10 <nlahouti_> david-lyle: Sure.
16:46:26 <nlahouti_> david-lyle: will do that.
16:46:58 <tqtran> yep, its basically an alternative way to render your table data.
16:47:11 <david-lyle> ericpeterson, I need to take a closer look, but I think the idea seems sound
16:47:19 <tqtran> it will work alongside the current implementation nicely
16:48:25 <ericpeterson> there is some cross repo dependency stuff like we have a horizon/tables/ import of openstack_dashboard/api stuff..... that is wonky.... which is why I brought that up with repo split
16:48:43 <david-lyle> that is very wonky
16:49:20 <lsmola2> :-0
16:49:29 <ericpeterson> that json encoder thing needs to know if it is dealing with an APIBaseResource type class, that's why
16:49:37 <david-lyle> the APIBaseResources are particular to the implementation (openstack_dashboard) and don't belong in the toolkit side
16:50:21 <ericpeterson> yeah.... I could move that jsonecoder code out to the openstack_dashboard section then..... and have a base implementation to override
16:51:16 <david-lyle> Unfortunately, I have to end 10 minutes early today due to a conflict, please carry on in #openstack-horizon  See everyone next week!
16:51:24 <david-lyle> #endmeeting