opendevreview | James Gibson proposed openstack/openstack-ansible master: Fix error in dynamic-address-fact task when no tunnel interface https://review.opendev.org/c/openstack/openstack-ansible/+/814804 | 06:55 |
---|---|---|
opendevreview | Alexandr Yeremko proposed openstack/openstack-ansible master: initial commit, Implements: blueprint protecting-plaintext-configs https://review.opendev.org/c/openstack/openstack-ansible/+/814863 | 07:58 |
opendevreview | Alexandr Yeremko proposed openstack/ansible-role-vault master: initial commit, Implements: blueprint protecting-plaintext-configs https://review.opendev.org/c/openstack/ansible-role-vault/+/814864 | 07:59 |
opendevreview | Alexandr Yeremko proposed openstack/openstack-ansible-os_glance master: initial commit, Implements: blueprint protecting-plaintext-configs https://review.opendev.org/c/openstack/openstack-ansible-os_glance/+/814865 | 08:00 |
opendevreview | Dmitriy Rabotyagov proposed openstack/ansible-config_template master: Add option to install as collection https://review.opendev.org/c/openstack/ansible-config_template/+/807581 | 08:51 |
ierdem | Hi everyone, I have OSA Victoria env and I am trying to deploy kubernetes cluster by using Magnum and got this error. "error GET 169.254.169.254/openstack/latest/user_data failed'. I've tried to run manually 'curl -v 169.254.169.254/openstack/latest' command and result has no 'user_data' https://paste.opendev.org/show/810142/. Any ideas? | 11:56 |
noonedeadpunk | sorry, no idea | 12:13 |
spatel | jamesdenton take a look here and see if any other improvement we can do otherwise looking good - https://review.opendev.org/c/openstack/openstack-ansible-os_neutron/+/814825 | 13:02 |
jamesdenton | spatel as-is, i think it limits you to a single bond, whereas users may want bonds for multiple provider networks | 13:59 |
jamesdenton | so, that is likely where we'd want to implement something like that. The 'network_interface' mechanism you showed me yesterday would probably be the best place, since it's already responsible for plugging in an interface into the bridge | 14:00 |
anskiy_h | hey! I'm trying to deploy a proper cluster from 23.1.1 on Ubuntu 20.04 and I keep getting error during setup-infrastructure (utility-install) about non-primary repo nodes not being able to build netifaces (which is okay, bc they don't even have GCC installed, so they should get it from wheels subdirectory on primary node), but the primary node doesn't build them either and the reason to this, as far as I see is flipped value of venv_wheel_buil | 14:00 |
jamesdenton | it could instead be turned into a list | 14:00 |
anskiy_h | I've put debug message just before the include_tasks: "python_venv_wheel_build.yml": https://paste.opendev.org/show/810147/ | 14:00 |
spatel | hmm | 14:01 |
spatel | jamesdenton you are saying instead of creating separate play just merge them here - https://opendev.org/openstack/openstack-ansible-os_neutron/src/branch/master/tasks/providers/setup_ovs_dpdk.yml#L115 | 14:03 |
jamesdenton | a separate play is fine, but i think we need to be more flexible in how the bonds are defined. We may have 4x interfaces defined in ovs_dpdk_pci_addresses, but want 2x bonds | 14:05 |
jamesdenton | one in br-vlan and one in br-vlan2 | 14:05 |
opendevreview | James Gibson proposed openstack/ansible-role-pki master: Add support for setting extended key usage https://review.opendev.org/c/openstack/ansible-role-pki/+/815007 | 14:05 |
spatel | jamesdenton i know what you saying. we can create separate variable like ovs_dpdk_bond_nic (where you can define nic you want to bond | 14:19 |
spatel | let me see what we can do to make more flexible, in worst case we have to define bridge name variable | 14:21 |
jrosser_ | anskiy_h: isn't that debug output becasue of this? https://opendev.org/openstack/ansible-role-python_venv_build/src/branch/master/defaults/main.yml#L113 | 14:43 |
anskiy_h | jrosser_: no, I've just added that logging here: https://opendev.org/openstack/ansible-role-python_venv_build/src/branch/master/tasks/main.yml#L24, so I could get my head around those variable values, or what was you question actually? | 14:48 |
jrosser_ | well, i was thinking that looking at the way the vars are set up, it might be expected to have that debug output? | 14:49 |
anskiy_h | nope it's definitely mine :) | 14:55 |
anskiy_h | jrosser_: or, I've got what you mean, sorry. Well, yes, it does expected, but this thing here https://opendev.org/openstack/ansible-role-python_venv_build/src/branch/master/tasks/main.yml#L30 only gets run if that variable is true, which is not for the first node and I assume that's why wheels aren't built | 14:59 |
anskiy_h | this ternary here https://opendev.org/openstack/ansible-role-python_venv_build/src/branch/master/tasks/python_venv_install.yml#L32 works as expected, I get gcc, python3-dev (from venv_build_distro_package_list (utility_devel_distro_packages)) and cmake, g++, python3-dev (from venv_build_base_distro_package_list) on the first node. I don't use containers, so maybe that's why I'm getting total failure and I assume that in LXC one just gets utili | 15:10 |
jrosser_ | the venv/wheel build should just happen on the host unless there is a bug | 15:17 |
jrosser_ | where does it actually fail? | 15:17 |
jrosser_ | the answer to this is probably in the venv/wheel build log in /var/log | 15:19 |
anskiy_h | there is only python_venv_build.log on all the hosts and no /var/log/python_wheel_build.log on second and third hosts (I assume it's because whole python_venv_wheel_build.yml task file doen't get run). venv build happens fine on the first node (which has gcc, etc), on the other nodes build fails on netifaces with "'x86_64-linux-gnu-gcc': No such file or directory" | 15:27 |
jrosser_ | so it's OK on the first node? you get netifaces built on the first node? | 15:32 |
anskiy_h | jrosser_: yes, it's this https://opendev.org/openstack/ansible-role-python_venv_build/src/branch/master/tasks/python_venv_install.yml#L155 task that fails on second and third nodes. | 15:37 |
jrosser_ | do you know what version of netifaces it wants? | 15:38 |
jrosser_ | i think that it wants a version of netifaces which does not publish a python3.8 wheel on pypi | 15:43 |
anskiy_h | it's 0.10.9, which is pretty old, yeah. | 15:44 |
anskiy_h | and only 0.11.0 has cp38 wheel | 15:44 |
jrosser_ | i wonder why the version built on your first node is not available from the repo server for the others | 15:47 |
anskiy_h | jrosser_: as far as I understood, python_venv_bulid role builds and puts wheels in /var/www/repo/os-releases/23.1.1/ubuntu-20.04-x86_64/wheels here: https://opendev.org/openstack/ansible-role-python_venv_build/src/branch/master/tasks/main.yml#L25-L33 and with that previous debug, when the first node has venv_wheel_build_enable False, it doesn't get run. | 15:51 |
spatel | jamesdenton i have one networking question, can single virtual router connect to two external network in flat networking? | 15:56 |
jrosser_ | anskiy_h: i feel there is a good chance that this is happening because of no LXC, which means that the test {{ venv_build_host != inventory_hostname }} will perhaps be false in a lot more cases than otherwise | 16:00 |
jamesdenton | only one can be considered 'external' | 16:00 |
jrosser_ | anskiy_h: you could set venv_wheel_build_enable: true in your user_variables.yml and see if it gets further | 16:02 |
anskiy_h | jrosser_: oh, yeah, I get it. Especially in the case, like you've said, that it should be built on the host. Thanks for the tip about the variable, it should work the way I expect, especially with that run_once. Thank again! | 16:04 |
anskiy_h | last case scenario would be just getting build chain on all the hosts | 16:05 |
jrosser_ | oh yes sure, that would do it too | 16:06 |
noonedeadpunk | Folks, can we merge several backports so we could do next minor release? Specifically: https://review.opendev.org/c/openstack/openstack-ansible-os_heat/+/813942 https://review.opendev.org/c/openstack/openstack-ansible/+/814650 / https://review.opendev.org/c/openstack/openstack-ansible/+/814651 and https://review.opendev.org/c/openstack/openstack-ansible-galera_server/+/809147 | 16:12 |
noonedeadpunk | there're also bunch of changes to stein | 16:12 |
noonedeadpunk | while we won't release them it would be nice to fix things there | 16:12 |
jrosser_ | for stein we first need https://review.opendev.org/c/openstack/ansible-role-python_venv_build/+/814559 then https://review.opendev.org/c/openstack/openstack-ansible/+/814560 | 16:15 |
noonedeadpunk | and https://review.opendev.org/c/openstack/openstack-ansible-os_tempest/+/814535 | 16:17 |
jamesdenton | do those have to merge in order? | 16:17 |
opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_tempest stable/stein: Fix tempest plugin versions https://review.opendev.org/c/openstack/openstack-ansible-os_tempest/+/814535 | 16:17 |
noonedeadpunk | well they have depends set | 16:18 |
noonedeadpunk | but yeah | 16:18 |
noonedeadpunk | (or rebased) | 16:18 |
jamesdenton | just wondering if I can W+1 all of them or need to wait | 16:18 |
noonedeadpunk | I'd say to go on actually | 16:24 |
anskiy_h | jrosser_: yeah, it worked. One downside to this is that I wouldn't get the build chain on the first node on a fresh installation, but I've put a note for future self there :) | 16:39 |
opendevreview | Merged openstack/openstack-ansible-galera_server stable/wallaby: Improve support for tags https://review.opendev.org/c/openstack/openstack-ansible-galera_server/+/809147 | 17:59 |
opendevreview | Merged openstack/openstack-ansible-os_neutron master: Add support for openvswitch interface driver with OVN https://review.opendev.org/c/openstack/openstack-ansible-os_neutron/+/813200 | 18:33 |
opendevreview | Merged openstack/openstack-ansible master: [doc] Fix netplan sample https://review.opendev.org/c/openstack/openstack-ansible/+/814579 | 18:37 |
*** sshnaidm is now known as sshnaidm|afk | 18:53 | |
opendevreview | Merged openstack/openstack-ansible stable/wallaby: Fix manila haproxy manage https://review.opendev.org/c/openstack/openstack-ansible/+/814650 | 19:02 |
opendevreview | Merged openstack/openstack-ansible stable/victoria: Fix manila haproxy manage https://review.opendev.org/c/openstack/openstack-ansible/+/814651 | 19:03 |
spatel | jamesdenton around? | 19:35 |
spatel | Quick networking question | 19:35 |
spatel | https://drive.google.com/file/d/15IXUP_IsI7Qrup_5b3tSpEZ4SsEHrU-Q/view?usp=sharing | 19:35 |
spatel | one of my friend has this design, two infra nodes and both connected to two separate ISP network | 19:36 |
spatel | Networking is flat | 19:36 |
spatel | In this case if i create virtual router then it can only talk to 1 ISP or connect to 1 ISP right? | 19:37 |
jamesdenton | spatel restricted | 20:02 |
spatel | i never work with virtual routers so little confused | 20:03 |
spatel | if my router schedule on infra-2 then he can't talk to ISP-A right? | 20:04 |
spatel | or he can over VxALN | 20:04 |
spatel | LAN* | 20:04 |
spatel | jamesdenton sorry i didn't realized that diagram is asking for permission | 20:10 |
jamesdenton | thats ok. a neutron router can be connected to both, and you might be able to add some routes but nothing real intelligent (i.e. no PBR) | 20:37 |
jamesdenton | only one would be consider "external" | 20:37 |
spatel | jamesdenton if i connect router to both ISP-A and B and then i have single default gateway that won't work right? | 20:40 |
spatel | that would be dumb solution | 20:40 |
spatel | in that case better solution would be create two router and attach both to separate ISP | 20:41 |
jamesdenton | yes? but what are they wanting to do? some kind of load balancing across ISP? | 20:43 |
spatel | yes kind of | 20:55 |
spatel | but that won't work i believe. may be more provider just for sharing load so not depend on single provider | 20:56 |
spatel | i will ask him more question tomorrow | 20:56 |
jrosser_ | spatel: 2 galera nodes = split brain | 21:02 |
jrosser_ | like you just can’t do it with only 2 | 21:02 |
spatel | yes.. that is good question :) | 21:02 |
spatel | i will ask him.. all he gave me that diagram to see if that is possible or not. | 21:03 |
spatel | even 4 node infra won't work right? | 21:03 |
jrosser_ | you’d have to check the clustering, even numbers are not good for ceph for example | 21:04 |
jrosser_ | and there would maybe be different considerations for galera | 21:05 |
spatel | thanks | 21:33 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!