| opendevreview | Ivan Halomi proposed openstack/kolla-ansible master: Refactor of docker worker https://review.opendev.org/c/openstack/kolla-ansible/+/908295 | 07:40 |
|---|---|---|
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: Run ML2/OVS agents processes in separate containers https://review.opendev.org/c/openstack/kolla-ansible/+/864780 | 08:12 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: Run ML2/OVS agents processes in separate containers https://review.opendev.org/c/openstack/kolla-ansible/+/864780 | 08:12 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: Run ML2/OVS agents processes in separate containers https://review.opendev.org/c/openstack/kolla-ansible/+/864780 | 08:15 |
| opendevreview | Wenping Song proposed openstack/kolla-ansible master: Fix the ansible intro_inventory.html link https://review.opendev.org/c/openstack/kolla-ansible/+/913624 | 09:21 |
| guesswhat[m] | Enable the Implicit flow (this one allows you to use the OpenStack CLI with oidcv3 plugin) ( https://opendev.org/openstack/kolla-ansible/src/branch/stable/2023.2/doc/source/contributor/setup-identity-provider.rst ) is it still true ? | 10:18 |
| opendevreview | Michal Arbet proposed openstack/kolla-ansible master: Fix installation of ovs-dpdk service https://review.opendev.org/c/openstack/kolla-ansible/+/913653 | 10:45 |
| opendevreview | Merged openstack/kolla-ansible master: Fix the ansible intro_inventory.html link https://review.opendev.org/c/openstack/kolla-ansible/+/913624 | 10:47 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: Run ML2/OVS agents processes in separate containers https://review.opendev.org/c/openstack/kolla-ansible/+/864780 | 11:08 |
| opendevreview | Jakub Darmach proposed openstack/kayobe master: Use new collections in Kayobe https://review.opendev.org/c/openstack/kayobe/+/910742 | 11:08 |
| halomiva | hey, i have bad news about this patchset https://review.opendev.org/c/openstack/ansible-collection-kolla/+/910751 in the end it was just partial solution because we install docker using pip only in virtual environments and during zuul doesn't use them so it means it fails on the same problem, I looked for solution but it seems that ubuntu/debian only support package version 5.0.3 of python3-docker. I see there is some osbpo repository used in p | 11:16 |
| halomiva | would it be possible to add it also to docker and add there newer release of python3-docker package ? or how should i deal with this problem? | 11:16 |
| Fl1nt | Hi everyone | 12:41 |
| Fl1nt | When doing a tox -e genconfig, tox complain that stevedore.named can't find kolla namespace, any idea? I'm trying to generate kolla-build.conf sample config file, but it seems there is something missing. Using 15.6.0 tag. | 12:42 |
| frickler | Fl1nt: iirc there was an issue with tox >= 4, can you check your tox version? | 12:44 |
| Fl1nt | ah! ok, 4.14 | 12:44 |
| Fl1nt | I guess I need to use below 4 then right? | 12:44 |
| Fl1nt | testing right now | 12:45 |
| Fl1nt | frickler, seems it work, perfect, thanks! | 12:46 |
| Fl1nt | oof ><' python plumbing seems to have a hard time. | 12:52 |
| Fl1nt | python is now complaining about setuptools and buildeggs being deprecated | 12:52 |
| mnasiadka | These are only warnings | 12:52 |
| Fl1nt | https://paste.opendev.org/show/bueuqo1OMa3KOAYssKoq/ | 12:54 |
| Fl1nt | mnasiadka, it completely broke on my run | 12:54 |
| mnasiadka | Please raise a bug then | 12:54 |
| Fl1nt | I was looking for humans in here first as sometimes you know things broke but just because of the doc informations being deprecated. | 12:56 |
| Fl1nt | BTW: What is kolla plan for RPM based build? Is the plan to abandon and switch to DEB based? How is the transition happening? Does kolla still support CentOS while transitioning to Rocky? | 12:57 |
| Fl1nt | mnasiadka, bugs tickets created: https://bugs.launchpad.net/kolla/+bug/2058385 & https://bugs.launchpad.net/kolla/+bug/2058383 | 13:17 |
| mnasiadka | We are not abandoning RPM | 13:23 |
| mnasiadka | We don't support CentOS 9 officially, but we have jobs that build and deploy on that distro, because that's a good prognostic of failures in EL9 ;-) | 13:23 |
| r3ap3r | Fl1nt, see the second "note" in this link regarding CentOS 9 Stream: https://docs.openstack.org/kolla-ansible/latest/user/support-matrix.html | 13:34 |
| r3ap3r | I wasn't sure what version you were trying to build so I just grabbed the latest docs. | 13:35 |
| SvenKieske | thanks for pointing to the docs, was in the process of doing the same | 14:25 |
| r3ap3r | SvenKieske np. :-) | 14:31 |
| opendevreview | Victor Morales proposed openstack/kolla-ansible master: Ensure that nova scheduler runs before refesh it https://review.opendev.org/c/openstack/kolla-ansible/+/913277 | 14:34 |
| Fl1nt | mnasiadka, ok thanks | 14:41 |
| Fl1nt | @r3ap3r, yeah I've already read these pages, hence my questions as it is a bit disturbing to get an ok answer for host but not for image. | 14:42 |
| Fl1nt | r3ap3r, :D | 14:42 |
| SvenKieske | why is that disturbing? | 14:42 |
| Fl1nt | Because docker images shouldn't care at all about host OS indeed. | 14:43 |
| SvenKieske | yeah and in theory, theory and practice are the same, but in practice they are never the same :) | 14:44 |
| SvenKieske | it begins with the kernel being used, which bleeds into every container. then the kolla containers are more like mini distros, not pure docker containers, as I'm pretty sure you know already. | 14:44 |
| SvenKieske | almost nobody runs docker containers like they "should be" run, that is, with a single binary inside it, and nothing else. | 14:45 |
| SvenKieske | I guess you could try bootstrap kolla in distroless containers and see if that works. but then again, if you don't need a distro and just have single binaries, you also don't need centos support in the container? | 14:46 |
| SvenKieske | but the docker best practices are unclear to begin with: https://docs.docker.com/develop/develop-images/guidelines/ so not really any advice you can follow easily. ¯\_(ツ)_/¯ | 14:51 |
| Fl1nt | SvenKieske, yep just my point, I'm wondering if someone already tried to build using distroless-python already. | 14:53 |
| SvenKieske | I don't think so, one of the many problems you will run into is, that many many applications assume a working linux/unix env | 14:53 |
| Fl1nt | SvenKieske, I'm not really following Docker best practices, just underlying technology way to work tho. | 14:53 |
| SvenKieske | e.g. fernet tokens in keystone are renewed with cron, so you need cron, but you don't get notified about any errors in cron, because the default cron mechanism for error logging is to mail the root account, so you need mail, in theory. | 14:54 |
| SvenKieske | elasticsearch/opensearch is sensible to LANG_* settings in env | 14:55 |
| SvenKieske | the list goes on and on. you can of course replicate all this stuff on a per container basis | 14:55 |
| Fl1nt | but anyway, right know my concerns are more related to CentOS Stream 9 build being so unrelayable so far on our side but I'm checking if it's related to our environment or the build process overall. Hence why I'm trying to build everything on my servers with a fully connected to public internet env. | 14:55 |
| Fl1nt | s/unrelayable/unreliable/ | 14:56 |
| SvenKieske | basically, docker is an elaborate way to contain the dependency chain issues modern systems have. at least that is what's it used for in many of infrastructure systems. many of the other advantages are not being used, because it's hard to do so, and a lot of work, that nobody has done so far. | 14:56 |
| SvenKieske | is your end goal running centos stream in prod? or is this more a canary for RHEL/other EL distros? | 14:57 |
| Fl1nt | We already run a very large cluster installation using CentOS since a long time now | 14:57 |
| SvenKieske | I don't want to discourage you but I hear quite often centos stream itself is breaking - as I would expect by it's nature as rhels new upstream dev env - | 14:57 |
| SvenKieske | most people I know switched to alma or rocky | 14:58 |
| SvenKieske | that's why we have those images as well | 14:58 |
| SvenKieske | that being said, if we support users building their own images with stream, at least that part should work | 14:58 |
| Fl1nt | Rocky and Alma are shitty broken replacement (excuse the language), we benchmarked them against CentOS Stream 9 on Snapshots, they're really not usable. | 14:58 |
| SvenKieske | interesting :) I don't use any of the *EL world since..10 years (I used scientifc linux back then) | 14:59 |
| Fl1nt | Most of Rocky and Alma repo are indeed CentOS repos tbh :D | 14:59 |
| SvenKieske | what's broken about them? Performance? Or Usage Regressions? | 14:59 |
| Fl1nt | Usage regression, need a lot of workarounds for repos etc. | 15:00 |
| Fl1nt | we've another small debian based cluster, but gosh debian can't support correctly enterprise level HW... | 15:00 |
| SvenKieske | yeah the ootb experience with hardware is better, well with newer kernels (and prop. firmware in some debian instances) | 15:01 |
| r3ap3r | CentOS Stream is not a point release distro. That is like a project saying we support CentOS 9 Stream and deploying Fedora and expecting it to work. Rocky Linux, Alma, RHEL, etc... are all "downstream" of CentOS Stream. The binaries are "newer" than the point release distros are "older". Your experiences between the two are going to be different. Not meant to be an "attack" but just trying to clarify what seems to be a | 15:01 |
| r3ap3r | misconception. | 15:01 |
| Fl1nt | Debian do partial support and implementation of HW, but I do cope with that as they're 100% fully benevolent, not Enterprise backed. | 15:02 |
| SvenKieske | oh you would be surprised how many companies work on debian, some hide behind gmail.com addresses though :D | 15:02 |
| SvenKieske | I would just use upstream LTS kernels and move on, but well, not everyone can do that | 15:03 |
| Fl1nt | r3ap3r, we've an internal product similar to artifactory but on steroid, as we're 100% offline installation, we do point in time installation using CentOS, everything is fine once your CI/Build pipeline do complete. | 15:03 |
| SvenKieske | nothing beats a custom gentoo build, but who has time for that these days? | 15:03 |
| r3ap3r | Fl1nt, that doesn't make your CentOS deployment point release though. Your CentOS deployment will still be incompatible with point release distros. | 15:04 |
| SvenKieske | we should imho also start looking into what it takes to support tox4, but I guess this is already happening somewhere in the opendev ecosystem, at least I saw some mails around this topic | 15:04 |
| Fl1nt | r3ap3r, this not a misconception at all, we do work really closely with RHEL on many topics as we do are using it heavily on customers products, so we do now how CentOS is working, and honestly it's way much more stable than supposedly stable enterprise distro such as ubuntu where canonical sneakily swap packages that need patches without changing the verisons and then crash the apt checksums. | 15:05 |
| SvenKieske | r3ap3r: I guess they don't care about point release compatibility, they just want something stable. if you mirror complete packages, versioned, you can basically build your own stable distro this way | 15:05 |
| SvenKieske | we did basically the same thing with varying degress of success in the long term at some former company. you need to watch which packages you really support, because the support burden can quickly grow out of hand | 15:07 |
| Fl1nt | We could basically replicate the whole CentOS Stream Build system and it would achieve 100% matching artifact, we just skip this part and basically do our own point in time distro using various advanced tools | 15:07 |
| SvenKieske | isn't all you need basically an aptly mirror? I forgot the name of the rhel counterpart. you can do snapshots there and basically install any version of any package ever hitting the mirrors. then you cut release images, test them. implement upgrade tests for important packages, do upgrades, release new images, done | 15:08 |
| Fl1nt | so basically we use a CentOS Stream 9 consistent and coherent installation properly freezed | 15:09 |
| SvenKieske | yep | 15:09 |
| SvenKieske | it start's getting unmaintainable for most companies once you seriously want to address security issues though, at least for smaller orgs. | 15:10 |
| SvenKieske | but that might not be an issue, either due to small images (less packages), or a large org, or very good automation. | 15:10 |
| Fl1nt | We do that internally as our solution do support many more than just CentOS, we do it for Ubuntu/CentOS/Oracle Linux/RHEL/Debian and HTTP/git/rpm/deb/whatever based sync packages | 15:10 |
| Fl1nt | Basically, we can't trust anything and can't get internet access, so all in all everything is sync/analyzed/build/used internally. | 15:11 |
| SvenKieske | it will be interesting though how distro kernels respond to https://lore.kernel.org/linux-cve-announce/ I bet we will see basically daily kernel updates, at least twice per week :D | 15:11 |
| r3ap3r | SvenKieske, what I was bringing up was more to address the thinking of "since CentOS is supported as a host for the containers, the CentOS based container images should work too" which is a faulty thought process since the point release binaries never really align with the CentOS binaries since they are essentially "beta" versions of what is in the point releases. Before the packages from CentOS are brought into the point | 15:12 |
| r3ap3r | releases, they are "massaged" and function tested to ensure compatibility and stability. We can't just assume they work because CentOS is upstream of the point releases. | 15:12 |
| Fl1nt | we could do it if required as we can completely manage our whole pipeline schedule, right know we do it every week with everything related to core distribution package being monthly based signature snapshots and then everything security related is weekly based. | 15:13 |
| r3ap3r | Same thing happens when they bring packages from Fedora to CentOS. Just because something works in CentOS, doesn't necessarily means it will work in Fedora. | 15:14 |
| Fl1nt | yes ABI/API/etc compatibility, hence why I'm trying to fix this specific bug that I'm chasing right now. | 15:15 |
| SvenKieske | this just shows how broken both concepts are: the "stream release" and "pin software version foo in my container and I'm fine" :D | 15:15 |
| Fl1nt | but in our case that doesn't really matter as all our stack is using the coherent release system. | 15:15 |
| SvenKieske | I don't understand your centos<-> fedora comparison. usually it's the other way around: centos stream is cut from fedora and fedora packages are brought into centos, not the other way around. | 15:16 |
| SvenKieske | fedora always was the dev upstream for rhel | 15:16 |
| SvenKieske | well not always, but since a very long time | 15:16 |
| r3ap3r | SvenKieske, the comparison is the equivalent of what Fl1nt is attempting to do with the Kolla containers. They are tested and built on Rocky Linux 9 but they want them to work on CentOS Stream. That is like trying to get something that works in CentOS Stream to work in Fedora. They are downstream from eachother, hence why the expectation of something from downstream to work upstream is a misnomer. | 15:18 |
| Fl1nt | Is there a reason why we don't put ansible on the matrix page for kolla and kolla-ansible? | 15:18 |
| Fl1nt | r3ap3r, hence why on any run of our system any downstream patch is then reported and contributed back to the upstream, that then, if they want do something with them. | 15:19 |
| Fl1nt | like for designate for instance... | 15:19 |
| kevko | Fl1nt what is very large cluster ? | 15:19 |
| Fl1nt | kevko, more nodes than a public european hosting provider for instance. | 15:20 |
| SvenKieske | ah understood now | 15:20 |
| SvenKieske | regarding ansible: I think it was somewhere, but I guess it's in the getting started or installation tutorial. I _think_ we also have prechecks now that check if the ansible version matches expectations and throws an error if not | 15:21 |
| kevko | Fl1nt: how many has public european hosting provider ? :D | 15:21 |
| r3ap3r | Fl1nt, seems sensible. | 15:21 |
| Fl1nt | SvenKieske, yep I know where to find the info, but it always seems a bit odd to me to get a matrix page about storage/base image but not any tools that actually build/generate all of that. | 15:23 |
| SvenKieske | Fl1nt: there you are: https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html#install-dependencies-for-the-virtual-environment | 15:23 |
| SvenKieske | as you know: PRs welcome. I just recently improved some little parts in the docs, but docs are not loved by most devs it seems. it's also hard to get reviews for docs only patches imho :-/ | 15:23 |
| SvenKieske | I guess most customers don't like to pay for explicit docs stuff, but complain when they are not there | 15:24 |
| SvenKieske | weird world, isn't it? :) | 15:24 |
| Fl1nt | SvenKieske, I could do doc review tho as our main feedback on the platform is about the openstack doc :D | 15:25 |
| SvenKieske | mhm, if you google for "kolla supported ansible versions" the first link goes to our github mirror, where the version isn't even rendered.. https://github.com/openstack/kolla-ansible/blob/master/doc/source/user/quickstart.rst | 15:25 |
| SvenKieske | guess github doesn't really support restructured text | 15:26 |
| Fl1nt | I mean, our customers of the platform do complain a lot about it, I'm myself used to it as I work with OS since cactus release. | 15:26 |
| SvenKieske | then I guess my sentence still applies: customers complain but don't want to pay for improvement :D | 15:27 |
| Fl1nt | kevko, OVH have over 400K servers split upon 41 Datacenters, we do have ~128 of them. I'll let you project it :D | 15:29 |
| Fl1nt | SvenKieske, I do it when I have time, like today... but you know how it is when you're working ^^ | 15:30 |
| SvenKieske | well, that reminds me about this burned out ovh "datacenter" :D (stacked containers with wood, which burns really good it seems) | 15:30 |
| SvenKieske | I hope your DC design is better then OVHs ;) | 15:30 |
| Fl1nt | yep, that was a glorious fire :D | 15:30 |
| SvenKieske | well they are dirt cheap, I guess you get what you pay for | 15:31 |
| Fl1nt | SvenKieske, on the most critical yes, definitely, on some others... meh :D | 15:31 |
| Fl1nt | Pay peanuts get monkey yep | 15:31 |
| SvenKieske | I only knew complete concrete building DCs with guards and stuff, seeing this the first time blew my mind. I mean I know about the containerzed DC that you can put on a truck, but how on earth can you use wood in the supporting construction? | 15:32 |
| opendevreview | Merged openstack/kolla-ansible master: Revert "Pin zun jobs to Docker 20" https://review.opendev.org/c/openstack/kolla-ansible/+/904093 | 15:32 |
| SvenKieske | "move fast and break things" :D | 15:32 |
| SvenKieske | dc edition | 15:32 |
| Fl1nt | SvenKieske, that's what you get when you fall for any weird concept such as greenscore... | 15:33 |
| SvenKieske | well I guess you can build a "green" DC and maybe even with certain wood stuff, if you have a good concept and people knowing their stuff (I know about a - afaik - 14 stories high wooden building in Hamburg, which is as fire resistant as a concrete building) | 15:34 |
| SvenKieske | but you need to have equipment, staff and excellent planning/time for such stuff. and I bet it's not cheap | 15:35 |
| SvenKieske | it's 18 floors, actually: https://suelzle-stahlpartner.de/en/references/housing-construction/germanys-highest-wooden-house/ | 15:36 |
| opendevreview | Merged openstack/kolla-ansible master: Zun: remove docker's cluster-store option https://review.opendev.org/c/openstack/kolla-ansible/+/904164 | 15:37 |
| opendevreview | Merged openstack/kolla-ansible master: Revert "zun: Deprecate Zun provisionally" https://review.opendev.org/c/openstack/kolla-ansible/+/904094 | 15:37 |
| Fl1nt | Wood per see ain't the issue as you point out ^^ | 15:38 |
| SvenKieske | well, the ground stuff is still concrete | 15:38 |
| SvenKieske | incompetent people will find a way to even burn down a fire resistant building I guess ;) | 15:39 |
| Fl1nt | yep, totally, but as long as they learn to not repeat the issue I'm fine with that ^^ | 15:40 |
| Fl1nt | although OVH is... not learning anything... | 15:40 |
| Fl1nt | they've a large OS cluster too btw | 15:40 |
| SvenKieske | yeah I know. I found their talk about backing up ceph quite interesting (I believe it was at fosdem some years ago) | 15:41 |
| opendevreview | Merged openstack/kolla-ansible master: Fix Skyline API Server TLS configuration https://review.opendev.org/c/openstack/kolla-ansible/+/909329 | 15:41 |
| SvenKieske | they actually do also some upstream work here and there, could be more I guess, but well. you take what you get. | 15:41 |
| opendevreview | Merged openstack/kolla-ansible master: Skyline configure Prometheus https://review.opendev.org/c/openstack/kolla-ansible/+/910514 | 15:41 |
| Fl1nt | Fun fact, CEPH Erasure Code come from one of my old team btw :D | 15:45 |
| Fl1nt | the erasure code part not the whole CEPH I mean :D | 15:47 |
| Fl1nt | Thanks everyone for this discussion, was cool ^^ see you later folks! | 15:56 |
| opendevreview | Martin Hiner proposed openstack/kolla-ansible master: Add container engine migration scenario https://review.opendev.org/c/openstack/kolla-ansible/+/836941 | 16:14 |
| guesswhat[m] | How is this relevant https://docs.openstack.org/kolla-ansible/latest/reference/storage/external-ceph-guide.html ? Seems that keyring names are changed https://github.com/openstack/kolla-ansible/blob/0b820f10e084a650950f144772993d8afbed247c/releasenotes/notes/multiple-ceph-backends-913051631c6e69ee.yaml#L15 | 16:33 |
| kevko | guesswhat[m]: its'not | 16:37 |
| kevko | guesswhat[m]: keyring names are just refactored ... nothing changed for user | 16:38 |
| kevko | guesswhat[m]: only if he wants to support several ceph clusters | 16:38 |
| guesswhat[m] | @kevko i have troubles with TASK [nova-cell : Copy over ceph cinder keyring file] The error was: 'dict object' has no attribute 'stat'. 'dict object' has no attribute 'stat'\n\nThe error appears to be in '/usr/local/share/kolla-ansible/ansible/roles/nova-cell/tasks/external_ceph.yml' | 16:47 |
| guesswhat[m] | but the /etc/kolla/config/nova/ceph.client.cinder.keyring file exists | 16:47 |
| guesswhat[m] | have it, seems that its because cinder_backend_ceph is disable, altough I am trying to enable it in different way | 16:50 |
| guesswhat[m] | any idea, how to skip this https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/cinder/templates/cinder.conf.j2#L148 ? cinder_ceph_backends: [] does not work | 16:51 |
| kevko | guesswhat[m]: wait | 16:52 |
| kevko | guesswhat[m]: you are trying to setup something really anti-pattern | 16:54 |
| kevko | guesswhat[m]: if you want to omit backend config for cinder_ceph_backend ...just turn off cinder_backend_ceph <<< | 16:54 |
| guesswhat[m] | 1. ) i have multiple pool names, kolla configuration does not solve this, cinder_ceph_backend has to be enabled, otherwise the error ^^^ | 16:55 |
| kevko | guesswhat[m]: what ? of course it solve | 16:56 |
| kevko | guesswhat[m]: okay, i can help you as i am author of that patch :) | 16:57 |
| kevko | guesswhat[m]: what is your ceph_cinder_user: "cinder" and ceph_nova_user: "nova" | 16:58 |
| guesswhat[m] | thats not a problem | 16:58 |
| kevko | guesswhat[m]: what is the problem ? you can use config-override ...so... | 16:59 |
| guesswhat[m] | this is not possible to set https://github.com/openstack/kolla-ansible/blob/0b820f10e084a650950f144772993d8afbed247c/ansible/roles/cinder/templates/cinder.conf.j2#L152 | 16:59 |
| guesswhat[m] | thus, if you want to have multiple backends, you have configure cinder_ceph_backends and also have override files, which is ... | 17:01 |
| SvenKieske | kevko: have you ever seen "Inappropriate ioctl for device" in the socat mariadb clustercheck? | 17:08 |
| mnasiadka | SvenKieske: everybody has seen that, socat logging is crap | 17:20 |
| mnasiadka | sometimes I think it would be better if that crap would not log anything :) | 17:20 |
| SvenKieske | xD it totally tripped me up and let me look in the wrong direction.. | 17:25 |
| SvenKieske | when do we replace this with proxysql again? :D | 17:25 |
| mnasiadka | I'm ok with defaulting to proxysql | 17:37 |
| mnasiadka | just somebody raise that patch please | 17:37 |
| mnasiadka | and people that love clustercheck can change enable_proxysql to false ;) | 17:37 |
| SvenKieske | I guess I even have a clue why socat dumps these logs. I think it's because haproxy does an HTTP check and afaik socat knows nothing about http and complains about the unclean connection shutdown because it can't unwind an http connection.. | 17:55 |
| SvenKieske | but it's only a wild guess, I'm not deeply familiar with socats protocol support, I would not be surprised if it speaks native http | 17:55 |
| guesswhat[m] | kevko: this is missing from your patch https://pastebin.com/raw/FcWrSbvX | 18:19 |
| Lockesmith | jovial, it looks like I actually screwed up a trunk group assignment. I'm not sure why that was causing the weird interaction and not just stopping all traffic, but fixing that appears to have gotten things running. Thanks for your time in troubleshooting this! | 19:25 |
| kevko | guesswhat[m]: no ! even if you leave cinder_ceph_backends as it is in defaults ...you can create /etc/kolla/config/cinder/cinder-volume.conf and place your [rbd-X] -> with configs as your override ...and service will be overconfigured with user specified override | 22:33 |
| kevko | guesswhat[m]: well, but there is a patch waiting for review which is solving this out-of-the box https://review.opendev.org/c/openstack/kolla-ansible/+/907166 << but it doens't mean that you can fullfill it with config override kolla already provides ... | 22:36 |
| kevko | guesswhat[m]: after those patch you have freedom to specify ceph cluster, user, rbd pool for every ceph cluster you would like ... | 22:38 |
| kevko | for all services and also for every single compute node ..if you want ...we are using it for splitting AZs and storages ... | 22:39 |
| kevko | (for one customer) | 22:39 |
| opendevreview | Michal Arbet proposed openstack/kolla-ansible master: Switch mariadb's loadbalancer from HAProxy to ProxySQL https://review.opendev.org/c/openstack/kolla-ansible/+/913724 | 22:52 |
| kevko | SvenKieske: don't use mariadb clustercheck ... using proxysql for years from stein | 22:53 |
| kevko | SvenKieske: mnasiadka: https://review.opendev.org/c/openstack/kolla-ansible/+/913724 << switch to proxysql :D | 22:53 |
| aravindh | I saw some chatter about replacing the bash in kolla-ansible command with python. Should I try to do this and contribute back? | 23:15 |
| aravindh | if you guys are okay, I would suggest writting the CLI with typer, it makes it way easier to maintain in the long run.. | 23:16 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!