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