19:01:44 #startmeeting storyboard 19:01:45 Meeting started Wed Aug 1 19:01:44 2018 UTC and is due to finish in 60 minutes. The chair is fungi. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:46 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:48 The meeting name has been set to 'storyboard' 19:02:05 #link https://wiki.openstack.org/wiki/Meetings/StoryBoard Meeting Agenda 19:02:37 #link http://eavesdrop.openstack.org/meetings/storyboard/ Logs from past meetings 19:02:55 #topic Announcements 19:03:22 [i notice meetbot seems to have lost the ability to change channel topics... will look into that later] 19:03:41 there's a bullet on the agenda with an announcement for the api sig migration 19:03:49 i think that's probably from the last meeting 19:04:00 but in case it's not, they're using sb now 19:04:10 nice! (I suspect it is too) 19:04:36 granted their project and project-group are getting renamed on friday 19:05:20 they had to start using "wg" instead of "sig" on storyboard.openstack.org waiting for an opportunity to rename their repository on review.openstack.org 19:06:20 we've done project renames in sb before and that's worked fine. this will be the first project-group rename but glancing at the db schema it should just be an update to the name column for the appropriate row in the project_groups table 19:06:39 any other announcements? 19:06:50 I don't have any 19:07:03 #topic Migration Updates 19:07:37 #link https://storyboard.openstack.org/#!/board/45 Launchpad to StoryBoard Migration 19:08:04 diablo_rojo_phon has mostly driven this, and with her travelling i expect it's on hold for the moment 19:08:16 or at least i don't have any updates (no idea if she does) 19:08:49 so we can probably move on with the rest of the agenda 19:09:05 #topic In Progress Work 19:09:26 we have a couple of standing entries here, i suppose 19:10:04 one for the list of needs octavia raised a while back and then the stories tagged as "blocking migration" 19:10:36 also a link to a docs change which i'm going to approve now 19:10:59 thanks :) 19:12:18 i saw fatema_ has been hacking on some changes 19:12:39 (which i haven't had time to review while on vacation for the past couple weeks) 19:13:26 yeah, I also noticed those and will try to find some time to review them soon 19:13:50 I also intend to finally get round to fixing the "get project by name" stuff too 19:14:19 oh, thanks! i had absolutely _no_ luck figuring out what was going wrong with the html escape plumbing that through 19:15:04 i'll get someone to approve your ssh key change (i assume that's preventing you from reproducing and viewing logs locally on sb-dev.o.o) 19:15:05 once https://review.openstack.org/#/c/587971/ makes it onto storyboard-dev I'll have a play around there 19:15:11 snappish 19:15:14 as i suspected! 19:16:29 looks like you have quite a bit up worth reviewing for storyboard-dev 19:16:48 and stephenfin has a couple there as well from last week 19:17:29 those two are actually quite old, it'd be good to get them merged 19:17:40 oh, i see those are from october and you rebased/updated them, right 19:17:44 thanks 19:17:53 i agree 19:18:26 a bunch of my webclient patches need re-ordering and/or more work though 19:18:44 I'm hopeful of having the time and energy to do that in the near future 19:19:01 no worries, take your time 19:19:44 anything else worth covering under in progress work? 19:20:10 not that I know of at the moment 19:20:16 #topic Wiki Overhaul 19:20:34 #link https://wiki.openstack.org/wiki/StoryBoard a very nice-looking wiki page 19:20:45 not sure if this already got covered last meeting 19:21:01 yeah, diablo_rojo_phon did a good job 19:21:09 I think I still owe an updated schema diagram 19:22:05 cool. any other feedback on the wiki page? 19:22:49 #topic Open Discussion 19:23:51 some of us got some feedback from a few of the starlingx community who have recently started using storyboard for their task and defect tracking 19:24:18 oh cool, how're they finding it? 19:24:24 one big thing they miss, which we hear a lot, is freeform file attachments 19:24:44 we know that's something we want to get working anyway 19:25:14 one interesting request i haven't heard before is an export story option in the webclient for archival and reporting purposes 19:26:06 i suggested they could dump story data via the api, but are welcome to try hacking on that addition if it's really something they want to see 19:26:17 I'm starting to think we're going to need a solution to the file attachments thing sooner rather than later 19:26:59 and yeah, my suggestion would've been to write a script to get things from the API, but I'm also not against a convenient button in the UI if someone wants to make one 19:27:24 yeah, i wonder if we could tempt some of the zuul team since they've just recently (in the past couple weeks) resurrected efforts to stash their logging in object stores. they might have a fresh view on how we could leverage something similar for story attachments 19:28:56 and i know we've (from a zuul perspective) struggled a little with things in private stories for embargoed vulnerability reports using preformatted text in comments as a stand-in for an attachment feature 19:29:42 in that case it worked, but some actual way to link to an attachment store would have been far easeir 19:29:51 hm, private stories is certainly a feature that our other recommendations (just host it somewhere else) haven't really considered 19:31:02 well, it could still work. for example if the object store is an openstack swift service running somewhere, just don't allow public indexing and use lengthy randomized object names 19:31:42 oh yes, I meant our current workaround suggestions of paste.o.o or wherever 19:31:56 idea being, unless someone is given the url to the attachment, they won't be able to find it, so that means they're either someone who has/had access to the story where it was linked or the information was leaked to them by someone 19:32:08 yep 19:32:36 yep, I think it'll be useful to talk with the zuul folk working on that to see how we can do something similar 19:32:40 services with indexes or guessable urls are a no-go for private data 19:33:10 do swift's tempurls help with this? 19:33:46 notmyname: likely, i just haven't investigated our options from the perspective of this feature work yet 19:34:04 ok. happy to talk about it with you whenever you need 19:34:27 i don't know if tempurls are a long-lived/indefinite construct (the name would imply otherwise)? 19:34:53 even ignoring the privacy concerns for private stories we probably don't want to make the objects too easily distributed without storyboard simply to avoid spam 19:34:55 they are time-limited and for a particular method (and now, a particular IP) 19:35:22 notmyname: ahh, then probably not the way we'd need to engineer that bit 19:36:14 unless maybe storyboard got unique tempurls per client request to hand out 19:36:21 but maybe that's the way around clarkb's concern 19:36:27 fungi: eg you could put the sensitive stuff in a non-public container. when showing a page with sensitive context, you generate the url and use that link. that would prevent sharing the links anywhere 19:37:00 tempurls can be generated offline with no connection to the cluster. they are hmacs based on the request to be made 19:37:13 ya we have/had support for that in zuul 19:37:20 it was how the first pass at logs in swift worked 19:37:34 (it's one of my favorite features in swift) 19:37:34 (we were using them for writes in that case but similar in concept I think) 19:37:39 i'm honestly less concerned about people redistributing access to private embargoed attachments as long as the urls can be made basically impossible to guess 19:38:35 but clarkb raises a great point that if we give people an easy way to upload files somewhere that anybody can directly download (regardless of whether it's public information) that is an invitation for abuse (warez and so on) 19:39:00 so maybe a per-request token handed out by sb makes that harder to misuse 19:39:46 on the other hand, it might break things like right-click, copy url, paste to wget command line in my terminal 19:40:03 whoever is running the cluster could install middleware to scan object writes for malware. that's a bit outside of the scope of this, I think, because you're not running the cluster 19:40:27 fungi: you could probably have storyboard host the urls then redirect to the actual tempurl location 19:40:37 sure, less concerned about malware and more about people who like to find places to redistribute copyrighted or illicit material 19:40:38 which is probably sufficient for chasing away most abusers 19:42:03 that remnids me, we probably also want to see about implementing that same directive we got gerrit to add which instructs search engines not to follow links when indexing content 19:42:22 yeah, I've been envisioning an API endpoint in storyboard which handles all the interaction with the store mostly invisibly to the client 19:42:33 so that storyboard installs don't present an attractive target for linkspammers 19:43:48 granted that does nothing to deter the phone scam spammers on our wiki (thanking $deity that crowd hasn't found gerrit) 19:46:35 "nofollow" i guess? if it's that, we can set it in robots.txt 19:48:28 i'm not actually finding what it was we had gerrit add 19:48:37 but i'll dig it up later 19:48:39 I think that'll do it, but I'm far from an expert 19:49:02 okay, anybody have anything else for open discussion? if not i'll go ahead and close out the meeting 19:49:16 I don't have anything 19:50:25 okay, well thanks everybody! this was helpful for me to get caught up 19:50:41 #endmeeting