| ozzzo | I'll try it tomorrow | 02:09 |
|---|---|---|
| johnsom | frickler: I am not sure I understand your question. I rolled up the data from the foundation on the discuss mailing list for the survey information I added to the PTG topics. It was hard to read in the csv form. | 06:09 |
| frickler | johnsom: I hadn't seen the mail from the foundation earlier, that's what my question was about. and I agree that the format is difficult to use. but it is also valuable to see the answers for designate in the context of the other answers for that deployment | 07:28 |
| opendevreview | Arkady Shtempler proposed openstack/designate-tempest-plugin master: Add new test cases for TLD test suite https://review.opendev.org/c/openstack/designate-tempest-plugin/+/803597 | 08:41 |
| opendevreview | Arkady Shtempler proposed openstack/designate-tempest-plugin master: List enabled Designate API versions https://review.opendev.org/c/openstack/designate-tempest-plugin/+/803116 | 09:19 |
| opendevreview | Arkady Shtempler proposed openstack/designate-tempest-plugin master: List enabled Designate API versions https://review.opendev.org/c/openstack/designate-tempest-plugin/+/803116 | 09:20 |
| ozzzo | eandersson: After applying the patch I'm no longer able to duplicate the error | 15:19 |
| johnsom | Nice, awesome work tracking that down! | 15:20 |
| ozzzo | ty for your help w/that | 15:22 |
| opendevreview | Arkady Shtempler proposed openstack/designate-tempest-plugin master: New test cases for tsigkey tests suite https://review.opendev.org/c/openstack/designate-tempest-plugin/+/798277 | 16:07 |
| opendevreview | Arkady Shtempler proposed openstack/designate-tempest-plugin master: Adding a new test: "test_create_zone_validate_recordsets_created" https://review.opendev.org/c/openstack/designate-tempest-plugin/+/803490 | 19:38 |
| eandersson | johnsom what do you think on https://review.opendev.org/c/openstack/designate/+/814290 ? | 20:15 |
| eandersson | The original idea with the sink was that it would create a record that could only be managed by the sink (with the exception of --edit-managed for admins in case something goes terribly terribly wrong) | 20:15 |
| eandersson | I honestly don't think you can modify even a recordset created by the sink without the --edit-managed, but even if not no one should be touching those records | 20:16 |
| eandersson | We could make this code a lot smarter, but it probably needs a complete overhaul | 20:17 |
| eandersson | Actually nvm | 20:19 |
| eandersson | I guess if a VM has two IPs it would have two records under a recordset | 20:19 |
| eandersson | but even then that wouldn't be an issue, since they are both created by the sink | 20:20 |
| frickler | eandersson: I was more thinking what would happen if two vms have the same hostname. then deleting one would remove records for both? | 20:21 |
| eandersson | 1) Leave patch as is and if someone adds something to the managed records they will be lost (this isn't supported anyway). | 20:22 |
| eandersson | 2) Move managed to the recordset level and enforce as intended. | 20:22 |
| eandersson | 3) Write something more complicated in base aka _update_or_delete_recordset. | 20:22 |
| eandersson | 4) Fix delete_record in central. | 20:22 |
| eandersson | frickler: That happens today already | 20:22 |
| eandersson | It's super annoying today because if someone creates two VMs with the same name by accident and removes one it wipes the records | 20:23 |
| eandersson | for both | 20:23 |
| frickler | is that a feature or a bug? | 20:23 |
| eandersson | bug I would say | 20:25 |
| eandersson | I wish we had some functional tests here lol | 20:25 |
| frickler | I was just about to ask, do we have a scenario test for sink at all? | 20:25 |
| eandersson | I don't believe so | 20:26 |
| eandersson | btw the code is just broken atm | 20:26 |
| eandersson | Because delete_record just puts the record into PENDING delete | 20:26 |
| eandersson | (which is then clean up by a secondary process) | 20:27 |
| eandersson | but couldn't find that process lol | 20:27 |
| frickler | o.k., will try to setup something locally tomorrow, eod now | 20:30 |
| johnsom | eandersson It was on my list to look at a bit later today, but if it's broken..... | 20:30 |
| eandersson | Thanks both of you. | 20:36 |
| eandersson | I can try some more stuff tonight. Looking at the code... I might have fixed that bug already | 20:36 |
| johnsom | I need to get my head around the sink code. I haven't spent much time on it. | 20:37 |
| eandersson | Because in theory it shouldn't delete the old record | 20:37 |
| eandersson | I think the idea was that it was replaced by the neutron code | 20:38 |
| eandersson | because it has a lot of flaws | 20:38 |
| johnsom | Right, API... | 20:38 |
| eandersson | notifications aren't reliable | 20:38 |
| eandersson | Ok.. I am running my forked version that is using old code.. so indeed you are right frickler | 20:42 |
| eandersson | Great call out! | 20:42 |
| eandersson | We really need functional testing for this | 20:43 |
| eandersson | I'll put together a wip implementation for #3 tonight | 20:44 |
| eandersson | Omg I see what I did... the problem with sink is that notifications sometimes fails, e.g. if you delete a VM off a compute that does is down (e.g. bad hardware) | 21:40 |
| eandersson | Because the notifications originate from nova-compute, not from nova-api or nova-conductor | 21:41 |
| eandersson | This means that if you delete a VM because the hypervisor is in a not so good state the records needs to be manually cleaned up by an administrator | 21:41 |
| eandersson | So in my implementation of this I delete all previous VM records. That way if a VM isn't cleaned up properly, when it is re-created it will always remove old records | 21:42 |
| eandersson | The disadvantage is that you cannot do round-robin vms | 21:42 |
| eandersson | Advantage is that you dont have to clean up old records when VM delete was done on a bad hypervisor | 21:43 |
| eandersson | btw if you have like... I don't know 10k+ hypervisors.. this is a major pain as a small percentage of hypervisors will die monthly and VMs need to be deleted and cleaned up | 21:44 |
| eandersson | and automating that process isn't super easy | 21:45 |
| johnsom | Yeah, I have an long open bug against nova (unless they rage closed it) that deletes shouldn't get resources stuck if the host is unreachable, they should just queue. It gets super nasty when you can't get IPs and ports back due to a host going down hard..... I wrote a monster patch to work around that in Octavia. | 22:37 |
| opendevreview | Michael Johnson proposed openstack/designate-tempest-plugin master: Unroll DDT API tests used for refstack/interop https://review.opendev.org/c/openstack/designate-tempest-plugin/+/814497 | 22:51 |
| johnsom | Throwing a proposed patch out there for the PTG discussion. | 22:59 |
| eandersson | I bet that might fix the nginx issue as well. | 23:02 |
| johnsom | nginx issue? | 23:02 |
| johnsom | The wsgi problem? | 23:03 |
| eandersson | Yea | 23:03 |
| eandersson | Those ddt tests are the only ones that trigger that issue. | 23:03 |
| johnsom | Yeah, I never narrowed down why we get that one random broken pipe on the uwsgi socket. I spent a day or two on it. I still mean to get back to that. | 23:04 |
| johnsom | But, yeah, we had tons of trouble with ddt in Octavia, mostly dependency breaking issues, etc. so we just removed it and did all stubs. | 23:04 |
| eandersson | https://review.opendev.org/c/openstack/designate-tempest-plugin/+/700255 | 23:05 |
| eandersson | I was trying to do something similar | 23:05 |
| johnsom | I would be more than happy to do that in designate too if we are interested. Some of the others are going to be a larger list of stubs though. | 23:05 |
| johnsom | Personally, I find the stubs are just simple and clear, probably saves a few lines overall too. grin | 23:06 |
| eandersson | I agree | 23:07 |
| johnsom | frickler If I remember right, you prefer jitsi over zoom? | 23:37 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!