| opendevreview | Bjoern Teipel proposed openstack/openstack-ansible master: Allowing ansible collection install behind proxies https://review.opendev.org/c/openstack/openstack-ansible/+/926170 | 04:35 |
|---|---|---|
| jrosser | morning | 07:29 |
| gillesMo | Hello, does someone manage to upgrade to Xena, after the OSSA-2023-003 security patch that force user service token ? OSA implements it only in Yoga | 08:18 |
| grauzikas | Hello, now im trying to make OSA install and configure corectly neutron with OVN, but there is a lot of not clear parts. 1: in mailing i have found that i should not provide network network_hosts, but if do that seems neutron has a lot of errors. 2: if i provide network_hosts neutron works, and i can create virtual routers, but seems port to exit port allways down and i cant make it to work. Also i have found on | 08:57 |
| grauzikas | /opt/openstack-ansible/etc/netplan/01-static.yml that there is configured br-ex and br-vlan may be inside all logic there is difference betwean br-ex and vlanre public ip on instance. Im not sure, but it may be my issue because im using for geneve and ovn same nic, but different vlans. My netplan example: https://paste.opendev.org/show/bYGFShhfWTc43apABlP9/ Because im near br-vlan in openstack_user_config providing | 08:57 |
| grauzikas | network_interface it should automatically append it. Im thinking that my issue could be: incorrect netplan and i should prepare br-vlan some how, but unclear till what level; may be im missing in user_variables some kind of bindings; incorrect openstack_user_config or some bindings. my last config what i tryed: https://paste.openstack.org/show/bPo83G762HGGfV4h77Cr/ also i have found not old conversation what was not | 08:57 |
| grauzikas | finished regarding same confusions: https://answers.launchpad.net/openstack-ansible/+question/709484 they tell that network_hosts should not be used in ovn scenario. May be some one could bring me on road and help to figure out where is potential issue and where my config is wrong? Also i have found on /opt/openstack-ansible/etc/netplan/01-static.yml that there is configured br-ex and br-vlan may be inside all logic | 08:57 |
| grauzikas | there is difference betwean br-ex and vlan? | 08:57 |
| grauzikas | long text was thinking will be shorter :D | 08:58 |
| grauzikas | huh…. all text structured wrong…. my irc client is terrible | 09:03 |
| grauzikas | should be better https://paste.openstack.org/show/bjiESyt0q7MuAsLHSWax/ | 09:11 |
| jrosser | grauzikas: there is a lot of incorrect information that you will find with google, please ignore it :) | 10:31 |
| jrosser | this is because we had very very early support for OVN in an experimental way, and a bunch of blog posts got written about that | 10:31 |
| jrosser | then there was a re-engineering of a lot of it based on that experience | 10:32 |
| jrosser | i would start with the current all-in-one as a reference to show you how to connect things up | 10:33 |
| grauzikas | probably will need to do that… but dont want to destroy current infrastructure, so probably will launch one more server | 10:35 |
| jrosser | gillesMo: the Xena branch is now in the unmaintaned status | 10:40 |
| jrosser | you would be able to fork the affected repos backporting the following patches https://review.opendev.org/q/topic:%22osa/OSSA-2023-003%22, and refer to them in your config | 10:41 |
| jrosser | and the same process of forking/patching the nova/cinder/glance services https://security.openstack.org/ossa/OSSA-2023-003.html | 10:42 |
| jrosser | if you want to run any of the unreleased/<...> branches I would strongly recommend becoming actively involved with maintaining those branches | 10:42 |
| grauzikas | https://paste.openstack.org/show/bLsr6JC9bEEhzCEFdhls/ as i understand {{ _service_setup_host }} this means issue in passing variable or undefined variable? | 10:45 |
| grauzikas | or this is normal :) | 10:46 |
| jrosser | i think that is normal when the destination host is a templated variable | 11:36 |
| jrosser | you can see all of how that works here https://codesearch.opendev.org/?q=_service_setup_host | 11:36 |
| gillesMo | jrosser: I know, I handle that just ignoring the check, it's the last task of the last includ in the os_nova ansible role. | 12:00 |
| gillesMo | jrosser: I don't really understand how the unmaintained branch works, and specifically the X-em and X-eom tags. If we commit something to the unmaintened branch, is there something that recreate the tags ? Or is the commiter responsible of ? | 12:05 |
| jrosser | gillesMo: there are no more releases on unmaintained branches | 12:15 |
| jrosser | there is some info in the openstack policy documentation here https://docs.openstack.org/project-team-guide/stable-branches.html | 12:17 |
| jrosser | if you want to use the unmainained branch in a production environment then it's probably best to curate the ansible-role-requirements and openstack service SHA yourself | 12:32 |
| gillesMo | jrosser: It's not really for production, but I need to upgrade to every release my old Wallaby cluster, to bring it to a supported version. So I can tolerate workaround. Thanks ! | 12:59 |
| opendevreview | Jonathan Rosser proposed openstack/openstack-ansible master: Simplify handling of 'telemetry' scenario in CI tests https://review.opendev.org/c/openstack/openstack-ansible/+/926206 | 13:17 |
| opendevreview | Jonathan Rosser proposed openstack/openstack-ansible master: Add vars to jobs to compute the scenario https://review.opendev.org/c/openstack/openstack-ansible/+/926214 | 14:21 |
| noonedeadpunk | Hey, I'm barely around today so can't host the meeting | 14:56 |
| noonedeadpunk | Sorry for the late notice | 14:57 |
| jrosser | no problem | 14:57 |
| opendevreview | Jonathan Rosser proposed openstack/openstack-ansible master: Add vars to jobs to compute the scenario https://review.opendev.org/c/openstack/openstack-ansible/+/926214 | 15:08 |
| platta | I finally got past the strange behavior with the inability to connect from the utility container to mariadb through haproxy. It was the my.cnf file inside the galera container, the proxy-protocol-networks setting. | 21:09 |
| platta | When running the AIO config, that setting includes 172.29.236.100, the address of br-mgmt, marked as is_management_address in the user config. This is the IP that connections come from when connecting through haproxy. | 21:10 |
| platta | In the config I was trying to get working, the ip of br-vlan (in my case the IP of the physical host) was getting put there. This was causing mariadb to deny proxy connections coming through haproxy because it wasn’t an allowed proxy source. | 21:11 |
| platta | I traced it back to here, line 43 https://opendev.org/openstack/openstack-ansible/src/commit/e88ba9b917a217a1a65133be1df592b869f0d8d4/inventory/group_vars/galera_all.yml I just don’t know how hostvars and management_address get defined. | 21:13 |
| jrosser | platta: is_management_address specifes the network that is used for the "openstack management network" - i.e the one that all the services communicate with each other on | 21:32 |
| jrosser | not to be confused with a network that you use as the the operator of the cloud to do "management" | 21:32 |
| jrosser | the value of "management_address" is determined by the dynamic inventory script, you'll be able to see what that generates in the .json inventory file in /etc/openstack_deploy | 21:36 |
| jrosser | ^ i think? | 21:36 |
| platta | Aha, you’re right! And that pretty much explains it. In my configuration I’m referencing the physical IP of the host instead of the host’s IP on the management network, so the inventory is getting generated incorrectly due to my mistake. | 21:38 |
| jrosser | yes you can see it here for an AIO galera instance https://zuul.opendev.org/t/openstack/build/4b6afa55f1ec44628fb4e489c597aaac/log/logs/etc/host/openstack_deploy/openstack_inventory.json.txt#149-208 | 21:38 |
| jrosser | well everything is configurable :) | 21:39 |
| jrosser | see the section at the end of here https://opendev.org/openstack/openstack-ansible/src/branch/master/doc/source/reference/inventory/configure-inventory.rst#L354 | 21:39 |
| platta | Next chance I get, I’ll re-image, correct the issue, and try again. I think that might do it. | 21:39 |
| jrosser | you can optionally make the ansible "ssh" IP independant of the br-mgmt addresses | 21:39 |
| jrosser | for example in my deployments we have a completely seperate out-of-band network that ansible and the pxeboot stuff uses | 21:40 |
| jrosser | nothing at all to do with br-mgmt | 21:40 |
| platta | That also makes sense. I think the only reason I switched to the physical IP is because the other one wasn’t working. But, my network configuration has been refined since then. I’ll try it both ways to see what works. | 21:40 |
| jrosser | cool - you can really make it however you need, if the ansible/ssh interface is not br-mgmt you can change that | 21:41 |
| jrosser | but `management_address` is used in a whole ton of places so it's important that references the right thing | 21:42 |
| platta | I’m running all the playbooks from inside the host, so I think it should work. What I’ve also built is a playbook that prepares the host for me, kind of like my own version of the playbook bootstrap-aio.sh runs. | 21:42 |
| platta | Installs packages, clones down the repo, and uses templates to write out my config files to `/etc/openstack_deploy` | 21:43 |
| jrosser | short answer is that `management_address` is the IP that gets chosen to bind all the various server processes to, and also as you've seen sets complimentary expectations in some services about acceptable incoming address ranges | 21:43 |
| jrosser | and in this case the database is setup to only accept connections from the loadbalancer IP (this of course can also be overidden if you need) | 21:44 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!