15:00:19 <krotscheck> #startmeeting Storyboard
15:00:19 <openstack> Meeting started Mon Sep 15 15:00:19 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:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:22 <openstack> The meeting name has been set to 'storyboard'
15:00:28 <krotscheck> Agenda: https://wiki.openstack.org/wiki/StoryBoard#Agenda
15:00:33 <krotscheck> Who’s here?
15:02:52 * krotscheck patiently waits for the echo chamber to not be an echo chamber.
15:03:19 * fungi is merely lurking
15:04:09 * krotscheck comes after the lurkers with a broom.
15:04:31 <krotscheck> Did I miss a timezone change or an hour shift or something?
15:04:40 <jeblair> ...
15:04:55 <krotscheck> Woo, there’s a jeblair
15:05:02 <krotscheck> Is there a ttx?
15:05:08 <jeblair> or a mordred?
15:05:14 <krotscheck> Or a NikitaKonovalov?
15:05:15 <ttx> yes
15:05:17 <ttx> o/
15:05:25 <ttx> sorry, having parallel discussions
15:05:27 <krotscheck> Great!
15:05:35 <krotscheck> #topic Urgent Items: RabbitMQ
15:06:08 <krotscheck> So from what I gathered, when the publisher merged we started to see consistent failed connections in the storyboard logs, yes?
15:06:26 <krotscheck> jeblair put up a patch to turn that off in the puppet module.
15:06:27 <jeblair> yeah, after a time
15:06:39 <krotscheck> At least, to turn off publishing.
15:06:54 <jeblair> (eg, works for some period of time, then all connections after that time failed)
15:07:07 <krotscheck> Part of the issue is that there was no robust reconnection logic in the message abstraction.
15:07:23 <krotscheck> There might be another issue, but that’s the big one.
15:08:01 <krotscheck> I’ve made some modifications to the connection handling that should address some of that, but it needs lots of eyeballs: https://review.openstack.org/#/c/119266/
15:08:27 <jeblair> i will be happy to review that; i think i can fit it in today
15:08:32 <krotscheck> Awesome
15:08:53 <krotscheck> Thanks jeblair. fungi, think you can dip your toe into StoryBoard country a bit today as well?
15:09:06 <fungi> sure
15:09:10 <krotscheck> Thanks :)
15:09:18 <jeblair> krotscheck: i note in the commit msg, you mention we can lose the connections after a rabbit restart...
15:09:28 <krotscheck> jeblair: Yeah - and rabbit is fail-fast
15:09:48 <jeblair> krotscheck: timeouts are another possibility yeah?
15:09:53 <krotscheck> jeblair: Yep
15:09:58 <jeblair> i mean, rabbit dropping due to idle timeouts
15:10:07 <jeblair> (which is probably what was actually happening?)
15:10:45 <krotscheck> jeblair: More likely, I think. I think we didn’t see that because in config on dev boxes we just set an infinite timeout, but that’s not a legitimate solution in a prod environment.
15:11:03 <krotscheck> jeblair: That, and we kept restarting the API server and tehrefore the connection
15:11:12 <jeblair> should we set a really long timeout in prod?
15:11:29 <krotscheck> jeblair: I don’t think that’ll be necessary after this patch?
15:11:38 <jeblair> k
15:11:57 <krotscheck> Any other thoughts on Rabbit before we talk Launchpad migration?
15:12:33 <krotscheck> #topic Urgent: Launchpad Migration
15:13:04 <krotscheck> mordred dropped a nice utility that does migration by project, without actually adding a way to invoke it.
15:13:43 <krotscheck> I’ve got a branch that I’m working on to fix and refine that a bit, however my efforts were partly hampered by very happy post-op painkillers.
15:14:27 <krotscheck> I want to get a quick feel for how “storyboard-import ‘projectname’” feels?
15:14:35 <krotscheck> (As a CLI)
15:15:03 <jeblair> krotscheck: you improved mordred's drunk coding with narcotic coding? ;)
15:15:22 <krotscheck> jeblair: Yes! I added rainbows.
15:15:34 <fungi> meh, sounds like a cli. i don't think a one-parameter command line invocation deserves a lot of bikeshedding
15:15:57 <krotscheck> I did run into a de-duplication issue on migration failure, the first step to address is this: https://review.openstack.org/#/c/121201/
15:16:14 <krotscheck> I’m a bit cagey about adding a full REST origin path into the database though.
15:16:31 <jeblair> seems good to me.  might we end up with different names on both sides though?
15:16:37 <fungi> also, the chances that we'll use it much past the transition from lp to sb is pretty remote (though i suppose it could come up from time to time if openstack adds a new project which already had a life in lp with existing bugs)
15:17:07 <krotscheck> jeblair: Hrm- good point.
15:17:12 <jeblair> well, for one, storyboard names are 'openstack/foo' rather than just 'foo' on lp; so they will all be at least a little different
15:17:13 <fungi> and yeah, i suppose being able to rename the project on import would be useful
15:17:29 <jeblair> so may as well just specify both old and new, i think
15:17:32 * krotscheck makes a mental note to do rename-on-import
15:18:06 <fungi> though we probably need to make sure the renaming-a-project-alread-in-storyboard scenario is well addressed regardless
15:18:06 <krotscheck> What about de-duping?
15:18:34 <krotscheck> fungi: That’s my test case, which is where the de-duplication issue started to come up :)
15:18:49 <jeblair> krotscheck: elaborate on de-duping?
15:18:59 * krotscheck wonders if the renaming thing can be a convenient way to say: Hey, ship all of bugs from project X into project Y.
15:19:41 <jeblair> oh.  i'm not immediately forseeing a need for that; i was mostly on about just differences in names in the 2 systems
15:19:54 <krotscheck> de-duping: So, the case I ran into was - 1- kick off an import, 2- have it fail because of +janitor not having an openid (other reasons possible), 3- Restarting the import, 4- Getting lots of duplicates.
15:20:09 <jeblair> krotscheck: oh gotcha
15:20:24 <jeblair> krotscheck: perhaps a related issue is bugs that affect multiple lp projects?
15:20:58 <jeblair> krotscheck: so if you import a bunch of foo bugs, and then a bunch of bar bugs, it would be nice if the bugs that affected both foo and bar ended up as on story with multiple tasks, rather than 2 stories
15:21:03 <fungi> right, given those different projects could be imported at different times
15:22:24 <jeblair> a legitimate solution would be to import the full set of projects at once, but i think it would be better to support the one-at-a-time mechanism (just so it's easier for us to actually run and test and fix problems etc), but with good deduping for both of these cases
15:23:33 <mordred> (maybe want to store their external id somewhere for this?)
15:24:03 <jeblair> mordred: the output of the tool is sql, right?
15:24:20 * krotscheck had to switch to phone tethering, just a sec while I catch up
15:24:30 <jeblair> mordred: so we don't actually know the state of the db when running it;  that makes it a bit hard, yeah?
15:24:56 <mordred> jeblair: the tool actually makes sqlalchemy calls
15:25:00 <jeblair> oh ok
15:25:14 <jeblair> then deduping should be possible
15:25:18 <mordred> jeblair: I had an "export some json so we could see what's going on" thing in there ... but it's not a needed step
15:25:32 <jeblair> we could probably store the ids in a local file then, so we don't have to dirty up the db schema
15:25:45 <krotscheck> My modification uses this fancy python generator thing taht turns launchpad into an interable.
15:26:27 * krotscheck doesn’t mind using a temporary import cache.
15:26:47 <krotscheck> I do like the idea of having some way of linking a task to something upstream-ish, but maybe that’s a different feature altogether.
15:27:42 <jeblair> i like that as part of lp's links to external bug trackers feature; however, that's hard and i think not to be undertaken lightly (it's really disappointing when it does not work).  and i don't think we need to maintain the import link once it's complete
15:27:49 <jeblair> (we all want to stop using lp completely)
15:29:09 <krotscheck> jeblair: Do you think the launchpad import would be an entirely manual step, i.e. a human would do it?
15:29:18 <fungi> agreed. at most we might like to be able to link to lp bugs for non-openstack projects from time to time (or bitbucket, or github, or...) but it doesn't seem like a required feature and certainly not one we'd want to use to link to external copies of our own bugs
15:29:41 <jeblair> krotscheck: yes i think so
15:29:58 <krotscheck> jeblair: Ok, then making it headless is not a priority. Good.
15:30:44 <jeblair> yeah, i think the import process is going to be exceptional, and we can have all hands on deck doing manual things as needed to help it along
15:30:50 <krotscheck> Alright, I’ll drop the schema change patch then :)
15:31:27 <krotscheck> And we’ll keep the cache in the filesystem.
15:31:40 <mordred> ++
15:32:00 <krotscheck> Cool. I’ll keep working on that today and will hopefully have something by the time I’m in SF, maybe beforehand.
15:32:34 <fungi> having "a way to do it whose steps are sufficiently documented for a root admin to follow" is good enough i think
15:32:50 <krotscheck> #topic Discussion: People keep using launchpad after we’ve moved a project to storyboard.
15:33:16 <jeblair> so i think we can turn off bug trackers in lp projects
15:33:43 <krotscheck> jeblair: Is that a ‘click a button in launchpad’ thing or a ‘make a patch to /config’ thing?
15:34:04 <jeblair> krotscheck: click in lp
15:34:09 <fungi> you disable bugs in the lp project, preferably also adding some visible link in lp to the new bug tracker
15:34:26 <krotscheck> Ok, so we’ll have to add that to the migration documentation.
15:34:58 * krotscheck feels like that’ll be a patch on top of https://review.openstack.org/#/c/108460/
15:36:03 <jeblair> we have a team that owns all the projects in lp, and so we can make this change for at least infra/openstack
15:36:44 <jeblair> i'm not sure what our answer will be if a stackforge project wants imports.  maybe we batch them up and do them every few weeks for a while, but eventually we should have a cutoff.
15:37:37 <krotscheck> jeblair: Well, we batch renames, don’t we?
15:37:41 <fungi> and after that they can copy/paste their old bugs into sb if they want them
15:37:41 <jeblair> yup
15:37:55 <jeblair> and yup
15:38:05 <krotscheck> Seems both sane and not-overwhelming.
15:38:47 <fungi> we're all already overwhelmed. the question is just how much more overwhelming
15:40:02 <krotscheck> Well, migrations are going to be a one time thing. Batching things up even to the point of saying: Hey, you can have this done At the mid-cycle or at the summit, anyything else is special-case
15:41:30 <fungi> sure
15:42:24 <krotscheck> That seems like we have reasonable consensus there, and turning things off in launchpad is also a thing. Let’ smove on
15:42:50 <krotscheck> #topic MVP1.1 Search
15:43:04 <krotscheck> I think search is at the point of “hey let’s treat everything form here on as a bug"
15:44:19 <krotscheck> I’m going to skip over subscription and project gorups, because we’ve talked about both of those.
15:44:25 <krotscheck> Sorry
15:44:29 <krotscheck> Subscriptions and data import
15:44:36 <krotscheck> #topic MVP1.1 Project Groups
15:45:27 <krotscheck> There seems to be a discussion related to, but orthogonal to, project groups that -infra needs to have regarding naming conventions of project groups?
15:45:40 <krotscheck> anetaya kicked it off here: https://review.openstack.org/#/c/111815/
15:47:35 <jeblair> krotscheck: those will be easy to change later?
15:47:58 <jeblair> krotscheck: because, yeah, i think the original classifications may have bitrotted a bit
15:48:16 <krotscheck> jeblair: It should be. I’m expecting that the project-group management is going to be handled via review.projects.yaml
15:48:38 <jeblair> so as long as we can come back and clean it up later (eg, move stuff in/out of oslo), i think we can proceed with the mechanical syntax change for now
15:49:13 <krotscheck> At this time, project groups are _only_ an artifact of StoryBoard.
15:49:35 <krotscheck> So yeah, we’ll be able to clean it up later.
15:50:17 <ttx> yes, but they are awesome!
15:50:18 <krotscheck> jeblair: I’ll bring the topic up in -infra later so anetaya can weigh in and it’s not a weird-back-meeting-decision thing.
15:50:38 <fungi> hrm... i'm not sure we can claim they're only an artifact of sb
15:50:49 * krotscheck doesn’t like ‘oh-you-weren’t-there’ decisions.
15:50:50 <krotscheck> fungi: Oh?
15:51:06 <fungi> we implemented that tracking in jeepyb specifically to deal with multiple-gerrit-projects -> one-lp-project mapping
15:51:21 <fungi> we called it "groups" because we planned to need to relate it to sb as well
15:51:24 <jeblair> oh that's right
15:51:37 <jeblair> i forgot about that (because we called it groups instead of what we used to call it to indicate it was for lp)
15:51:46 <fungi> 'zactly
15:52:07 <krotscheck> ….hrm. I think that makes it more complicated.
15:52:09 <jeblair> so we should probably, and this is slightly insane, leave 'group' as is
15:52:20 <jeblair> and then just start adding 'groups' for storyboard
15:52:22 <krotscheck> …..
15:52:27 <fungi> heh
15:52:29 <krotscheck> urm.
15:52:33 <jeblair> and if we have a spare moment, change 'group' back to mean 'launchpad mapping'
15:52:33 <krotscheck> slightly
15:52:34 * fungi buries his face in his hands
15:52:42 <jeblair> or
15:52:48 <jeblair> we can update jeepyb to also understand groups
15:52:54 <jeblair> and make the switch to groups
15:53:03 <jeblair> but then we'll need to think carefully about any changes there
15:53:11 <fungi> i think maybe we make them synonyms, and have jeepyb assume sb-only of the list is longer than one?
15:53:12 <krotscheck> jeblair: You mean like this? https://review.openstack.org/#/c/111814/
15:53:16 <jeblair> (eg, is this both what we want in storyboard and will it still do what we want in lp)
15:53:39 <fungi> ahh, yeah, do we want to split up projects in sb which are members of a group in lp... gotcha
15:53:55 <fungi> though... for imports that's still a problem
15:54:30 <fungi> because there's no way to map bugs from an lp group to separate sb projects on import, except somewhat arbitrarily-tracked tags
15:55:06 <jeblair> krotscheck: yep, that's what i meant.  ;)
15:55:20 <jeblair> okay, so we can do the mechanical translation once that merges...
15:55:42 <jeblair> but we will need to keep in mind the lp functionality while we're still using lp
15:55:52 <jeblair> and then we are free to change groups around after the import
15:55:56 <fungi> i feel like supporting a divergence from lp grouping to sb grouping during import is probably not worth the effort either
15:55:57 <jeblair> (eg, openstack-ci -> infra)
15:56:41 <krotscheck> Ok, I’m going to add this topic to the infra agenda, because it feels like a broader discussion.
15:56:56 <krotscheck> ....
15:57:14 * krotscheck feels like he just escalated something. Which feels corporate-ish.
15:58:04 <krotscheck> #topic Ongoing Work
15:58:22 <krotscheck> Y’all know what I’m working on. NikitaKonovalov is currently still assigned to Sahara at the Mirantis side of things.
15:58:42 <krotscheck> Ish__ is back at school, so at the moment it’s all me.
15:58:51 <krotscheck> #topic Open Discussion
15:58:57 <krotscheck> We’ve got 2 minutes! Discuss things!
15:59:42 <krotscheck> Allllright, let’s call it then.
15:59:46 <krotscheck> Thanks everyone
15:59:50 <jeblair> krotscheck: do you have any specs that need attention?
15:59:58 <krotscheck> jeblair: Nope. Too much leftover work.
16:00:02 <jeblair> kk
16:00:19 <krotscheck> jeblair: I need to spend a lot of time actually finishing things :)
16:00:26 <jeblair> i know the feeling :)
16:00:34 <krotscheck> Without narcotics :D
16:00:41 <krotscheck> jeblair: You going to be at OpenStack SV?
16:00:47 <jeblair> nope
16:00:58 <openstack> rakhmerov: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
16:00:59 <krotscheck> kk, then I’ll miss you this SF trip.
16:01:03 <krotscheck> #endmeeting