19:01:55 #startmeeting storyboard 19:01:56 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:59 The meeting name has been set to 'storyboard' 19:02:21 I'll give running things a go since SotK said he couldn't make it today :( 19:02:41 #link https://wiki.openstack.org/wiki/Meetings/StoryBoard#Agenda_for_next_meeting Agenda 19:02:50 #topic Announcements 19:03:00 Cyborg has migrated! 19:03:12 * diablo_rojo cues applause 19:03:52 better than queuing applause i suppose 19:04:11 Ha ha 19:04:33 Other announcement: Forum submissions are open till the 15th! 19:04:41 So if you have ideas please submit them! 19:05:13 I have one I drafted for StoryBoard in this etherpad: 19:05:32 #link https://etherpad.openstack.org/p/sb_forum_yvr_rocky_proposal Kendall's SB Forum Proposal 19:05:50 I would love comments and edits 19:06:01 Any other announcements before I move on? 19:06:37 nothing from the peanut gallery here 19:06:53 no announcements here 19:07:40 #topic Migration Updates! 19:08:04 So! Sounds like we have OpenStackSDK and OpenStackClient scheduled for Friday. 19:08:23 Which is super awesome. I love this having migrations every week business. 19:08:45 #link https://storyboard.openstack.org/#!/board/45 Board Tracking Migration Progress 19:08:47 yeah, happy to take care of them 19:08:53 setting myself a reminder now 19:09:04 do we have changes proposed for those? 19:09:07 fungi, much appreciated! I owe you so many beers. 19:09:15 fungi, not yet, but I can do that today. 19:09:34 tripleo's ui squad also requested migrating the validations tags to openstack/tripleo-validations 19:09:56 i have a change up for that and can merge it whenever they're ready for me to run it 19:10:08 #action diablo_rojo will create project-config changes for OSDK and OSC 19:10:33 #link https://review.openstack.org/558934 Track tripleo-validations tasks on StoryBoard 19:10:40 fungi, excellent I will check it out and I can poke EmilienM to look too if you want 19:10:47 Anything else I can do to help there? 19:10:54 * EmilienM hides 19:11:01 :) 19:11:05 thanks! 19:11:23 Last update is that we also started talking about migrating the TripleO security squad 19:11:33 it becomes tricky though 19:11:39 because they don't have specific repos 19:11:45 yeah, i replied on that thread because i'm confused as to what they're looking for 19:11:47 they use most of tripleo repos 19:12:13 I guess we want to create the tripleo project and migrate bugs with certain tags maybe? 19:12:28 I feel like it would be fine if we created the repos and then just migrate the relevant tags 19:12:35 EmilienM, exactly :) 19:13:19 that would probably work, but i'm trying to think about what problems it might cause 19:13:26 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 are you expecting tripleo users to start reporting suspected vulnerabilities into sb but keep reporting all other bugs in lp? 19:13:59 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 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 Yes, important to note. 19:16:10 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 EmilienM, how far behind are the rest of the squads from being willing to migrate? 19:17:03 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 dhellmann, yeah for the first few squads it was fine as they had their own repos, but for others that share.. 19:17:35 and the repository-specific task concept aligns perfectly with storyboard's model 19:17:40 diablo_rojo: not easy answer 19:17:53 EmilienM, I didn't expect it would be lol 19:17:55 tripleo project is really big, lot of repos, lot of teams, lot of people :) 19:18:08 which why I suggested we do baby steps here 19:18:15 Are there others that have specific repos we can do first? 19:18:24 Or were UI and validation the only ones? 19:18:25 no 19:18:35 they were the only ones 19:19:03 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 could we have "tripleo" project in SB 19:21:27 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 That was a terribly worded sentence lol 19:21:56 and we migrate some bugs but only some tags 19:22:20 if we move all bugs all in once and ask everyone to switch it's going to be messy 19:22:38 we can TRY! but only if you have a time machine in case things go south 19:22:44 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 EmilienM, sadly I have no Tardis. 19:23:18 what??? pfftt :) 19:23:21 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 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 yeah we can try 19:24:55 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 Let me know what meetings I need to attend to rally the people EmilienM 19:25:55 fungi, so is this feasible? 19:27:45 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 diablo_rojo: tuesday at your 7am (yes sorry) 19:28:11 diablo_rojo: on #tripleo 19:28:21 diablo_rojo: but really you can join the channel at anytime 19:28:24 workflow for people filing bugs or for the team fungi ? 19:28:34 EmilienM, I'll add it to my calendar. 19:28:42 awesome 19:29:39 Oh man. FC SIG at 1 AM. TripleO at 7AM. 19:29:45 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 lhinds, might be able to share thoughts on that? ^^ 19:30:48 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 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 Agreed 19:32:32 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 ? 19:32:48 What goes where 19:32:59 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 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 why are we going team-by-team instead of repo-by-repo? 19:34:39 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 dhellmann: tripleo didn't track bugs by repo 19:35:03 they just used one big tripleo bucket in lp 19:35:18 hmm 19:35:22 at least for the most part 19:35:36 Yes thats my understanding 19:36:05 ok 19:36:09 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 but there is a lot of intersection with squads and repos 19:36:41 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 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 from the infrastructure side of things, yes moving them all at once would be way easier 19:37:32 All at once would certainly be preferable.. 19:37:45 maybe they're not good candidates to go early, then, if they're a special case or need extra encouragement 19:37:48 I can talk to the team Tuesday during their meeting and beg :) 19:38:00 we invented a way to fan out bugs to different repositories based on tag filtering specifically for tripleo in fact 19:38:19 oh, wow 19:38:27 More for sahara, but TripleO had a vested interest 19:38:40 oh, right, thanks for the correction 19:38:50 we did use it on sahara first for similar reasons 19:39:05 One big lp projects that covered a lot of repos 19:39:19 It was a super cool migration script addition in my opinion 19:39:33 for sure, it's handy 19:39:43 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 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 exactly 19:40:41 I have like 15 projects ready to move that I have been casually chatting with PTLs about migration with 19:40:53 nice 19:41:04 I presume that means we no longer have any feature blockers? 19:41:09 with storyboard itself, that is 19:41:34 dhellmann, the last big blocker was the private stories and I believe all that has been implemented 19:41:36 there are a few i'm personally prioritizing 19:42:00 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 but they're more like irritations/inconveniences to projects who have already moved to sb which we need to fix 19:42:12 that all sounds good 19:42:14 We will get to that in the agenda if we are good to move on? 19:42:21 the ones i'm focusing on at least 19:42:31 yup, i'm all set 19:42:35 #topic In Progress Work 19:42:46 fungi? gerrit posting on stories? 19:43:17 yeah, i'm in the process of diagnosing that one today 19:43:35 then there are a couple further down the list i plan to look at once i have that settled 19:43:46 Cool. 19:44:03 I think that getting fixed will unblock another team or two 19:44:30 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 #link https://review.openstack.org/#/q/project:openstack-infra/storyboard+status:open Open Storyboard Reviews 19:45:33 #link https://review.openstack.org/#/q/project:openstack-infra/storyboard-webclient+status:open Open Webclient Reviews 19:45:34 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 before fixing that we want to be able to test that it doesn't regress again 19:46:03 #link https://review.openstack.org/#/q/project:openstack-infra/python-storyboardclient+status:open Open Pythonclient reviews 19:46:23 Agreed. 19:46:25 but corvus has been having some difficulty wrangling the testsuite to get a test for that added 19:46:59 Ah yes I recall him having issues and needing SotK to explain some things. 19:47:31 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 :-( 19:48:15 :( 19:49:39 this feels like a good use case for something like celery 19:49:50 celery? 19:49:55 https://pypi.python.org/pypi/celery 19:50:27 SB would start a task to send email instead of blocking on talking to the sendmail daemon 19:50:44 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 Interesting. 19:51:10 oh, yeah, I would consider that a blocker 19:51:26 users are going to want to be able to find stories when they plug error messages into web search engines 19:52:08 Oh yes, for sure. 19:52:45 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 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 and yeah, an index too 19:53:11 makes sense 19:53:25 storyboard.openstack.org/static/ or something 19:53:48 Ahh okay. Similar to the bug indicies in lp. 19:54:10 yeah, if you want the crawler to crawl your site, you have to give it a place to start 19:54:53 Makes sense. So..thats something we need to implement in the webclient then I suppose. 19:55:06 or maybe as a separate tool 19:55:11 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 separate tool would be nicer. 19:55:31 yeah, I don't know the state of the art either 19:55:49 I mean I would have thought the URL to load a story would produce HTML that includes the story 19:56:00 rather than JS to fetch the story details after loading 19:56:05 i mean, we could easily(?) just periodically dump the whole data set and render static versions with the redirecting juice embedded 19:56:16 right, that's what I was thinking, too 19:56:29 We had been tentatively planning making a new repo storyboard-tools 19:56:33 This could live there? 19:56:39 seems reasonable 19:57:22 3 min left heads up 19:57:27 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 I wonder if they're doing agent-string identification 19:57:54 fungi, yeah I would agree 19:57:55 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 ++ 19:58:10 ++ :) 19:58:17 get it working; get it working right; get it working fast 19:58:20 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 Out of time to go through other blocking things this week. 20:00:27 But I think we all have enough things to work on for now. 20:00:35 Thanks for coming fungi and dhellmann :) 20:00:38 #endmeeting