16:03:13 <cody-somerville> #startmeeting storyboard
16:03:14 <openstack> Meeting started Thu Mar 27 16:03:13 2014 UTC and is due to finish in 60 minutes.  The chair is cody-somerville. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:17 <openstack> The meeting name has been set to 'storyboard'
16:03:42 <cody-somerville> #link https://wiki.openstack.org/wiki/StoryBoard
16:03:59 <cody-somerville> #topic MVP status
16:04:14 <ttx> I don't see krotscheck around
16:04:18 <ruhe> well, what can we discuss without krotscheck and NikitaKonovalov? :)
16:04:30 <ruhe> i'll call Nikita on cell-phone
16:04:39 <cody-somerville> Well, I'll say that storyboard.openstack.org is looking pretty sharp :)
16:04:41 <ruhe> he was going to attend
16:04:43 <ttx> ruhe: we can discuss next meeting time and screw them up even more :)
16:05:09 <ttx> cody-somerville: maybe we could start with current login breakage ?
16:05:20 <cody-somerville> Indeed.
16:05:30 <cody-somerville> Logging into storyboard is currently broken, returns 500 error.
16:05:36 <cody-somerville> The bug number for this is.. oh wait.
16:05:39 <cody-somerville> :)
16:06:07 <cody-somerville> jeblair: You wouldn't happen to be able to check the logs real quick would you?
16:06:34 <jeblair> [Thu Mar 27 16:05:54 2014] [error] [client 2001:690:2380:7770:ca60:ff:fe0c:6111] ImportError: No module named migrate.changeset
16:06:47 <ttx> uh.
16:06:55 <jeblair> full traceback en route
16:07:03 <cody-somerville> Merci.
16:07:16 <fungi> cody-somerville: i was so hoping you'd provide a storyboard link to the bug ;)
16:07:30 <jeblair> http://paste.openstack.org/show/74456/
16:08:31 <ttx> weird, been around for a while
16:08:56 * ttx git blames Monty
16:09:14 <cody-somerville> So I suppose we have two issues:
16:09:22 <jeblair> i can reproduce with: >>> import storyboard.api.app
16:09:22 <cody-somerville> 1. login is broken; and
16:09:36 <cody-somerville> 2. our gate is broken.
16:09:52 <jeblair> 3. we have a testing hole?
16:10:24 <ttx> jeblair: I think that falls under 2
16:10:41 <jeblair> oh, that's what you meant
16:10:45 <krotscheck> Huhn - sorry, I've been heads down on the comments UI - when did s.o.o break?
16:10:47 <ttx> "gate" in the existantial sense
16:11:01 <jeblair> i usually associate 'gate broken' with jenkins giving -2 votes, not +2.  :)
16:11:05 <ttx> krotscheck: when did you last use it and it worked ?
16:11:14 <krotscheck> Two days ago?
16:11:17 <jeblair> so errors like this don't show up immediately
16:11:18 <krotscheck> ish?
16:11:24 <ttx> ish for me too
16:11:27 <jeblair> because apache keeps processes around for a while before discarding them
16:11:41 <cody-somerville> I think this commit is what introduced the bug: https://github.com/openstack-infra/storyboard/commit/856577614082b2b7856a41626587b8a6f5e0b3b8
16:11:42 <krotscheck> Huhn. Will file that one away
16:11:52 <jeblair> it can take a while for apache to get around to starting a new process that loads the wsgi app anew
16:12:05 <krotscheck> kk, so my problem to fix.
16:12:42 <ttx> jeblair: can't reproduce on master tox venv
16:13:08 <NikitaKonovalov> o/
16:13:13 <cody-somerville> the issue is that sqlalchemy-migrate is now being used in storyboard
16:13:22 <cody-somerville> sqlalchemy-migrate is only in the test requirements file
16:13:25 <cody-somerville> not requirements.txt
16:13:25 <jeblair> here's pip freeze from that server: http://paste.openstack.org/show/74460/
16:13:31 <jeblair> that would do it.
16:13:33 <ttx> cody-somerville: hah. nice catch
16:13:38 <jeblair> indeed it is not in that list.
16:13:55 <ttx> cody-somerville: back to our regular agenda ?
16:14:01 <cody-somerville> we'll also need eventlet it looks like
16:14:27 <cody-somerville> Sure thing
16:14:34 <cody-somerville> krotscheck: Any update on MVP status?
16:14:36 <krotscheck> Testing locally now.
16:15:05 <krotscheck> Comments and task updates have patches up, the backend is basically there
16:15:18 <krotscheck> ttx and I are arguing about comment ui.
16:15:57 <krotscheck> That's more-or-less the status of MVP
16:16:00 <jeblair> are either of you arguing that it shouldn't let you leave comments? :)
16:16:07 <krotscheck> :-P
16:16:12 <krotscheck> No, it's more about the layout
16:16:25 <NikitaKonovalov> We wanted auth to be a part of MVP
16:16:34 <NikitaKonovalov> so what about refresh token
16:16:38 <cody-somerville> Do we have a projected completion date for MVP? (or date rate?)
16:16:41 <cody-somerville> s/rate/range/
16:16:47 <ttx> krotscheck: arguably I'm bitching about the whole UI, abusing this change to do so :)
16:17:12 <jeblair> this one i take it https://review.openstack.org/#/c/82213/
16:17:17 <persia> Yep
16:17:26 <krotscheck> ttx: Well, do you want something that works, right now, and iterate on the UI later? Or do you want something later, that looks the way you want it to, that also works?
16:17:35 <ttx> krotscheck: if comment UI is the last step missing from MVP I'm fine letting it go and bitching about ordering in a separate bug
16:17:38 <cody-somerville> ttx: it would be cool if we could get to the point where we can bitch about the ui via storyboard comments on a bug ;)
16:17:51 <ttx> cody-somerville: no kidding :)
16:18:15 <krotscheck> MIssing pieces are the comment UI and that task update taht follows it.
16:18:16 <persia> So, columnar for now, and fix it after arguing in storyboard?
16:18:31 <krotscheck> That one's minor, it just changes the status labels into a dropdown.
16:18:47 <ttx> persia: the last change was no longer columnar
16:19:06 <krotscheck> ttx: persia: Well, it sortof is. Tasks got moved into more of a sidebar.
16:19:15 <ttx> krotscheck: if you think it's ready I'll +1 it and bitch about general UI separately.
16:19:23 <cody-somerville> #topic Foreign keys, soft deletion, oh my!
16:19:42 <krotscheck> ttx: It'll never be ready. That's the nature of UI
16:19:47 <ttx> krotscheck: fwiw we should probably use wireframes to bitch about UI
16:19:54 <krotscheck> ttx: I agree.
16:19:58 <krotscheck> Anyway: Soft deletion
16:20:05 <ttx> krotscheck: rather than forcing you to do wireframes in JS
16:20:39 <cody-somerville> Is this topic to discuss if we're going to drop foreign key constraints or not? or about something different?
16:20:58 <ttx> cody-somerville: and about soft-deletion and how that factors in
16:21:12 <ttx> I don't have strong opinions on that, but I know others have
16:21:28 <ttx> and it gets to the point where we should decide which way we want to go
16:21:41 <ruhe> dropping FKs means a lot of manual code to remove parentless records
16:21:50 <jeblair> i don't think soft deletion affects the question of using fk in the db
16:21:55 <jeblair> ruhe: no it doesn't
16:22:11 <jeblair> sqlalchemy needs to understand the relationships between tables in order for it to be useful at all
16:22:33 <jeblair> (like having a story object with a tasks attribute that is a list of tasks...
16:22:49 <jeblair> where the story and the tasks are loaded from two different tables, but it handles that automatically)
16:23:05 <cody-somerville> Ok. So I agree soft  deletion and dropping fk are separate issues.
16:23:11 <jeblair> part of establishing those relationships is also indicating how deletes are handled
16:23:29 <jeblair> so when you say story.delete() sqla should know to delete all the tasks as well.
16:23:41 <ruhe> jeblair: that changes my vote :)
16:23:59 <cody-somerville> what happens if raw sql is executed?
16:24:10 <jeblair> cody-somerville: by a rogue admin?
16:24:12 <krotscheck> Sounds to me like the harder problem would be teaching SQLA to do soft-deletes on child records. Is that already an option?
16:24:17 <cody-somerville> jeblair: no. in the code.
16:24:25 <krotscheck> cody-somerville: We -2 it.
16:24:52 <krotscheck> 'cause I'm ok just dropping soft deletes altogether
16:25:05 <jeblair> krotscheck: ++ on both counts
16:25:22 <cody-somerville> Ok, so I'm strongly opposed to dropping foreign key  constraints. I understand the argument. They're not compelling enough to me to discard the extra protection the constraints provide.
16:25:31 <cody-somerville> FWIW, I argued with Monty until he admitted he didn't care strongly about it.
16:25:51 <NikitaKonovalov> but when fetching a child object, we may check if his parent was deleted
16:26:04 <cody-somerville> Does mysql support views?
16:26:23 <krotscheck> NikitaKonovalov: That's harder to do on list GET's
16:26:35 <jeblair> cody-somerville: fwiw, i have zero interest in dealing with fk problems in the db.  so i do hope someone is going to step up and deal with that.
16:28:29 <ttx> fwiw, jeblair has final say here. they will run the thing
16:28:36 <cody-somerville> I should note that in sqlalchemy, the ORM is not a core component of the system. It is built on top. It also specifically supports the ability to swap out generated SQL with hand optimized statements.
16:28:37 <krotscheck> cody-somerville: If you feel that strongly about it, are you willing to take over management of our DB migrations?
16:28:41 <ttx> not saying he is right
16:28:54 <ttx> or wrong for that matter
16:29:25 <ttx> My weak preference is for dropping FKs because the drawbacks are not worth the benefits imho
16:29:43 <jeblair> my argument at the moment is that it should be on the table and we should explore it.  i'm not entirely certain what it would look like yet, so i actually think it's premature to make the call one way or the other
16:29:57 <jeblair> but i think we can get something on the table to look at pretty soon, and we should try to make a decision like that early
16:30:01 <ttx> the only benefit being "data lives longer than apps and it should always be consistent"
16:30:09 <ruhe> StoryBoard is young, we can try and see how it works
16:30:25 <cody-somerville> The sqlalchemy feature page also states "All object-relational patterns are designed around the usage of proper referential integrity, and foreign keys are an integral part of its usage."
16:31:07 <ttx> jeblair / cody-somerville: how easy is it to remove them / add them back in the future ?
16:31:22 * krotscheck is going to back out of this argument altogether, he's got enough battles looming on the UI
16:31:23 <ttx> i.e. is it a call we need to make now ?
16:31:39 <cody-somerville> It's easier to remove them later than to remove them and then re-add them later.
16:31:48 <ttx> krotscheck: you agree it's orthogonal to the soft-deletions issue ?
16:31:50 <persia> That's a frightening prospect: either the system integrity is guaranteed or one needs to audit it carefully
16:32:30 <jeblair> ttx: fairly easy to do both, but adding them back after removal can be difficult if we screw up the db in the interim
16:32:34 <krotscheck> ttx: Yup. Soft deletion is a data implementation detail. FK's are there for integrity.
16:32:49 <krotscheck> ttx: Different problems. Different approaches. Different solutions.
16:33:06 <NikitaKonovalov> in case with no FK, the db_api will be responsible for handling data correctly
16:33:27 <ttx> krotscheck: ok so we don't need to decide now. I put it on agenda because it looked like you needed a call to be made due to that issue leaking into the softdeletion issue
16:33:50 <cody-somerville> and once the database constraints are gone, corrupting the integrity of our data is easy as forgetting to add a dependency to the requirements.txt f ile.
16:34:07 <jeblair> cody-somerville: this is why tests are important
16:34:12 <ttx> Do we agree on where we are going for deleting objects ?
16:34:58 <jeblair> no objection to removing soft-delete
16:35:22 <cody-somerville> wait. we're discussing *removing* soft-delete?
16:35:29 <cody-somerville> I like soft delete. Tons of value to it.
16:35:59 <ruhe> cody-somerville: did you follow http://lists.openstack.org/pipermail/openstack-dev/2014-March/029567.html ?
16:36:01 <cody-somerville> jeblair: constraints are a type of test
16:36:06 <cody-somerville> I don't read those, no.
16:36:12 <cody-somerville> ;p
16:36:22 <jeblair> cody-somerville: hah, so there's a change to "move to soft delete" which has a -1 because "openstack is moving away from it"; so confusion about the motion on the table is understandable...
16:36:57 <jeblair> i probably should not have said "removing soft-delete" since i don't know how much soft delete we actually do right now...
16:37:35 <krotscheck> Backstory: I found the soft delete mixin in Oslo. I thought: Oh, we already have something like this, maybe we should use oslo instead! Then that thread started.
16:37:47 <NikitaKonovalov> jeblair: we have soft delete for stories, tasks, comments and tokens
16:38:15 <ttx> krotscheck: maybe we should just keep using what we use now and close the pandora box
16:38:27 <jeblair> a more general question is what do we need from the ux pov?  we don't ever really want to delete stories, right?
16:38:58 <cody-somerville> Yes, we may want to.
16:38:59 <jeblair> tasks?  maybe... comments? possibly admin-only (for spam/malware/etc), tokens?  hard-delete seems to make sense
16:39:10 <krotscheck> Good question. That hasn't relaly been discussed yet, I just put it in because people were putting garbage data into the UI
16:39:20 <NikitaKonovalov> a user may accidentally remove his comment, we may allow him to restore it
16:39:56 <cody-somerville> Plus metrics and stats are important (like comments over time). We'd want to continue to have that data even if we say delete a project.
16:40:09 <krotscheck> The reason I used soft delete because I started running into issues where I'd deleted a project, but the task still showed up as active.
16:40:29 <krotscheck> cody-somerville: Data collection is a separate issue, and I don't think that should be handled directly from DB data.
16:40:36 <krotscheck> we can argue about how to do that later.
16:40:49 <jeblair> i'm a 'urls are forever' kind of guy, so i would be in favor of having projects, stories and comments be able to be deleted only by an admin
16:41:01 <krotscheck> Honestly, I'd rather prefer hard deletes as long as the key references are properly handled.
16:41:03 <jeblair> we can't delete gerrit projects anyway, so it's not going to come up very often.
16:41:58 <persia> Deleting tasks is probably more common: sometimes one discovers one doesn't need to do something.
16:42:17 <cody-somerville> I really want soft deletes. cause I know I'll need them.
16:42:21 <persia> Comments are also popular for edit/delete, although there are revisionist historical arguments against that.
16:43:09 <NikitaKonovalov> we need to delete tokens not in a 'soft', or they will slow down the database, when there are millions of them
16:43:16 <cody-somerville> #agreed Keep foreign keys. Discussion can be re-opened later down the road if needed.
16:43:46 <jeblair> cody-somerville: i thought we were talking about soft delete?
16:43:46 <cody-somerville> NikitaKonovalov: agreed.
16:44:08 <cody-somerville> #agreed Keep soft deletes. Discussion can be re-opened after MVP.
16:44:21 <cody-somerville> Anything else on this topic? We need to move on with agenda.
16:44:27 <ttx> jeblair: I'm a "urls are meaningful' guy, and I don't really like URLs using numbers to designate projects... not sure how to fix it though
16:44:43 <ttx> codekobe: nope, move on
16:44:48 <ttx> cody-somerville: ^
16:44:48 <jeblair> ttx: yeah
16:44:52 <cody-somerville> #topic Finishing auth: refresh tokens, clearing db from unused codes and tokens
16:44:52 <ttx> codTAB fail
16:44:57 <krotscheck> Huh? We didn't agree on either of those.
16:45:02 <cody-somerville> Yes we did.
16:45:20 * krotscheck reads scrollback
16:45:37 <cody-somerville> NikitaKonovalov: What's the sitrep with auth? :)
16:46:22 <NikitaKonovalov> we want it to be apart of mvp
16:46:35 <krotscheck> I said I prefer hard deletes. jeblair said he wants only admins to delete things, and said hard-delete makes sense. How did we agree on keeping soft delete?
16:46:36 <NikitaKonovalov> the missing thing is handling the refresh_token
16:46:44 <krotscheck> Did I miss something?
16:47:22 <cody-somerville> krotscheck: We currently have soft deletes. There was no strong consensus to remove that functionality and considerable consensus the feature can be useful.
16:47:30 <cody-somerville> NikitaKonovalov: What needs to happen there?
16:47:36 <NikitaKonovalov> now the user has to authorize every hour when his access_token expires
16:47:40 <krotscheck> cody-somerville: Maintaining the status quo is not agreeing on anything.
16:48:04 <NikitaKonovalov> so what we need is ...
16:48:17 <NikitaKonovalov> just follow the protocol on both sides
16:48:49 <NikitaKonovalov> The server is almost ready, except for a /token endpoint
16:49:14 <NikitaKonovalov> the client needs a check for expiration to send refresh request
16:49:34 <cody-somerville> NikitaKonovalov: I agree that authentication should be a part of the MVP, especially with it being so close to  completion.
16:50:18 <cody-somerville> Does anyone object to authentication being part of the MVP?
16:51:03 <krotscheck> I believe that the current state of auth is sufficient for MVP
16:51:16 <krotscheck> Refresh tokens are nice, but not necessary
16:51:17 <jeblair> yeah, i'm not actually following what's missing
16:51:46 <NikitaKonovalov> jeblair: you have to go through launchpad every hour using storyboard :)
16:51:51 <ttx> refresh token can be out of MVP
16:51:57 <ttx> (imho)
16:52:09 <cody-somerville> Can we just extend the expiration of the token?
16:52:16 <cody-somerville> that is, the default initial one?
16:52:27 <NikitaKonovalov> cody-somerville: we can
16:52:43 <jeblair> NikitaKonovalov: got it.  yes, i don't think that's too important for mvp, but should definitely be the next auth-related thing we do.
16:52:45 <cody-somerville> Cause I'm pretty sure I've been using the same cookie for launchpad itself for months ;p
16:53:37 <NikitaKonovalov> so let's just extend the time to 24 hours then
16:54:02 <cody-somerville> How about a week?
16:54:40 <krotscheck> 24 hours seems good. Just annoying enough for us to remember to put refresh tokens in.
16:54:45 <jeblair> krotscheck: ++
16:54:51 <krotscheck> A week drops below the threshold of giving a fuck.
16:55:03 <NikitaKonovalov> I think we'll agree on a configurable value
16:55:16 <cody-somerville> If you submit a form or something when token expires, do we hold the data and submit it after auth?
16:55:49 <cody-somerville> #agreed Current state of auth is sufficient for MVP
16:55:56 <krotscheck> Nope. We don't maintain state when you're redirected to launchpad.
16:56:14 <cody-somerville> #agreed Extend default token expiry to 24 hours.
16:56:16 <persia> cody-somerville: Hrm?  I thought we agreed that auth token expiry should be adjusted to 24 hours, rather than 1.
16:56:49 <cody-somerville> It's a configuration value apparently.
16:57:07 <cody-somerville> #topic Next meeting time (rest of world DST)
16:57:11 <cody-somerville> ttx: ^^
16:57:19 <ttx> oh ya
16:57:34 <ttx> rest of world moves to summer time this weekend
16:57:48 <ttx> so this meeting time will start becoming inconvenient for me
16:57:51 <ruhe> ttx: aren't we a part of the world any more? :)
16:58:05 <ruhe> we don't have summer/winter time
16:58:13 <ttx> ruhe: oh
16:58:22 <ttx> ruhe: so it might not be that much of a problem then
16:58:51 <ttx> I'll just have trouble attending starting next week
16:59:25 <cody-somerville> Should we change the time?
16:59:28 <ttx> but I suspect one hour earlier makes it bad for krotscheck (that's what we had pre-DSt change)
16:59:33 <cody-somerville> ah
16:59:36 <krotscheck> nope.
16:59:41 <krotscheck> We got bumped
16:59:57 <ttx> krotscheck: would one hour earlier work for you ?
17:00:08 <krotscheck> Going an hour earlier will make it 8am for me again, which is what it was before our own DST change.
17:00:19 <krotscheck> So yes, that'll work
17:00:32 <jeblair> one hour earlier or later wfm;
17:00:40 <jeblair> one hour earlier would make it 7am after we change back though
17:00:50 <ttx> ok so 15:00 UTC during summer season
17:01:01 <ttx> jeblair: we'll change again then
17:01:12 <cody-somerville> #agreed Move meeting one hour back
17:01:15 <cody-somerville> #endmeeting