19:05:22 <SotK> #startmeeting storyboard
19:05:23 <openstack> Meeting started Wed Dec  6 19:05:22 2017 UTC and is due to finish in 60 minutes.  The chair is SotK. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:05:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:05:27 <openstack> The meeting name has been set to 'storyboard'
19:06:15 <SotK> #link https://wiki.openstack.org/wiki/Meetings/StoryBoard Agenda
19:06:47 <SotK> I expect today will be fairly quick
19:06:59 <SotK> #topic In Progress Work
19:07:34 <SotK> so, the email bug got sorted out, thanks fungi!
19:07:40 <SotK> "bug"
19:07:49 <Zara> haha
19:08:39 <SotK> in other news, I addressed Zara's comments on https://review.openstack.org/#/c/511246/ so that we can unblock those
19:08:43 <SotK> #link https://review.openstack.org/#/c/511246/
19:08:57 <SotK> #link https://review.openstack.org/#/c/511247/
19:09:23 <Zara> neat, thanks!
19:09:44 <Zara> (sorry I'm late, my food was ready)
19:10:11 <SotK> np :)
19:11:15 <fungi> heyhey
19:11:31 <SotK> welcome fungi
19:12:56 <fungi> only thing i had (aside from noting that storyboard.o.o is now exempted frmo the spamhaus policy blocklist entry rackspace blankets their ipv4 allocations with), is that kolla-kubernetes bugs have been migrated today
19:13:19 <SotK> nice!
19:13:23 <SotK> how did that go?
19:13:39 <fungi> fine, import was probably around 20-30 minutes to complete
19:13:50 <fungi> i wasn't timing it, but should have done
19:14:11 <Zara> sounds good
19:14:23 <Zara> 20-30 mins sounds specific enough for us tbh
19:15:14 <SotK> indeed
19:15:25 <fungi> discussion on the migration goal proposal is also coming along
19:16:06 <SotK> so I see
19:16:15 <SotK> I had a skim of it but not yet a proper read
19:16:24 <SotK> #link https://review.openstack.org/#/c/513875/
19:16:54 <fungi> thanks, gertty was taking too long to pull it up for me so i could grab the link
19:17:46 <Zara> I've also been lurking
19:18:03 <Zara> since I think anything I write would read as 'storyboard storyboard storyboard' anyway
19:18:05 <fungi> i think most of the concerns have been assuaged at this point other than where it would be nice to have a smoother experience on private story reporting and the need to generally just get some more projects migrated before we set it as a goal
19:19:04 <SotK> they seem like fair concerns
19:19:24 <fungi> kmalloc mentioned earlier this week that the discussion around migrating had come up in #openstack-keystone and they're concerned about the private story situation getting resolved before considering it
19:19:50 <fungi> being one of the more security-critical projects we have
19:19:59 <SotK> I think we had a plan on how to solve the private story reporting somewhere in our meeting logs, idk if it ever got written up into a story
19:20:16 * SotK will confirm he isn't going mad and do so later
19:20:36 <fungi> that would be awesome if you get a chance
19:21:00 <Zara> I'm about 70% certain it did
19:21:25 <fungi> i didn't have anything else. dunno whether diablo_rojo_phon has anything to add from kubecon, but she's probably otherwise occupied there at the moment
19:23:14 <Zara> (istr it involved having a specific tag and then notifying teams subscribed to the tag, all I can find atm is: https://storyboard.openstack.org/#!/story/2000568)
19:23:33 <Zara> where the tag wasn't a freeform thing so that people would definitely get the right one
19:23:48 <Zara> applied via a checkbox?
19:23:51 <SotK> Zara: that sounds similar to my memory
19:23:52 <fungi> ahh, so overloading story tags for auto access?
19:25:10 <SotK> I don't remember if it was using actual tags or setting a "vulnerability" flag on the story
19:25:13 <Zara> I'm not *certain* if it was a tag or if we were going to add a field in the db
19:25:20 <Zara> yeah I think we might've settled on db in the end
19:25:25 <fungi> to me the critical bit to solve is having some logic for granting private story access to specific accounts or, preferably, predefined groups of accounts
19:25:50 <Zara> I think that was fairly straightforward (just hooking up 'teams' to view permissions)
19:25:55 <Zara> and the tricky bit was on the reporting side
19:26:07 <Zara> because we needed people to consistently make them private
19:26:26 <fungi> right, seems like that piece is probably solvable in the webclient
19:26:28 <Zara> so eg: they couldn't write 'private' themselves as a tag because they might write 'prrrivate' or something
19:26:48 <fungi> there's already a "private" checkbox when reporting a new story
19:27:04 <SotK> aha, found the discussion
19:27:07 <SotK> #link http://eavesdrop.openstack.org/meetings/storyboard/2017/storyboard.2017-03-08-19.00.log.html#l-94
19:27:11 <Zara> thanks
19:27:49 <fungi> my ideal future would be having a reporting url which defaults the private setting true for a new story and hides it
19:28:16 <fungi> and then we can just use that url in our reporting suspected vulnerabilities workflow documentation
19:29:01 <SotK> that sounds like a good idea, and ties in with the need from other docs folks to link to a partially filled story creation thing
19:29:42 <fungi> agreed, fairly similar
19:29:54 <fungi> just involving a different field
19:30:13 <SotK> yep
19:30:34 <fungi> so what's the situation with "teams" in sb right now? is that still theoretical/roadmap or is it implemented? partly implemented? anything there at all yet?
19:31:03 <SotK> teams are pretty much complete in storyboard
19:31:12 <SotK> they can be created and edited by admins iirc
19:31:19 <Zara> we've had them in storyboard-dev for a while
19:31:22 <SotK> and can be added to the permission list for stories
19:31:25 <Zara> if you want to poke around there
19:31:48 <fungi> and can access be granted to a team for a private story yet, or is that still just supportnig individual accounts?
19:31:56 <fungi> hah, you answered that already
19:31:58 <fungi> thanks
19:32:03 <SotK> :)
19:32:23 <SotK> you can't add teams to boards/worklists permissions yet though
19:32:48 <SotK> there's a really old half finished patch for that somewhere that is fairly high on my todo list to revisit
19:33:03 <fungi> i can see people being interested in access controls for boards and worklists, but for now i'm mostly just concerned with the private story situation since vmt needs are seen a s major migration blocker
19:33:22 <SotK> makes sense
19:33:33 <fungi> that's excellent news though
19:33:36 <Zara> yeah, I think the roadmap side is fairly clear at least and we're mainly struggling for time.
19:33:43 <Zara> to actually do the things
19:33:43 <fungi> closer to solved than i realized even
19:34:02 <SotK> I think the main missing piece there is that currently the bug reporter has to manually remember to add the VMT (if someone were to make such a team in sb) to their story
19:34:25 <Zara> that's it, because private =! sec vulnerability
19:34:31 <Zara> it might sometimes or it might not
19:34:36 <fungi> yeah, i expect that's something which could also be done via the not-yet-defined custom reporting urls mechanism
19:35:09 <Zara> which is how we ended up with needing a specific tag or other mechanism to report sec vuln, I remember now.
19:35:21 <fungi> so the suspected vulnerability reporting url could set private true and add access for the vmt
19:35:30 <SotK> Zara: yep
19:36:21 <SotK> fungi: indeed, though I feel like we'd still need some mechanism for it in storyboard itself to catch folk who don't follow that link
19:36:33 <fungi> i can certainly see having bolt-on automation autoadd vmt access to private stories with a "security" tag on them, as a workaround
19:38:30 <SotK> #action SotK to add detail to the private stories story
19:38:41 <SotK> anything else?
19:38:57 <fungi> as for the "making sure private stories don't slip through the cracks" problem, the solution launchpad adopted was to have the ability to set a team (on a per-project basis) which automatically has access to any private bug reports
19:39:42 <fungi> so teams could set that as the vmt or as their own team-specific core security reviewers team, whoever is expected to triage those
19:40:09 <fungi> s/team-specific/project-specific/
19:40:55 <fungi> not sure how something like that would align with the current data model around teams and permissions in sb
19:41:13 <fungi> and no, nothing else from me this week
19:42:34 <SotK> that's certainly something to consider, my only immediate concern is of it being a stepping stone to adding full permissions for projects and so on
19:43:00 <SotK> which is something we've deliberately avoided so far
19:43:49 <fungi> agreed, makes sense to avoid
19:45:25 <fungi> wonder if it would make sense to have an option to prevent adding a private story without selecting at least one team to grant access for
19:46:08 <fungi> so that a naive reporter couldn't accidentally create a story only they could see
19:47:11 <SotK> yeah, that could make sense I guess, though it could be limiting if someone deliberately wanted to create a private story visible to only them and certain other people for whatever reason
19:47:34 * SotK doesn't really see there being much benefit in doing that, but I guess some follk might
19:48:14 <fungi> well, the certain other people part is probably solvable if you just require that the reporter add at least one team or an account who isn't them
19:48:45 <fungi> and sure, it seems like it could be a global setting to turn that behavior on/off for a deployment
19:49:35 <SotK> yeah, I think I'd prefer "at least one team or other person", or make it fully configurable
19:50:40 <fungi> makes sense
19:52:13 * SotK will leave the meeting open for a couple of minutes in case anyone has anything further to discuss
19:54:56 <SotK> thanks for attending folk!
19:54:59 <SotK> #endmeeting