15:00:08 #startmeeting StoryBoard 15:00:09 Meeting started Mon Aug 11 15:00:08 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:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:12 The meeting name has been set to 'storyboard' 15:00:23 Agenda! https://wiki.openstack.org/wiki/StoryBoard#Agenda 15:00:47 ohai 15:01:04 ttx can haz cheezburger 15:01:25 #topic Urgent Items (Rabbit) 15:01:27 * ttx wonders why the recent review approvals did not trigger a merge avalanche yet 15:01:33 o/ 15:01:35 ttx: zuul is borked 15:01:35 * ttx queries gerrit for info 15:01:39 krotscheck: ah! 15:02:31 So, the initial puppet patch landed on friday, but it brought up the “Why are our config files getting confused” issue again. 15:02:45 That resulted in this patch: https://review.openstack.org/#/c/113013/ 15:02:58 Which precedes this one (the actual one with rabbit in it) https://review.openstack.org/#/c/98474/ 15:03:20 And, for fun and profit, there’s also this one, but it’s less urgent: https://review.openstack.org/#/c/112998/ 15:03:44 Either way, getting clarkb/mordred/jeblair/other infra people to look at it this week would be neat. 15:04:08 #topic Discussion Topics (Subscription) 15:04:35 The question here is oslo.messaging vs. pika 15:04:36 I just wanted to know advantages of using Pika instaead of oslo 15:05:22 Well, pika is the one used in most of the rabbit tutorials, while oslo.messaging is the one that openstack built for itself. 15:05:23 isn't oslo.messaging using pika as backend? 15:05:29 ttx, I believe it is. 15:05:56 ttx: There’s an abstraction layer there though that also allows other backends to get plugged in. 15:06:22 right, like qpid 15:06:25 Right 15:06:49 So, there isn’t so much an _advantage_ of using pika, as there is a disadvantage to using oslo.messaging 15:07:13 Ish__ discovered as she was working on it, that creating a new notifier created both an exchange _and_ a queue. 15:07:20 A persistent queue. 15:07:46 what's wrong with that? 15:07:48 Which, if you’re really only looking for a single consumption queue and you care about data retention makes some sense. 15:08:09 Well, let’s walk through what would happen. 15:08:21 I want to broadcast a message with topic project, and one with project_group 15:08:33 So I have to create two notifiers, because topics are locked by notifiers. 15:08:47 Sorry - I mean that a topic is passed to a notifier at creation. 15:09:04 So then the notifier creates one exchange, and two queues, one for project_groups and one for projects. 15:09:12 Except my consumer wants to get _both_ 15:09:40 My consumer then attaches itself and… does what? Consumes from two different queues? Or creates a new queue with a binding of *. 15:09:45 krotscheck: so pika exposes more features than oslo.msg, including one you would like to use 15:09:58 ok, I see 15:10:01 Well, it’s more that pika allows us to be more granular and specific. 15:10:43 to be fair, oslo.msg's goal was to streamline queue communication across openstack projects, so limiting options is a bit in its goals 15:10:53 I'm fine with storyboard having a slightly different use case 15:10:54 And that totally makes sense. 15:11:24 And, especially in openstack itself, keeping all the messages in predefined queues is super important because different components of openstack have different boot times. 15:11:31 would you say that using pika would prevent us frm switching to an oslo.messaging that would expose the feature we want ? due to different semantics? 15:12:02 i.e. if our use case becomes supported in oslo.messaging, would we be able to switch to that at reasonable cost ? 15:12:13 Ish__? Is your code abstracted enough so that we can switch libraries? 15:12:17 or is picking pika (haha) a bit of a non-return point? 15:12:19 * krotscheck seems to recall that it is. 15:12:27 just to make things clear, there is going to be as many queues as we need for every topic, and a number of consumers listenening to a specific queue each? 15:12:56 I think using RabbitMQ is much more important as far as consistency/familiarity goes than using oslo.messaging 15:13:13 but I would rather not PREVENT us from using oslo.messaging in the future 15:13:14 NikitaKonovalov: That depends on each use case? For subscriptions, we should only be creating one queue that takes all topics. 15:13:20 I think it should be easier to switch. 15:13:38 and we should definitely use the library that lets us have the cake and the icing 15:13:46 Case and point: It took Ish__ less than a day to switch her code over from oslo.messaging to pika 15:13:47 we have already hardened MySQL with it's drivers, so why messaging should be generec then? 15:14:31 NikitaKonovalov: Good point 15:14:56 So ttx’s concerns are portability. Are you comfortable that we can switch over to oslo.messaging in the future? 15:15:44 if that is required, well we can. 15:16:06 krotscheck, Ish__: then as far as I'm concerned, use pika 15:16:18 Ok. NikitaKonovalov - what do you think? 15:16:37 works for me 15:16:45 I'll remove my -2 15:16:45 Alright.... 15:16:51 it's totally defensible saying we need feature X and are willing to switch back to oslo.messaging if it ever implements it 15:16:51 but still need to review that 15:17:00 but will use foo until then 15:17:09 #agreed Use pika instead of oslo.messaging, with the understanding that once oslo.messaging supports it we can move to use it again. 15:17:44 * krotscheck would rather have someone else maintain his messaging library :) 15:18:14 #topic MVP(Search) 15:18:32 I think all of these bits are in review. Anyone remember any stoppers? 15:19:03 the backend is approved 15:19:14 just waiting for the tests to pass 15:19:20 Awesome. 15:19:35 Frontend is pending a rather large review so that the resources know how to search. 15:20:32 I did run into a weird issue with the fulltext library on the backend in that it doesn’t seem to like additional criteria, but I didn’t have enough time to dig into _why_. 15:21:11 krotscheck: I'll check that all parameters are passed correctly 15:21:42 NikitaKonovalov: They are. It’s just that our search endpoints only accept q= right now, and when I tried to add story_id or something else it just ignored them. 15:22:03 that's strange, I'll chaeck taht 15:22:09 *that 15:22:09 Thanks. 15:22:12 #topic Launchpad Data Import 15:22:27 mordred? I have the sneaking suspicion you’re still driving. 15:22:46 * krotscheck wants to publicly thank mordred for making the treck all the way to seattle by car this weekend :) 15:23:44 Alright, let’s move on until he sees this. 15:23:46 #topic Subscription 15:23:54 We have LOTS of patches for this. 15:24:09 yes… 15:24:20 most patches in review are 80% approved 15:24:27 they should all go in very fast 15:24:40 There’s some cross dependencies that need to be managed. 15:24:42 if zuul is with us 15:24:49 We can’t land the publisher without rabbit for instance. 15:24:51 all hail Zuul 15:25:59 So for the time being, let’s get everything reviewed, and manually land patches so that everything lands in order. 15:26:10 I believe the order should be.... 15:26:12 let’s see. 15:26:14 Subscription API. 15:26:17 Subscription UI 15:26:19 Rabbit 15:26:28 Subscription Publisher. 15:26:32 Subscription consumer. 15:26:39 Deferred processing daemon. 15:26:54 Did I miss anything? 15:27:28 reasonable order for me 15:27:47 no.. 15:27:55 Cool. 15:28:08 Ish__: Is that “No I didn’t miss anything” or “No don’t merge it like that”? 15:28:11 I mean didn’t miss anything,. ;) 15:28:14 :) 15:28:15 Thanks 15:28:34 There’s still one outstanding piece of work, which is to make the subscriptions show up on the dashboard. 15:29:10 And I have to get that in before leaving for vacation on saturday, so the pressure’s on. 15:29:20 Any questions before we move on? 15:29:34 nope 15:29:36 #topic Project Groups 15:29:39 No progress. 15:29:54 Status is as it was a week ago. 15:29:56 nothing from me here either 15:30:15 We still have to cover Tags and Emails, but I don’t think we’ve got anything on those. 15:30:41 So unless I get objections I’m going to skip. 15:30:51 I'm back from vacation, so I'll focus on tags this week 15:30:56 Awesome, thanks. 15:31:01 #topic Ongoing Work 15:31:26 How do people feel about this meeting section? It’s… I dunno, I feel like we cover most of what everyone is working on in the previous pieces. 15:31:53 * NikitaKonovalov has the same feeling 15:32:09 sotoryboard should ultimately make it obvious 15:32:10 How about we merge this with open discussion? 15:32:14 True 15:32:34 #topic Open Discussion 15:32:41 I think that we are gettingthere, between the vision/roadmap/stories/reviews, we get a pretty accurate picture of where we stand 15:33:08 so i'm fnie with merging with open discussion 15:33:18 for highlights 15:33:37 Ok, so the only open discussion piece I have is the ongoing cleanup of the jenkins build. 15:33:39 * ttx looks up roadmap 15:34:14 The highest priority piece right now that we have that’s seeing no movement is the launchpad data import, and I can confidently say that if it doesn’t get done this week, it probably won’t land until september. 15:34:39 because both mordred and I won’t be around. 15:34:44 So at this point i'm confident we'll hit 1.1 targets before Paris, and hopefully cover 1.1.1 targets before then 15:34:58 that means we'll get infra to use us fully 15:34:59 yay :) 15:35:43 i don't think we'll have 1.2 targets, so it will be a little early to fish for guinea pig projects withing the openstack release 15:36:08 Well, we’ve already got refstack and openstack-groups. 15:36:21 We may get oslo to switch early though 15:36:30 That’d be nice. 15:36:35 since they don't have the same heavy requirements as the other integrated projects 15:36:43 and desperately need our projectgroups 15:37:04 so maybe they could move in with only basic milestone support 15:37:18 Alrightey. 15:37:23 i'll have to look into splitting that 1.2 between Oslo and other integrated projects 15:37:40 but it will be difficult imho 15:37:56 ttx: It may make the most sense to do project-support as point releases in the 1.2.x versions 15:38:10 That way we can focus instead of trying to please everyone. 15:38:28 krotscheck: right. Pick project X as the target and implement what THEy need to move 15:39:49 That’ll have to be balanced with infra coming to us with “Thanks, and” requests. 15:39:54 krotscheck: anyway, the 1.1 goals are pretty well set and ordered, so not urgent to refine the 1.2 goals 15:39:59 Exactly 15:40:11 Also, we have a bug backlog :) 15:40:18 just need to think how to optimize onboarding 15:40:55 Def something we can do during the summit? 15:41:16 krotscheck: yes, sounds like the right place for it 15:41:23 given our current progress 15:41:24 Alrightey. 15:41:33 Any other topics? 15:41:34 if we finish 1.1.1 early I'm pretty sure we'll keep ourselves busy anyway 15:41:42 Yeah, ‘cause we have backlogs 15:42:10 nothing new from me 15:42:28 Ok, let’s end early. 15:42:42 Thanks everyone 15:42:44 #endmeeting