22:04:44 #startmeeting Horizon 22:04:45 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:04:49 The meeting name has been set to 'horizon' 22:05:04 Hello Horizon folks! 22:05:06 o/ 22:05:07 hello 22:05:08 hello everyone 22:05:08 Hello 22:05:10 o/ 22:05:15 o/ 22:05:19 hi 22:05:37 * stevebaker lurks if needed 22:06:00 Ahoy! 22:06:12 Icehouse-1 feature freezes on Dec 3, everything scheduled for it is up for review. 22:06:19 https://launchpad.net/horizon/+milestone/icehouse-1 22:06:30 and only 2 have been merged 22:06:47 so reviews are needed, by all 22:07:26 #topic Review IA proposal 22:08:03 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 http://ask-openstackux.rhcloud.com/question/1/openstack-ui-information-architecture/ 22:08:57 This is still a proposal and feedback is requested in the ux askbot tool 22:09:28 There will be actual documentation that goes along with this once finalized and some blueprints to support reorganization 22:10:36 #topic (lsmola)Deleting of resource usage page tables: https://bugs.launchpad.net/horizon/+bug/1249279 22:10:38 Launchpad bug 1249279 in horizon "Resource Usage Page table views shows statistics in a wrong way" [Medium,In progress] 22:10:44 yes 22:10:44 lsmola 22:10:57 so it is described here https://bugs.launchpad.net/horizon/+bug/1249279 22:11:20 thing is, the tables were very buggy, so I am deleting them 22:11:45 if anybody thinks they should stay, speak now :-) 22:12:15 in the review you are not only deleting the view, but the API calls as well? 22:12:29 plan is to rather spread those stats through all dashboards table as sparklines 22:12:39 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 sparklines are fancy! 22:13:02 so why are you removing API calls as well 22:13:02 david-lyle, the basic api call stayed, just the concrete were deleted 22:13:03 ok, so what's left in the page, some charts? 22:13:34 david-lyle, yes, linechart showin all stats 22:14:06 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 lsmola: ok. if the data is incorrect or buggy anyway, I don't see a reason to keep them 22:14:40 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 mrunge, those were specialized API calls for the tables, it doesn make sense to keep without the tables 22:15:04 jpich, yes 22:15:09 lsmola, yeah. got that 22:15:22 lsmola, still I'd love to see replacements 22:15:40 somebody needs to step in, and document all Ceilometer metrics on ceilometer side, apparently each metric is special 22:15:54 that somebody will probably be me 22:16:04 though feel free to sign up :-) 22:16:06 ha 22:16:31 mrunge, well the point is whether we need it centralized into one table 22:16:42 mrunge, or rather spread as sparklines 22:17:09 mrunge, so e.g. table with instances will also contain sparklines like cpu_util, memory use, etc. 22:17:30 mrunge, so the data that was originally here 22:17:38 lsmola, we agreed in Portland in April, we don't want graphics centralized, but spread throughout the dashboard 22:17:47 mrunge, not in the form of sparklines though 22:17:58 mrunge, yes 22:17:58 lsmola, yes, got that ;-) 22:18:15 mrunge, it will make the whole dashboard more beautiful 22:18:18 :-) 22:18:51 and are page loads blocked on the api calls to ceilmeter for each sparkline? 22:19:02 lsmola, we had a proposal back in April, just showing all graphics on one page. Somehow that was not appreciated 22:19:04 david-lyle, nope 22:19:21 david-lyle, right now, each chart take care of itself via ajax 22:19:25 lsmola: very good 22:19:33 yupp, great! 22:20:09 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 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 david-lyle, yes 22:20:57 since the integration is maturing, we want to move it to the proper location 22:21:21 cool 22:21:42 The remaining meters are cross-project measurements then 22:21:54 err, I guess global 22:22:00 cross cloud? 22:22:20 ehm 22:22:30 what do you mean by remain ing meters? 22:22:43 on the existing view if you remove the table 22:22:55 charts 22:23:11 david-lyle, yeah those vere aggregates, grouped by project 22:23:28 david-lyle, though they are tracked per resource 22:24:04 david-lyle, so I think implementation of sparklines will start on project tab, as it shows the resources 22:24:29 the latter thing you said scales, how does the first? 22:24:34 david-lyle, then we will see how to show the agregates for admin 22:24:44 aggregate per project? 22:24:50 yes 22:24:56 10000 projects? 22:25:34 well, that is the other thing, we will probably have to paginate the chart 22:25:55 for sparklines, tables will be paginated 22:26:06 alright, we can take the second part offline, but it worries me 22:26:40 I think removing the existing tables and concentrating on spark lines is a valid approach 22:26:47 yeah we were speaking with jcoufal and other how to scale the resource usage page linechart for more projects 22:26:55 anyone disagree? 22:27:00 david-lyle, yes itÅ› a good start 22:27:23 alright, sounds good 22:27:37 #topic Updates from I18N team 22:27:46 amotoki? 22:27:57 hi 22:28:19 as i wrote on wiki, i18n team plans to update translations for 2013.2.1 22:28:55 which is awesome :) 22:29:05 indeed 22:29:06 there are some patches to fix strings. I hope they are merged soon :-) 22:29:22 looks like 1 is merged and 3 are still pending 22:29:56 yes. 22:30:35 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 amotoki: Does that mean the strings can be changed ahead of the patch landing? 22:31:59 jpich: it can, but we need to maintain private branch to do that :-( 22:32:29 i think it is not a good idea. 22:32:31 ok, so we need to find another stable branch maintainer other than mrunge 22:32:40 I can work on that 22:33:11 david-lyle, I'd love to see someone from another company, different to Red Hat 22:33:18 *hint* 22:33:34 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 david-lyle, if it's urgent, I know who to contact 22:33:46 * david-lyle totally oblivious to process 22:33:55 https://wiki.openstack.org/wiki/StableBranch#Joining_the_Team 22:34:13 of course there's a wiki page :) 22:34:28 People interested in joining should start including a comment on "why this is an appropriate, safe backport" when +1ing stable patches 22:34:37 ...though it's actually a good habit to pick up for everyone :) 22:34:54 there's always a wiki page 22:34:55 somewhere 22:34:56 definitely! 22:34:59 :-) 22:35:06 * david-lyle enlightened 22:35:24 :P 22:35:53 if only there was a search on the wiki... oh wait 22:36:12 jpich: to update transifex before landing a patch, we need to collect proposed patches. this is "private branch" i mean. 22:36:33 amotoki: ok, we'll work to get those merged 22:36:50 amotoki: Ok! Hopefully we can avoid this. Thank you :) 22:36:58 that's all from me. 22:37:01 jpich: any addition? 22:37:16 thanks for tracking this amotoki 22:37:41 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 Yes, thanks a lot amotoki! 22:38:24 #topic Open Discussion 22:38:53 btw: really enjoying agendas, thanks for posting them ahead of time 22:39:08 yaay 22:39:10 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 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 +1 for having agendas! 22:40:22 not that I am aware of, had conversations with ayoung in Hong Kong, but I haven't made it beyond that 22:40:48 LIES! 22:40:53 what are we talking about? 22:41:10 jpich, true, I havent noticed date is missing 22:41:27 policy read access 22:41:47 policy management in general 22:41:59 ayoung 22:42:35 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 And..since horizon does everything as the end user... 22:43:28 ayoung: yes, making the policy available to horizon 22:43:29 no bug that I am aware of. BUt I'm heads down in other things ATM 22:43:34 please file. 22:43:47 ayoung: will do 22:43:53 thanks 22:44:19 david-lyle: Please send me the bug # afterwards so I can subscribe too :-) 22:44:30 absolutely 22:44:48 and the date was missing out of laziness :) 22:44:55 hehe 22:45:01 so much to update 22:45:29 any other items 22:45:50 hi, I'm new in the community and have been working in a couple of bugs to add client-side validations 22:46:14 link? 22:46:49 jpich: GET /v3/policies <-- but we don't have a policy engine to consume from that API, yet 22:47:25 https://bugs.launchpad.net/horizon/+bug/1125232 22:47:26 Launchpad bug 1125232 in horizon "Object Upload is validated after object upload" [Medium,In progress] 22:47:40 dolphm: we just wanted read access to the blobs, that noone is uploading 22:48:04 casanch1: thanks for doing this. would also be useful for this bug: https://bugs.launchpad.net/horizon/+bug/1253791 22:48:05 Launchpad bug 1253791 in horizon "create an image leaks tmp file if name not specified" [Undecided,In progress] 22:48:05 and a way to tie it to the endpoint 22:48:29 dolphm: Oh, thank you! Is the related work tracked/documented somewhere? 22:48:46 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 jpich: it would be in oslo, if anything -- but i'm not aware of it 22:49:10 casanch1: I agree a client side check makes sense 22:49:24 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 casanch1: will definitely take a look at your approach 22:50:28 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 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 david-lyle: ok, thanks 22:50:49 jpich: so what you pull from keystone might be service/PEP specific 22:51:00 dolphm: are your referring to the mailing list item re: policy as a service? 22:51:10 or a third thing? 22:51:14 david-lyle: oh no, there's that too! 22:51:16 dolphm: Interesting, thanks. Obviously I need to do some more reading around policies 22:51:47 david-lyle: i haven't gotten my head around congress at all 22:51:47 dolphm: an endpoint specific policy blob is fine 22:52:04 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 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 jtomasek, yeah 22:53:01 but, if it's not based on the json rules that the oslo policy engine uses, we're lost 22:53:14 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 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 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 casanch1: definitely agree 22:54:33 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 but it seems our use case came late to the party 22:55:48 casanch1, yes, as long as it is a few lines patch, it is alright to have it as temporary solution 22:56:35 dolphm: I see. There's lot of things I forgot to consider, thanks for the extra information 22:56:44 casanch1, jtomasek I guess proper general client side vaidations in angular, integrated to horizon framework will take some time :-) 22:57:05 lsmola: it's only one line patch for each field to be marked as required with HTML5 attributes 22:57:07 not that much time 22:57:46 casanch1, yes, I have just checked, thank you for that patch :-) 22:57:49 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 angular is just one core review away from being in right? 22:58:05 jomara, sooner the better :-) 22:58:07 probably not worth implementing a stop gap before that 22:59:09 jomara, not sure, this is really like few lines of code, that can be easily wiped out 22:59:55 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 jomara, yep angular should be in very soon 23:00:34 jomara: thanks for the angular jump start 23:01:11 david-lyle, do i see client side validations as a topic for the next meeting? 23:01:22 jomara, casanch1 ^ 23:01:24 lsmola: I think so 23:01:24 when angular is in, I can for sure work on another implementation to add those client-side validations 23:01:25 david-lyle: np 23:01:39 looks like times up 23:01:43 thanks everyone 23:01:43 casanch1: just stay tuned, itll be soon:) 23:01:49 #endmeeting