19:13:47 <SotK> #startmeeting storyboard
19:13:48 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:13:51 <openstack> The meeting name has been set to 'storyboard'
19:13:54 <fungi> the suspense was unbearable! ;)
19:14:06 <SotK> haha
19:14:12 <SotK> hopefully its worth the wait :D
19:14:32 <SotK> #link https://wiki.openstack.org/wiki/Meetings/StoryBoard Agenda
19:14:44 <SotK> #topic Announcements
19:14:55 <SotK> I don't have anything to announce, anyone else?
19:15:16 <fungi> nothin
19:15:42 <mkarray> I'm good
19:15:47 <diablo_rojo> No announcements
19:16:03 <SotK> #topic Migration Updates
19:16:25 <SotK> anything?
19:16:43 <fungi> karbor has expressed an interest in moving from lanchpad to storyboard
19:16:53 <fungi> waiting to hear back from them on the change review
19:16:54 <diablo_rojo> Looks like Karbor is migrating on their own accord
19:16:58 <diablo_rojo> There a patch right fungi ?
19:17:02 <SotK> nice
19:17:24 <fungi> #link https://review.openstack.org/636574 Update karbor to use storyboard
19:17:29 <fungi> yep, that one
19:18:12 <diablo_rojo> Cinder also had a new lib that they were creating and were going to set up in storyboard
19:18:35 <diablo_rojo> 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 <fungi> they had second thoughts at the last moment (i didn't follow the discussion in their meeting)
19:18:55 <fungi> or rather slightly after the last moment
19:19:11 <fungi> i'm working out the db queries now to remove their unused project and project group and the associated mapping
19:19:24 <SotK> yeah, they seemed to be concerned about ending up half in one tool and half in the other
19:19:36 <fungi> if so, that's a reasonable concern
19:19:41 <SotK> yep
19:19:55 <fungi> most project teams migrate all their projects at once
19:21:03 <diablo_rojo> We could always migrate the rest of their stuff right now too ;)
19:22:05 <SotK> 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 <SotK> any other updates?
19:23:50 <fungi> 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 <fungi> gotta delete from project_group_mapping first because of foreign key constraints, it appears
19:24:30 <fungi> and no, i don't have any other migration updates at the moment
19:24:36 <SotK> oh, I forgot about that table
19:24:57 <SotK> #topic Story Attachments
19:25:17 <diablo_rojo> Well thats sad that they are pushing it to Train. They had previously said Stein.,
19:25:28 <SotK> #link https://review.openstack.org/#/q/status:open+topic:story-attachments
19:26:23 <fungi> looks like diablo_rojo has reviewed about half of them. making me look bad! ;)
19:26:28 <SotK> diablo_rojo: it is, but hopefully it helps them feel more prepared
19:26:38 <SotK> indeed, thanks for the reviews so far :D
19:26:41 <fungi> i'll try to go over those at least so we can get some of it merged quickly
19:26:55 <SotK> thanks
19:27:11 <fungi> for 3-week-long definitions of "quickly" i guess :/
19:27:25 <diablo_rojo> Ha ha ha
19:27:30 <diablo_rojo> yeah I will finish reviewing those this week
19:27:50 <SotK> has anyone given thought to how to go about actually using it in production?
19:27:56 <SotK> as in, around storage providers and such?
19:28:05 <SotK> s/providers/donors/
19:28:15 <fungi> i need to have those conversations still
19:28:46 <fungi> clarkb: ^ when you're not fishing, that's something we should probably bring up with the rest of the infra team
19:28:57 <diablo_rojo> We should get that on the infra agenda next week
19:29:07 <fungi> or talk through it sooner
19:29:12 <fungi> that's 6 days away
19:29:39 <fungi> #action fungi find a home for storing storyboard.openstack.org's attachments
19:30:07 <SotK> yeah, the sooner the better as far as I'm concerned :)
19:30:54 <fungi> 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 <SotK> 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 <SotK> hopefully I'll get that done or started before the next meeting
19:31:49 <SotK> can't promise anything though
19:32:19 <SotK> but I don't want to have to field complaints about red error messages on every story :D
19:32:25 <fungi> ahh, yeah, got a pointer to where the error is raised?
19:33:32 <diablo_rojo> Yeah okay. Hold off on webclient patches then
19:34:37 <SotK> 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 <SotK> 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 <fungi> 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 <fungi> let the webclient always request attachments and make it a successful no-op for the api
19:36:14 <SotK> 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 <fungi> (brainstorming)
19:37:05 <SotK> that works for the retrieval side, but all the uploading UI will also be visible but non-functional
19:37:15 <fungi> ahh, right-o
19:37:33 <fungi> so maybe we do need a webclient config option to toggle support
19:37:52 <SotK> yeah, that's what we've done in the past
19:38:01 <SotK> (for editable comments for example)
19:38:31 <fungi> sure
19:38:32 <SotK> 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 <fungi> yeah, a means of exposing configuration info from the api would be better design in the end, completely agree
19:39:52 <SotK> anything else on attachments?
19:40:07 <fungi> some boolean methods like enabled_comment_editing, enabled_story_attachments, and so on
19:40:34 <fungi> i don't have any questions, nope. just need to get rolling on reviewing and discussing storage
19:41:15 <diablo_rojo> Nothing from me
19:41:16 <SotK> indeed, or even making better use of the existing /v1/system_info endpoint
19:41:19 <SotK> #topic Moving database closer to the site
19:41:28 <SotK> this is done now I think, thanks fungi!
19:41:39 <fungi> you're most welcome
19:42:11 <fungi> as also seen with storyboard-dev, we do experience rather heavy database query activity around loading boards/worklists
19:42:45 <fungi> 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 <SotK> yep, hopefully we can start making some good improvements
19:43:16 <fungi> i just need to wrangle some help from some of our more relational-database-savvy contributors
19:44:00 <fungi> should take advantage of the fact that we have former mysql developers on hand ;)
19:44:19 <fungi> (several)
19:44:40 <SotK> heh, yes
19:45:20 <SotK> #topic Outreachy Intern
19:45:22 <fungi> #action fungi find out if some of our mysqlish folks have query profiling recommendations
19:45:32 <diablo_rojo> Call for proposals is open
19:45:38 <SotK> #link https://etherpad.openstack.org/p/sb-train-outreachy-planning
19:45:54 <diablo_rojo> I was thinking optimizing database queries.
19:45:58 <diablo_rojo> But am open to other ideas\
19:46:33 <fungi> it's a reasonable one to add there if you think that's not too much for an outreachy timeframe
19:47:37 <diablo_rojo> I think if its broken down into small fixes at a time its doable
19:47:47 <diablo_rojo> Maybe not quite as fun as working on an entire feature
19:47:48 <diablo_rojo> ?
19:47:48 <SotK> 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 <diablo_rojo> Yeah thats fair.
19:48:11 <diablo_rojo> I definitely am not the most qualified
19:48:54 <SotK> if entire features are deemed more fun, maybe looking at implementing an "official" way of handling duplicates would be nice
19:49:25 <SotK> 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 <fungi> dare i say, overhauling the continuous testing may fit?
19:50:03 <diablo_rojo> We should decide on one thing. Maaaaaybe two.
19:50:26 <diablo_rojo> The application process was a pain last time
19:50:43 <fungi> 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 <diablo_rojo> Either of those sound good too if we think we can get other people to do the db query optimizations
19:51:13 <diablo_rojo> Yeah thats true
19:51:48 <fungi> 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 <SotK> 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 <fungi> 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 <mkarray> Do we currently have the ability to export a list into a CSV through the GUI?
19:53:07 <fungi> that i'll agree with. qa/test work rarely looks glamorous on paper
19:54:01 <SotK> 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 <fungi> 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 <fungi> 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 <mkarray> Sounds good
19:55:38 <diablo_rojo> I think we put the test one up last time, but it didn't get chosen
19:55:46 <fungi> since the idea with outreachy is that there is an intern being paid to complete whatever assignment(s) we choose
19:55:47 <diablo_rojo> We can try again.
19:56:05 <fungi> no, i agree with SotK it's probably unlikely to garner much interest
19:56:30 <diablo_rojo> So either duplicates or query optimization?
19:56:51 <fungi> 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 <mkarray> As an intern myself the query optimization task seems pretty cool
19:57:29 <fungi> 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 <diablo_rojo> 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 <SotK> 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 <fungi> we're running out of time on our meeting slot, btw
19:59:28 <SotK> indeed, lets finish over in #storyboard :)
19:59:35 <fungi> thanks SotK!
19:59:39 <SotK> #endmeeting