19:13:47 #startmeeting storyboard 19:13:48 Meeting started Wed Feb 20 19:13:47 2019 UTC and is due to finish in 60 minutes. The chair is SotK. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:13:49 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:13:51 The meeting name has been set to 'storyboard' 19:13:54 the suspense was unbearable! ;) 19:14:06 haha 19:14:12 hopefully its worth the wait :D 19:14:32 #link https://wiki.openstack.org/wiki/Meetings/StoryBoard Agenda 19:14:44 #topic Announcements 19:14:55 I don't have anything to announce, anyone else? 19:15:16 nothin 19:15:42 I'm good 19:15:47 No announcements 19:16:03 #topic Migration Updates 19:16:25 anything? 19:16:43 karbor has expressed an interest in moving from lanchpad to storyboard 19:16:53 waiting to hear back from them on the change review 19:16:54 Looks like Karbor is migrating on their own accord 19:16:58 There a patch right fungi ? 19:17:02 nice 19:17:24 #link https://review.openstack.org/636574 Update karbor to use storyboard 19:17:29 yep, that one 19:18:12 Cinder also had a new lib that they were creating and were going to set up in storyboard 19:18:35 but I think I saw chatter this morning in their meeting about just wanting to get the patch in and now talking about making it in lp instead 19:18:47 they had second thoughts at the last moment (i didn't follow the discussion in their meeting) 19:18:55 or rather slightly after the last moment 19:19:11 i'm working out the db queries now to remove their unused project and project group and the associated mapping 19:19:24 yeah, they seemed to be concerned about ending up half in one tool and half in the other 19:19:36 if so, that's a reasonable concern 19:19:41 yep 19:19:55 most project teams migrate all their projects at once 19:21:03 We could always migrate the rest of their stuff right now too ;) 19:22:05 I think the outcome of their discussion was to try to migrate during Train after having more discussions about workflows f2f at the PTG 19:23:30 any other updates? 19:23:50 as an update, i've dumped a copy of the db just in case and then deleted the associated records from the projects, project_groups and project_group_mapping tables 19:24:10 gotta delete from project_group_mapping first because of foreign key constraints, it appears 19:24:30 and no, i don't have any other migration updates at the moment 19:24:36 oh, I forgot about that table 19:24:57 #topic Story Attachments 19:25:17 Well thats sad that they are pushing it to Train. They had previously said Stein., 19:25:28 #link https://review.openstack.org/#/q/status:open+topic:story-attachments 19:26:23 looks like diablo_rojo has reviewed about half of them. making me look bad! ;) 19:26:28 diablo_rojo: it is, but hopefully it helps them feel more prepared 19:26:38 indeed, thanks for the reviews so far :D 19:26:41 i'll try to go over those at least so we can get some of it merged quickly 19:26:55 thanks 19:27:11 for 3-week-long definitions of "quickly" i guess :/ 19:27:25 Ha ha ha 19:27:30 yeah I will finish reviewing those this week 19:27:50 has anyone given thought to how to go about actually using it in production? 19:27:56 as in, around storage providers and such? 19:28:05 s/providers/donors/ 19:28:15 i need to have those conversations still 19:28:46 clarkb: ^ when you're not fishing, that's something we should probably bring up with the rest of the infra team 19:28:57 We should get that on the infra agenda next week 19:29:07 or talk through it sooner 19:29:12 that's 6 days away 19:29:39 #action fungi find a home for storing storyboard.openstack.org's attachments 19:30:07 yeah, the sooner the better as far as I'm concerned :) 19:30:54 right, it'll take us some time to set up and figure out how we want to manage it, so getting that discussion going in parallel is warranted 19:31:20 we should probably hold off on merging the webclient patches either until I've stopped the error that happens when attachments are disabled or we are ready to turn them on 19:31:37 hopefully I'll get that done or started before the next meeting 19:31:49 can't promise anything though 19:32:19 but I don't want to have to field complaints about red error messages on every story :D 19:32:25 ahh, yeah, got a pointer to where the error is raised? 19:33:32 Yeah okay. Hold off on webclient patches then 19:34:37 the issue is just that the webclient has no way of checking whether or not the API supports attachments and just always makes a request to get the attachments for a story 19:35:04 with an old backend or a backend with attachments disabled that doesn't work and causes a (harmless) error to be displayed 19:35:41 yeah, maybe the api can just return an empty set for that query rather than an error when attachments aren't configured? 19:36:04 let the webclient always request attachments and make it a successful no-op for the api 19:36:14 you can see it in action in the js preview: http://logs.openstack.org/12/633612/2/check/build-javascript-content/8309dae/npm/html/#!/story/1 19:36:17 (brainstorming) 19:37:05 that works for the retrieval side, but all the uploading UI will also be visible but non-functional 19:37:15 ahh, right-o 19:37:33 so maybe we do need a webclient config option to toggle support 19:37:52 yeah, that's what we've done in the past 19:38:01 (for editable comments for example) 19:38:31 sure 19:38:32 but I'm increasingly feeling like both of these should be things that the webclient finds out from the API its pointed at 19:39:02 yeah, a means of exposing configuration info from the api would be better design in the end, completely agree 19:39:52 anything else on attachments? 19:40:07 some boolean methods like enabled_comment_editing, enabled_story_attachments, and so on 19:40:34 i don't have any questions, nope. just need to get rolling on reviewing and discussing storage 19:41:15 Nothing from me 19:41:16 indeed, or even making better use of the existing /v1/system_info endpoint 19:41:19 #topic Moving database closer to the site 19:41:28 this is done now I think, thanks fungi! 19:41:39 you're most welcome 19:42:11 as also seen with storyboard-dev, we do experience rather heavy database query activity around loading boards/worklists 19:42:45 but this puts us in a better place to start doing some profiling of the production workload there and figuring out our hotspots 19:42:46 * diablo_rojo takes it off agenda so we dont bring it up next week too 19:43:15 yep, hopefully we can start making some good improvements 19:43:16 i just need to wrangle some help from some of our more relational-database-savvy contributors 19:44:00 should take advantage of the fact that we have former mysql developers on hand ;) 19:44:19 (several) 19:44:40 heh, yes 19:45:20 #topic Outreachy Intern 19:45:22 #action fungi find out if some of our mysqlish folks have query profiling recommendations 19:45:32 Call for proposals is open 19:45:38 #link https://etherpad.openstack.org/p/sb-train-outreachy-planning 19:45:54 I was thinking optimizing database queries. 19:45:58 But am open to other ideas\ 19:46:33 it's a reasonable one to add there if you think that's not too much for an outreachy timeframe 19:47:37 I think if its broken down into small fixes at a time its doable 19:47:47 Maybe not quite as fun as working on an entire feature 19:47:48 ? 19:47:48 sounds like an interesting one to me, but it might be dependent on folk with sufficient expertise being around to give advice 19:48:02 Yeah thats fair. 19:48:11 I definitely am not the most qualified 19:48:54 if entire features are deemed more fun, maybe looking at implementing an "official" way of handling duplicates would be nice 19:49:25 or perhaps some of the board-related improvements that were discussed way back in Dublin (I'm not sure if they're written up anywhere) 19:49:30 dare i say, overhauling the continuous testing may fit? 19:50:03 We should decide on one thing. Maaaaaybe two. 19:50:26 The application process was a pain last time 19:50:43 we've got an attempt at fixing the defect with private stories not sending e-mail notifications, blocked on being unable to actually write a working regression test, because the current test framework is rather inscrutible 19:51:03 Either of those sound good too if we think we can get other people to do the db query optimizations 19:51:13 Yeah thats true 19:51:48 just from a personal pain-point perspective... folks reporting security vulnerabilities in private end up having to ping me to let me know they opened them because sb can't notify me 19:52:35 yeah, fixing the tests would be good too but I suspect it won't sound like interesting work on an internship proposal 19:52:38 * SotK could be wrong 19:52:43 fixing that is likely not hard, but being unable to test that we don't break it in the future would be better 19:52:59 Do we currently have the ability to export a list into a CSV through the GUI? 19:53:07 that i'll agree with. qa/test work rarely looks glamorous on paper 19:54:01 mkarray: we don't, but it'd likely be fairly trivial to write a python script to generate one using the api 19:54:25 mkarray: that also sounds useful, but i think we also don't have a shortage of feature requests which have already been prioritized 19:54:55 so it's more about coming up with one of those which would be tractable for (and attractive to) an intern to tackle 19:55:18 Sounds good 19:55:38 I think we put the test one up last time, but it didn't get chosen 19:55:46 since the idea with outreachy is that there is an intern being paid to complete whatever assignment(s) we choose 19:55:47 We can try again. 19:56:05 no, i agree with SotK it's probably unlikely to garner much interest 19:56:30 So either duplicates or query optimization? 19:56:51 er, i should restate, the idea with outreachy is that there is an intern being paid to complete whatever assignment(s) THEY choose from the ones we suggest 19:57:09 As an intern myself the query optimization task seems pretty cool 19:57:29 so we're sort of competing for offering work which will make them want to work on our project rather than another one 19:58:09 I feel like we might be able to write both of them in time, but I will prioritize the query one first? 19:58:17 yeah I think if we're picking two then those two make sense, and if just one then I think I'd lean to the query optimisation 19:59:06 we're running out of time on our meeting slot, btw 19:59:28 indeed, lets finish over in #storyboard :) 19:59:35 thanks SotK! 19:59:39 #endmeeting