16:00:08 #startmeeting Storyboard 16:00:10 Meeting started Mon Feb 2 16:00:08 2015 UTC and is due to finish in 60 minutes. The chair is krotscheck. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:14 o/ 16:00:15 The meeting name has been set to 'storyboard' 16:00:36 Agenda! https://wiki.openstack.org/wiki/StoryBoard#Agenda 16:00:55 #topic Actions from last week: Get storyboard to a happy place 16:01:04 Storyboard is happy again! 16:01:13 hi 16:01:21 totally happy? :) 16:01:23 We still have an outstanding discussion on validation. 16:01:52 Which, to be honest, I don’t exactly recall the details of. 16:02:04 I’ll bring that up in discussion topics. 16:02:23 #topic Actions from Last week: Gating Tests (yolanda) 16:02:30 so there is a pending spec 16:02:32 let me link it 16:02:58 https://review.openstack.org/150743 16:03:22 i created a proposal, then i got some comments from jeblair, and i amended it according to the comments 16:03:38 * krotscheck likes the changes :) 16:03:56 o/ 16:04:12 i wanted to start working on that, maybe i can just start adding integration tests on the client till we get final approval 16:05:02 yolanda: Given that we already have the integration framework there, that makes a lot of sense. 16:05:15 And, to be honest, the test suite on the client is rather atrocious. 16:05:28 Anything else? 16:05:28 well, you said that, not me :) 16:06:03 Alright, moving on! 16:06:06 #topic Urgent Items 16:06:13 some things still broken 16:06:15 Did anything come up that needs immediate attention? 16:06:18 oh> 16:06:19 ? 16:06:28 niet 16:06:36 worker daemon is broken 16:06:36 yolanda: What’s broken? 16:06:40 oh yeah that 16:06:41 Right 16:06:45 i created a fix but i need to amend it 16:06:45 https://review.openstack.org/151630 16:07:00 check if options are already declared, i thought it only was called from that entry point 16:07:06 Got it. 16:07:11 So 16:07:27 That particular execution path exists only for two reasons. 16:07:40 1: Engineer convenience. It’s nice for one of us to just spin up one worker. 16:07:59 2: In case someone else wants to wroll teir own startup script instead of using ours. 16:08:50 Given that 1 is easy enough to circumvent simply by invoking python (though it would require additional documentation) 16:09:02 And we don’t have any reported use of 2 yet.... 16:09:07 …do we really need it? 16:09:16 yolanda: btw, maybe newer oslo.log versions handle that better? I've heard some one else had problems initialising logger 16:09:37 That’d also be worth looking at. 16:09:44 NikitaKonovalov, i google that, yes, i discovered the origin of the problem just seeing a similar case in nova, i think 16:10:03 Would it make sense to patch oslo? 16:10:21 well, oslo raises an exception 16:10:25 we could handle that properly 16:10:37 That works! 16:10:44 Or add a new main() method.... 16:11:06 Lots of sane options, I’m ok leaving it to you to figure out which one’s best. 16:11:33 i'm afraid of just patching this one with new method and then have same case on the future with some other entry points 16:12:05 maybe just enclose all the calls for register options and catch this exception in particular? 16:12:42 I don’t see any major problems with that. NikitaKonovalov, any thoughts? 16:12:46 yolanda: catching specific exception lgtm 16:13:07 ok 16:13:11 sounds good 16:13:20 also... general validation in the client is broken :) 16:13:20 Cool, anything else that’s urgent? 16:13:33 new checks for min length are not handled properly 16:13:41 it just fails silently on the frontend 16:13:44 i started patching that 16:13:53 https://review.openstack.org/152133 16:14:23 this is one but checks need to be placed properly on all templates 16:15:30 Is this project_groups only? 16:15:47 yes, i just sent a patch for project groups 16:15:51 wanted to send them by separate 16:16:00 because each one has its own problems 16:16:39 btw, there are some cases that cannot be handled by simple angular validation, such as duplicates, and this isn't reported on the frontend, it fails silently as well 16:16:44 Ok, something definitely seems off there. 16:16:57 Also, why are our errors not showing up in the UI anymore? 16:17:23 krotscheck, i have never have seen errors from backend showing into the UI , so i cannot tell :( 16:17:26 #action krotscheck Figure out why client errors are not being shown to the user. 16:17:29 Right 16:17:42 It should be the same thing that shows “You have been logged out”, except red or yellow. 16:17:59 maybe they come in another format now? 16:18:15 Perhaps. 16:18:33 I’ll check it out. That should fix 99% of the client validation problems I think. 16:18:42 Any other urgent items? 16:19:12 #topic User Feedback 16:19:15 * yolanda stops reporting broken things now 16:19:37 * krotscheck got a positive feedback from infra last week, but doesn’t recall who it was from :/ 16:19:52 Moving on 16:20:09 #topic Discussion topics: How to unset attributes in REST API (nkonovalov) 16:20:35 so the question here is how to unset an assignee_id of a task for example 16:20:55 the most obvious option is to send None 16:21:09 but the issue is that we filter out Nones on backend 16:21:41 how about creating an application level 'undefined' value for that 16:21:45 Right- because we don’t accidentally want to overwrite if someone sends partial data. 16:21:58 rcarrillocruz: that's the second option:) 16:22:06 and I actually like it 16:22:20 None seems like the one which everyone’s going to expect. 16:22:50 So, javascript has three different null values: null, undefined, and false. 16:22:53 krotscheck: from nibalizer, remarking on the ease of use when we have 60+ tasks 16:23:01 jeblair: Oh, thanks! 16:23:15 krotscheck: if we treat None as a command to unset a value, the client should not send it when it simply does not know the value 16:23:46 btw, null and undefined are both treated as python None 16:24:05 so I see 2 scenario here: 16:25:03 1. Make client send None to unset a value, handle this on backend and handle that user is not unsetting something he should not 16:25:53 2. Send some specific values like -1 for integers and empty sting for strings, handle that on backend and continue skiping Nones 16:26:10 1 could become messy :-) 16:26:33 rcarrillocruz: agree it involves additional validation 16:26:39 2 tromps over valid use cases. I might want to set an integer to -1 16:27:08 but from the other point we will need ACL valitdations some day 16:27:44 if we go for 1, could we do it with middleware? 16:27:55 What’s the REST-y thing to do? 16:28:10 my point is, it's tempting to write if/else in backend to validate things, but that can become messy quickly... 16:28:28 rcarrillocruz: I agree. 16:29:11 Will jsonschema permit us to set valid values for each field? Say, ‘This must be a string of 3-255 characters, but it can also be None' 16:29:12 krotscheck: I'm not sure but I think there are some solutions utilizing PUT and PATCH request types 16:29:36 krotscheck: jsonschema allows to set a string or none 16:30:10 the quetion is None means do_not_change of set_to_None 16:30:17 or* 16:31:09 I think it should mean ‘set_to_value’. Example: if we POST something (create), we can either post a task with an assignee or post it with None as the assignee. 16:31:34 In that case it’s very clearly “Here’s what I want this resource to be". 16:31:43 krotscheck: ok, and PUT? 16:32:17 I don’t really want the meaning of any convention to change between HTTP methods. 16:32:39 The way our backend works right now, if I simply omit a field, then we don’t make a change. 16:33:28 So the difference between wanting to unassign or ignore, is either PUT {assignee_id: None} or PUT { values_other_than_assignee_id } 16:33:32 But then the question becomes. 16:33:38 PUT is supposed to operate on entire entities. 16:33:43 yep 16:33:58 WHich means it’s the client’s job to keep state. 16:34:06 And, well, I’m kindof ok with that. 16:34:34 The complex part there though becomes once we have ACL's. 16:34:34 so if we treat a None as command to unset a field, the client should be carefull sending that 16:34:39 Yep. 16:34:41 Very careful 16:34:44 krotscheck: exactly 16:35:30 With ACL’s there’s the third question. Q1: Does the value match our constraints, Q2: Is this person logged in, Q3: Is this person allowed to change _this_ field to _that_ value. 16:35:39 I guess it's time to get ACLs to StoryBoard, than we can tell who can set/unset what 16:36:17 Will JSONschema support invoking custom validation methods? 16:36:43 krotscheck: allows to define validations 16:37:12 Good enough 16:37:29 so Q1 goes under jsonscema 16:37:44 Q2 is a hook we already have 16:38:33 Q3 is what I guess is described here https://review.openstack.org/#/c/103667/ 16:38:45 I… guess? 16:38:49 Right 16:39:04 I need to look at that spec again to make sure it still makes sense. 16:39:28 But for the sake of setting things to None, it feels like JSONschema is all we need. 16:40:38 so right now we may have a jsonschema that allows None, and db_api sets it and the client is just not sending None values until it is told to do so 16:40:55 RIght. 16:41:09 That’s going to require a lot of integration tests on the client to make sure it stays sane. 16:41:49 once ACLs appear some users will just not be able to set/unset fields but that looks like an independent change 16:42:07 Right 16:42:15 and yep, we need to test this before some send None everywhere he can 16:42:23 And at that poitn the client will have to load a user’s ACL’s so it knows what to enable and/or disable. 16:43:23 NikitaKonovalov: Ready for the tags discussion? 16:43:29 yep 16:43:39 #topic Discussion: Where to place tags in UI? 16:43:51 Project tags? Story Tags? All the tags! 16:44:02 We now have Story tags only 16:44:54 what's the use case for project tags? 16:45:40 rcarrillocruz: That’s part of the new openstack project dimensions the board is working on. 16:45:50 rcarrillocruz: there were some, but we agreed to have project_groups, which seem enough 16:46:00 everything may change though 16:46:04 Exactly 16:46:11 But now we’re talking about story tags only 16:46:26 there is not much space left on a story page 16:47:08 Listing them out right under the Author/last updated might work. 16:47:08 I think the best place is between tasks and comments 16:47:51 i prefer on the right side, but how does it work on mobile? 16:48:41 * NikitaKonovalov has never checked SB in mobile browser. Need to try 16:48:49 We’ve got three different opinions now :) 16:48:55 * rcarrillocruz will open a story to have an Android SB app 16:48:55 Fun fun :) 16:49:06 rcarrillocruz: Do that 16:49:09 :D 16:49:23 rcarrillocruz: You’d be surprised how easy that’s going to be. We can install it directly from the javascript 16:49:54 btw, at some point we'll need to find place for tasks branch/milestone 16:50:04 but that's out of scope now 16:50:07 oh? is that with some PhoneGap black magic? 16:50:41 I’ve been taking a long hard look at the JIRA task ui, to see what we can pull from that. 16:50:42 https://issues.apache.org/jira/browse/CASSANDRA-8715 16:50:44 As an example 16:50:59 It doesn’t do so well in mobile. 16:51:09 But it does seem to hold up rather well. 16:51:48 I feel it’d benefit us to break apart the different properties of a story into different taxonomies. Some are story properties, some are user based, etc. 16:52:04 If ttx was here I’d totally ask him his opinion, but he’s travelling :) 16:52:33 lp tags are not that easy to locate on the page https://bugs.launchpad.net/sahara/+bug/1319079 16:52:56 Wow. 16:52:59 Yeah, that’s kindof terrible 16:54:34 i have a quick update on the streaming api 16:54:38 5 minute warning 16:55:11 NikitaKonovalov: How about you come up with a UI draft and see how people feel about it? That’s why we have the draft build after all. 16:55:25 re tags: I'll start implemeting that part and when the thing comes to the layout we'll get back to discussion 16:55:49 Alright. 16:55:54 krotscheck: yep, that's what the js-draft is for 16:55:58 #topic Discussion: Streaming API 16:56:02 rcarrillocruz: Go 16:56:03 :) 16:56:24 i need the notifications events to show up time and the data per the pubsub spec 16:56:45 as we discussed with krotscheck, we were working on similar things, but your change was much wider in scope 16:56:46 https://review.openstack.org/#/c/151645 16:57:22 i'd like to get reviews, krotscheck you could then base your changes on that mechanism of passing entity state in the hook? 16:57:26 This change will also benefit subscriptions and emails. 16:57:29 i put tests as yolanda asked 16:57:34 rcarrillocruz: Absolutely :) 16:57:37 cool 16:57:50 in other news, the replay/reconnect thing, i thought 3 options: 16:58:24 1. having a deferred queue that piles up messages. Won't work, i thought having durable attributes would allow to pick messages from that queue from several consumers without consuming, that's not possible 16:59:02 2. have a streams queue where the consumer consume events and a 'backup' queue for storing all messages in case they want to replay. Unscalable, we'd need 2 queues per consumer 16:59:49 (time is almost upon us!) 17:00:01 3. have a x-expires TTL attribute in the consumer queues that expires if it has not been action in 5 minutes (whichever value, that's arbitrary) to allow clients to reconnect, and use DB queries to do the replay part 17:00:04 i'll go with 3 17:00:06 bye! 17:00:10 Ok, thanks everyone! 17:00:11 #endmeeting