Monday, 2014-04-07

*** wchrisj has joined #openstack-meeting-300:20
*** eguz has quit IRC00:28
*** yamahata has joined #openstack-meeting-300:36
*** eghobo has joined #openstack-meeting-300:39
*** eghobo has quit IRC00:39
*** alexpilotti has quit IRC00:45
*** wchrisj has quit IRC00:50
*** yamahata has quit IRC01:45
*** xuhanp has joined #openstack-meeting-302:06
*** wchrisj has joined #openstack-meeting-302:07
*** wchrisj has quit IRC02:21
*** coolsvap has joined #openstack-meeting-302:56
*** eghobo has joined #openstack-meeting-303:15
*** xuhanp has quit IRC03:22
*** banix has joined #openstack-meeting-303:27
*** yamahata has joined #openstack-meeting-303:30
*** eghobo has quit IRC03:49
*** eghobo has joined #openstack-meeting-303:49
*** banix has quit IRC04:08
*** eghobo has quit IRC04:38
*** eghobo has joined #openstack-meeting-304:39
*** eguz has joined #openstack-meeting-304:50
*** eghobo has quit IRC04:50
*** lpetrut has joined #openstack-meeting-304:56
*** saju_m has joined #openstack-meeting-305:13
*** xuhanp has joined #openstack-meeting-305:21
*** wendar_ has joined #openstack-meeting-305:29
*** timello has quit IRC05:29
*** ryanpetrello has quit IRC05:29
*** lifeless has quit IRC05:30
*** wendar has quit IRC05:30
*** lifeless has joined #openstack-meeting-305:31
*** ryanpetrello has joined #openstack-meeting-305:32
*** timello has joined #openstack-meeting-305:33
*** marios has quit IRC05:56
*** jtomasek has joined #openstack-meeting-306:05
*** mrunge has joined #openstack-meeting-306:26
*** xuhanp has quit IRC06:30
*** lpetrut has quit IRC06:32
*** saju_m has quit IRC06:41
*** xuhanp has joined #openstack-meeting-306:43
*** saju_m has joined #openstack-meeting-306:55
*** xuhanp has quit IRC07:02
*** lpetrut has joined #openstack-meeting-307:04
*** lpetrut has quit IRC07:08
*** lsmola_ has joined #openstack-meeting-307:16
*** eguz has quit IRC07:22
*** jcoufal has joined #openstack-meeting-307:25
*** nacim has joined #openstack-meeting-308:00
*** MaxV has joined #openstack-meeting-308:03
*** safchain has joined #openstack-meeting-308:11
*** lpetrut has joined #openstack-meeting-308:28
*** MaxV has quit IRC08:36
*** MaxV has joined #openstack-meeting-308:38
*** lpetrut_ has joined #openstack-meeting-308:52
*** lpetrut has quit IRC08:52
*** saju_m has quit IRC09:27
*** alexpilotti has joined #openstack-meeting-309:40
*** lpetrut_ has quit IRC09:48
*** niksud has quit IRC10:03
*** lpetrut has joined #openstack-meeting-310:03
*** lpetrut_ has joined #openstack-meeting-310:13
*** lpetrut has quit IRC10:16
*** coolsvap has quit IRC10:27
*** saju_m has joined #openstack-meeting-310:32
*** MaxV has quit IRC10:41
*** saju_m has quit IRC10:49
*** MaxV has joined #openstack-meeting-310:49
*** alexpilotti has quit IRC11:16
*** mwagner_lap has quit IRC11:23
*** saju_m has joined #openstack-meeting-311:24
*** ycombinator has quit IRC11:42
*** glenc_ has joined #openstack-meeting-311:43
*** glenc has quit IRC11:43
*** annegentle has quit IRC11:43
*** mwagner_lap has joined #openstack-meeting-312:10
*** yamahata has quit IRC12:20
*** zigo has quit IRC12:26
*** alexpilotti has joined #openstack-meeting-312:39
*** alexpilotti has quit IRC12:40
*** alexpilotti has joined #openstack-meeting-312:53
*** alexpilotti has quit IRC12:58
*** lblanchard has joined #openstack-meeting-313:02
*** MaxV has quit IRC13:03
*** MaxV has joined #openstack-meeting-313:06
*** rustlebee is now known as russellb13:08
*** mfer has joined #openstack-meeting-313:10
*** alexpilotti has joined #openstack-meeting-313:11
*** lblanchard has quit IRC13:26
*** lpetrut_ has quit IRC13:29
*** lblanchard has joined #openstack-meeting-313:35
*** jnoller has joined #openstack-meeting-313:37
*** jnoller has joined #openstack-meeting-313:38
*** jnoller has joined #openstack-meeting-313:39
*** damnsmith is now known as dansmith13:39
*** jnoller has joined #openstack-meeting-313:39
*** jnoller has joined #openstack-meeting-313:41
*** jnoller has joined #openstack-meeting-313:41
*** jnoller has joined #openstack-meeting-313:42
*** overlayer has joined #openstack-meeting-313:42
*** jnoller has joined #openstack-meeting-313:42
*** banix has joined #openstack-meeting-313:44
*** jnoller has joined #openstack-meeting-313:44
*** jnoller has joined #openstack-meeting-313:45
*** jnoller has quit IRC13:45
*** jnoller has joined #openstack-meeting-313:45
*** yamahata has joined #openstack-meeting-313:45
*** jnoller has joined #openstack-meeting-313:46
*** peristeri has joined #openstack-meeting-313:46
*** jnoller has joined #openstack-meeting-313:46
*** jnoller has joined #openstack-meeting-313:47
*** jnoller has joined #openstack-meeting-313:47
*** jnoller has joined #openstack-meeting-313:48
*** jnoller has quit IRC13:48
*** jnoller has joined #openstack-meeting-313:48
*** jnoller has joined #openstack-meeting-313:49
*** jnoller has joined #openstack-meeting-313:51
*** jnoller has quit IRC13:51
*** jnoller has joined #openstack-meeting-313:51
*** jnoller has joined #openstack-meeting-313:52
*** jnoller has joined #openstack-meeting-313:53
*** jnoller has joined #openstack-meeting-313:53
*** jnoller has joined #openstack-meeting-313:54
*** jnoller has joined #openstack-meeting-313:54
*** jnoller has joined #openstack-meeting-313:55
*** jnoller has joined #openstack-meeting-313:55
*** jnoller has joined #openstack-meeting-313:56
*** jnoller has joined #openstack-meeting-313:56
*** jnoller has joined #openstack-meeting-313:57
*** jnoller has joined #openstack-meeting-313:57
*** lpetrut has joined #openstack-meeting-314:03
*** alexpilotti has quit IRC14:05
*** alexpilotti has joined #openstack-meeting-314:06
*** lpetrut has quit IRC14:09
*** lpetrut has joined #openstack-meeting-314:18
*** julim has joined #openstack-meeting-314:34
*** MaxV has quit IRC14:47
*** MaxV has joined #openstack-meeting-314:47
*** krotscheck has joined #openstack-meeting-314:47
*** lpetrut has quit IRC14:50
*** saju_m has quit IRC14:50
*** lpetrut has joined #openstack-meeting-314:56
krotscheckOk, who’s here for storyboard?15:00
NikitaKonovalovo/15:00
ruheo/15:01
krotscheck#startmeeting storyboard15:02
openstackMeeting 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
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:02
*** openstack changes topic to " (Meeting topic: storyboard)"15:02
openstackThe meeting name has been set to 'storyboard'15:02
SergeyLukjanovo/15:02
krotscheck#topic MVP Status15:02
*** openstack changes topic to "MVP Status (Meeting topic: storyboard)"15:02
*** mordred has joined #openstack-meeting-315:02
mordredmorning all15:02
krotscheckOk, so what’s outstanding?15:03
*** cody-somerville has joined #openstack-meeting-315:03
krotscheckI did a strawpoll in #storyboard earlier, current consensus seems that MVP is complete.15:03
ttxo/15:03
mordredI 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 nodepool15:04
ttxagreed, that's why I adde a MVP 1.01 topic for end of meeting :)15:04
krotscheckGot it, so MVP is done.15:04
mordredas a first step15:04
*** yamahata has quit IRC15:04
* krotscheck pops the champagne15:04
krotscheck#topic easier access to logs15:04
*** openstack changes topic to "easier access to logs (Meeting topic: storyboard)"15:04
*** yamahata has joined #openstack-meeting-315:04
ttxkrotscheck: thanks for keeping us all honest and going forward :)15:04
jeblairthe task statuses aren't what we discussed at the sprint, but i assume that's an easy patch15:04
krotscheckcody-somerville: Is this a zombie topic from last week?15:04
krotscheckjeblair: Yes, that can be done quickly. Submit a story?15:05
cody-somervillezombie topic from last week, yes. sorry.15:05
krotscheckGot it15:05
krotscheck#topic ux labs /resources15:05
*** openstack changes topic to "ux labs /resources (Meeting topic: storyboard)"15:05
krotscheckPersonal question for me: Other than redhat, what UX labs / usability resources do we have available other than “make grumpy engineers use it?15:06
mordredI think "make grumpy engineers use it" is what we have for now15:06
krotscheckOk, that’s from HP. I can occasionally get some feedback from jcoufal, anything from Mirantis?15:06
*** lpetrut has quit IRC15:06
ttxgrumpy engineers are like 80% of our target population anyway15:07
mordredthere'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
krotscheckAlright, new user profile: Grumpy Engineer.15:07
krotscheckmordred: Send me an intro?15:07
mordredkrotscheck: I shall15:07
krotscheckGood15:07
jcoufalyeah, it's piet kruithof15:07
jcoufalhe might help with usability testing15:07
krotscheck#action mordred Send krotscheck intro to piet kruithof15:07
*** david-lyle has joined #openstack-meeting-315:08
ttxwe actually identified two profiles. Linux grumpy engineer and MacOs hipster dev15:08
SergeyLukjanov+ grumpy release manager proflle15:08
krotscheck:-P15:08
krotscheckHipster?15:08
*** lpetrut has joined #openstack-meeting-315:08
ttxthe second profile likes stuff that resembles github15:08
ttxby principle15:08
krotscheckmordred: I think… I don’t know what I think about being called a hipster :)15:08
krotscheckANYWAY15:08
krotscheck#topic design discussion: Search & DB support15:08
*** openstack changes topic to "design discussion: Search & DB support (Meeting topic: storyboard)"15:08
ttxkrotscheck: i was not thinking about you15:09
krotscheckSo, our list views right now fail hard.15:09
*** cjellick has joined #openstack-meeting-315:09
krotscheckAs does any project dropdown.15:09
krotscheckNow, for the time being we can do a cached typeahead, however that’s not going to scale.15:09
ttxkrotscheck: i suggested typin URLs by hand but somehow you didn't like it15:09
krotscheck(cached typeahead: Load all results, filte rthem in browser memory)15:09
krotscheckttx: That’s orthogonal :)15:10
krotscheckttx: That’s more of a “how to find a specific project” issue rather than “find all tasks like X” issue15:10
NikitaKonovalovkrotscheck: but if the query fails on the server side, how filtering would help inside a browser?15:10
ttxkrotscheck: list views fail ? or the project list view fails ?15:11
krotscheckNikitaKonovalov: 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
mordredkrotscheck: so - we probably want some amount of both thing, right?15:11
krotscheckmordred: Yes.15:11
ttxkrotscheck: I think users shall be able to subscribe to project (and/or project groups) and get them in a default view15:11
mordredttx: 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 neer15:12
ttxthey should almost never search for them15:12
krotscheckttx: True. Difficult to do if you can’t find what you’re looking for in the first place.15:12
ttxkrotscheck: it's difficult but not impossible. And with subscription it's a one-time pain15:13
krotscheckSo the actual question I have is this: SQLAlchemy does _not_ have a good fulltext abstraction.15:13
krotscheckThat’s more or less requred for search15:13
ttx(agree it can use improvement)15:13
krotscheck(rather than browse. Browse is well understood)15:13
* ttx ttx uses CTRL-F in project list window15:13
krotscheckShould 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
krotscheckThoughts?15:14
NikitaKonovalovwell, mysql whould be fine for searching in 'name' fields15:14
NikitaKonovalovwe may even let it fetch all the data (projects) and then filter in db_api15:15
jeblairmordred: i think there are other full-text options for mysql, yeah?15:15
krotscheckNikitaKonovalov: Yes. What about description fields?15:15
mordreddoor number 315:15
*** nacim has quit IRC15:15
krotscheckOr ‘name’ and ‘description’ fields.15:15
jeblairi'm pretty sure we would like to search across all fields, including descriptions and comments15:15
ruhejeblair: there is mysql sphinx15:15
mordredwe should stay with mysql - and we should use sphinxsearch with it15:15
NikitaKonovalovkrotscheck: no differece for those i  guess15:16
jeblairruhe: that's what i was thinking of...15:16
*** cjellick has quit IRC15:16
krotscheckmordred: jeblair: That requires ditching postgres altogether, yes?15:16
*** cjellick has joined #openstack-meeting-315:17
jeblairkrotscheck: i believe so.  i don't have a problem with that.15:17
*** alexpilotti has quit IRC15:17
krotscheckAlrightey, let’s vote on it.15:17
jeblairfungi: you've poked at our elasticsearch cluster a bit more than i have...15:18
* krotscheck assumes that he can figure out the vote syntax.15:18
ruhepostgres is always several steps behind. most OpenStack projects don't have indexes configured for it15:18
jeblairfungi: my thoughts are that the infrastructure and maintenance burden is too big for a problem like this15:18
krotscheck#vote Deprecate all secondary database support in favor of one.15:18
fungiyeah, i think the search limitations we have are imposed by us to aboid dos'ing the cluster currently15:18
mordredI'm not sure whether sphinx can work with postgres - but I have to be hoenst that I do not care about our postgres support personally15:18
jeblairperhaps that's just because i've only seen it used in a frighteningly busy system15:18
krotscheck#startvote Deprecate all secondary database support in favor of one.15:19
openstackUnable to parse vote topic and options.15:19
krotscheckDammit15:19
krotscheckSomeone else do that15:19
jeblairkrotscheck: http://ci.openstack.org/irc.html#voting15:19
ttxkrotscheck: only the meeting chair can :)15:19
fungithe 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 it15:19
krotscheckOh15:19
*** alexpilotti has joined #openstack-meeting-315:19
krotscheck: #startvote Deprecate all secondary database support in favor of only one? Yes, No, Maybe15:19
jeblairfungi: right, but are we going to need to run another 'cluster'? what's the minimal cluster look like?15:20
jeblairkrotscheck: once more without the ': '15:20
fungioh, 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 initially15:21
krotscheckjeblair: There isn’t one....15:21
fungisince that's what clarkb set up originally before we grew it to cope with the volume we have15:21
krotscheck#startvote Deprecate all secondary database support in favor of only one?15:21
openstackBegin voting on: Deprecate all secondary database support in favor of only one? Valid vote options are Yes, No.15:21
openstackVote using '#vote OPTION'. Only your last vote counts.15:21
ruhe#vote Yes15:22
NikitaKonovalov#vote Yes15:22
fungii 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 further15:22
krotscheck#vote Yes15:22
jeblair#vote Yes15:22
ttx#vote Abstain15:22
ttx:)15:22
krotscheck#endvote15:22
openstackVoted on "Deprecate all secondary database support in favor of only one?" Results are15:22
krotscheckOk, so next issue: Which database to pick.15:22
ruheit might be reasonable to conduct a study of mysql+sphinx+sqlalchemy before the decision is made to build on top of these technologies15:22
jeblairfungi: i'd rather not; i think storyboard search uptime is far more important that test log uptime15:23
mordred#vote Yes15:23
jeblairfungi: so we wouldn't be able to take it offline for, say, a day in order to rebuild indexes anymore15:23
mordredsorry (got distracted)15:23
krotscheckOk, ruhe: Do you  have time to do this study?15:23
fungijeblair: 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:23
fungimight even be able to just stick the elasticsearch and storyboard instances on the same vm for better performance15:24
krotscheck#startvote Pick a database? mysql, postgres, sqlite15:24
openstackBegin voting on: Pick a database? Valid vote options are mysql, postgres, sqlite.15:24
openstackVote using '#vote OPTION'. Only your last vote counts.15:24
fungii'd want to pass this by clarkb later though since he very well may be able to point out that i'm being an idiot15:24
NikitaKonovalovis it hard to run elastic search loaclly?15:24
ttx#vote mysql15:24
jeblairfungi, krotscheck: i agree, we should ask clarkb to weigh in on this; he's our elasticsearch expert15:25
ruhekrotscheck: 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
NikitaKonovalov#vote mysql15:25
jeblair#vote mysql15:25
ruhe#vote mysql15:25
mordred#vote mysql15:25
krotscheck#endvote15:25
openstackVoted on "Pick a database?" Results are15:25
openstackmysql (5): mordred, NikitaKonovalov, ttx, jeblair, ruhe15:25
krotscheckOk, we’re using msyql, end of story15:25
ttxnow we could dramatically simplify our initial migrations15:26
krotscheckLast 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
krotscheckttx just volunteered to fix our migrations15:26
ruhettx: you mean squash all the existing migrations into a single one?15:26
krotscheckOr is there a third option? :)15:26
ttxruhe: rather than keep the postgresql compat cruft yes15:26
ttxbut then I don'ty know how the prod system would like that15:27
krotscheck#action ttx File a story in storyboard to get the postgres cruft out of our database migrations.15:27
jeblairkrotscheck: i think we should get clarkb and mordred, at least, into a conversation, as ES and sphinx experts respectively15:28
ruhettx: they manage it somehow in giant projects like Nova. It should be a piece of cake in StoryBoard :)15:28
* mordred will ping the guys at sphinxsearch and see if they're interested in helping15:28
krotscheckjeblair: You got it. I’ll grab clark and mordred offline and get a better sense of the benefits/tradeoffs.15:28
jeblairmordred: what does that look like on the sysadmin side?15:28
* ttx is multitasking on 3 cores15:28
jeblairkrotscheck: feel free to do it online.  :)15:29
krotscheck#action krotscheck extract mordred and clarkb’s brain segments on elastic search vis-a-vis sphinx.15:29
krotscheckjeblair: Yeah, but that discussion does not have to happen in this meeting :)15:29
jeblairkrotscheck: yep15:29
krotscheck#topic FK or no FK15:30
*** openstack changes topic to "FK or no FK (Meeting topic: storyboard)"15:30
krotscheckI’m bringing both FK and soft delete back up because I felt the discussion 2 weeks ago was prematurely cut off.15:30
krotscheckWith 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
krotscheckThe 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
krotscheckThrowing 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
*** alexpilotti has quit IRC15:30
krotscheckIf foreign keys become a performance constraint, we can revisit and explore this. Until then I propose that we stick with FK’s.15:30
krotscheckBasically: I think referential integrity is a better benefit than code duplication, because we really should be testing the latter.15:31
jeblairkrotscheck: i feel you may have misapprehended my arguments for dropping FK support15:31
krotscheckjeblair: Oh?15:31
*** alexpilotti has joined #openstack-meeting-315:32
jeblairkrotscheck: i'm primarily interested in dropping it because of the complications introduced by defining the same relationships in multiple places15:33
jeblairthe multiple places being both the orm and the database15:33
jeblairthat is error prone and one can end up with problems resulting from mismatches there, as we've already seen15:34
krotscheckjeblair: The only place where I’ve seen that become an issue is in cross-database situations, are there others?15:34
krotscheckMy hypothesis is that now that we’re on mysql only, most of those issues won’t crop up anymore.15:34
NikitaKonovalovbtw, will it be valid if we set up constraints in migrations, but do not tell sqlalchemy anything?15:35
jeblairkrotscheck: i'm pretty sure it's come up in earlier problems with storyboard's migrations; also, i believe the current unit tests have FK errors15:35
jeblairNikitaKonovalov: i think that's backwards -- sqlalchemy needs to know the constraints, the database does not15:35
jeblairit's redundant to have two different systems checking those constraints15:35
mordredNikitaKonovalov: I want to do the opposite15:35
mordredyeah - what NikitaKonovalov said15:35
krotscheckjeblair: It sounds like we can test for the kinds of errors you’re concerned about, is that correct?15:35
mordredthe important part is the the orm layer know about them15:36
mordredthat' VERY important15:36
*** wchrisj has joined #openstack-meeting-315:36
krotscheckDoes SQLAlchemy keep an in-memory running cache of queried records, or does it handle things on a per-request basis?15:36
NikitaKonovalovkrotscheck: it handles sessions15:37
jeblairkrotscheck: during a session, records are cached; in our case a session is probably a single http request15:37
* mordred has to drop off15:38
krotscheckGot 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:38
jeblairkrotscheck: the orm is responsible for that too15:39
ttxdon't FKs make migrations slightly more complex/costly, which increase the downtime windows ?15:39
krotscheckttx: Again, i think it’s testable.15:39
ttxI think the only valid argument FOR FKs is that the data will outlive the app. Which frankly, I doubt.15:40
krotscheckOk, any more arguments for/against? I’d like to move to vote.15:40
ttxI've seen data migrated away from systems well before said systems are replaced by some other on top of same db15:40
ttxi.e. when someone replaces your system, it migrates data to new db. It doesn't rebuild on top of same db15:41
krotscheck#startvote Should we remove Foreign Keys and keep all relationship defenitions in the ORM? Yes, No15:41
openstackBegin voting on: Should we remove Foreign Keys and keep all relationship defenitions in the ORM? Valid vote options are Yes, No.15:41
openstackVote using '#vote OPTION'. Only your last vote counts.15:41
jeblair#vote Yes15:41
krotscheck#vote No15:41
ttxto be fair, the main advocate for FKs is not present15:41
krotscheckI think we can assume he’s voting no.15:41
ttx#vote Yes15:41
krotscheckSo we can adjust the vote.15:41
NikitaKonovalovwe need a 'don't know' option15:42
ttxkrotscheck: that's fair15:42
*** alexpilotti has quit IRC15:42
ttxand that mordred votes Yes, I guess15:42
ruhei abstain15:42
krotscheckmordred: ^^ vote15:42
jeblairkrotscheck: mordred said he had to leave15:42
krotscheckkk15:42
ttxyes he dropped off15:42
krotscheck#endvote15:42
openstackVoted on "Should we remove Foreign Keys and keep all relationship defenitions in the ORM?" Results are15:42
openstackYes (2): ttx, jeblair15:42
openstackNo (1): krotscheck15:42
*** alexpilotti has joined #openstack-meeting-315:43
krotscheckOk, making the assumption that mordred is voting yes, and cody-somerville is voting no, that leaves it with “ORM keys” as the winner15:43
krotscheckAny disagreements/15:43
*** alexpilotti has quit IRC15:43
krotscheck?15:43
krotscheckkk15:43
krotscheck#topic Soft Delete15:43
*** openstack changes topic to "Soft Delete (Meeting topic: storyboard)"15:43
ttxkrotscheck: I suspect the discussion will be reborn in the review, but at least that's a decision15:43
krotscheckIndeed15:43
ttxsomeone has to care enough to remove them15:43
jeblairyeah, i think seeing some of this in practice will help15:43
krotscheckThe arguments for keeping it are all about data retention for reporting, while the arguments against are performance based.15:43
krotscheckjeblair: I agree15:44
krotscheckSorry, soft delete15:44
krotscheckSince 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
NikitaKonovalovI'd suggest we split objects to soft-deletable(stories, comments, ...) and tokens15:44
krotscheckNikitaKonovalov: Yes, you’re correct.15:44
NikitaKonovalovthings like tokens will populate the base pretty quickly, so let's remove them for real15:45
krotscheckSecurity bits are definitely things we want to make dissappear when no longer used.15:45
ttxcould you elaborate on "data retention for reporting" ?15:45
*** alexpilotti has joined #openstack-meeting-315:45
jeblairkrotscheck: 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 premature15:45
jeblairto be clear, i am opposed to soft-delete for most things (especially comments, tasks, etc)15:46
krotscheckttx: Number of stories closed/deleted over X time.15:46
jeblairkrotscheck: closed != deleted15:46
krotscheckjeblair: To be clear, I’m opposed to delete in most things :)15:46
krotscheck(soft or no)15:46
ttxI don't think we should be able to delete stories15:46
jeblairttx: i think i am in agreement15:46
ttxexcept in very very corner case15:46
ttxwe shoudln't be able to delete comments either15:47
jeblairttx: we may need a superuser level exception for abuse/dmca, etc15:47
ttx(as in "the general public")15:47
ttxjeblair: right15:47
ttxthat's the very corner case15:47
ttxbasically the only thing i would be able to softdelete would be projects15:47
ttxtasks ? just recreate them15:47
krotscheckjeblair: Can you go into more details on how removing soft-delete in the future would be a problem?15:47
ttxcomments ? just don't allow deletion15:48
jeblairttx: i can probably get behind not being able to delete comments (again, except for superuser)15:48
ttxstories is a bit in -between, i would let stories with no tasks fade from view15:48
fungieven for admin extroadinary situations, delete is probably actually "hide"15:49
ttxfungi: that's soft-delete15:49
krotscheckWe’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:49
krotscheck#startvote Should we support soft-delete? Yes, No, Case-by-case15:50
openstackBegin voting on: Should we support soft-delete? Valid vote options are Yes, No, Case-by-case.15:50
openstackVote using '#vote OPTION'. Only your last vote counts.15:50
jeblairin 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 db15:50
ttxI 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 stuff15:50
krotscheckHrm.15:51
krotscheckOk, so feels to me like voting doesn’t give us a decent enough choice15:51
krotscheck#endvote15:51
openstackVoted on "Should we support soft-delete?" Results are15:51
jeblairkrotscheck: 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
ttxcould we have one example of stuff you would like to be able to soft-delete ?15:51
krotscheckttx: I could probably come up with use cases for all records. Users, for instance.15:52
ttxwe should have 3 buckets (non-deleteable, hard-delete, soft-delete) and put various objects into them15:52
krotscheckThough in practice users are active/inactive15:52
ttxif a bucket is near empty it might make sense to stop supporting that case15:52
krotscheckAlright, let’s try a quick straw poll on each current record type.15:52
jeblairkrotscheck: agreed, i don't think we'd want to delete users, just make them unable to log in15:52
krotscheckUsers: Soft delete or hard?15:52
krotscheckWait15:52
jeblairkrotscheck: users -> no delete15:52
krotscheckUsers: soft delete, hard delete, or other state ( banned/blocked/active)15:53
krotscheckI’m for ‘other state'15:53
ttx'other state'15:53
jeblairkrotscheck: users -> other state15:53
krotscheckProjects?15:53
jeblairi'm having trouble with this one15:53
ttxI think that would be other state too15:53
krotscheck(This one I’m worried about because of cascading references.15:53
ttxa project existed at some point and got shelved15:53
krotscheck(What if we have 10000 tasks assigned to a project?)15:54
ttxwe need to keep cascading refs15:54
ttxso I wouldn't delete it15:54
ttxI would mark it obsolete or something15:54
krotscheckFeels like ‘other state'15:54
NikitaKonovalovprojects -> no delete from me15:54
ttxyeah15:54
*** eghobo has joined #openstack-meeting-315:54
jeblairso the difference between soft delete and other state here...15:54
jeblairis whether random users would still be able to access it?15:54
krotscheckIs 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
jeblairsoft delete == only admin can recover it, other state == maybe users can find it if they look hard?15:54
ttxjeblair: imho it's different because it's still accessible by users15:55
ttxright, if thye look hard enough.15:55
krotscheckjeblair: Right - A deprecated project is still available and accessible.15:55
krotscheckThough perhaps a banned user...?15:55
jeblairokay, then i think our use cases would tend toward 'other state' for projects15:55
krotscheckI don’t think we want to get into the legal quandary of publicly shaming someone15:55
ttxkrotscheck: 'other state' is like a specific soft-delete15:55
krotscheckRighto15:55
krotscheckTasks?15:55
ttx(a column in the db)15:56
jeblairtasks -> hard delete15:56
krotscheckI saw yw just delete them.15:56
ttxtasks: hard delete15:56
krotscheckOk. Stories?15:56
NikitaKonovalovhard delete  for tasks15:56
krotscheck(Stories without tasks?15:56
ttxStories is a bit harder. I would keep them around as empty or completed15:56
ttxdon't let end users delete them15:56
jeblairstories -> no delete (admin can hard delete)15:56
ttxsame for comments15:56
krotscheckI hear an awful lot of consensus here.15:57
ttxfwiw in LP you can't delete a bug15:57
NikitaKonovalovttx: that brings us to the field of "who can do what"15:57
jeblaircomments -> no delete (admin can hard delete)15:57
ttxNikitaKonovalov: we should never delete a story15:57
ttxNikitaKonovalov: but there will be corner cases. Like DMCA notices15:57
ttxasking you to take down something15:57
krotscheckOk, so we’re out of time.15:57
krotscheckI’m sorry that we didn’t get to ttx’ agenda items, we’ll move those to the top for next week15:58
ttxkrotscheck: in summary I think we don't need universal soft-delete15:58
krotscheck#topic Open Discussion and Summary15:58
*** openstack changes topic to "Open Discussion and Summary (Meeting topic: storyboard)"15:58
ttxkrotscheck: we need specific state columns for users15:58
ttxa,d projects15:58
krotscheckAlright, 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
ttxand*15:58
krotscheckkrotscheck will grab clarkb and mordred to talk about search options15:58
jeblair#link https://storyboard.openstack.org/#!/story/6015:58
krotscheckWe’re getting rid of soft delete in favor of actual use states for each records.15:58
krotscheckTasks are hard delete, stories are not (though stories without tasks shouldn’t be surfaced, etc)15:58
jeblairsubmitted story about changing task labels ^15:58
krotscheckProjects are other state, users are other state.15:58
ttx#action ttx to create a story  about getting our migrations cleaned up for MySQL15:59
krotscheckAh, thanks for reminding me jeblair15:59
krotscheckjeblair: I’ll put that first on my list15:59
krotscheckANything else I forgot?15:59
krotscheck#endmeeting storyboard15:59
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"15:59
ttxkrotscheck: MVP 1.01 items sound like what's blocking me from using sb efficiently to track Sb tasks15:59
openstackMeeting ended Mon Apr  7 15:59:51 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:59
openstackMinutes:        http://eavesdrop.openstack.org/meetings/storyboard/2014/storyboard.2014-04-07-15.02.html15:59
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/storyboard/2014/storyboard.2014-04-07-15.02.txt15:59
openstackLog:            http://eavesdrop.openstack.org/meetings/storyboard/2014/storyboard.2014-04-07-15.02.log.html15:59
krotscheckttx: Yeah, I know.16:00
ttxkrotscheck: if you empty your TODO bucket, feel free to pick stuff in that list :)16:00
*** xazel is now known as enykeev16:00
krotscheckttx: Oh beleive me, I will. That entire list are pain points for me as well.16:00
ttx(if your TODO bucket looks like mine those days, that should be never)16:00
*** banix has quit IRC16:00
krotscheckttx: Storyboard is my todo bucket16:00
krotscheck:)16:01
*** jcoufal has quit IRC16:07
*** saju_m has joined #openstack-meeting-316:12
*** jpomero has joined #openstack-meeting-316:27
*** zigo has joined #openstack-meeting-316:28
*** zigo has quit IRC16:33
*** markmcclain has joined #openstack-meeting-316:33
*** zigo has joined #openstack-meeting-316:34
*** saju_m has quit IRC16:35
*** devlaps has joined #openstack-meeting-316:37
*** zigo has quit IRC16:41
*** MaxV has quit IRC16:45
*** zigo has joined #openstack-meeting-316:46
*** SumitNaiksatam has quit IRC16:55
*** markmcclain has quit IRC16:59
*** markmcclain has joined #openstack-meeting-317:00
*** markmcclain has quit IRC17:00
*** SumitNaiksatam has joined #openstack-meeting-317:08
*** MaxV has joined #openstack-meeting-317:24
*** safchain has quit IRC17:27
*** annegentle_ has joined #openstack-meeting-317:57
*** Sukhdev has joined #openstack-meeting-318:00
*** lpetrut has quit IRC18:06
*** overlayer has quit IRC18:09
*** mwagner_lap has quit IRC18:10
*** glenc_ is now known as glenc18:20
*** ttrifonov is now known as ttrifonov_zZzz18:23
*** lpetrut has joined #openstack-meeting-318:31
*** markmcclain has joined #openstack-meeting-318:39
*** saju_m has joined #openstack-meeting-318:51
*** mwagner_lap has joined #openstack-meeting-319:00
*** jnoller has joined #openstack-meeting-319:05
*** jnoller has joined #openstack-meeting-319:06
*** jnoller has joined #openstack-meeting-319:08
*** mrunge has quit IRC19:08
*** eguz has joined #openstack-meeting-319:09
*** eghobo has quit IRC19:12
*** eghobo has joined #openstack-meeting-319:13
*** eguz has quit IRC19:15
*** jnoller has left #openstack-meeting-319:18
*** markmcclain has quit IRC19:26
*** banix has joined #openstack-meeting-319:39
*** tedchang has joined #openstack-meeting-319:57
*** SumitNaiksatam has quit IRC19:59
*** Sukhdev has quit IRC20:00
*** tedchang has quit IRC20:06
*** russellb_ has joined #openstack-meeting-320:09
*** boris-42 has quit IRC20:10
*** russellb has quit IRC20:10
*** haleyb has quit IRC20:10
*** edhall has quit IRC20:10
*** russellb_ is now known as russellb20:10
*** SumitNaiksatam has joined #openstack-meeting-320:12
*** SumitNaiksatam has quit IRC20:13
*** SumitNaiksatam has joined #openstack-meeting-320:13
*** haleyb has joined #openstack-meeting-320:17
*** edhall has joined #openstack-meeting-320:17
*** markmcclain has joined #openstack-meeting-320:18
*** sarob has joined #openstack-meeting-320:23
*** boris-42 has joined #openstack-meeting-320:28
*** markmcclain has quit IRC20:32
*** markmcclain has joined #openstack-meeting-320:32
*** rand738 has quit IRC20:35
*** rand738 has joined #openstack-meeting-320:36
*** devlaps has left #openstack-meeting-320:41
*** saju_m has quit IRC20:41
*** rand738 has quit IRC20:42
*** rand738 has joined #openstack-meeting-320:44
*** amotoki has joined #openstack-meeting-320:57
*** Sukhdev has joined #openstack-meeting-320:59
*** lpetrut has quit IRC21:01
*** lblanchard has quit IRC21:06
*** peristeri has quit IRC21:12
*** jcoufal has joined #openstack-meeting-321:17
*** mfer has quit IRC21:20
*** MaxV has quit IRC21:22
*** markmcclain has quit IRC22:02
*** lpetrut has joined #openstack-meeting-322:05
*** lenrow has joined #openstack-meeting-322:05
*** markmcclain has joined #openstack-meeting-322:06
*** lpetrut has quit IRC22:16
*** MaxV has joined #openstack-meeting-322:18
*** banix has quit IRC22:33
*** amotoki has quit IRC22:41
*** alexpilotti has quit IRC22:45
*** Sukhdev has quit IRC22:59
*** eguz has joined #openstack-meeting-323:03
*** eghobo has quit IRC23:08
*** Sukhdev has joined #openstack-meeting-323:13
*** david-lyle has quit IRC23:20
*** jcoufal has quit IRC23:22
*** yamahata has quit IRC23:24
*** markmcclain has quit IRC23:35
*** markmcclain has joined #openstack-meeting-323:35
*** markmcclain has quit IRC23:52
*** alexpilotti has joined #openstack-meeting-323:53

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!