17:00:11 <timsim> #startmeeting designate 17:00:12 <openstack> Meeting started Wed Apr 12 17:00:11 2017 UTC and is due to finish in 60 minutes. The chair is timsim. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:16 <openstack> The meeting name has been set to 'designate' 17:00:18 <timsim> #topic Roll Call 17:00:44 <trungnv> o/ 17:00:51 <timsim> ping mugsie kiall_ sonuk 17:01:00 <timsim> I'll give folks a minute 17:01:07 <mugsie> o/ 17:02:35 <timsim> #topic Bug Triage 17:02:42 <timsim> I don't see any new ones, am I wrong? 17:02:55 <mugsie> nope 17:02:58 <sonuk_> \o 17:03:00 <timsim> There's a couple that need a bit of looking into 17:03:04 <mugsie> yeah 17:03:08 <timsim> But ya know. action 17:03:12 <mugsie> I wont have time until monday :/ 17:03:23 <timsim> Don't know if I'll ever have time :x 17:03:52 <timsim> #topic Stable Backport Triage 17:03:54 <timsim> nope 17:04:12 <timsim> #topic Open Discussion 17:04:19 <trungnv> Please review my detail specs before. this is my BP which attached my detail specs: https://blueprints.launchpad.net/designate/+spec/designate-rolling-upgrade 17:04:28 <timsim> I took a look at that trungnv 17:04:35 <trungnv> I had also Added assert "assert:supports-accessible-upgrade" tag for Designate before "assert:supports-rolling-upgrade" tag. 17:04:44 <timsim> There is a _lot_ of work in there. 17:04:52 <trungnv> yes. I know 17:04:59 <timsim> Like a full cycle for one of the designate cores. 17:05:00 <mugsie> the problem with accessible upgrade is there is no way to test it currently 17:05:05 <trungnv> we have 4 persons to work at the moment 17:05:17 <timsim> On Designate alone? 17:05:19 <mugsie> and - microversions are not needed for rolling upgrade 17:05:41 <mugsie> and, OVO - there is no way to use them in designate 17:06:01 <mugsie> we have so much custom logic, and systems build around them that we would need a brand new API 17:06:15 <trungnv> we will change object into O.VO format then using it. 17:06:34 <mugsie> you cant 17:06:46 <mugsie> OVO do things completely differently 17:07:02 <mugsie> we rely on the way we do validations for the API errors 17:07:18 <mugsie> OVO does validation completely differently (and worse) 17:07:30 <timsim> So the API contract will be broken, which is a non-starter. 17:08:04 <timsim> trungnv: I want to ask again, because it's important. Why, of all of the possiblities, do you want to work on "rolling upgrade"? 17:08:16 <timsim> The upgrade story for Designate is not that complicated. It's not like nova 17:08:30 <timsim> If you have four people to do work, there are other things that would be much more valuable. 17:08:41 <trungnv> yes. we want. 17:08:50 <trungnv> because: My actual reason to implement rolling-upgrade that is Fujitsu had used Designate in Cloud K5 system and we are concerning upgrade for Designate in our system. this is 1 requirement very importance for us. thus we really need to rolling-upgrade for our system. 17:09:11 <mugsie> you cannot have any API down time? 17:09:17 <trungnv> my company is Fujitsu then we need rolling upgrade for Designate 17:09:41 <trungnv> yes. 17:09:46 <timsim> Why? 17:09:47 <trungnv> mugsie: Yes 17:10:58 <mugsie> why can you not have downtime? 17:11:15 <trungnv> We need any requests to queried and or created without downtime. 17:11:34 <mugsie> well, queried, the DNS servers are separate 17:11:43 <timsim> Yes, the DNS servers have 0 down time 17:11:56 <mugsie> but why can you not have creation downtime? 17:12:32 <trungnv> Cloud K5 of us really need to process any request without downtime and or get minimal downtime. 17:12:58 <mugsie> we can do minimal down time 17:13:03 <mugsie> already 17:13:28 <mugsie> shutdown services, migrate DB, start new code base 17:13:29 <trungnv> last time I know that Designate got 80% 17:13:38 <mugsie> this should only take a few mins 17:13:50 <trungnv> But we need get about 100%. 17:14:33 <trungnv> we have 4 persons to complete this feature. 17:14:59 <trungnv> we hope this feature will complete in next cycle. 17:15:10 <mugsie> OK. you need to do more research - you need to find a way to do object versioning with out oslo vertsioned objects 17:15:24 <mugsie> and there is no chance that this will be completeed in a cycle 17:15:34 <timsim> Agreed. 17:15:43 <mugsie> there is far too much work, and it has the potentinial to break the entire system 17:15:59 <mugsie> this needs to be a slow, incremental improvement 17:16:40 <trungnv> I know. But our system really need this feature thereforce we will working hard to complete this. 17:16:53 <mugsie> OK. 17:17:01 <mugsie> there is a big problem for this 17:17:01 <trungnv> please believe us 17:17:05 <mugsie> we have 0 cores 17:17:23 <mugsie> and for this work you will need *very* exipirenced cores 17:18:08 <mugsie> this is a very big feature, and the code will need *very* careful review 17:18:23 <trungnv> we will always discuss our solution on IRC to cores get more information then 17:18:41 <trungnv> yes. we will 17:19:10 <trungnv> we will review be carefull before pushing 17:19:32 <mugsie> we do not have enough cores to review the code is the problem 17:19:45 <mugsie> you cannot push any code, it has to be reviewed 17:20:08 <trungnv> I understand. 17:20:59 <mugsie> I would suggest you spend more time working on the project before taking such a big feature 17:21:54 <trungnv> yes. I will working on both. 17:21:59 <timsim> trungnv: mugsie and I do not think what you are proposing is possible. If you would like to try, we can't stop you. But be aware of what will happen: 17:22:13 <timsim> 1. It is going to take us a very long time (months) to review the code that you propose. 17:22:36 <timsim> 2. We are going to be very harsh in that review process, it will be very very difficult for you to get this code merged. 17:22:44 <timsim> 3. It is going to take longer than one cycle. 17:23:08 <trungnv> 1. I understand. Please approve with low priority. 17:23:26 <timsim> 4. We will not be available to help you at all hours of the day on IRC. Most days, we will not answer at all. 17:23:38 <trungnv> 2. I understand your situation. 17:23:42 <mugsie> I will add some comments to the spec 17:24:51 <trungnv> 3. I hope my codes will complete in next cycle and merged in the next couple cycles. 17:24:59 <trungnv> 4. I know. 17:25:05 <trungnv> mugsie: thanks 17:27:09 <timsim> Alright, let's circle back on this again next week and see how it's going. 17:27:12 <mugsie> ++ 17:27:23 <timsim> Answering mugsie 's comments well will take a lot of research. 17:27:36 <timsim> Prototyping, etc. 17:27:42 <trungnv> yes 17:27:58 <timsim> Does anyone else have anything they'd like to discuss? 17:28:13 <mugsie> I will say the designate object adaptor code is ... hard 17:28:22 <mugsie> I wrote it, and it still hurts my brain 17:28:44 <timsim> mugsie and I still need to work on fixing the gates. 17:28:47 <mugsie> and it is unfortunatly the key to keeping the API right 17:28:49 <mugsie> yeah 17:29:01 <timsim> Seems like step one is fixing/deleting those nsd tests that randomly fail now 17:29:09 <timsim> Then merging that sqla patch 17:29:10 <trungnv> yeah. my specs bug still -1 with gate issue. 17:29:11 <mugsie> I will not have time till monday - I fly out early on Friday, and get back Sund 17:29:15 <mugsie> ay* 17:29:29 <timsim> I might have time some evening this week to poke at it. I'll try, no promises. 17:30:42 <timsim> Alright, anything else? 17:31:25 <trungnv> No. I am looking your comments in my specs to get approval for my BP. 17:31:37 <sonuk_> timsim : can we set acl over tenant network to secure network traffic 17:32:06 <timsim> uhhhh 17:33:05 <timsim> mugsie: ^ 17:33:10 * timsim doesn't really know what that means 17:33:32 <mugsie> sonuk_: we do not do anything with that 17:33:48 <mugsie> thats your network team's job 17:34:37 <sonuk_> I think I will have to check some options in neutron 17:35:05 <mugsie> yeah - we do not have any interactions with tenant networks 17:35:10 <timsim> Alright, anything else? 17:35:33 <mugsie> I got to drop, I am late for dinner :) 17:36:14 <timsim> Alright, I think we're done. See you all next week 17:36:16 <timsim> #endmeeting