15:02:35 <krotscheck> #startmeeting storyboard
15:02:35 <openstack> Meeting started Mon Apr  7 15:02:35 2014 UTC and is due to finish in 60 minutes.  The chair is krotscheck. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:39 <openstack> The meeting name has been set to 'storyboard'
15:02:44 <SergeyLukjanov> o/
15:02:51 <krotscheck> #topic MVP Status
15:02:58 <mordred> morning all
15:03:02 <krotscheck> Ok, so what’s outstanding?
15:03:33 <krotscheck> I did a strawpoll in #storyboard earlier, current consensus seems that MVP is complete.
15:03:48 <ttx> o/
15:04:00 <mordred> I think I still need to go clean out some of the extra data from the current install - and then I thnk per last week's infra meeting we're going to start using it to track zuul and nodepool
15:04:08 <ttx> agreed, that's why I adde a MVP 1.01 topic for end of meeting :)
15:04:14 <krotscheck> Got it, so MVP is done.
15:04:15 <mordred> as a first step
15:04:20 * krotscheck pops the champagne
15:04:33 <krotscheck> #topic easier access to logs
15:04:42 <ttx> krotscheck: thanks for keeping us all honest and going forward :)
15:04:49 <jeblair> the task statuses aren't what we discussed at the sprint, but i assume that's an easy patch
15:04:54 <krotscheck> cody-somerville: Is this a zombie topic from last week?
15:05:14 <krotscheck> jeblair: Yes, that can be done quickly. Submit a story?
15:05:34 <cody-somerville> zombie topic from last week, yes. sorry.
15:05:38 <krotscheck> Got it
15:05:46 <krotscheck> #topic ux labs /resources
15:06:11 <krotscheck> Personal question for me: Other than redhat, what UX labs / usability resources do we have available other than “make grumpy engineers use it?
15:06:39 <mordred> I think "make grumpy engineers use it" is what we have for now
15:06:56 <krotscheck> Ok, that’s from HP. I can occasionally get some feedback from jcoufal, anything from Mirantis?
15:07:04 <ttx> grumpy engineers are like 80% of our target population anyway
15:07:05 <mordred> there's a UX dude at HP we can talk to to see if he'll do some UX studies on it (he ran some on horizon recently)
15:07:24 <krotscheck> Alright, new user profile: Grumpy Engineer.
15:07:32 <krotscheck> mordred: Send me an intro?
15:07:40 <mordred> krotscheck: I shall
15:07:42 <krotscheck> Good
15:07:46 <jcoufal> yeah, it's piet kruithof
15:07:53 <jcoufal> he might help with usability testing
15:07:59 <krotscheck> #action mordred Send krotscheck intro to piet kruithof
15:08:03 <ttx> we actually identified two profiles. Linux grumpy engineer and MacOs hipster dev
15:08:06 <SergeyLukjanov> + grumpy release manager proflle
15:08:14 <krotscheck> :-P
15:08:16 <krotscheck> Hipster?
15:08:24 <ttx> the second profile likes stuff that resembles github
15:08:32 <ttx> by principle
15:08:36 <krotscheck> mordred: I think… I don’t know what I think about being called a hipster :)
15:08:41 <krotscheck> ANYWAY
15:08:55 <krotscheck> #topic design discussion: Search & DB support
15:09:07 <ttx> krotscheck: i was not thinking about you
15:09:09 <krotscheck> So, our list views right now fail hard.
15:09:21 <krotscheck> As does any project dropdown.
15:09:41 <krotscheck> Now, for the time being we can do a cached typeahead, however that’s not going to scale.
15:09:46 <ttx> krotscheck: i suggested typin URLs by hand but somehow you didn't like it
15:09:52 <krotscheck> (cached typeahead: Load all results, filte rthem in browser memory)
15:10:04 <krotscheck> ttx: That’s orthogonal :)
15:10:29 <krotscheck> ttx: That’s more of a “how to find a specific project” issue rather than “find all tasks like X” issue
15:10:39 <NikitaKonovalov> krotscheck: but if the query fails on the server side, how filtering would help inside a browser?
15:11:01 <ttx> krotscheck: list views fail ? or the project list view fails ?
15:11:33 <krotscheck> NikitaKonovalov: The UX for actually finding a specific project, task, or story is bad. The sort order is wrong, items are shown that are closed, there’s no way to search by text, etc.
15:11:35 <mordred> krotscheck: so - we probably want some amount of both thing, right?
15:11:43 <krotscheck> mordred: Yes.
15:11:50 <ttx> krotscheck: I think users shall be able to subscribe to project (and/or project groups) and get them in a default view
15:12:21 <mordred> ttx: that still doesn't help wehn I want to find something for a project I'm not subscribed to - which i do in gerrit more than neer
15:12:25 <ttx> they should almost never search for them
15:12:28 <krotscheck> ttx: True. Difficult to do if you can’t find what you’re looking for in the first place.
15:13:03 <ttx> krotscheck: it's difficult but not impossible. And with subscription it's a one-time pain
15:13:10 <krotscheck> So the actual question I have is this: SQLAlchemy does _not_ have a good fulltext abstraction.
15:13:18 <krotscheck> That’s more or less requred for search
15:13:20 <ttx> (agree it can use improvement)
15:13:25 <krotscheck> (rather than browse. Browse is well understood)
15:13:57 * ttx ttx uses CTRL-F in project list window
15:14:04 <krotscheck> Should we A) pick either postgres or mysql, and use their own fulltext search, or B) take what ruhe suggested and get elastic search up and running?
15:14:30 <krotscheck> Thoughts?
15:14:45 <NikitaKonovalov> well, mysql whould be fine for searching in 'name' fields
15:15:18 <NikitaKonovalov> we may even let it fetch all the data (projects) and then filter in db_api
15:15:19 <jeblair> mordred: i think there are other full-text options for mysql, yeah?
15:15:23 <krotscheck> NikitaKonovalov: Yes. What about description fields?
15:15:39 <mordred> door number 3
15:15:41 <krotscheck> Or ‘name’ and ‘description’ fields.
15:15:50 <jeblair> i'm pretty sure we would like to search across all fields, including descriptions and comments
15:15:52 <ruhe> jeblair: there is mysql sphinx
15:15:56 <mordred> we should stay with mysql - and we should use sphinxsearch with it
15:16:01 <NikitaKonovalov> krotscheck: no differece for those i  guess
15:16:04 <jeblair> ruhe: that's what i was thinking of...
15:16:34 <krotscheck> mordred: jeblair: That requires ditching postgres altogether, yes?
15:17:40 <jeblair> krotscheck: i believe so.  i don't have a problem with that.
15:17:58 <krotscheck> Alrightey, let’s vote on it.
15:18:02 <jeblair> fungi: you've poked at our elasticsearch cluster a bit more than i have...
15:18:14 * krotscheck assumes that he can figure out the vote syntax.
15:18:20 <ruhe> postgres is always several steps behind. most OpenStack projects don't have indexes configured for it
15:18:32 <jeblair> fungi: my thoughts are that the infrastructure and maintenance burden is too big for a problem like this
15:18:41 <krotscheck> #vote Deprecate all secondary database support in favor of one.
15:18:48 <fungi> yeah, i think the search limitations we have are imposed by us to aboid dos'ing the cluster currently
15:18:55 <mordred> I'm not sure whether sphinx can work with postgres - but I have to be hoenst that I do not care about our postgres support personally
15:18:59 <jeblair> perhaps that's just because i've only seen it used in a frighteningly busy system
15:19:06 <krotscheck> #startvote Deprecate all secondary database support in favor of one.
15:19:06 <openstack> Unable to parse vote topic and options.
15:19:10 <krotscheck> Dammit
15:19:14 <krotscheck> Someone else do that
15:19:24 <jeblair> krotscheck: http://ci.openstack.org/irc.html#voting
15:19:32 <ttx> krotscheck: only the meeting chair can :)
15:19:33 <fungi> the quantity of data in storyboard is likely to never pose a problem for elasticsearch substring matching, by comparison with the volume of log data we're currently stashing in it
15:19:34 <krotscheck> Oh
15:19:52 <krotscheck> : #startvote Deprecate all secondary database support in favor of only one? Yes, No, Maybe
15:20:16 <jeblair> fungi: right, but are we going to need to run another 'cluster'? what's the minimal cluster look like?
15:20:48 <jeblair> krotscheck: once more without the ': '
15:21:03 <fungi> oh, yeah from a sizing standpoint i have no idea, but am pretty sure we can run a one-node cluster and not do any sharding initially
15:21:06 <krotscheck> jeblair: There isn’t one....
15:21:31 <fungi> since that's what clarkb set up originally before we grew it to cope with the volume we have
15:21:54 <krotscheck> #startvote Deprecate all secondary database support in favor of only one?
15:21:55 <openstack> Begin voting on: Deprecate all secondary database support in favor of only one? Valid vote options are Yes, No.
15:21:56 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
15:22:10 <ruhe> #vote Yes
15:22:11 <NikitaKonovalov> #vote Yes
15:22:13 <fungi> i expect we could probably reuse the existing cluster instead if we want, though right now it's already at capacity so we might need to expand it further
15:22:16 <krotscheck> #vote Yes
15:22:19 <jeblair> #vote Yes
15:22:23 <ttx> #vote Abstain
15:22:30 <ttx> :)
15:22:35 <krotscheck> #endvote
15:22:36 <openstack> Voted on "Deprecate all secondary database support in favor of only one?" Results are
15:22:52 <krotscheck> Ok, so next issue: Which database to pick.
15:22:55 <ruhe> it might be reasonable to conduct a study of mysql+sphinx+sqlalchemy before the decision is made to build on top of these technologies
15:23:04 <jeblair> fungi: i'd rather not; i think storyboard search uptime is far more important that test log uptime
15:23:18 <mordred> #vote Yes
15:23:20 <jeblair> fungi: so we wouldn't be able to take it offline for, say, a day in order to rebuild indexes anymore
15:23:25 <mordred> sorry (got distracted)
15:23:38 <krotscheck> Ok, ruhe: Do you  have time to do this study?
15:23:59 <fungi> jeblair: agreed. we could pilot with a one-node shardless cluster initially and then go to two or three with shards if we wanted better performance/capacity (if it ever became necessary)
15:24:15 <fungi> might even be able to just stick the elasticsearch and storyboard instances on the same vm for better performance
15:24:47 <krotscheck> #startvote Pick a database? mysql, postgres, sqlite
15:24:48 <openstack> Begin voting on: Pick a database? Valid vote options are mysql, postgres, sqlite.
15:24:49 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
15:24:52 <fungi> i'd want to pass this by clarkb later though since he very well may be able to point out that i'm being an idiot
15:24:53 <NikitaKonovalov> is it hard to run elastic search loaclly?
15:24:59 <ttx> #vote mysql
15:25:14 <jeblair> fungi, krotscheck: i agree, we should ask clarkb to weigh in on this; he's our elasticsearch expert
15:25:19 <ruhe> krotscheck: i do, if time is equal to 10 days. but i'd prefer ES instead of sphinx (maybe because i have osx and i'm kinda hipster)
15:25:21 <NikitaKonovalov> #vote mysql
15:25:22 <jeblair> #vote mysql
15:25:28 <ruhe> #vote mysql
15:25:28 <mordred> #vote mysql
15:25:35 <krotscheck> #endvote
15:25:36 <openstack> Voted on "Pick a database?" Results are
15:25:37 <openstack> mysql (5): mordred, NikitaKonovalov, ttx, jeblair, ruhe
15:25:50 <krotscheck> Ok, we’re using msyql, end of story
15:26:08 <ttx> now we could dramatically simplify our initial migrations
15:26:16 <krotscheck> Last question: We need search, we’ve got two options on the table - sphinx and elasticsearch. I do not know enough about either of these to make a decision, who wants to be our expert?
15:26:33 <krotscheck> ttx just volunteered to fix our migrations
15:26:34 <ruhe> ttx: you mean squash all the existing migrations into a single one?
15:26:52 <krotscheck> Or is there a third option? :)
15:26:53 <ttx> ruhe: rather than keep the postgresql compat cruft yes
15:27:11 <ttx> but then I don'ty know how the prod system would like that
15:27:58 <krotscheck> #action ttx File a story in storyboard to get the postgres cruft out of our database migrations.
15:28:02 <jeblair> krotscheck: i think we should get clarkb and mordred, at least, into a conversation, as ES and sphinx experts respectively
15:28:10 <ruhe> ttx: they manage it somehow in giant projects like Nova. It should be a piece of cake in StoryBoard :)
15:28:26 * mordred will ping the guys at sphinxsearch and see if they're interested in helping
15:28:50 <krotscheck> jeblair: You got it. I’ll grab clark and mordred offline and get a better sense of the benefits/tradeoffs.
15:28:52 <jeblair> mordred: what does that look like on the sysadmin side?
15:28:52 * ttx is multitasking on 3 cores
15:29:07 <jeblair> krotscheck: feel free to do it online.  :)
15:29:15 <krotscheck> #action krotscheck extract mordred and clarkb’s brain segments on elastic search vis-a-vis sphinx.
15:29:29 <krotscheck> jeblair: Yeah, but that discussion does not have to happen in this meeting :)
15:29:42 <jeblair> krotscheck: yep
15:30:02 <krotscheck> #topic FK or no FK
15:30:06 <krotscheck> I’m bringing both FK and soft delete back up because I felt the discussion 2 weeks ago was prematurely cut off.
15:30:15 <krotscheck> With regards to foreign keys, I propose keeping them. The argument _for_ is all about referential integrity, which is well understood and comes with clear benefits.
15:30:23 <krotscheck> The argument _against_ is ‘performance’ and ‘code duplication’. Only the latter is understood as a benefit, while the former (performance) is a complete unknown vague promisey thing which nobody’s been able to put numbers around, and given our scale, isn’t even necessary yet.
15:30:32 <krotscheck> Throwing away referential integrity in favor of something whose benefits are poorly explored because of optimizations we don’t yet need feels premature to me.
15:30:46 <krotscheck> If foreign keys become a performance constraint, we can revisit and explore this. Until then I propose that we stick with FK’s.
15:31:39 <krotscheck> Basically: I think referential integrity is a better benefit than code duplication, because we really should be testing the latter.
15:31:44 <jeblair> krotscheck: i feel you may have misapprehended my arguments for dropping FK support
15:31:56 <krotscheck> jeblair: Oh?
15:33:08 <jeblair> krotscheck: i'm primarily interested in dropping it because of the complications introduced by defining the same relationships in multiple places
15:33:26 <jeblair> the multiple places being both the orm and the database
15:34:04 <jeblair> that is error prone and one can end up with problems resulting from mismatches there, as we've already seen
15:34:16 <krotscheck> jeblair: The only place where I’ve seen that become an issue is in cross-database situations, are there others?
15:34:58 <krotscheck> My hypothesis is that now that we’re on mysql only, most of those issues won’t crop up anymore.
15:35:03 <NikitaKonovalov> btw, will it be valid if we set up constraints in migrations, but do not tell sqlalchemy anything?
15:35:15 <jeblair> krotscheck: i'm pretty sure it's come up in earlier problems with storyboard's migrations; also, i believe the current unit tests have FK errors
15:35:32 <jeblair> NikitaKonovalov: i think that's backwards -- sqlalchemy needs to know the constraints, the database does not
15:35:45 <jeblair> it's redundant to have two different systems checking those constraints
15:35:46 <mordred> NikitaKonovalov: I want to do the opposite
15:35:49 <mordred> yeah - what NikitaKonovalov said
15:35:51 <krotscheck> jeblair: It sounds like we can test for the kinds of errors you’re concerned about, is that correct?
15:36:02 <mordred> the important part is the the orm layer know about them
15:36:11 <mordred> that' VERY important
15:36:42 <krotscheck> Does SQLAlchemy keep an in-memory running cache of queried records, or does it handle things on a per-request basis?
15:37:15 <NikitaKonovalov> krotscheck: it handles sessions
15:37:24 <jeblair> krotscheck: during a session, records are cached; in our case a session is probably a single http request
15:38:23 * mordred has to drop off
15:38:53 <krotscheck> Got it. I get that the ORM needs to know about relationships to simplify reading records and related records. The DB-side FK constraint to me is most useful when _deleting_ records.
15:39:07 <jeblair> krotscheck: the orm is responsible for that too
15:39:16 <ttx> don't FKs make migrations slightly more complex/costly, which increase the downtime windows ?
15:39:38 <krotscheck> ttx: Again, i think it’s testable.
15:40:05 <ttx> I think the only valid argument FOR FKs is that the data will outlive the app. Which frankly, I doubt.
15:40:31 <krotscheck> Ok, any more arguments for/against? I’d like to move to vote.
15:40:34 <ttx> I've seen data migrated away from systems well before said systems are replaced by some other on top of same db
15:41:04 <ttx> i.e. when someone replaces your system, it migrates data to new db. It doesn't rebuild on top of same db
15:41:17 <krotscheck> #startvote Should we remove Foreign Keys and keep all relationship defenitions in the ORM? Yes, No
15:41:18 <openstack> Begin voting on: Should we remove Foreign Keys and keep all relationship defenitions in the ORM? Valid vote options are Yes, No.
15:41:19 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
15:41:31 <jeblair> #vote Yes
15:41:31 <krotscheck> #vote No
15:41:41 <ttx> to be fair, the main advocate for FKs is not present
15:41:52 <krotscheck> I think we can assume he’s voting no.
15:41:56 <ttx> #vote Yes
15:41:57 <krotscheck> So we can adjust the vote.
15:42:02 <NikitaKonovalov> we need a 'don't know' option
15:42:03 <ttx> krotscheck: that's fair
15:42:17 <ttx> and that mordred votes Yes, I guess
15:42:22 <ruhe> i abstain
15:42:25 <krotscheck> mordred: ^^ vote
15:42:36 <jeblair> krotscheck: mordred said he had to leave
15:42:38 <krotscheck> kk
15:42:43 <ttx> yes he dropped off
15:42:44 <krotscheck> #endvote
15:42:45 <openstack> Voted on "Should we remove Foreign Keys and keep all relationship defenitions in the ORM?" Results are
15:42:46 <openstack> Yes (2): ttx, jeblair
15:42:47 <openstack> No (1): krotscheck
15:43:04 <krotscheck> Ok, making the assumption that mordred is voting yes, and cody-somerville is voting no, that leaves it with “ORM keys” as the winner
15:43:08 <krotscheck> Any disagreements/
15:43:09 <krotscheck> ?
15:43:23 <krotscheck> kk
15:43:30 <krotscheck> #topic Soft Delete
15:43:33 <ttx> krotscheck: I suspect the discussion will be reborn in the review, but at least that's a decision
15:43:39 <krotscheck> Indeed
15:43:52 <ttx> someone has to care enough to remove them
15:43:54 <jeblair> yeah, i think seeing some of this in practice will help
15:43:57 <krotscheck> The arguments for keeping it are all about data retention for reporting, while the arguments against are performance based.
15:44:00 <krotscheck> jeblair: I agree
15:44:07 <krotscheck> Sorry, soft delete
15:44:16 <krotscheck> Since we don’t know whether we need the performance boost, and the argument for keeping it _requires_ data history, I suggest that we don’t pull the rug out from underneath the opposing argument.
15:44:36 <NikitaKonovalov> I'd suggest we split objects to soft-deletable(stories, comments, ...) and tokens
15:44:47 <krotscheck> NikitaKonovalov: Yes, you’re correct.
15:45:07 <NikitaKonovalov> things like tokens will populate the base pretty quickly, so let's remove them for real
15:45:07 <krotscheck> Security bits are definitely things we want to make dissappear when no longer used.
15:45:24 <ttx> could you elaborate on "data retention for reporting" ?
15:45:29 <jeblair> krotscheck: i think this is going to be moderately hard to change later; i'm not normally in favor of premature optimization, but i don't think this is premature
15:46:08 <jeblair> to be clear, i am opposed to soft-delete for most things (especially comments, tasks, etc)
15:46:08 <krotscheck> ttx: Number of stories closed/deleted over X time.
15:46:18 <jeblair> krotscheck: closed != deleted
15:46:27 <krotscheck> jeblair: To be clear, I’m opposed to delete in most things :)
15:46:35 <krotscheck> (soft or no)
15:46:40 <ttx> I don't think we should be able to delete stories
15:46:48 <jeblair> ttx: i think i am in agreement
15:46:55 <ttx> except in very very corner case
15:47:07 <ttx> we shoudln't be able to delete comments either
15:47:12 <jeblair> ttx: we may need a superuser level exception for abuse/dmca, etc
15:47:15 <ttx> (as in "the general public")
15:47:22 <ttx> jeblair: right
15:47:27 <ttx> that's the very corner case
15:47:39 <ttx> basically the only thing i would be able to softdelete would be projects
15:47:53 <ttx> tasks ? just recreate them
15:47:53 <krotscheck> jeblair: Can you go into more details on how removing soft-delete in the future would be a problem?
15:48:04 <ttx> comments ? just don't allow deletion
15:48:09 <jeblair> ttx: i can probably get behind not being able to delete comments (again, except for superuser)
15:48:36 <ttx> stories is a bit in -between, i would let stories with no tasks fade from view
15:49:14 <fungi> even for admin extroadinary situations, delete is probably actually "hide"
15:49:25 <ttx> fungi: that's soft-delete
15:49:56 <krotscheck> We’ve got 10 minutes and a lot more to go through, does anyone object to going to a vote given the several weeks of discussion we’ve had on this?
15:50:32 <krotscheck> #startvote Should we support soft-delete? Yes, No, Case-by-case
15:50:33 <openstack> Begin voting on: Should we support soft-delete? Valid vote options are Yes, No, Case-by-case.
15:50:34 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
15:50:39 <jeblair> in short, i think we should avoid soft-delete because there are only a few things we actually _want_ users to be able to delete, and they are not worth keeping around in the db
15:50:42 <ttx> I think there are plenty of things we shouldn't be able to delete, and plenty of things where deletion should be final. Not so sure there is a large need/space for soft-deleted stuff
15:51:06 <krotscheck> Hrm.
15:51:17 <krotscheck> Ok, so feels to me like voting doesn’t give us a decent enough choice
15:51:20 <krotscheck> #endvote
15:51:21 <openstack> Voted on "Should we support soft-delete?" Results are
15:51:33 <jeblair> krotscheck: i'm not sure about those options -- i basically feel it should be case-by-case, but we should lean towards not using it.
15:51:34 <ttx> could we have one example of stuff you would like to be able to soft-delete ?
15:52:03 <krotscheck> ttx: I could probably come up with use cases for all records. Users, for instance.
15:52:13 <ttx> we should have 3 buckets (non-deleteable, hard-delete, soft-delete) and put various objects into them
15:52:13 <krotscheck> Though in practice users are active/inactive
15:52:24 <ttx> if a bucket is near empty it might make sense to stop supporting that case
15:52:37 <krotscheck> Alright, let’s try a quick straw poll on each current record type.
15:52:42 <jeblair> krotscheck: agreed, i don't think we'd want to delete users, just make them unable to log in
15:52:44 <krotscheck> Users: Soft delete or hard?
15:52:50 <krotscheck> Wait
15:52:55 <jeblair> krotscheck: users -> no delete
15:53:03 <krotscheck> Users: soft delete, hard delete, or other state ( banned/blocked/active)
15:53:09 <krotscheck> I’m for ‘other state'
15:53:16 <ttx> 'other state'
15:53:16 <jeblair> krotscheck: users -> other state
15:53:22 <krotscheck> Projects?
15:53:44 <jeblair> i'm having trouble with this one
15:53:45 <ttx> I think that would be other state too
15:53:49 <krotscheck> (This one I’m worried about because of cascading references.
15:53:55 <ttx> a project existed at some point and got shelved
15:54:00 <krotscheck> (What if we have 10000 tasks assigned to a project?)
15:54:01 <ttx> we need to keep cascading refs
15:54:10 <ttx> so I wouldn't delete it
15:54:18 <ttx> I would mark it obsolete or something
15:54:21 <krotscheck> Feels like ‘other state'
15:54:23 <NikitaKonovalov> projects -> no delete from me
15:54:25 <ttx> yeah
15:54:31 <jeblair> so the difference between soft delete and other state here...
15:54:38 <jeblair> is whether random users would still be able to access it?
15:54:50 <krotscheck> Is that the other state actually has a specified UI purpose, and makes a record discoverable, rather than creating a zombie in the database.
15:54:58 <jeblair> soft delete == only admin can recover it, other state == maybe users can find it if they look hard?
15:55:02 <ttx> jeblair: imho it's different because it's still accessible by users
15:55:14 <ttx> right, if thye look hard enough.
15:55:16 <krotscheck> jeblair: Right - A deprecated project is still available and accessible.
15:55:24 <krotscheck> Though perhaps a banned user...?
15:55:33 <jeblair> okay, then i think our use cases would tend toward 'other state' for projects
15:55:41 <krotscheck> I don’t think we want to get into the legal quandary of publicly shaming someone
15:55:45 <ttx> krotscheck: 'other state' is like a specific soft-delete
15:55:51 <krotscheck> Righto
15:55:56 <krotscheck> Tasks?
15:56:01 <ttx> (a column in the db)
15:56:05 <jeblair> tasks -> hard delete
15:56:06 <krotscheck> I saw yw just delete them.
15:56:09 <ttx> tasks: hard delete
15:56:15 <krotscheck> Ok. Stories?
15:56:20 <NikitaKonovalov> hard delete  for tasks
15:56:20 <krotscheck> (Stories without tasks?
15:56:37 <ttx> Stories is a bit harder. I would keep them around as empty or completed
15:56:48 <ttx> don't let end users delete them
15:56:51 <jeblair> stories -> no delete (admin can hard delete)
15:56:55 <ttx> same for comments
15:57:13 <krotscheck> I hear an awful lot of consensus here.
15:57:13 <ttx> fwiw in LP you can't delete a bug
15:57:18 <NikitaKonovalov> ttx: that brings us to the field of "who can do what"
15:57:29 <jeblair> comments -> no delete (admin can hard delete)
15:57:30 <ttx> NikitaKonovalov: we should never delete a story
15:57:39 <ttx> NikitaKonovalov: but there will be corner cases. Like DMCA notices
15:57:54 <ttx> asking you to take down something
15:57:56 <krotscheck> Ok, so we’re out of time.
15:58:09 <krotscheck> I’m sorry that we didn’t get to ttx’ agenda items, we’ll move those to the top for next week
15:58:13 <ttx> krotscheck: in summary I think we don't need universal soft-delete
15:58:25 <krotscheck> #topic Open Discussion and Summary
15:58:26 <ttx> krotscheck: we need specific state columns for users
15:58:32 <ttx> a,d projects
15:58:34 <krotscheck> Alright, so current actions are: ttx to get a story in about getting our migrations cleaned up for MySQL, and probably another one to fix our documentation.
15:58:35 <ttx> and*
15:58:38 <krotscheck> krotscheck will grab clarkb and mordred to talk about search options
15:58:40 <jeblair> #link https://storyboard.openstack.org/#!/story/60
15:58:43 <krotscheck> We’re getting rid of soft delete in favor of actual use states for each records.
15:58:49 <krotscheck> Tasks are hard delete, stories are not (though stories without tasks shouldn’t be surfaced, etc)
15:58:56 <jeblair> submitted story about changing task labels ^
15:58:57 <krotscheck> Projects are other state, users are other state.
15:59:03 <ttx> #action ttx to create a story  about getting our migrations cleaned up for MySQL
15:59:05 <krotscheck> Ah, thanks for reminding me jeblair
15:59:12 <krotscheck> jeblair: I’ll put that first on my list
15:59:25 <krotscheck> ANything else I forgot?
15:59:51 <krotscheck> #endmeeting storyboard