Tuesday, 2022-10-04

opendevreviewJakob Meng proposed openstack/ansible-collections-openstack stable/1.0.0: Release 1.10.0 version  https://review.opendev.org/c/openstack/ansible-collections-openstack/+/86022309:07
opendevreviewJakob Meng proposed openstack/ansible-collections-openstack master: Refactored floating_ip and floating_ip_info modules  https://review.opendev.org/c/openstack/ansible-collections-openstack/+/82861309:11
opendevreviewJakob Meng proposed openstack/ansible-collections-openstack master: Replaced expensive get_server() and fixed issues in server module  https://review.opendev.org/c/openstack/ansible-collections-openstack/+/85211909:57
jm1gtema: o/ running into yet another issue with add_ips_to_server and i need your input on how to solve this.12:20
gtemaok, I hear12:20
jm1gtema: suppose you have two private networks, a server which is attached to one of these networks and now you call add_ips_to_server(server) without any other arguments, hence auto_ip=True12:20
jm1gtema: you also have a router and a public network and neutron12:21
jm1gtema: i would assume that add_ips_to_server would attach a floating ip to the server12:21
jm1gtema: but actually it will fail here https://opendev.org/openstack/openstacksdk/src/commit/093e71e5a6050e6f7d47a03b5f03a62b8f60ca60/openstack/cloud/_floating_ip.py#L112912:22
gtemajm1 - generally in any way this can work only: the net server is attached to is connected through router with public network12:22
jm1gtema: sure, the router is attached to public network and the private networks12:23
gtemathe place you mention is exactly one of the black holes 12:23
jm1gtema: we also have subnets12:23
jm1gtema: the issue is, that this line here might return the "wrong" network https://opendev.org/openstack/openstacksdk/src/commit/093e71e5a6050e6f7d47a03b5f03a62b8f60ca60/openstack/cloud/_floating_ip.py#L110912:23
jm1gtema: it might return the one the server is connected to, but it could also return the other one12:24
gtemabecause historically it searches for this "NAT network" which should be a private net server is connected to and connected through router to public net12:24
gtemado you have logs (or how to reproduce?12:25
jm1gtema: https://6aef0912e1e7e067f94c-3957ec525977d9a3771da3eb17c87a1d.ssl.cf5.rackcdn.com/852119/18/check/ansible-collections-openstack-functional-devstack/593fd7f/job-output.txt12:25
jm1gtema: here is the culprit: https://opendev.org/openstack/openstacksdk/src/commit/093e71e5a6050e6f7d47a03b5f03a62b8f60ca60/openstack/cloud/_network_common.py#L18012:26
jm1gtema: this will look though all subnets which will be returned even though the server might not be attached to that12:26
gtemawhich which change it is (so that I reconstruct conditions)?12:26
jm1gtema: https://review.opendev.org/c/openstack/ansible-collections-openstack/+/852119/1812:27
jm1gtema: my approach would be to return all possible nat destinations and let the caller choose what the best is12:27
gtemaactually there is clouds.yaml parameter for manual name of such net12:28
jm1gtema: but _nat_destination_port() can decide what nat destination to use without the user having to help the sdk12:29
gtemaI told you this is now all quite historical and not too much scalable, haven't I?12:30
jm1gtema: _nat_destination_port gets a server and has a list of ports. it just has to check which port is actually on a nat_destination network12:30
jm1gtema: hmm12:30
jm1gtema: so ignore?12:30
gtemanope, I want to have a functest for that directly in SDK12:30
jm1gtema: the use case is pretty straight forward though: one has a server and wants it to have a floating ip. this should not fail just because the user has two networks with a gateway..12:31
gtemahttps://review.opendev.org/q/topic:better_tests is a chain where this would need to go12:31
gtemathis is clear, jm1. But I would need to create a proper functest for that12:31
jm1gtema: sure. question is, should i write a patch for this _nat_destination_port or is this going away anyway?12:32
gtemano, I would first want to have a test that reproduces error and with that start reworking of the whole madness12:33
jm1gtema: ok sooo.. should i write a test?12:34
gtemajust describe to me detailed conditions12:35
jm1gtema: here or in a bug report?12:36
gtemadoesn't matter - even an email to me. Important is that I do not loose it12:36
gtemaand bugreport is exactly the place to loose everything once you close the tab12:36
jm1gtema: ok. devstack default setup with public network. 2 private networks with a subnet each. all three networks attached to the router. server attached to one private network. call to add_ips_to_server(server, auto_ip=True, reuse=False). sometimes fails with "No port on server... was found matching your NAT destination network" because _nat_destination_port() returns the other private network, not the one the server has been attached to.12:44
jm1gtema: plus links above. enough?12:44
gtemaoh, so actually all private nets attached to one router? that is a great fact to know12:46
jm1gtema: yes. although this would not change the bug because it lists all subnets anyway12:49
jm1gtema: have more than one network with a gateway? boom12:51
jm1gtema: or rather "potential boom"12:51
gtemawhere is the connectivity between pub net and router? don't see it in the change12:52
jm1gtema: https://review.opendev.org/c/openstack/ansible-collections-openstack/+/852119/18/ci/roles/server/tasks/main.yml#3712:53
gtemaah, overseen12:53
gtemaok, will sketch the test12:53
jm1gtema: while you are at it.. https://storyboard.openstack.org/#!/story/2010153 ;)12:56
jm1gtema: he also submitted a patch12:56
gtemaugh, I don't know how to deal with patches into something that is so fragile12:57
jm1gtema: this patch actually looks good. it does not remove or change functionality, it just adds a missing parameter12:59
gtemawhich works "magically"12:59
gtemathere are no really reasonable tests for this whole "chapter"13:00
jm1gtema: so you cannot break something with merging this13:00
gtemalol - I can break you even further13:00
jm1gtema: not with this patch though ;)13:02
gtemasure?13:02
jm1gtema: not more than what is broken already13:03
gtemait doesn't look bad, I am just too skeptic since there are no real tests here13:03
gtemaokay, then I can go with merging it and restructure with it being added13:03
opendevreviewArtem Goncharov proposed openstack/openstacksdk master: support nat_destination when attaching existing floating_ip to a server  https://review.opendev.org/c/openstack/openstacksdk/+/85011513:06
jm1gtema: i know you hate storyboard but i need a place to track that error https://storyboard.openstack.org/#!/story/201035213:18
gtemaI do not hate it - I do not use it ;-)13:19
gtemabecause it does not help, but rather disturb13:19
* jm1 gtema has been kicked due to inactivity on floating ips :P13:44
gtemareally? okay, then I just don't push any other big changes ;-)13:45
opendevreviewMerged openstack/ansible-collections-openstack stable/1.0.0: Release 1.10.0 version  https://review.opendev.org/c/openstack/ansible-collections-openstack/+/86022313:56
gtemayou know jm1, while now reworking tests to be working in regular clouds faced already something fun errors ("Multiple possible networks found, use a Network ID to be more specific.") 14:35
jm1gtema: i am feeling you 😬14:39
opendevreviewArtem Goncharov proposed openstack/openstacksdk master: Whitelist cloud functional tests in acceptance  https://review.opendev.org/c/openstack/openstacksdk/+/86000915:19
opendevreviewMerged openstack/cliff master: Replace abc.abstractproperty with property and abc.abstractmethod  https://review.opendev.org/c/openstack/cliff/+/85205818:15
opendevreviewMerged openstack/cliff master: columns: Useful __str__, __repr__ implementation  https://review.opendev.org/c/openstack/cliff/+/85855018:15
opendevreviewJakob Meng proposed openstack/ansible-collections-openstack master: Replaced expensive get_server() and fixed issues in server module  https://review.opendev.org/c/openstack/ansible-collections-openstack/+/85211919:05

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!