17:01:08 #startmeeting Designate 17:01:08 Meeting started Wed May 11 17:01:08 2016 UTC and is due to finish in 60 minutes. The chair is mugsie. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:11 The meeting name has been set to 'designate' 17:01:16 #topic Roll Call 17:01:23 so - whos here? 17:01:24 o/ 17:01:33 o/ 17:01:58 o/ 17:02:25 will we wait, or is there a Joe meeting happening? 17:02:35 no meeting this week! 17:02:50 Kiall is afk today - something about power surges and some switches and a router 17:03:09 #topic Announcements 17:03:24 I sent my summit recap to the list 17:03:38 if you think I missed anything please reply and update it 17:03:43 it is also here - http://graham.hayes.ie/posts/designate-newton-design-summit/ 17:04:07 The stable/(mitaka|liberty) gates are currently blocked 17:04:33 waiting for requirements cores to +A https://review.openstack.org/#/q/Ib3849cd5c0f4908c0b19787ed84891d7a49f63e1,n,z 17:04:49 any other anouncements? 17:05:35 OK then 17:05:39 #topic Bug Triage (timsim - recurring) 17:05:53 https://bugs.launchpad.net/designate/+bug/1578199 17:05:55 Launchpad bug 1578199 in Designate "Designate cannot listen for notifications in different RabbitMQ vhosts" [Undecided,New] 17:06:03 sink :| 17:06:30 Is that something you could change in a handler, or would it require a sink change? 17:07:19 it requires a olso messaging change afaik 17:07:30 but at the very least it is a sink change 17:07:50 Sounds like a won't fix, or a feature request 17:08:02 feature request 17:08:16 I'll tell them to file a blueprint? 17:08:47 yeah 17:08:56 https://bugs.launchpad.net/designate/+bug/1580014 17:08:57 Launchpad bug 1580014 in Designate "zone_name attribute is not set in Response body of REST API call for creation of zone transfer request." [Undecided,New] 17:09:35 it is an issue 17:09:41 m, n1 17:09:49 k 17:09:52 That's it 17:10:23 cool 17:10:41 I am going to push stable back port, as we have broken gates right now 17:10:56 #action mugsie do stable backport for 4 weeks 17:11:09 #topic Open Discussion 17:11:37 anyone have any thoughts, ideas, dreams? or just any topics to talk about? 17:12:04 there is talk in #openstack-dev about Golang right now as a heads up 17:12:08 nice job driving the golang conversation forward! 17:12:48 well, apparently I have not been doing a good enough job 17:12:55 I'm working on a reply to that ML post about speeding up the python bits 17:13:05 so, will need to instrment some code and show where and why 17:13:26 and, sure isn't youtube writen in python? 17:14:10 Don't you wan to spend your months optimizing your python code to death when you could just write naive code that was just as fast? 17:14:20 yeah 17:14:24 * timsim jumps off a bridge 17:14:40 we do need to articulate that the cost to the community is worth it technically 17:14:53 have you considered thinking harder about the problem or using a profiler? ;-) 17:15:05 notmyname: :) 17:15:31 I'll address that in an upcoming post 17:15:31 But 17:15:37 I honestly thing the bottleneck is the dns.record.from_text().to_wire() 17:15:42 There are certainly areas that you could make the current code 4-5 times faster 17:15:46 but I need to find a way to prove that 17:15:49 timsim: 100% 17:16:12 but I think having something that is 10-50x faster out of the gate is better 17:16:23 But without significant effort, adding a cache (that will be almost constantly invalid), you still won't get even close to the naive go version 17:16:33 we may need to run them in parallel for a while (python + go_ 17:16:43 the deprecation we talked about might need to change 17:16:58 we can invalidate the cache from central / pm 17:17:25 but i think that most cache entries will get used a lot less that assumed in that thread 17:17:31 I'm like 80% to the point of just letting there be a python one, and if you actually want to use the damn thing in production, go use the Go one. 17:18:07 But I'll do my best to articulate the problem for the community from my point of view 17:18:08 but we will not be able to host it in openstack, and block changes to designate that break it unless this policy change 17:18:11 +s 17:18:51 * timsim shrugs. 17:18:56 how much of a concern is it that you'd have changes to designate that woudl break it though? knowing the team's intent on supporting the golang implementation 17:21:38 I guess we can think on it 17:21:51 If this mailing list thread keeps careening toward death 17:21:56 :) 17:22:04 Or maybe we can just think harder 17:22:06 ffs 17:22:08 We done? 17:22:28 timsim: please don't do that (make some golang better implementation that is external and the toy py one part of the community). nobody will win 17:22:52 timsim: the ML thread isn't careenign towards death (yet) 17:23:02 notmyname: But I can't have the Go one either right? 17:23:32 in my experience, this is the natural course of things in openstack. it happened 5+ years ago. it will still happen next year 17:23:59 What's "this"? 17:24:02 IMO this whole debate is about finding and solving (or getting a path to solve) the cross-project and -infra issues for using golang 17:24:03 Bringing up new languages? 17:24:16 just how we decide to do things 17:24:19 "this" being silly ML threads that seem to go on for ages ;-) 17:24:20 it does look dark for a while 17:25:09 Dope, well in the meantime, while I've got a product to ship, I can just iterate on the eventual solution inside my company's walls :D 17:26:13 somoen wise once told me (when I was frustrated about a different ML thread a years ago): "you know, so many of these problems go away when you have to worry about prod" 17:26:20 sory, been distracted by -dev 17:26:30 OK, any other topics? 17:27:11 goign once 17:27:15 twice 17:27:19 and - done 17:27:22 #endmeeting