19:01:55 <diablo_rojo> #startmeeting storyboard
19:01:56 <openstack> Meeting started Wed Apr 11 19:01:55 2018 UTC and is due to finish in 60 minutes.  The chair is diablo_rojo. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:59 <openstack> The meeting name has been set to 'storyboard'
19:02:21 <diablo_rojo> I'll give running things a go since SotK said he couldn't make it today :(
19:02:41 <diablo_rojo> #link https://wiki.openstack.org/wiki/Meetings/StoryBoard#Agenda_for_next_meeting Agenda
19:02:50 <diablo_rojo> #topic Announcements
19:03:00 <diablo_rojo> Cyborg has migrated!
19:03:12 * diablo_rojo cues applause
19:03:52 <fungi> better than queuing applause i suppose
19:04:11 <diablo_rojo> Ha ha
19:04:33 <diablo_rojo> Other announcement: Forum submissions are open till the 15th!
19:04:41 <diablo_rojo> So if you have ideas please submit them!
19:05:13 <diablo_rojo> I have one I drafted for StoryBoard in this etherpad:
19:05:32 <diablo_rojo> #link https://etherpad.openstack.org/p/sb_forum_yvr_rocky_proposal Kendall's SB Forum Proposal
19:05:50 <diablo_rojo> I would love comments and edits
19:06:01 <diablo_rojo> Any other announcements before I move on?
19:06:37 <fungi> nothing from the peanut gallery here
19:06:53 <dhellmann> no announcements here
19:07:40 <diablo_rojo> #topic Migration Updates!
19:08:04 <diablo_rojo> So! Sounds like we have OpenStackSDK and OpenStackClient scheduled for Friday.
19:08:23 <diablo_rojo> Which is super awesome. I love this having migrations every week business.
19:08:45 <diablo_rojo> #link https://storyboard.openstack.org/#!/board/45 Board Tracking Migration Progress
19:08:47 <fungi> yeah, happy to take care of them
19:08:53 <fungi> setting myself a reminder now
19:09:04 <fungi> do we have changes proposed for those?
19:09:07 <diablo_rojo> fungi, much appreciated! I owe you so many beers.
19:09:15 <diablo_rojo> fungi, not yet, but I can do that today.
19:09:34 <fungi> tripleo's ui squad also requested migrating the validations tags to openstack/tripleo-validations
19:09:56 <fungi> i have a change up for that and can merge it whenever they're ready for me to run it
19:10:08 <diablo_rojo> #action diablo_rojo will create project-config changes for OSDK and OSC
19:10:33 <fungi> #link https://review.openstack.org/558934 Track tripleo-validations tasks on StoryBoard
19:10:40 <diablo_rojo> fungi, excellent I will check it out and I can poke EmilienM to look too if you want
19:10:47 <diablo_rojo> Anything else I can do to help there?
19:10:54 * EmilienM hides
19:11:01 <diablo_rojo> :)
19:11:05 <fungi> thanks!
19:11:23 <diablo_rojo> Last update is that we also started talking about migrating the TripleO security squad
19:11:33 <EmilienM> it becomes tricky though
19:11:39 <EmilienM> because they don't have specific repos
19:11:45 <fungi> yeah, i replied on that thread because i'm confused as to what they're looking for
19:11:47 <EmilienM> they use most of tripleo repos
19:12:13 <EmilienM> I guess we want to create the tripleo project and migrate bugs with certain tags maybe?
19:12:28 <diablo_rojo> I feel like it would be fine if we created the repos and then just migrate the relevant tags
19:12:35 <diablo_rojo> EmilienM, exactly :)
19:13:19 <fungi> that would probably work, but i'm trying to think about what problems it might cause
19:13:26 <diablo_rojo> And then migrate other tags later then finally, once all the squads are over, run the last time for all of TripleO to make sure the rest is migrated and things are all up to date before disabling the tracker.
19:13:56 <fungi> are you expecting tripleo users to start reporting suspected vulnerabilities into sb but keep reporting all other bugs in lp?
19:13:59 <diablo_rojo> fungi, it would be hard not being able to disable bug reporting for certain cases- things might continue to get filed there
19:15:03 <fungi> also keep in mind that any currently private bugs don't get migrated. we'd have to manually summarize them in new private stories if they need to remain private due to an in-progress embargo at the time of migration
19:15:52 <diablo_rojo> Yes, important to note.
19:16:10 <dhellmann> splitting the bugs for repos up like that seems like it's going to make the migration more complicated than just waiting to do that team until the others are done
19:16:43 <diablo_rojo> EmilienM, how far behind are the rest of the squads from being willing to migrate?
19:17:03 <fungi> right. splitting tripleo bugs along repository boundaries is a bit easier since you basically used bugtags to indicate which repository you were targeting with them
19:17:26 <diablo_rojo> dhellmann, yeah for the first few squads it was fine as they had their own repos, but for others that share..
19:17:35 <fungi> and the repository-specific task concept aligns perfectly with storyboard's model
19:17:40 <EmilienM> diablo_rojo: not easy answer
19:17:53 <diablo_rojo> EmilienM, I didn't expect it would be lol
19:17:55 <EmilienM> tripleo project is really big, lot of repos, lot of teams, lot of people :)
19:18:08 <EmilienM> which why I suggested we do baby steps here
19:18:15 <diablo_rojo> Are there others that have specific repos we can do first?
19:18:24 <diablo_rojo> Or were UI and validation the only ones?
19:18:25 <EmilienM> no
19:18:35 <EmilienM> they were the only ones
19:19:03 <fungi> so anyway, sounds like the security squad would probably actually straddle lp and sb if they're handling security issues in parts of tripleo which are in sb and parts which are still in lp
19:21:26 <EmilienM> could we have "tripleo" project in SB
19:21:27 <diablo_rojo> I think continuing to do a squad at a time is doable, though it might get messy. Coming up with a more concrete timeline for the rest of them to minimize lag would be best before we split the repo would be a good idea I think.
19:21:54 <diablo_rojo> That was a terribly worded sentence lol
19:21:56 <EmilienM> and we migrate some bugs but only some tags
19:22:20 <EmilienM> if we move all bugs all in once and ask everyone to switch it's going to be messy
19:22:38 <EmilienM> we can TRY! but only if you have a time machine in case things go south
19:22:44 <diablo_rojo> EmilienM, yeah we can do that- its just going to get messy I think as people could still report bugs with the tags in lp instead of where they should be in storyboard.
19:23:03 <diablo_rojo> EmilienM, sadly I have no Tardis.
19:23:18 <EmilienM> what??? pfftt :)
19:23:21 <fungi> well, "projects" in sb correspond to individual git repositories. i suppose we could migrate them to have initial tasks in the openstack/tripleo-common project
19:24:21 <diablo_rojo> So 10 squads. 1 is already migrated. validation is set to go. Security after, then maybe one or two each following week?
19:24:43 <EmilienM> yeah we can try
19:24:55 <fungi> and create projects in sb for all the tripleo team's other deliverable repositories too and then active stories could get new tasks manually (or scripted through the api based on some determined characteristics) created for the relevant projects
19:25:26 <diablo_rojo> Let me know what meetings I need to attend to rally the people EmilienM
19:25:55 <diablo_rojo> fungi, so is this feasible?
19:27:45 <fungi> migrating (public) tripleo security squad bugs to specific repository projects in sb based on one or more lp bugtags is feasible, but it's the workflow i'm mostly worried about
19:28:04 <EmilienM> diablo_rojo: tuesday at your 7am (yes sorry)
19:28:11 <EmilienM> diablo_rojo: on #tripleo
19:28:21 <EmilienM> diablo_rojo: but really you can join the channel at anytime
19:28:24 <diablo_rojo> workflow for people filing bugs or for the team fungi ?
19:28:34 <diablo_rojo> EmilienM, I'll add it to my calendar.
19:28:42 <EmilienM> awesome
19:29:39 <diablo_rojo> Oh man. FC SIG at 1 AM. TripleO at 7AM.
19:29:45 <fungi> a little of both. main concerns are 1. if users are filing security bugs will they know to do so in sb, and 2. when users are filing security bugs do they know in advance they're security bugs or do they get triaged as such later (and will someone then need to tell the reporter to copy that into sb or perhaps do so themselves)?
19:30:19 <diablo_rojo> lhinds, might be able to share thoughts on that? ^^
19:30:48 <fungi> it's a little easier at least when the users can expect to file security and normal bugs in the same system
19:31:40 <fungi> knowing to use different bug trackers to report bugs for different subsystems/repositories is one thing, but deciding which tracker to use based on more subtle characteristics like "is this maybe security-related" could be a lot harder to figure out
19:31:56 <diablo_rojo> Agreed
19:32:32 <diablo_rojo> I suppose they can note that in their list of bug tags and in the lp project description and any other documentation they have
19:32:36 <diablo_rojo> ?
19:32:48 <diablo_rojo> What goes where
19:32:59 <fungi> at least from my (vmt) perspective, it's a lot more common to see bugs originally reported as security bugs turn out not to be and vice versa than it is to see bugs reported against the wrong subsystem
19:34:01 <diablo_rojo> Yeah I suppose if its reported as security but itsnt then its already in sb but the regular squad dealing with it wouldnt see it unless they are already looking at both places.
19:34:38 <dhellmann> why are we going team-by-team instead of repo-by-repo?
19:34:39 <fungi> and if it's reported as a not-security bug but then turns out to be security related, it needs to get moved into sb somehow
19:34:54 <fungi> dhellmann: tripleo didn't track bugs by repo
19:35:03 <fungi> they just used one big tripleo bucket in lp
19:35:18 <dhellmann> hmm
19:35:22 <fungi> at least for the most part
19:35:36 <diablo_rojo> Yes thats my understanding
19:36:05 <dhellmann> ok
19:36:09 <fungi> and then augmented some of that by using bugtags to identify different responsible subteams which in some cases roughly corresponded to one or a set of repositories
19:36:39 <diablo_rojo> but there is a lot of intersection with squads and repos
19:36:41 <fungi> but the concern is that tripleo is so huge and has so many subteams that convincing them all to switch from lp to sb at once would be hard
19:36:54 <dhellmann> my inclination would be to just move it all at once, but if you have ways to not do that I guess it's probably fine and since I'm not doing the work I should probably just stay out of it
19:37:22 <fungi> from the infrastructure side of things, yes moving them all at once would be way easier
19:37:32 <diablo_rojo> All at once would certainly be preferable..
19:37:45 <dhellmann> maybe they're not good candidates to go early, then, if they're a special case or need extra encouragement
19:37:48 <diablo_rojo> I can talk to the team Tuesday during their meeting and beg :)
19:38:00 <fungi> we invented a way to fan out bugs to different repositories based on tag filtering specifically for tripleo in fact
19:38:19 <dhellmann> oh, wow
19:38:27 <diablo_rojo> More for sahara, but TripleO had a vested interest
19:38:40 <fungi> oh, right, thanks for the correction
19:38:50 <fungi> we did use it on sahara first for similar reasons
19:39:05 <diablo_rojo> One big lp projects that covered a lot of repos
19:39:19 <diablo_rojo> It was a super cool migration script addition in my opinion
19:39:33 <fungi> for sure, it's handy
19:39:43 <diablo_rojo> There are enough other irons in the fire that if we can't do TripleO now it wont stop progress.
19:40:18 * dhellmann nods
19:40:20 <fungi> and also, the more high-profile migrations we get behind us, the easier it is to convince some of the teams who are still on the fence
19:40:30 <dhellmann> exactly
19:40:41 <diablo_rojo> I have like 15 projects ready to move that I have been casually chatting with PTLs about migration with
19:40:53 <dhellmann> nice
19:41:04 <dhellmann> I presume that means we no longer have any feature blockers?
19:41:09 <dhellmann> with storyboard itself, that is
19:41:34 <diablo_rojo> dhellmann, the last big blocker was the private stories and I believe all that has been implemented
19:41:36 <fungi> there are a few i'm personally prioritizing
19:42:00 <diablo_rojo> There are some things people have filed but I think a lot of them are 'nice to have' rather than actually blocking issues
19:42:02 <fungi> but they're more like irritations/inconveniences to projects who have already moved to sb which we need to fix
19:42:12 <dhellmann> that all sounds good
19:42:14 <diablo_rojo> We will get to that in the agenda if we are good to move on?
19:42:21 <fungi> the ones i'm focusing on at least
19:42:31 <fungi> yup, i'm all set
19:42:35 <diablo_rojo> #topic In Progress Work
19:42:46 <diablo_rojo> fungi? gerrit posting on stories?
19:43:17 <fungi> yeah, i'm in the process of diagnosing that one today
19:43:35 <fungi> then there are a couple further down the list i plan to look at once i have that settled
19:43:46 <diablo_rojo> Cool.
19:44:03 <diablo_rojo> I think that getting fixed will unblock another team or two
19:44:30 <diablo_rojo> Not sure what I can do to help, but I'm here if you need a rubber duck at the very least.
19:45:13 <diablo_rojo> #link https://review.openstack.org/#/q/project:openstack-infra/storyboard+status:open Open Storyboard Reviews
19:45:33 <diablo_rojo> #link https://review.openstack.org/#/q/project:openstack-infra/storyboard-webclient+status:open Open Webclient Reviews
19:45:34 <fungi> one of the bigger issues further down my list is that private stories don't generate e-mail notifications to subscribers who are able to see them
19:46:01 <fungi> before fixing that we want to be able to test that it doesn't regress again
19:46:03 <diablo_rojo> #link https://review.openstack.org/#/q/project:openstack-infra/python-storyboardclient+status:open Open Pythonclient reviews
19:46:23 <diablo_rojo> Agreed.
19:46:25 <fungi> but corvus has been having some difficulty wrangling the testsuite to get a test for that added
19:46:59 <diablo_rojo> Ah yes I recall him having issues and needing SotK to explain some things.
19:47:31 <fungi> to the point where it may just be easier (sadly) to create an external periodic cron job to query the sb api and send e-mails
19:48:01 <dhellmann> :-(
19:48:15 <diablo_rojo> :(
19:49:39 <dhellmann> this feels like a good use case for something like celery
19:49:50 <diablo_rojo> celery?
19:49:55 <dhellmann> https://pypi.python.org/pypi/celery
19:50:27 <dhellmann> SB would start a task to send email instead of blocking on talking to the sendmail daemon
19:50:44 <fungi> the other one i'm tracking as a priority (which is a sort-of-blocker for some teams) is that due to the webclient doing all content querying and rendering browser-side, search engines are unable to easily index stories
19:50:48 <diablo_rojo> Interesting.
19:51:10 <dhellmann> oh, yeah, I would consider that a blocker
19:51:26 <fungi> users are going to want to be able to find stories when they plug error messages into web search engines
19:52:08 <diablo_rojo> Oh yes, for sure.
19:52:45 <dhellmann> I suppose that means we need some sort of index page that can be crawled to find all of the bugs, too
19:52:59 <fungi> so we probably need some indexible content returned in indexible "flat" pages which use something like a meta refresh redirect to bounce browser clients to the dynamic versions
19:53:09 <fungi> and yeah, an index too
19:53:11 <dhellmann> makes sense
19:53:25 <dhellmann> storyboard.openstack.org/static/ or something
19:53:48 <diablo_rojo> Ahh okay. Similar to the bug indicies in lp.
19:54:10 <dhellmann> yeah, if you want the crawler to crawl your site, you have to give it a place to start
19:54:53 <diablo_rojo> Makes sense. So..thats something we need to implement in the webclient then I suppose.
19:55:06 <dhellmann> or maybe as a separate tool
19:55:11 <fungi> given i'm not really a webapp designer, i have to assume there are standard/conventional solutions to this problem and i just don't know what they are
19:55:27 <diablo_rojo> separate tool would be nicer.
19:55:31 <dhellmann> yeah, I don't know the state of the art either
19:55:49 <dhellmann> I mean I would have thought the URL to load a story would produce HTML that includes the story
19:56:00 <dhellmann> rather than JS to fetch the story details after loading
19:56:05 <fungi> i mean, we could easily(?) just periodically dump the whole data set and render static versions with the redirecting juice embedded
19:56:16 <dhellmann> right, that's what I was thinking, too
19:56:29 <diablo_rojo> We had been tentatively planning making a new repo storyboard-tools
19:56:33 <diablo_rojo> This could live there?
19:56:39 <fungi> seems reasonable
19:57:22 <diablo_rojo> 3 min left heads up
19:57:27 <fungi> that "dump the content to flat files" feels really inelegant though. i have a hard time believing that's how, say, forum apps which are browser-side rendered accomplish things
19:57:49 * diablo_rojo will move the creation of that repo higher on her todo list
19:57:53 <dhellmann> I wonder if they're doing agent-string identification
19:57:54 <diablo_rojo> fungi, yeah I would agree
19:57:55 <fungi> but maybe i'll pull a mordred and implement the ugly solution so that it will anger someone enough they ragecode the right one
19:58:04 <dhellmann> ++
19:58:10 <diablo_rojo> ++ :)
19:58:17 <dhellmann> get it working; get it working right; get it working fast
19:58:20 <fungi> it's a viable tactic
19:59:11 * fungi did not mean to insult but rather compliment mordred's sensibilities in these matters ;)
20:00:18 <diablo_rojo> Out of time to go through other blocking things this week.
20:00:27 <diablo_rojo> But I think we all have enough things to work on for now.
20:00:35 <diablo_rojo> Thanks for coming fungi and dhellmann :)
20:00:38 <diablo_rojo> #endmeeting