| grauzikas | Hello every one, can i simply rerun setup-infrastructure playbok when im using OSA with ceph in it or should i destroy everything and start from begining? | 08:41 |
|---|---|---|
| grauzikas | was not wiped disks :) so ceph ansible was not able to create osd | 08:42 |
| grauzikas | trying to rerun will see what happen | 08:43 |
| noonedeadpunk | so playbooks we have are indempotent | 08:45 |
| noonedeadpunk | though when it comes to ceph-ansible part - I'm not 100% sure as this is a completely separate project we integrate with | 08:45 |
| noonedeadpunk | but also there're standalone playbooks to manage ceph and all other bits included in setup-infrastructure | 08:46 |
| noonedeadpunk | as setup-infrastrcuture just contains bunch of inlcudes of other playbooks: https://opendev.org/openstack/openstack-ansible/src/branch/master/playbooks/setup-infrastructure.yml#L46-L53 | 08:47 |
| grauzikas | if it will fail then will destroy. simply need to test | 08:47 |
| noonedeadpunk | so you can save up some time by running what you need directly | 08:47 |
| grauzikas | yes when i was debuging with neutron i was running seperated neutron task i know that | 08:48 |
| grauzikas | also tryed to use unbound, but it was faling so now trying without it with /etc/hosts, but when i will make all tasks will try again unbound. remembered unbound because i noticed it in most first tasks in your link | 08:49 |
| noonedeadpunk | ah, frankly - haven't tried unbound path in a while.. likely need quite some love, as it's not inlcuded in CI :( | 08:50 |
| grauzikas | if i have different osd drived per servers then i should enter in openstack_user_config like this? | 09:23 |
| grauzikas | https://www.irccloud.com/pastebin/a2pEO9XC | 09:23 |
| noonedeadpunk | grauzikas: | 09:26 |
| noonedeadpunk | so, I'd susggest using host_vars/group_vars | 09:26 |
| noonedeadpunk | you can create a file /etc/openstack_deploy/host_vars/ceph1 | 09:27 |
| noonedeadpunk | and there place a specific variables which should be applied for a host | 09:27 |
| noonedeadpunk | I personally prefer to keep vars out of openstack_user_config, but it's me... | 09:28 |
| grauzikas | ok, and is i want to pass variable to ceph playbook i should add ceph_ in front? like this: ceph_dashboard_admin_password: "{{ ceph_dashboard_admin_password }}" | 09:32 |
| grauzikas | or should i use exact same names like in ceph ansible | 09:34 |
| noonedeadpunk | um, no, I'm not sure about that | 09:34 |
| noonedeadpunk | just use vars names from ceph-ansible directly | 09:34 |
| grauzikas | ok thanks | 09:34 |
| grauzikas | worked, thank you | 09:41 |
| grauzikas | and probably ceph is not included in to haproxy? :) | 09:43 |
| noonedeadpunk | RGW is | 09:43 |
| noonedeadpunk | if you cefine ceph-rgw | 09:43 |
| gokhan | hello folks, I am trying to migrate from lxb to ovs in a test environment. I benefit from https://www.jimmdenton.com/migrating-lxb-to-ovn/ guide. Now on the qg-x and qr-x interface , router gateways aren't created. so on private network ı can not acceess vm. do I need to any change on db ? | 11:06 |
| gokhan | I run MariaDB [neutron]> update ml2_port_bindings set vif_type='ovs' where vif_type='bridge'; | 11:06 |
| gokhan | Query OK, 30 rows affected (0.026 sec) | 11:06 |
| gokhan | Rows matched: 30 Changed: 30 Warnings: 0 | 11:06 |
| * noonedeadpunk thinks that migrating to ovs in 2024 sounds like a weird choice | 11:15 | |
| noonedeadpunk | so, you can't access VMs through floating ips? | 11:15 |
| noonedeadpunk | or they're unreachable via private network between each other? | 11:15 |
| noonedeadpunk | as router kind of not required to communicate between vms on private network | 11:16 |
| kleini_ | A guide to migrate from OVS to OVN would be very helpful btw. | 11:25 |
| *** kleini_ is now known as kleini | 11:25 | |
| noonedeadpunk | oh yes | 11:28 |
| * noonedeadpunk still didn't get to a point of playing with that | 11:28 | |
| noonedeadpunk | but having in a backlog really for a while now | 11:29 |
| gokhan | noonedeadpunk, ı can't access VMs through floating ips, because router gateway is not created in qg interface | 11:29 |
| noonedeadpunk | I guess I'd try to ask neutron folks of what could be preventing that, as I personally no idea about such migration | 11:30 |
| gokhan | why you think that migrating to ovs in 2024 is a weird choice :) because of the fwaas we need to use ovs instead of ovn | 11:30 |
| noonedeadpunk | and would pick lxb over ovs at any time.... | 11:30 |
| noonedeadpunk | oh, so now I know whom I may ask about fwaas :D | 11:31 |
| noonedeadpunk | And, I think, there was a patch for fwaas to work on OVN | 11:32 |
| kleini | I also prefer OVS over LXB. OVS is much easier to debug if issues arise. | 11:32 |
| noonedeadpunk | https://review.opendev.org/c/openstack/neutron-fwaas/+/845756 | 11:32 |
| noonedeadpunk | I kinda completely disagree about debugging issues in OVS... | 11:33 |
| gokhan | noonedeadpunk, yes I see it ı am waiting for it to be merged | 11:33 |
| noonedeadpunk | as amount of issues related to ovs specifically is kind of amazing | 11:33 |
| noonedeadpunk | gokhan: I bet that testing the patch and voting on it (as well as pinging cores) might help to get it landed sooner then later | 11:34 |
| noonedeadpunk | kleini: as we had multiple issues where ovs was misbehaving due to gcc version being used, then OVS upgrades itself are leading to network interruptions, not saying about race conditions when you restart ovs and neutron-opvs-agent at the same time | 11:35 |
| noonedeadpunk | or upgrade packages and restart neutron right after | 11:35 |
| noonedeadpunk | so plenty things i never had on lxb setups... | 11:36 |
| noonedeadpunk | gokhan: but what I meant about choice, is that both canonical and rehat already have migrated all of their deployments to OVN. Last year. So not a lot of enterprises care about ovs I'd say | 11:37 |
| noonedeadpunk | but dunno | 11:38 |
| kleini | sounds like time to migrate to OVN soon | 11:38 |
| noonedeadpunk | I really don't enjoy ovs overall... ovn is great though, imo | 11:38 |
| noonedeadpunk | but, fwiw, we're seems to have a bug for OVN upgrades when you do distro upgrade | 11:39 |
| * noonedeadpunk also in my to do list | 11:39 | |
| gokhan | noonedeadpunk, we are also thinking to migrate ovn, because of vpnaas and fwaas we stopped. we also don't have enough know-how for ovn. we firstly need to test and learn it :) | 11:41 |
| noonedeadpunk | we're already running vpnaas on ovn btw | 12:19 |
| noonedeadpunk | and vpnaas patch is already merged for 2024.1 | 12:19 |
| noonedeadpunk | so it's not an issue on the contrary to fwaas | 12:19 |
| noonedeadpunk | but I guess I don't jsut fully get fwaas either. probably getting traffic filtered on router and not letting it further is nice... but if you're running true DVR with OVN - kinda pointless as security groups does do the same thing pretty much? | 12:20 |
| noonedeadpunk | but not sure what else fwaas does give except blocking traffic earlier | 12:21 |
| noonedeadpunk | so if you can share usecase and your rationale for fwaas - that would be interesting to hear | 12:21 |
| opendevreview | Merged openstack/openstack-ansible stable/2023.2: Bump SHAs for 2023.2 (Bobcat) https://review.opendev.org/c/openstack/openstack-ansible/+/925751 | 12:58 |
| opendevreview | Merged openstack/openstack-ansible stable/2023.1: Bump SHAs for 2023.1 (Antelope) https://review.opendev.org/c/openstack/openstack-ansible/+/925792 | 13:09 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Do not install Skyline with os-infra_hosts https://review.opendev.org/c/openstack/openstack-ansible/+/926070 | 15:28 |
| opendevreview | Merged openstack/openstack-ansible stable/2024.1: Bump SHAs for 2024.1 (Caracal) https://review.opendev.org/c/openstack/openstack-ansible/+/925732 | 18:52 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!