| *** GonZo2K has joined #openstack-dns | 00:43 | |
| *** EricGonczer_ has joined #openstack-dns | 00:47 | |
| *** mwagner_lap has joined #openstack-dns | 01:12 | |
| *** Stanley00 has joined #openstack-dns | 01:19 | |
| *** GonZo2K has quit IRC | 01:38 | |
| *** stanzgy has joined #openstack-dns | 01:39 | |
| *** nosnos has joined #openstack-dns | 01:43 | |
| *** GonZo2K has joined #openstack-dns | 01:43 | |
| *** Javin has joined #openstack-dns | 01:47 | |
| *** EricGonczer_ has quit IRC | 01:48 | |
| *** Javin has quit IRC | 01:50 | |
| *** GonZo2K has quit IRC | 01:55 | |
| *** GonZo2K has joined #openstack-dns | 01:57 | |
| *** EricGonczer_ has joined #openstack-dns | 02:19 | |
| *** EricGonczer_ has quit IRC | 02:42 | |
| *** nosnos has quit IRC | 03:13 | |
| *** GonZo2K has quit IRC | 04:03 | |
| *** nosnos has joined #openstack-dns | 04:20 | |
| *** chlong has joined #openstack-dns | 04:37 | |
| *** hichtakk has joined #openstack-dns | 06:10 | |
| *** nihilifer has joined #openstack-dns | 06:26 | |
| *** hichtakk has quit IRC | 07:09 | |
| *** chlong has quit IRC | 07:47 | |
| *** hichtakk has joined #openstack-dns | 07:54 | |
| *** stanzgy has quit IRC | 07:55 | |
| *** stanzgy has joined #openstack-dns | 08:00 | |
| *** simon-AS559 has joined #openstack-dns | 08:06 | |
| *** hichtakk has quit IRC | 08:18 | |
| *** jordanP has joined #openstack-dns | 08:47 | |
| *** mikedillion has joined #openstack-dns | 08:49 | |
| *** mikedillion has quit IRC | 09:00 | |
| *** pfreund__ is now known as pfreund | 09:49 | |
| *** Stanley00 has quit IRC | 10:19 | |
| *** simon-AS559 has quit IRC | 10:20 | |
| *** ekarlso- has quit IRC | 10:24 | |
| *** ekarlso- has joined #openstack-dns | 10:24 | |
| *** chlong has joined #openstack-dns | 10:47 | |
| *** stanzgy has quit IRC | 10:51 | |
| *** simon-AS559 has joined #openstack-dns | 10:53 | |
| *** untriaged-bot has joined #openstack-dns | 11:02 | |
| untriaged-bot | Untriaged bugs so far: | 11:02 |
|---|---|---|
| untriaged-bot | https://bugs.launchpad.net/designate/+bug/1403267 | 11:02 |
| uvirtbot | Launchpad bug 1403267 in designate "create_domain should handle status asynchronously" [Undecided,New] | 11:02 |
| untriaged-bot | https://bugs.launchpad.net/designate/+bug/1404395 | 11:02 |
| uvirtbot | Launchpad bug 1404395 in designate "Pool manager attempts to periodically sync *all* zones" [Undecided,New] | 11:02 |
| untriaged-bot | https://bugs.launchpad.net/designate/+bug/1406414 | 11:02 |
| uvirtbot | Launchpad bug 1406414 in designate "Delete zone fails to propagate to all (Bind) nameservers in a pool depending on threshold_percentage" [Undecided,New] | 11:02 |
| untriaged-bot | https://bugs.launchpad.net/designate/+bug/1403591 | 11:02 |
| uvirtbot | Launchpad bug 1403591 in designate "A ZeroDivisionError is Thrown Without Servers" [Undecided,New] | 11:02 |
| untriaged-bot | https://bugs.launchpad.net/designate/+bug/1289444 | 11:02 |
| uvirtbot | Launchpad bug 1289444 in designate "Designate with postgres backend is having issues" [Undecided,New] | 11:02 |
| untriaged-bot | https://bugs.launchpad.net/designate/+bug/1404529 | 11:02 |
| uvirtbot | Launchpad bug 1404529 in designate "DynECT is called twice when any domain action happens." [Undecided,Confirmed] | 11:02 |
| *** untriaged-bot has quit IRC | 11:02 | |
| *** mugsie has joined #openstack-dns | 11:14 | |
| *** mugsie has quit IRC | 11:14 | |
| *** mugsie has joined #openstack-dns | 11:14 | |
| *** nosnos has quit IRC | 11:20 | |
| *** mugsie has quit IRC | 11:36 | |
| *** chlong has quit IRC | 11:36 | |
| *** arn has quit IRC | 11:36 | |
| *** mugsie has joined #openstack-dns | 11:36 | |
| *** arn has joined #openstack-dns | 11:37 | |
| *** chlong has joined #openstack-dns | 11:52 | |
| *** GonZo2K has joined #openstack-dns | 11:55 | |
| *** mwagner_lap has quit IRC | 12:22 | |
| *** GonZo2K has quit IRC | 12:50 | |
| *** ryanpetrello has joined #openstack-dns | 12:56 | |
| *** simon-AS5591 has joined #openstack-dns | 13:00 | |
| *** eandersson has joined #openstack-dns | 13:01 | |
| *** simon-AS5592 has joined #openstack-dns | 13:02 | |
| *** simon-AS559 has quit IRC | 13:02 | |
| *** mwagner_lap has joined #openstack-dns | 13:03 | |
| *** simon-AS5591 has quit IRC | 13:04 | |
| *** betsy has joined #openstack-dns | 13:12 | |
| *** betsy has quit IRC | 13:13 | |
| *** GonZo2K has joined #openstack-dns | 13:18 | |
| eandersson | Kiall: Morning :D So testing pymysql now, and it seems to work if you only have one worker. | 14:01 |
| eandersson | with 2014.2 | 14:01 |
| eandersson | That is probably why it worked for you, but not for me. | 14:02 |
| *** mwagner_lap has quit IRC | 14:04 | |
| *** mwagner_lap has joined #openstack-dns | 14:05 | |
| *** GonZo2K has quit IRC | 14:06 | |
| *** nihilifer has quit IRC | 14:13 | |
| *** betsy has joined #openstack-dns | 14:26 | |
| *** mikedillion has joined #openstack-dns | 14:36 | |
| *** nkinder has joined #openstack-dns | 14:47 | |
| *** GonZo2K has joined #openstack-dns | 14:54 | |
| *** GonZo2K has quit IRC | 14:56 | |
| *** timsim has joined #openstack-dns | 14:58 | |
| *** EricGonczer_ has joined #openstack-dns | 14:58 | |
| *** vinod has joined #openstack-dns | 14:59 | |
| *** paul_glass has joined #openstack-dns | 14:59 | |
| *** GonZo2K has joined #openstack-dns | 15:02 | |
| *** openstack has joined #openstack-dns | 15:05 | |
| *** ChanServ sets mode: +v openstack | 15:05 | |
| *** artom has joined #openstack-dns | 15:18 | |
| *** artom has quit IRC | 15:26 | |
| * timsim wonders if everyone is back today | 15:40 | |
| mugsie | timsim: o/ | 15:44 |
| *** paul_glass has quit IRC | 15:44 | |
| timsim | mugsie o/ Nice holiday? | 15:45 |
| mugsie | timsim: yup | 15:47 |
| mugsie | did nothing - didnt even boot the work laptop once | 15:47 |
| timsim | Doing nothing is literally my favorite thing to do. | 15:48 |
| mugsie | yeah, I certainly got my moneys worth from netflix this christmas :) | 15:49 |
| *** paul_glass has joined #openstack-dns | 15:52 | |
| *** ryanpetrello_ has joined #openstack-dns | 15:54 | |
| *** ryanpetrello has quit IRC | 15:57 | |
| *** ryanpetrello_ is now known as ryanpetrello | 15:57 | |
| *** openstackgerrit has quit IRC | 16:06 | |
| *** openstackgerrit has joined #openstack-dns | 16:07 | |
| *** ChanServ sets mode: +v openstackgerrit | 16:07 | |
| *** vinod has quit IRC | 16:25 | |
| *** vinod has joined #openstack-dns | 16:25 | |
| *** paul_glass has quit IRC | 16:35 | |
| *** eandersson has quit IRC | 16:35 | |
| *** richm1 has joined #openstack-dns | 16:38 | |
| *** paul_glass has joined #openstack-dns | 16:39 | |
| *** richm1 is now known as richm | 16:39 | |
| *** paul_glass1 has joined #openstack-dns | 16:39 | |
| *** rjrjr has joined #openstack-dns | 16:42 | |
| *** paul_glass has quit IRC | 16:43 | |
| rjrjr | are we meeting today? | 16:46 |
| timsim | rjrjr: I think it's wednesday | 16:46 |
| timsim | According to my memory and https://wiki.openstack.org/wiki/Meetings/Designate | 16:46 |
| Kiall | We talked about a interim meet, and ruled it out ;) | 16:49 |
| *** openstackgerrit has quit IRC | 16:51 | |
| *** openstackgerrit has joined #openstack-dns | 16:51 | |
| *** ChanServ sets mode: +v openstackgerrit | 16:51 | |
| rjrjr | okay. thanks. | 16:52 |
| betsy | rjrjr: But if you need to discuss something, I think most of us are in the irc room | 16:56 |
| rjrjr | k | 16:56 |
| rjrjr | did rackspace get permission to come to SJ for 19-22? | 16:58 |
| betsy | hmm. Not as far as I know. I’ll touch base with Joe again | 17:01 |
| *** untriaged-bot has joined #openstack-dns | 17:02 | |
| untriaged-bot | Untriaged bugs so far: | 17:02 |
| untriaged-bot | https://bugs.launchpad.net/designate/+bug/1403267 | 17:02 |
| uvirtbot | Launchpad bug 1403267 in designate "create_domain should handle status asynchronously" [Undecided,New] | 17:02 |
| untriaged-bot | https://bugs.launchpad.net/designate/+bug/1404395 | 17:02 |
| uvirtbot | Launchpad bug 1404395 in designate "Pool manager attempts to periodically sync *all* zones" [Undecided,New] | 17:02 |
| untriaged-bot | https://bugs.launchpad.net/designate/+bug/1406414 | 17:02 |
| uvirtbot | Launchpad bug 1406414 in designate "Delete zone fails to propagate to all (Bind) nameservers in a pool depending on threshold_percentage" [Undecided,New] | 17:02 |
| untriaged-bot | https://bugs.launchpad.net/designate/+bug/1403591 | 17:02 |
| uvirtbot | Launchpad bug 1403591 in designate "A ZeroDivisionError is Thrown Without Servers" [Undecided,New] | 17:02 |
| untriaged-bot | https://bugs.launchpad.net/designate/+bug/1289444 | 17:02 |
| untriaged-bot | https://bugs.launchpad.net/designate/+bug/1404529 | 17:02 |
| uvirtbot | Launchpad bug 1289444 in designate "Designate with postgres backend is having issues" [Undecided,New] | 17:02 |
| uvirtbot | Launchpad bug 1404529 in designate "DynECT is called twice when any domain action happens." [Undecided,Confirmed] | 17:02 |
| *** untriaged-bot has quit IRC | 17:02 | |
| *** openstackgerrit has quit IRC | 17:04 | |
| *** EricGonc_ has joined #openstack-dns | 17:04 | |
| *** openstackgerrit has joined #openstack-dns | 17:04 | |
| *** ChanServ sets mode: +v openstackgerrit | 17:04 | |
| *** EricGonczer_ has quit IRC | 17:05 | |
| *** jmcbride has joined #openstack-dns | 17:10 | |
| *** simon-AS5592 has quit IRC | 17:11 | |
| *** rmoe has quit IRC | 17:19 | |
| *** mikedillion has quit IRC | 17:24 | |
| *** zhang_liang_ has quit IRC | 17:31 | |
| *** zhang_liang_ has joined #openstack-dns | 17:31 | |
| *** rmoe has joined #openstack-dns | 17:37 | |
| *** paul_glass1 has quit IRC | 17:42 | |
| *** paul_glass has joined #openstack-dns | 17:42 | |
| *** mwagner_lap has quit IRC | 17:53 | |
| *** jordanP has quit IRC | 18:00 | |
| rjrjr | paul_glass: saw the bugs you reported. i am investigating them now. | 18:01 |
| rjrjr | jmcbride: is rackspace coming to the mid-cycle meetup? or will you be joining by video conference? | 18:02 |
| paul_glass | rjrjr: cool. let me know if you have any questions. | 18:03 |
| rjrjr | i appreciate your taking the time to write up the bugs. | 18:04 |
| vinod | rjrjr: I was thinking we should have the periodic sync do only errors. Also once the updates are successful, we should remove them from the status table | 18:06 |
| *** jmcbride has quit IRC | 18:06 | |
| rjrjr | how do we check if the backend DNS servers are out of sync? | 18:07 |
| vinod | One of the things we need to consider - if the threshold is less than 100% and one of the nameservers does not have an update - how do we get the information to it | 18:07 |
| vinod | For keeping the DNS servers in sync - we could do one of 2 things - (1) have another periodic function - this lets the admin dictate how frequently they want this done - since this generates a lot of network traffic | 18:08 |
| rjrjr | i can see using another thread for that. | 18:09 |
| rjrjr | so a 'periodic_retry_errors' and a 'periodic_sync'. | 18:09 |
| Kiall | Don't be tempted to try create a real thread inside of eventlet unless you want to poke your eyes out after a week or so of pain ;) | 18:10 |
| vinod | (2) Currently we have a sync api - that does something similar - I am not sure if that needs to be updated with the recent pool manager changes. But assuming that the sync api works correctly we could allow the admins to write their own tool for keeping things in sync | 18:10 |
| *** ryanpetrello has quit IRC | 18:10 | |
| *** ryanpetrello has joined #openstack-dns | 18:10 | |
| rjrjr | keeping the data in the status table is kinda important though. | 18:10 |
| Kiall | I'd go for #1 - add a new periodic task to validate the backend servers are in sync.. | 18:10 |
| rjrjr | periodic_error_retry and period_sync? | 18:11 |
| vinod | Are we or admins concerned about cases where there are zones in the backend but not in the pool manager and flag them | 18:11 |
| *** serverascode____ has quit IRC | 18:12 | |
| rjrjr | there can be zones on the backend that have nothing to do with designate. | 18:12 |
| Kiall | Do we *need* both? (I can see the value in being able to retry just the errors more often than you might want to validate everything, but it may be better to keep it simple to start) | 18:12 |
| Kiall | vinod: yea, I think we are.. From memory, we discussed deleting them from the backend DNS server when we find them | 18:13 |
| *** d34dh0r53 has quit IRC | 18:13 | |
| rjrjr | that wouldn't be good though. are we saying the backend DNS servers have to be dedicated to Designate? | 18:13 |
| rjrjr | what if they are slaves/masters for zones that have nothing to do with Designate? | 18:14 |
| *** harmw has quit IRC | 18:14 | |
| Kiall | (With a "if trying to delete 5% or more of the zones on this DNS server, then bail" in case something goes wrong fetching the list of expected zones) | 18:14 |
| rjrjr | and how do you get a list from BIND9? | 18:14 |
| Kiall | Generally, we've said that we own the nameserver.. | 18:14 |
| Kiall | rjrjr: DNS query for the SOA record of every possible zone name? (kidding!) | 18:14 |
| rjrjr | LOL | 18:15 |
| Kiall | I'm guessing we can look it up from the bind config "nzf" file or whatever it's called | 18:15 |
| rjrjr | so, we are back to having an agent on the server. | 18:15 |
| Kiall | Humm - or a "unsupported with bind" ;) | 18:15 |
| *** CaptTofu_ has quit IRC | 18:15 | |
| rjrjr | this feels like a new feature. i think we should stabilize what we have and discuss new features. | 18:15 |
| vinod | We already have a "new" agent/slappy | 18:15 |
| rjrjr | vinod, what is driving these requests? | 18:15 |
| *** nkinder has quit IRC | 18:16 | |
| Kiall | with BIND - if a server misses a delete due to being offline, it's for an admin to fix.. at some point, the logs are going to be filled with failed AXFR's once the refresh interval hits | 18:16 |
| vinod | I am looking at the bugs filed by Paul and seeing how best we can fix them | 18:16 |
| *** d34dh0r53 has joined #openstack-dns | 18:16 | |
| *** CaptTofu_ has joined #openstack-dns | 18:16 | |
| vinod | We have some work around delete that we need to do - to make it more robust | 18:17 |
| *** serverascode____ has joined #openstack-dns | 18:17 | |
| rjrjr | i would like to discuss the 'we own the backend DNS server' part. that is going to be a problem with the cutover plan we are employeeing at eBay. | 18:17 |
| *** zhang_liang__ has joined #openstack-dns | 18:17 | |
| vinod | We can revisit that once we have the current bugs fixed | 18:18 |
| Kiall | rjrjr: Yea, it's always been something that would be nice to get rid of.. But it's difficult to do AND guarantee we never are going to clobber an unmanaged zone | 18:18 |
| Kiall | vinod: agreed | 18:18 |
| Kiall | brb | 18:18 |
| rjrjr | vinod: is there a DNS query we can run to have the DNS server tell us the serial number for a zone? | 18:19 |
| *** zhang_liang_ has quit IRC | 18:20 | |
| rjrjr | never mind, that is more or less build into the sync. | 18:20 |
| vinod | are you looking at more information than the SOA or do you not have the zone name? | 18:20 |
| rjrjr | the periodic_sync is not doing a AXFR every peroidic_sync interval, it is checking first. | 18:21 |
| rjrjr | only if a diff is found does a AXFR occur. | 18:21 |
| *** harmw has joined #openstack-dns | 18:21 | |
| rjrjr | i imagine that checking is pretty light weight. splitting that into it's own thread should be sufficient. | 18:22 |
| rjrjr | we could use the SOA data itself for the periodic sync. like DNS servers do. | 18:23 |
| rjrjr | never mind. i think those values are for the client to refresh the zone. | 18:24 |
| vinod | Currently the SOA data for refresh comes from a config setting - from th admin | 18:24 |
| vinod | But having a separate thread as a start would be helpful especially if you have a lot of zones. | 18:24 |
| rjrjr | yes. what i'm saying is DNS has an inbuilt mechanism to do a period sync. it uses some of the fields in the SOA for that. | 18:24 |
| rjrjr | but, they are client initiated i believe. | 18:25 |
| rjrjr | we'll go with a separate thread. | 18:25 |
| vinod | For deletes - I think we need an option to delete from storage only - instead of the backends too. This could be an admin option. | 18:27 |
| Kiall | I guess that falls under the "unmanaged zones not supported" thing? | 18:28 |
| vinod | The reason is that with the thresholds and nameservers being down - we see that it is easy to get into a state where one of the nameservers is down and is not updated but the storage has it and it prevents it from the zone being recreated | 18:29 |
| Kiall | deleting only from storage would leave the zone as if it was hand created on the server - leaving it open to clobbering etc | 18:29 |
| *** nkinder has joined #openstack-dns | 18:29 | |
| vinod | Having an admin only option would allow support to delete it if we encounter an error situation | 18:29 |
| Kiall | Shouldn't it still be pending if it didn't get created on enough nameservers? And if it did get created on enough, the periodic sync should fix it on the others nameservers when they come back? | 18:30 |
| rjrjr | kiall: correct. | 18:30 |
| Kiall | Also - If support deletes+recreates it, keeping it on the DNS servers won't do much good, as once recreated it will be an empty zone - and an AXFR will eventually happen and wipe the content from the nameservers | 18:31 |
| vinod | I am talking about the case where the backends do not have it - but storage does | 18:32 |
| vinod | Support would only be deleting it from storage - recreating it if needed would be upto the user | 18:32 |
| rjrjr | what is the use case? | 18:32 |
| Kiall | Oh.. Well, I think, if a zone exists in storage, a delete should always succeed - even when it doesn't exist on any backend servers. | 18:36 |
| vinod | With Bind, I found that it easy to get into a state where the rndc delzone reports an error, but later BIND removes it on its own, but pool manager keeps trying to do rndc delzone and gets the error | 18:36 |
| vinod | So we end up with a zone in storage but not on the backend | 18:37 |
| rjrjr | vinod: that is a bug we can fix in pool manager. | 18:37 |
| Kiall | We have similar issues with Akamai, we ignore failures on delete from them, and ignore "zone already exists" on create to handle the recreate case | 18:37 |
| vinod | Kiall: How do you distinguish between new creates and recreates? | 18:38 |
| Kiall | There's no need - Unless your sharing the nameserver with manually created zones.. | 18:38 |
| vinod | When do you then flag a duplicate domain error? | 18:39 |
| rjrjr | duplicate domain is if someone create a domain in designate that already exists in the database. | 18:40 |
| Kiall | if a "zone already exists" is returned from Akamai (or BIND etc), it means designate failed to delete it at some point, so we just "take it over" and let the "new" zone have it - if that makes sense | 18:40 |
| Kiall | duplicate domain would be caught before it ever hits the backend | 18:40 |
| Kiall | (^ is all part of why Designate owns the DNS servers, there's just no good way to distinguish between a manually managed zone and a stray/leftover zone) | 18:41 |
| vinod | Ah ok - a duplicate at the backend is not a duplicate but a recreate | 18:41 |
| rjrjr | ? | 18:41 |
| mugsie | Kiall: we dont ignore failre to delete on Akamai... | 18:41 |
| Kiall | mugsie: Yep, we do.. | 18:42 |
| rjrjr | we would never see a duplicate domain for the backend. | 18:42 |
| mugsie | at least not all | 18:42 |
| mugsie | failures | 18:42 |
| mugsie | I have 20 zones to prove it ;) | 18:42 |
| Kiall | lol - yea, there 1 or 2 error codes we missed. | 18:42 |
| rjrjr | sorry, meant duplicate domain error. | 18:43 |
| rjrjr | that would come before the backend in the database code. | 18:43 |
| rjrjr | in either case, i'll take a look at the bugs paul sent us. | 18:44 |
| *** pk has joined #openstack-dns | 18:45 | |
| vinod | rjrjr: I had some questions on the entries in the statuses table | 18:47 |
| vinod | Why do we need to retain the entries in the table after we mark something as active? | 18:48 |
| Kiall | Gotta run, back later.. | 18:48 |
| *** jmcbride has joined #openstack-dns | 18:52 | |
| rjrjr | the table entries are used to determine the status of the last query to the backend servers. | 18:53 |
| rjrjr | it has the serial number from the backend server, for example. | 18:54 |
| rjrjr | without looking at the code, that information is compared to the Designate database to determine when the backend needs to be called. | 18:55 |
| rjrjr | i'd have to look at the code further if you need more detail. | 18:55 |
| rjrjr | of course, we could have done the implementation differently. | 18:56 |
| vinod | My question is we never seem to delete an entry from the status table once it is created - I would think that once the designate database and the backend match up - the entry should be deleted | 18:57 |
| rjrjr | i am using that information in the cache to make choices. hence it not being deleted. | 18:58 |
| rjrjr | think of it as a cache of the information on the backend server. | 18:59 |
| rjrjr | (specifically the serial number) | 18:59 |
| rjrjr | cuts down on the calls to the backend servers. and to the designate database too. | 19:00 |
| timsim | Is there a reason to need that after a change has succesfully propagated everywhere? | 19:01 |
| rjrjr | is it more expensive to delete and add rows to a table or update a field in the row? | 19:02 |
| timsim | With creates/deletes there isn't ever a need to update the information again, is there? | 19:04 |
| timsim | For updates, won't you need individual change records for IXFR? | 19:04 |
| rjrjr | timsim, are we talking about the pool manager cache now or the Designate database? | 19:06 |
| timsim | PM cache. | 19:06 |
| rjrjr | the PM cache doesn't care about IXFR or AXFR. | 19:06 |
| rjrjr | it just keeps the serial number and status of the backend server. | 19:06 |
| timsim | What was going to keep those records for AXFR? Was that going to be in the main DB? | 19:07 |
| timsim | Or separate completely | 19:07 |
| rjrjr | correct. the main DB. | 19:07 |
| timsim | s/AXFR/IXFR | 19:07 |
| timsim | Well, anyway. | 19:07 |
| *** simon-AS559 has joined #openstack-dns | 19:07 | |
| rjrjr | the pool manager cache doesn't concern itself with records. just the serial number and status of the backend. | 19:08 |
| *** mwagner_lap has joined #openstack-dns | 19:08 | |
| timsim | With updates, do you not lose the capability to track a single change that may have failed on 2/20 nameservers by just having one for the zone? | 19:08 |
| timsim | one record in the cache | 19:08 |
| rjrjr | the serial number takes care of that. | 19:09 |
| rjrjr | if a change occurs, the serial number is incremented. | 19:09 |
| rjrjr | and the main DB takes care of the status of the individual records. | 19:10 |
| *** simon-AS5591 has joined #openstack-dns | 19:10 | |
| timsim | So if NS1 Gets changes 1,2, and 3. Representing three different versions of the zone, and NS2 doesn't get any of them, does the Pool Manager Cache entry for UPDATE for that zone remain at serial before change 1? | 19:11 |
| *** paul_glass has quit IRC | 19:11 | |
| rjrjr | yes. i believe it defaults to 0 when i create the UPDATE row. | 19:11 |
| *** simon-AS559 has quit IRC | 19:12 | |
| rjrjr | (i'd have to look at the code. it might be null too.) | 19:12 |
| timsim | So when Periodic sync comes around, you NOTIFY every server in the pool for that zone until they all come back with the serial that matches the Designate DB? | 19:13 |
| rjrjr | yes. | 19:14 |
| timsim | But there would be no ability to track which servers in the pool had a specific change. | 19:14 |
| rjrjr | all pool manager cares about is if the server has the latest zone which is tracked by serial number. | 19:15 |
| rjrjr | it reports back to central the status and central takes care of updating the record table to see if the individual changes occurred. | 19:16 |
| rjrjr | if the server has the latest zone - success. life is good. report this to central. | 19:17 |
| timsim | Alright. | 19:17 |
| rjrjr | if the server does not have the latest zone - problem. report this to central and retry at the next interval. | 19:17 |
| timsim | So the mechanism for marking a zone to ERROR then, maybe after three poll attempts, does that work now? | 19:18 |
| rjrjr | it should, yes. | 19:18 |
| rjrjr | is the concern about records in the cache specifically the CREATE and DELETE statuses? | 19:18 |
| rjrjr | the UPDATE statuses are constantly being used. | 19:19 |
| timsim | Ah yes, forgot. | 19:19 |
| timsim | So is there any reason to keep the Creates/Deletes around? | 19:19 |
| rjrjr | none whatsoever. | 19:19 |
| timsim | Alright, we ought to delete them then. | 19:19 |
| rjrjr | we can remove them or keep them. | 19:19 |
| rjrjr | i'll look at that too. | 19:20 |
| rjrjr | and we can remove the UPDATE when the DELETE statuses are removed. | 19:20 |
| timsim | Alright. | 19:20 |
| timsim | Yep. | 19:20 |
| rjrjr | adding it to my list. | 19:21 |
| timsim | I've had a look at https://bugs.launchpad.net/designate/+bug/1404377 | 19:21 |
| uvirtbot | Launchpad bug 1404377 in designate "Zone marked as ACTIVE prior to being transferred to nameserver" [Critical,Triaged] | 19:21 |
| timsim | It looks like the reason there, which may be bind-specific, is that the zone is marked active when an RNDC addzone succeeds, but that's not enough to say a zone is active in bind9, it's still got to do the AXFR. | 19:22 |
| timsim | It's got to do that update also. | 19:22 |
| rjrjr | an AXFR occurs in BIND when the RNDC addzone succeeds. now, whether or not the AXFR is successful... | 19:23 |
| rjrjr | i'll take a look. | 19:23 |
| timsim | Yeah, so you've got to be sure the AXFR is sucessful to mark the zone 'ACTIVE' | 19:23 |
| rjrjr | powerDNS needed the notify to be sent explicitly. BIND does it for us. | 19:24 |
| rjrjr | timsim: i'll take a look. | 19:24 |
| rjrjr | i have to go and work now. 8^) i'll take a look at these bugs and try to close them out before Wednesday's meeting. | 19:25 |
| timsim | I've got a patch locally that delays calling update_status in create_domain unless it knows the update was succesful, I was going to throw it up and see if you thought it was the right thing. But I was just waiting to see if a zone gets to ERROR if it doesn't happen, which I haven't seen yet. | 19:25 |
| rjrjr | it's possible there is a bug in there. | 19:26 |
| timsim | Alright, well I'll test my fix a bit more and maybe put it up, pending your thoughts. | 19:26 |
| rjrjr | okay. | 19:27 |
| *** penick has joined #openstack-dns | 19:41 | |
| *** jmcbride has quit IRC | 19:47 | |
| *** jmcbride has joined #openstack-dns | 19:49 | |
| *** vinod has quit IRC | 19:56 | |
| *** vinod has joined #openstack-dns | 19:56 | |
| *** paul_glass has joined #openstack-dns | 19:57 | |
| *** simon-AS5591 has quit IRC | 20:00 | |
| penick | Does anyone know if Designate allows administrators to control which projects are allowed to create records under certain zones? For example, if I work for baz.com, and I want to allow anyone in my private cloud to be able to create an instance with the name *.bar.baz.com, but only allow certain projects to create domains under *.baz.com (like www.baz.com). Is this possible? | 20:06 |
| penick | I read through the docs but don’t think i’ve pulled up a clear answer on that | 20:06 |
| timsim | penick: I'm not sure there are controls quite that fine grained...you might be able to define different tenants and transfer zones between them. So create baz.com, bar.baz.com and transfer bar.baz.com over to another tenant so that they can do things on it. But i'm not sure. | 20:11 |
| penick | Ah, hrm. Unfortuantely in the private cloud case there are cases where I need more than one project to have access to create stuff in a zone, but to deny other projects | 20:12 |
| timsim | https://blueprints.launchpad.net/designate/+spec/share-domains probably meets your needs, it's a high priority for us. | 20:14 |
| penick | Awesome! Is there a blueprint in gerrit or another place where I can check to see if my particular use case is covered? If not, I can comment and explain why it’d be valuable to me | 20:24 |
| timsim | I don't think there's a bp anywhere else. | 20:25 |
| timsim | Stick around though, when other folks read the scroll back they might have other thoughts better than mine :) | 20:26 |
| penick | Will, do, thanks! | 20:28 |
| penick | s/,// | 20:28 |
| rjrjr | we have a requirements that takes this even further. we would like to limit the record types that particular users can manage. | 20:31 |
| rjrjr | for example, we have users we want to only be able to manage CNAME records, not the other record types. | 20:33 |
| timsim | There's probably an elegant policy solution in there somewhere. | 20:33 |
| mugsie | timsim: I would think there is | 20:44 |
| mugsie | might be a good topic for the hackathon | 20:44 |
| mugsie | policy in general | 20:44 |
| mugsie | penick: we do have "blacklisted" domains - and you could edit the policy.json file to allow only a certain group create a blackisted domain | 20:45 |
| mugsie | but you would have to be explict in the blacklist regex about creating the "*.bar.baz.com." exemption | 20:46 |
| mugsie | in the regex | 20:46 |
| mugsie | gah | 20:46 |
| mugsie | brain == not good | 20:46 |
| timsim | mugsie: Can you create a subdomain, and then transfer that to another tenant? Wouldn't quite work for penick because he needs mutliple tenants to be able to do things to it, but that's a use case I could see people wanting to do. | 20:47 |
| timsim | The sticking point would be having a different tenant owning a subdomain of another tenant's zone. | 20:48 |
| penick | Ahh, ok. So I could blacklist ^[a-zA-Z0-9]\\.baz.\com$, create a group for can_haz_baz_2ld which does have permissions to create domains under that zone, then just add users or projects to that group. | 20:48 |
| mugsie | penick: yup | 20:58 |
| *** penick has quit IRC | 21:05 | |
| *** penick has joined #openstack-dns | 21:11 | |
| *** penick has quit IRC | 21:12 | |
| mugsie | timsim: yup - that would work | 21:23 |
| openstackgerrit | Tim Simmons proposed openstack/designate: Zones prematurely marked ACTIVE https://review.openstack.org/145067 | 21:29 |
| *** penick has joined #openstack-dns | 21:31 | |
| *** jmcbride has quit IRC | 21:42 | |
| *** jmcbride has joined #openstack-dns | 21:46 | |
| *** jmcbride1 has joined #openstack-dns | 21:49 | |
| *** jmcbride1 has quit IRC | 21:50 | |
| *** jmcbride1 has joined #openstack-dns | 21:50 | |
| *** jmcbride has quit IRC | 21:51 | |
| *** penick has quit IRC | 21:51 | |
| *** chlong has quit IRC | 21:59 | |
| *** betsy has quit IRC | 22:02 | |
| *** penick has joined #openstack-dns | 22:27 | |
| *** EricGonc_ has quit IRC | 22:27 | |
| *** penick has quit IRC | 22:28 | |
| *** penick has joined #openstack-dns | 22:37 | |
| *** vinod has quit IRC | 22:42 | |
| *** vinod has joined #openstack-dns | 22:42 | |
| *** timsim has quit IRC | 22:51 | |
| *** chlong has joined #openstack-dns | 22:57 | |
| *** nkinder has quit IRC | 23:13 | |
| *** chlong_ has joined #openstack-dns | 23:14 | |
| *** jmcbride1 has quit IRC | 23:22 | |
| *** chlong has quit IRC | 23:39 | |
| *** chlong_ has quit IRC | 23:39 | |
| *** chlong_ has joined #openstack-dns | 23:46 | |
| *** chlong has joined #openstack-dns | 23:46 | |
| *** chlong_ has quit IRC | 23:46 | |
| *** penick has quit IRC | 23:46 | |
| *** paul_glass has quit IRC | 23:51 | |
| *** vinod has quit IRC | 23:57 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!