22:04:44 <david-lyle> #startmeeting Horizon
22:04:45 <openstack> Meeting started Tue Nov 26 22:04:44 2013 UTC and is due to finish in 60 minutes.  The chair is david-lyle. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:04:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:04:49 <openstack> The meeting name has been set to 'horizon'
22:05:04 <david-lyle> Hello Horizon folks!
22:05:06 <jtomasek> o/
22:05:07 <lsmola> hello
22:05:08 <jomara> hello everyone
22:05:08 <jpich> Hello
22:05:10 <devlaps> o/
22:05:15 <mrunge> o/
22:05:19 <amotoki> hi
22:05:37 * stevebaker lurks if needed
22:06:00 <matty_dubs> Ahoy!
22:06:12 <david-lyle> Icehouse-1 feature freezes on Dec 3, everything scheduled for it is up for review.
22:06:19 <david-lyle> https://launchpad.net/horizon/+milestone/icehouse-1
22:06:30 <david-lyle> and only 2 have been merged
22:06:47 <david-lyle> so reviews are needed, by all
22:07:26 <david-lyle> #topic Review IA proposal
22:08:03 <david-lyle> So, I don't want to do the review today, but Jarda and I have spent a little time collaborating on an IA diagram based on the summit talks
22:08:19 <david-lyle> http://ask-openstackux.rhcloud.com/question/1/openstack-ui-information-architecture/
22:08:57 <david-lyle> This is still a proposal and feedback is requested in the ux askbot tool
22:09:28 <david-lyle> There will be actual documentation that goes along with this once finalized and some blueprints to support reorganization
22:10:36 <david-lyle> #topic (lsmola)Deleting of resource usage page tables: https://bugs.launchpad.net/horizon/+bug/1249279
22:10:38 <uvirtbot> Launchpad bug 1249279 in horizon "Resource Usage Page table views shows statistics in a wrong way" [Medium,In progress]
22:10:44 <lsmola> yes
22:10:44 <david-lyle> lsmola
22:10:57 <lsmola> so it is described here https://bugs.launchpad.net/horizon/+bug/1249279
22:11:20 <lsmola> thing is, the tables were very buggy, so I am deleting them
22:11:45 <lsmola> if anybody thinks they should stay, speak now :-)
22:12:15 <david-lyle> in the review you are not only deleting the view, but the API calls as well?
22:12:29 <lsmola> plan is to rather spread those stats through all dashboards table as sparklines
22:12:39 <jpich> Having tried to explain what "Network duration" meant in the table context, I agree they are hard to understand and confusing at the moment. Removing them until the improved version (tm) makes sense to me
22:12:44 <jomara> sparklines are fancy!
22:13:02 <mrunge> so why are you removing API calls as well
22:13:02 <lsmola> david-lyle, the basic api call stayed, just the concrete were deleted
22:13:03 <david-lyle> ok, so what's left in the page, some charts?
22:13:34 <lsmola> david-lyle, yes, linechart showin all stats
22:14:06 <lsmola> david-lyle, that could be moved somewhere else, if it should be only thing left there, like a tab of overview page
22:14:16 <david-lyle> lsmola: ok.  if the data is incorrect or buggy anyway, I don't see a reason to keep them
22:14:40 <jpich> We've usually not included API calls if they're not used anywhere in our codebase, which makes sense to me. The ones that make sense can be brought back later if needed
22:14:47 <lsmola> mrunge, those were specialized API calls for the tables, it doesn make sense to keep without the tables
22:15:04 <lsmola> jpich, yes
22:15:09 <mrunge> lsmola, yeah. got that
22:15:22 <mrunge> lsmola, still I'd love to see replacements
22:15:40 <lsmola> somebody needs to step in, and document all Ceilometer metrics on ceilometer side, apparently each metric is special
22:15:54 <lsmola> that somebody will probably be me
22:16:04 <lsmola> though feel free to sign up :-)
22:16:06 <david-lyle> ha
22:16:31 <lsmola> mrunge, well the point is whether we need it centralized into one table
22:16:42 <lsmola> mrunge, or rather spread as sparklines
22:17:09 <lsmola> mrunge, so e.g. table with instances will also contain sparklines like cpu_util, memory use, etc.
22:17:30 <lsmola> mrunge, so the data that was originally here
22:17:38 <mrunge> lsmola, we agreed in Portland in April, we don't want graphics centralized, but spread throughout the dashboard
22:17:47 <lsmola> mrunge, not in the form of sparklines though
22:17:58 <lsmola> mrunge, yes
22:17:58 <mrunge> lsmola, yes, got that ;-)
22:18:15 <lsmola> mrunge, it will make the whole dashboard more beautiful
22:18:18 <lsmola> :-)
22:18:51 <david-lyle> and are page loads blocked on the api calls to ceilmeter for each sparkline?
22:19:02 <mrunge> lsmola, we had a proposal back in April, just showing all graphics on one page. Somehow that was not appreciated
22:19:04 <lsmola> david-lyle, nope
22:19:21 <lsmola> david-lyle, right now, each chart take care of itself via ajax
22:19:25 <david-lyle> lsmola: very good
22:19:33 <mrunge> yupp, great!
22:20:09 <lsmola> david-lyle, later there will be manager that will group them, with some enhancements of Ceilometer and API. I can make more queries in one using group by
22:20:25 <david-lyle> I think the understanding was the existing ceilometer page was a first pass at integration to have something to show for the Havana efforts in that direction
22:20:41 <lsmola> david-lyle, yes
22:20:57 <david-lyle> since the integration is maturing, we want to move it to the proper location
22:21:21 <lsmola> cool
22:21:42 <david-lyle> The remaining meters are cross-project measurements then
22:21:54 <david-lyle> err, I guess global
22:22:00 <david-lyle> cross cloud?
22:22:20 <lsmola> ehm
22:22:30 <lsmola> what do you mean by remain ing meters?
22:22:43 <david-lyle> on the existing view if you remove the table
22:22:55 <david-lyle> charts
22:23:11 <lsmola> david-lyle, yeah those vere aggregates, grouped by project
22:23:28 <lsmola> david-lyle, though they are tracked per resource
22:24:04 <lsmola> david-lyle, so I think implementation of sparklines will start on project tab, as it shows the resources
22:24:29 <david-lyle> the latter thing you said scales, how does the first?
22:24:34 <lsmola> david-lyle, then we will see how to show the agregates for admin
22:24:44 <david-lyle> aggregate per project?
22:24:50 <lsmola> yes
22:24:56 <david-lyle> 10000 projects?
22:25:34 <lsmola> well, that is the other thing, we will probably have to paginate the chart
22:25:55 <lsmola> for sparklines, tables will be paginated
22:26:06 <david-lyle> alright, we can take the second part offline, but it worries me
22:26:40 <david-lyle> I think removing the existing tables and concentrating on spark lines is a valid approach
22:26:47 <lsmola> yeah we were speaking with jcoufal and other how to scale the resource usage page linechart for more projects
22:26:55 <david-lyle> anyone disagree?
22:27:00 <lsmola> david-lyle, yes itś a good start
22:27:23 <david-lyle> alright, sounds good
22:27:37 <david-lyle> #topic Updates from I18N team
22:27:46 <david-lyle> amotoki?
22:27:57 <amotoki> hi
22:28:19 <amotoki> as i wrote on wiki, i18n team plans to update translations for 2013.2.1
22:28:55 <jpich> which is awesome :)
22:29:05 <david-lyle> indeed
22:29:06 <amotoki> there are some patches to fix strings. I hope they are merged soon :-)
22:29:22 <david-lyle> looks like 1 is merged and 3 are still pending
22:29:56 <amotoki> yes.
22:30:35 <amotoki> for havana update, i don't propose POT files update patch . Instead i directly update transifex.
22:31:02 * jpich didn't know one could do that
22:31:21 <jpich> amotoki: Does that mean the strings can be changed ahead of the patch landing?
22:31:59 <amotoki> jpich: it can, but we need to maintain private branch to do that :-(
22:32:29 <amotoki> i think it is not a good idea.
22:32:31 <david-lyle> ok, so we need to find another stable branch maintainer other than mrunge
22:32:40 <david-lyle> I can work on that
22:33:11 <mrunge> david-lyle, I'd love to see someone from another company, different to Red Hat
22:33:18 <mrunge> *hint*
22:33:34 <jpich> amotoki: Probably - I'm not sure what you are proposing then? Also, did we create the new horizon_havana repo yet? (Sorry I didn't follow the latest updates)
22:33:46 <mrunge> david-lyle, if it's urgent, I know who to contact
22:33:46 * david-lyle totally oblivious to process
22:33:55 <jpich> https://wiki.openstack.org/wiki/StableBranch#Joining_the_Team
22:34:13 <david-lyle> of course there's a wiki page :)
22:34:28 <jpich> People interested in joining should start including a comment on "why this is an appropriate, safe backport" when +1ing stable patches
22:34:37 <jpich> ...though it's actually a good habit to pick up for everyone :)
22:34:54 <jpich> there's always a wiki page
22:34:55 <jpich> somewhere
22:34:56 <mrunge> definitely!
22:34:59 <jpich> :-)
22:35:06 * david-lyle enlightened
22:35:24 <mrunge> :P
22:35:53 <david-lyle> if only there was a search on the wiki...  oh wait
22:36:12 <amotoki> jpich: to update transifex before landing a patch, we need to collect proposed patches. this is "private branch" i mean.
22:36:33 <david-lyle> amotoki: ok, we'll work to get those merged
22:36:50 <jpich> amotoki: Ok! Hopefully we can avoid this. Thank you :)
22:36:58 <amotoki> that's all from me.
22:37:01 <amotoki> jpich:  any addition?
22:37:16 <david-lyle> thanks for tracking this amotoki
22:37:41 <jpich> Nope... You mentioned the timeline, we should have a translation patch up before Dec 5th when the stable branch will be frozen and the latest patches merged
22:38:07 <jpich> Yes, thanks a lot amotoki!
22:38:24 <david-lyle> #topic Open Discussion
22:38:53 <david-lyle> btw: really enjoying agendas, thanks for posting them ahead of time
22:39:08 <lsmola> yaay
22:39:10 <jpich> david-lyle: I was wondering: if there a keystone bug or blueprint you know of, for tracking read access to RBAC policies?
22:39:39 <jpich> We might want to include the meeting date in the agenda, I always wonder first if it's last week's or next... maybe just me :-) Still love having them!
22:40:06 <mrunge> +1 for having agendas!
22:40:22 <david-lyle> not that I am aware of, had conversations with ayoung in Hong Kong, but I haven't made it beyond that
22:40:48 <ayoung> LIES!
22:40:53 <ayoung> what are we talking about?
22:41:10 <lsmola> jpich, true, I havent noticed date is missing
22:41:27 <david-lyle> policy read access
22:41:47 <david-lyle> policy management in general
22:41:59 <david-lyle> ayoung
22:42:35 <ayoung> david-lyle, as I recall, the real issue was figuring out which policy to hand to which endpoint. Who can read it is probably a related but different problem.
22:42:51 <ayoung> And..since horizon does everything as the end user...
22:43:28 <david-lyle> ayoung: yes, making the policy available to horizon
22:43:29 <ayoung> no bug that I am aware of.  BUt I'm heads down in other things ATM
22:43:34 <ayoung> please file.
22:43:47 <david-lyle> ayoung: will do
22:43:53 <david-lyle> thanks
22:44:19 <jpich> david-lyle: Please send me the bug # afterwards so I can subscribe too :-)
22:44:30 <david-lyle> absolutely
22:44:48 <david-lyle> and the date was missing out of laziness :)
22:44:55 <jpich> hehe
22:45:01 <david-lyle> so much to update
22:45:29 <david-lyle> any other items
22:45:50 <casanch1> hi, I'm new in the community and have been working in a couple of bugs to add client-side validations
22:46:14 <david-lyle> link?
22:46:49 <dolphm> jpich: GET /v3/policies <-- but we don't have a policy engine to consume from that API, yet
22:47:25 <casanch1> https://bugs.launchpad.net/horizon/+bug/1125232
22:47:26 <uvirtbot> Launchpad bug 1125232 in horizon "Object Upload is validated after object upload" [Medium,In progress]
22:47:40 <david-lyle> dolphm: we just wanted read access to the blobs, that noone is uploading
22:48:04 <devlaps> casanch1: thanks for doing this. would also be useful for this bug: https://bugs.launchpad.net/horizon/+bug/1253791
22:48:05 <uvirtbot> Launchpad bug 1253791 in horizon "create an image leaks tmp file if name not specified" [Undecided,In progress]
22:48:05 <david-lyle> and a way to tie it to the endpoint
22:48:29 <jpich> dolphm: Oh, thank you! Is the related work tracked/documented somewhere?
22:48:46 <casanch1> I've noticed that there's no client-side validations, but in cases like that bug, I think it make sense, so to avoid file uploads
22:48:49 <dolphm> jpich: it would be in oslo, if anything -- but i'm not aware of it
22:49:10 <david-lyle> casanch1: I agree a client side check makes sense
22:49:24 <dolphm> jpich: it'd be an extension of the existing policy engine that pulls the policy blob from keystone and caches it rather than from disk
22:50:04 <david-lyle> casanch1: will definitely take a look at your approach
22:50:28 <dolphm> jpich: keystone doesn't pretend to understand the policy documents though -- and doesn't dictate the use of JSON or a particular language
22:50:35 <casanch1> so, I proposed a quick fix by adding HTML5 required attribute to some fields. This might be enough for now, but for sure it'll be needed a common approach for that kind of validations
22:50:45 <casanch1> david-lyle: ok, thanks
22:50:49 <dolphm> jpich: so what you pull from keystone might be service/PEP specific
22:51:00 <david-lyle> dolphm: are your referring to the mailing list item re: policy as a service?
22:51:10 <david-lyle> or a third thing?
22:51:14 <dolphm> david-lyle: oh no, there's that too!
22:51:16 <jpich> dolphm: Interesting, thanks. Obviously I need to do some more reading around policies
22:51:47 <dolphm> david-lyle: i haven't gotten my head around congress at all
22:51:47 <david-lyle> dolphm: an endpoint specific policy blob is fine
22:52:04 <jtomasek> casanch1, david-lyle: Angular has good means for client side validations, I think there is a good reason to check that out, once angular is in...
22:52:36 <dolphm> jpich: keystone's policy API is intentionally lightly defined... https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md#policy
22:52:46 <lsmola> jtomasek, yeah
22:53:01 <david-lyle> but, if it's not based on the json rules that the oslo policy engine uses, we're lost
22:53:14 <dolphm> jpich: there's no relation to services, endpoints or domains because we didn't have a strong use case to dictate any of that
22:53:38 <dolphm> jpich: so a new policy engine would basically have to know the policy ID, or really just URL, to fetch the policy from
22:53:50 <casanch1> jtomasek: I agree, but if angular is not in... I think it's worth it to have a temporal solution which will prevent waste of resources to upload unnecessary files
22:54:10 <jtomasek> casanch1: definitely agree
22:54:33 <david-lyle> dolphm: which makes it unusable by Horizon, unless we want to upload our own policy blob to store and read, as an admin
22:55:18 <david-lyle> but it seems our use case came late to the party
22:55:48 <lsmola> casanch1, yes, as long as it is a few lines patch, it is alright to have it as temporary solution
22:56:35 <jpich> dolphm: I see. There's lot of things I forgot to consider, thanks for the extra information
22:56:44 <lsmola> casanch1, jtomasek I guess proper general client side vaidations in angular, integrated to horizon framework will take some time :-)
22:57:05 <casanch1> lsmola: it's only one line patch for each field to be marked as required with HTML5 attributes
22:57:07 <jomara> not that much time
22:57:46 <lsmola> casanch1, yes, I have just checked, thank you for that patch :-)
22:57:49 <jpich> david-lyle: I need to level up my grasp of policy before I try to review your patches again :-) I forgot about the headaches around e.g. different policy files on different compute nodes
22:58:01 <jomara> angular is just one core review away from being in right?
22:58:05 <lsmola> jomara, sooner the better :-)
22:58:07 <jomara> probably not worth implementing a stop gap before that
22:59:09 <lsmola> jomara, not sure, this is really like few lines of code, that can be easily wiped out
22:59:55 <david-lyle> jpich: yes, there are lots of potential holes, but I designed in a fail safe in the settings files to just ignore policy
22:59:56 <lsmola> jomara, yep angular should be in very soon
23:00:34 <david-lyle> jomara: thanks for the angular jump start
23:01:11 <lsmola> david-lyle, do i see client side validations as a topic for the next meeting?
23:01:22 <lsmola> jomara, casanch1 ^
23:01:24 <david-lyle> lsmola: I think so
23:01:24 <casanch1> when angular is in, I can for sure work on another implementation to add those client-side validations
23:01:25 <jomara> david-lyle: np
23:01:39 <david-lyle> looks like times up
23:01:43 <david-lyle> thanks everyone
23:01:43 <jomara> casanch1: just stay tuned, itll be soon:)
23:01:49 <david-lyle> #endmeeting