| oli | tafkamax: We have ours set up with dual nic > bond0 > bond0.30 > bridge30 for vlan30 ( openstack API network ). In globals.yml we set network_interface: bridge30 and neutron_external_interface: bond0, then we create vlan networks in openstack. and trunk down to the compute node what vlans we want to be allowed | 08:07 |
|---|---|---|
| tafkamax | Thank you for the information! | 08:09 |
| tafkamax | How do you make the VLAN-s in openstack? I can not find a guide for that for the life of me | 08:16 |
| opendevreview | Maximilian Stinsky proposed openstack/kolla-ansible master: Implement neutron-ovn-vpn-agent https://review.opendev.org/c/openstack/kolla-ansible/+/924575 | 08:24 |
| opendevreview | Sven Kieske proposed openstack/kolla-ansible stable/2024.1: fix flake8 error in database_shards.py https://review.opendev.org/c/openstack/kolla-ansible/+/925737 | 08:30 |
| opendevreview | Sven Kieske proposed openstack/kolla-ansible stable/2023.2: fix flake8 error in database_shards.py https://review.opendev.org/c/openstack/kolla-ansible/+/925738 | 08:31 |
| opendevreview | Sven Kieske proposed openstack/kolla-ansible stable/2023.1: fix flake8 error in database_shards.py https://review.opendev.org/c/openstack/kolla-ansible/+/925739 | 08:31 |
| SvenKieske | bbezak, mnasiadka, frickler: I wrote down some questions for kolla meeting on what's our plan for future slurp upgrades, as I think there's some room for improvement, or maybe I missed some information: https://etherpad.opendev.org/p/KollaWhiteBoard#L81 | 09:00 |
| frickler | SvenKieske: tbh I don't care much about slurp, it will just make deployers delay doing updates even more | 09:05 |
| kevko | frickler: can u approve https://review.opendev.org/c/openstack/kolla-ansible/+/924548 please ? | 09:05 |
| SvenKieske | frickler: well I can certainly understand that feeling, nevertheless, if we built support for slurp into the release, people will inevitably use it and complain if it breaks in the future :) | 09:06 |
| Core4227 | Guys I'm running into issues integrating keycloak with keystone. I followed the kolla guide and configured it now, I head to horizon, it forwards me to keycloak and authenticate, on redirection to keystone:5000/redirect_uri , it says "OPENID Connect Provider error: Error in handling response type"? Any pointers ple | 09:06 |
| tafkamax | frickler: We are currently in the final stages of setting up OS via KS and because our team is not big, we have decided to go with SLURP, because we don't need to do 2 big upgrades per year, just the yearly. As slurp releases in the spring, we can do it at summer when lots of ppl are on vacation. | 09:08 |
| tafkamax | As we need to focus our resources elsewhere aswell. | 09:08 |
| frickler | sure, I just need to focus my resources elsewhere, too | 09:09 |
| SvenKieske | tafkamax: you still need to read all renos for alle intermediate releases and act on them, you're just compressing the work of two upgrades into one and thus multiply the risk for failure :) | 09:09 |
| SvenKieske | all* | 09:09 |
| tafkamax | Hmm true | 09:09 |
| SvenKieske | it's of course possible, and sometimes there is just no other option (blame it on your org chart I guess), but you can't make work magically disappear by going slurp, that's an illusion :) | 09:10 |
| SvenKieske | in the best cases I guess you can get away with it and just get lucky ;) | 09:11 |
| SvenKieske | Core4227: did you follow the OpenID guide? which release are you on? are you installing latest stable versions from git as recommended? https://docs.openstack.org/kolla-ansible/latest/reference/shared-services/keystone-guide.html#setting-up-openid-connect-via-kolla-ansible | 09:12 |
| SvenKieske | see here for how to install properly (many people still install from pypi, not from git and are missing bugfixes this way): https://docs.openstack.org/kolla-ansible/2024.1/user/quickstart.html#install-kolla-ansible | 09:13 |
| Core4227 | SvenKieske Yes I followed that guide and setup-identity-provider docs from kolla | 09:15 |
| Core4227 | what logs should I look at for more info | 09:16 |
| SvenKieske | I fuzzily remember someone else also having problems with openid and keycloak, but I'm not sure it was a kolla bug or something else.. | 09:18 |
| SvenKieske | which openstack release do you use? | 09:19 |
| Core4227 | SvenKieske I'm doing Antelope | 09:21 |
| Core4227 | and I always do source install | 09:21 |
| Core4227 | 2024-08-06 08:06:24.938841 oidc_check_config_openid_openidc: the URL scheme (http) of the configured OIDCRedirectURI SHOULD be "https" for security reasons (moreover: some Providers may reject non-HTTPS URLs) | 09:34 |
| Core4227 | this is the only thing I see in Apache log | 09:34 |
| tafkamax | Ah yes I think I had similar issue | 09:35 |
| tafkamax | we were testing without TLS certs | 09:35 |
| tafkamax | * TLS certs and http | 09:35 |
| Core4227 | I'm doing with HTTP only too | 09:36 |
| tafkamax | If we added everything with https it went away. | 09:36 |
| tafkamax | But that was some time ago and I was not the one who configured it, but I remember that non-HTTPS url issue. | 09:36 |
| Core4227 | even with self signed ones? | 09:37 |
| tafkamax | We didn't use self signed ones so I can not vouch if it will work :/ | 09:37 |
| tafkamax | You could test it. | 09:37 |
| Core4227 | yep will do and update back. | 09:39 |
| Core4227 | if I do kolla-ansible certificate and reconfigure the services, will that be enough? | 09:41 |
| tafkamax | I don't know :/ | 09:48 |
| Core4227 | Found out the guide to do it. Reconfig is in progress, I'll update once it completes | 09:50 |
| SvenKieske | would maybe worth a bug report if http is not working | 09:51 |
| SvenKieske | not sure though why you would want http support outside of labs | 09:51 |
| SvenKieske | and even in labs, if you don't test https before prod you have a problem anyway | 09:51 |
| Core4227 | yep, you're right. | 10:19 |
| Core4227 | I'm still seeing the same error, so I think I'm missing something else | 10:50 |
| kevko | SvenKieske: regarding https://review.opendev.org/c/openstack/kolla-ansible/+/924548 << why do you think it needs release note ? | 10:56 |
| SvenKieske | kevko: I was actually not 100% sure, but don't external ceph users need to adjust their deployment to the new variable names? I rarely use this without wrappers handling all the stuff, so I'm not sure though | 11:53 |
| kevko | SvenKieske: no ..it was also discussed in a comments ... it's libvirt secrets ...they used uuid ...it's not changed .. . | 11:58 |
| kevko | SvenKieske: only the names are changed to be more clear ...and description added ... users don't need to know about anything ... | 11:59 |
| opendevreview | Merged openstack/kolla-ansible master: heat: set backups_enabled based on cinder-backup https://review.opendev.org/c/openstack/kolla-ansible/+/918455 | 12:01 |
| SvenKieske | kevko: alright | 12:02 |
| kevko | SvenKieske: in original refactor the names were client.nova and client.cinder ....so in my refactor code i changed to be {{ var }} from ansible ...but then I realized that cephadm jobs are failing ...because by default cinder_user and nova_user are same in kolla (in my setup it was working ..because i don't use same users ) ....so on the end | 12:05 |
| kevko | libvirt secrets rendered as two client.nova (so one rbd uuid replaced another .... and that's it) -- because of {{ var }} render .... so this point me to create new patch before the refactor WHICH will define different name and add description ..to be clear for the future .... | 12:05 |
| kevko | TLDR - i realized that it depends only on UUIDs in libvirt secret ...but client.nova and client.cinder were just confusing ... | 12:06 |
| kevko | so in fact it's just cosmetic change but it will bring light into this ... | 12:07 |
| PrzemekK | Can someone write how much CPU/Memory mid size enviroment is using for rabbitmq ? | 13:45 |
| SvenKieske | PrzemekK: I guess that depends on your definition of "mid size" ;) | 14:14 |
| PrzemekK | @SvenKieske something like 3 controllers, 4 gw and 10+ Compute - standard services on openstack - Maybe Someone can check how much rabbit takes - "docker stats --no-stream" | 14:42 |
| SvenKieske | depends essentially on how much load you put onto rabbitmq, so basically: how much activity do you expect? e.g. k8s workload which maybe dynamically creates networks, vms, security groups, load balancers etc.? Or just some static workload that doesn't change much? | 14:56 |
| SvenKieske | I assume you already read https://www.rabbitmq.com/blog/2020/06/18/cluster-sizing-and-other-considerations ? | 14:59 |
| PrzemekK | @SvenKieske yes i read this article and by default rabbit use 40% of ram and shutdown - But my rabbitmq admin configured 2vcpu / 4 GB ram so i wanted to know what values are on different enviroments | 15:12 |
| SvenKieske | that depends, in the end on the number of messages, which depends on how much messages are sent via openstack services, which depends on workload activity on your openstack installation. | 15:15 |
| SvenKieske | you can have huge installs which are static which might get away with a relative small rmq setup. and you can have small installed sizes where constantly workload is shifting around (cloud like, ha!) which will put more stress on rmq | 15:16 |
| SvenKieske | also it depends on the used setup: quorum queues, ha queues, etc. | 15:16 |
| PrzemekK | current kolla-ansible releases = quorum queues :> I saw some change related different queues. Anyway for now i received information that current utilization o 700-900MB ram and about 15% CPU (2 vcpu) | 15:22 |
| opendevreview | Victor Morales proposed openstack/kolla master: Add rust dependencies required by bcrypt https://review.opendev.org/c/openstack/kolla/+/925827 | 23:33 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!