15:00:38 <krotscheck> #startmeeting StoryBoard
15:00:39 <openstack> Meeting started Mon Sep 22 15:00:38 2014 UTC and is due to finish in 60 minutes.  The chair is krotscheck. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:43 <openstack> The meeting name has been set to 'storyboard'
15:00:56 <krotscheck> Good [insert-appropriate-time-of-day-here] everyone!
15:01:03 <gothicmindfood> ohai, krotscheck
15:01:06 <ttx> o/
15:01:11 <krotscheck> ohai, gothicmindfood!
15:01:25 * krotscheck hopes jeblair is around for the first two topics.
15:01:34 <krotscheck> #topic Urgent Item: RabbitMQ Failures.
15:01:58 <jeblair> oh hello
15:02:00 <krotscheck> So, the somewhat-more-robust Rabbitmq pubsub code landed this morning, meaning that StoryBoard should now automatically reconnect.
15:02:24 <krotscheck> i.e. jeblair, sometime this afternoon I’ll poke you to go look at the logs and verify that, ok?
15:02:30 <jeblair> krotscheck: happy to
15:02:33 <krotscheck> Cool.
15:02:40 <jeblair> did my "disable subscriptions" config change ever land?
15:02:46 <krotscheck> jeblair: Urm...
15:02:49 <krotscheck> jeblair: I don’t know?
15:03:14 <jeblair> i will search and report back shortly
15:03:26 <krotscheck> Thanks
15:03:40 <jeblair> yes: https://review.openstack.org/#/c/116973/
15:03:50 <jeblair> so we probably need to revert that
15:04:10 <krotscheck> Cool - want me to do that?
15:04:20 <krotscheck> jeblair: You haz review queue, no?
15:04:28 <krotscheck> (i.e. you’ve got lots of other things on your plate)
15:04:36 <jeblair> krotscheck: i'll do it
15:04:44 <krotscheck> jeblair: Gotcha
15:05:14 <krotscheck> I’m going to leave that item on the agenda until it’s well and truly closed.
15:05:22 <jeblair> #link https://review.openstack.org/#/c/123152/
15:05:39 <krotscheck> #topic Urgent Item: Launchpad Migration
15:05:48 <krotscheck> The launchpad migration CLI also landed.
15:06:06 <krotscheck> jeblair: See https://review.openstack.org/#/c/122047/
15:07:02 <krotscheck> At this point there may still be a few bugs, but I feel we can pick smaller projects to run test-migrations on.
15:08:02 <krotscheck> For the sake of sanity though, it might be best to spin up a test storyboard VM and run the script on that database without impacting prod.
15:08:30 <krotscheck> I’ve verified that it works for storyboard and zuul, but I haven’t run others.
15:09:00 <krotscheck> One thing though: with lots more data, the UI starts to fall down rather severely since we never built page controls.
15:09:26 <krotscheck> Upside: It’s now easy to seed your local database with lots of real data.
15:10:12 <krotscheck> Any questions on that?
15:10:48 <jeblair> yeah, one of the hopes is that we will get annoyed at little problems like that when using them with infra and get them fixed before the rest of the project has to see them :)
15:10:56 <krotscheck> Exactly :)
15:11:26 <krotscheck> So I feel thsi topic is completed, does anyone have questions and/or disagreements?
15:12:45 <krotscheck> Anyone? No? Ok, moving on.
15:12:50 <krotscheck> #topic Discussion
15:12:55 <krotscheck> No topics listed. Moving on
15:13:06 <krotscheck> #topic MVP 1.1: Data Import
15:13:40 <krotscheck> See above discussion in Launchpad migration. Do we want to talk migration process/strategy right now or is that a ‘handle it in the infra meeting tomorrow’ thing?
15:14:00 <ttx> yeah, this one is ready code-wise, it's more a project adoption thing now
15:14:04 <jeblair> we should probably at least handle it in the infra meeting
15:14:09 <ttx> so I would strikeout the task now
15:14:16 <krotscheck> Awesome.
15:14:18 <krotscheck> Next!
15:14:22 <jeblair> (but also happy to talk about it here if you want)
15:14:24 <jeblair> (guess not :)
15:14:43 <krotscheck> jeblair: Well, at this point any single data import is going to make us scramble to update the UI
15:15:06 <krotscheck> So, the storm is coming, batten down the hatches :D
15:15:11 <krotscheck> #topic MVP 1.1 Subscription
15:15:18 <jeblair> do you want to delay import until you do some basic ui changes?
15:15:31 <krotscheck> jeblair: Naah, what could possibly go wrong :)
15:15:36 <mordred> heh
15:15:37 <jeblair> okiedokie :)
15:16:02 <mordred> krotscheck: is there anything that's so horribly broken that it will make a jeblair come through a computer monitor with a dead chicken?
15:16:21 <krotscheck> mordred: Even if it was, I’d rather leave it in there just to film it and put it on youtube.
15:16:35 * krotscheck doesn’t actually think there’s anything that broken.
15:16:39 <mordred> krotscheck: k. cool
15:16:49 <krotscheck> So, subscription was my second major task last week, because running multiple daemons and setting that up via puppet is hard.
15:17:14 <krotscheck> I ended up going with a build-the-daemon-manager-in-python approach, which right now is up for review BUT turns out is actually still broken.
15:17:41 <krotscheck> Mostly because of stupid sigterm trapping things when having the parent process manage multiple child processes.
15:18:03 <krotscheck> I’ll try to get that working soon, but for the time being it’s still WIP
15:18:07 * krotscheck makes a note to wip that.
15:18:25 <krotscheck> Any questions on that?
15:18:36 <ttx> nope, makes sense
15:18:40 <krotscheck> #link https://review.openstack.org/#/c/122890/
15:19:10 <krotscheck> #topic MVP 1.1 Project Groups
15:19:32 <krotscheck> There was an extended discussion on project group naming last week.
15:20:12 <krotscheck> And it _feels_ like https://review.openstack.org/#/c/111814/ and https://review.openstack.org/#/c/111815/ are now ready, because everyone understands the scope/intent.
15:21:11 <krotscheck> Given that, I’ve got a question.
15:21:38 <krotscheck> There are some parts of the UI which are enabled for admins, even though from a practical perspective they’re managed by puppet/scripts.
15:21:47 <krotscheck> Example: Creation of Projects and Project Groups.
15:22:16 <krotscheck> Do we care that those remain enabled?
15:22:25 * krotscheck is ambivalent.
15:22:37 <jeblair> i think in the long run we should find a way to disable them, possibly via an acl system like gerrit
15:22:49 <jeblair> in the short term, i think all our admins know not to use them
15:22:53 <krotscheck> Got it.
15:22:56 * krotscheck likes ACL systems
15:23:01 <ttx> I think jebalir sums it up well
15:23:06 <ttx> jeblair even
15:23:36 <krotscheck> So, current status on the feature is : Admin UI is there, script management is ready to land, user UI is not yet there.
15:23:55 <krotscheck> So you can’t yet search on project group, nor are project groups available from a not-admin user yet.
15:24:04 <ttx> ack
15:24:54 <krotscheck> Since it’ll probably be me who builds that, I also have to track down an annoying left-join bug in the task search that’s messing with our paging.
15:25:34 <krotscheck> No other updates. Any questions?
15:26:01 <ttx> no questiuon on that
15:26:31 <krotscheck> #topic MVP 1.1: Tags
15:26:42 <krotscheck> Only one update here: The import script _does_ load tags.
15:27:03 <krotscheck> Other than that, NikitaKonovalov mentioned in #storyboard earlier that he has no updates, likely because he’s still stuck in sahara country.
15:27:25 <krotscheck> #topic MVP 1.1 Emails
15:27:29 <krotscheck> No progress.
15:27:36 <SergeyLukjanov> krotscheck, ack re NikitaKonovalov
15:27:55 <krotscheck> SergeyLukjanov: Can we have him back soon? :)
15:28:10 <krotscheck> SergeyLukjanov: Or is he going to be stuck until Juno goes.
15:28:16 <SergeyLukjanov> krotscheck, honestly, I don't think that it'll be earlier than Juno release
15:28:41 <krotscheck> SergeyLukjanov: Well, as long as he continues to help review things I’m ok with that.
15:29:01 <krotscheck> #topic Open Discussion
15:29:08 <krotscheck> Any open discussion topics?
15:29:09 <ttx> Some time ago I posted https://wiki.openstack.org/wiki/StoryBoard/Story_Types
15:29:24 <ttx> Based on the initial feedback, I could turn that into a proper spec
15:29:40 <ttx> but if it sounds completely crazy, maybe not worth it :)
15:30:06 <krotscheck> ttx: Is it likely that a story could have multiple types?
15:30:21 <ttx> krotscheck: not the way it's proposed
15:31:41 * krotscheck is reading
15:31:44 <ttx> I'm trying to strike a balance between types that would trigger different things and types that are just refinements
15:31:59 <ttx> hence the whole inheritance thing
15:32:38 <ttx> krotscheck: originally I only had the first 3... but then jogo started distinguishing between "improvements" and "new features" for his runway thing
15:33:07 <krotscheck> So, I think that yes- this is a thing we want.
15:33:22 <ttx> so I figured we might need a subtype
15:33:26 <krotscheck> The only thing I’m pondering is whether it should be its own thing or should be a thing on top of tags.
15:33:50 <krotscheck> But that’s an implementation detail.
15:33:56 <krotscheck> ….maybe?
15:34:30 <ttx> krotscheck: i thought about using tags... but then I was struggling to see how we could build milestone pages (release notes) that would show bugsn featrues and vulnerabilities in different lists
15:35:02 <ttx> (like Launchpad milestone reports, only adding vulnerabilities as another category of released things
15:35:11 * gothicmindfood sees people fighting to be considered 'improvements' over 'new features' during k cycle development
15:35:24 <ttx> so we could have a reporting module and we would select which tags are significant...
15:35:29 <gothicmindfood> who decides whether something is a new feature or improvement?
15:36:00 <ttx> gothicmindfood: I could go with only the first 3, to avoid discussion
15:36:27 <ttx> (although I like distinguishing between a regression and a bug, they are both bugs)
15:36:44 <mordred> yah - maybe it'sa  bug with a regression tag or something
15:36:53 <gothicmindfood> ttx: maybe just that as a start? but I agree that the distinction is useful. It's just I wonder how it plays out in story creation/maintenance
15:36:59 <ttx> that's what it is right now (we tag the bugs regression)
15:37:14 <ttx> krotscheck: maybe just use the first 3, then use tags to subtype.
15:37:20 <ttx> that would work
15:37:24 <krotscheck> (Side note: Does the is_bug field in the story table make sense at all anymore? Because if not I’m going to delete it)
15:37:38 <ttx> krotscheck: that would replace it
15:37:41 <krotscheck> Cool
15:37:46 <ttx> so you could say it's not useful right now
15:37:50 <krotscheck> Hrm.
15:38:05 <ttx> I don't think anything uses is_bug right now
15:38:33 <krotscheck> So, a Vulnerability is a… special kind of bug?
15:38:43 <ttx> but at the very minimum we'll need to distinguish between feature and bug, and story types sound preferable to implementing exclusive tag groups :)
15:38:56 <gothicmindfood> it's a bug no one but special people see :)
15:39:16 <ttx> krotscheck: a vulnerability is a bug that only gets a very limited audience first (then it expands)
15:39:19 <krotscheck> Hrm.
15:39:21 <krotscheck> Hrm hrm hrm
15:39:28 <ttx> so that could be implemenetd another way, for sure
15:39:45 <ttx> Launchpad has a flag ("security")
15:39:56 <ttx> which appears at bug submission time
15:40:23 <krotscheck> mordred’s suggestion suggests that there are types, and there are separate classifiers such as ‘scheduling’, ‘priority’, and ‘security'
15:40:26 <ttx> I would rather ask the user: what do you want to file ? A public bug ? A feature plan ? Or a vulnerability report
15:41:04 <ttx> scheduling?
15:41:55 <krotscheck> ttx: Scheduling -> This is a new feature vs. this is a feature + regression.
15:42:02 <krotscheck> Maybe schduling is not the right word.
15:42:14 <krotscheck> Maybe release target.
15:42:15 <krotscheck> Hrm
15:42:44 <ttx> for targeting / scheduling we would use arbitrary task lists instead
15:42:47 <krotscheck> I think I like regression as a tag. Because that way regression can be Icehouse-2, Juno, etc, while also being known as a bug?
15:42:50 <ttx> so that anyone can have their own priorities
15:43:04 <ttx> krotscheck: i'm fine with regression being a tag
15:43:06 <krotscheck> Oh, so work target is a task thing?
15:43:10 <krotscheck> Hrm.
15:43:32 <ttx> krotscheck: well, each project / code repo might have different targets / releases
15:43:39 <krotscheck> Ok, so  ttx’s original question was whether Story Types needs to be an official spec.
15:43:42 <ttx> so it has to be task-level
15:43:45 <krotscheck> And I think nobody here disagrees with that.
15:44:03 <ttx> yeah, if it doesn't sound like a terriuble idea, I can flesh out implementation options
15:44:13 <krotscheck> It’s a pretty good idea.
15:44:21 * krotscheck thinks it’s a good idea. Anyone else?
15:44:26 <ttx> we just need to get it right :)
15:44:34 <krotscheck> ttx: The first time!
15:44:35 <krotscheck> :D
15:44:39 * gothicmindfood thinks it's a great idea
15:44:40 <ttx> always!
15:45:00 <krotscheck> Any dissenting opinions? If not we’ll give ttx free reign to go speccing.
15:45:08 <ttx> yeah speccing
15:45:34 <krotscheck> Okidokey, let’s do it!
15:45:42 <krotscheck> Any other open discussion topics?
15:46:23 <krotscheck> Oh, one quick thing from me. I want to (eventually) make our deferred processing engine our plugin system.
15:47:16 <krotscheck> The approach is: API event happens, message goes into queue, worker picks up message, checks for plugins via stevedore, hands message to plugins, exits.
15:48:32 <krotscheck> There’s no question there though, It’s still a fuzzy thing in my head.
15:48:57 <krotscheck> If there’s nothing else I’ll end the meeting early so those of us at GMT -8 can get more coffee :)
15:49:27 <krotscheck> Going once....
15:49:41 <krotscheck> Going twice….
15:49:58 <krotscheck> #endmeeting