| 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 | 07:51 |
|---|---|---|
| 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 | 07:54 |
| 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:05 |
| opendevreview | Michal Nasiadka proposed openstack/kayobe master: Bump up Ansible supported versions to 6.x/7.x https://review.opendev.org/c/openstack/kayobe/+/878207 | 08:10 |
| Fl1nt | Hi there! | 08:40 |
| Fl1nt | Team, are we seriously implementing such dirty trick in kolla now? https://opendev.org/openstack/kolla/src/commit/6786e4384c1a19e4658310e109b8ab9704f5eff9/docker/kolla-toolbox/Dockerfile.j2#L86 all that for a retry mecanism?? | 08:43 |
| SvenKieske | the change in question: https://review.opendev.org/c/openstack/kolla/+/874588 | 08:45 |
| Fl1nt | timeout is fine, but if remote galaxy endpoint isn't reliable we need to implement a retry correctly... this for loop make me sick a bit ^^ | 08:46 |
| opendevreview | Merged openstack/kolla-ansible stable/zed: opensearch: alter path after using rpm/deb packaging https://review.opendev.org/c/openstack/kolla-ansible/+/883929 | 08:47 |
| Fl1nt | mnasiadka, WTF is this ?? You made me used to a better code quality lol :D | 08:47 |
| mnasiadka | Fl1nt: and how else do you want to retry? | 08:47 |
| Fl1nt | with a variable for amount of retry at first instead of this range :D | 08:48 |
| mnasiadka | and why do you need a variable? | 08:48 |
| Fl1nt | because it can goes over 5 times | 08:48 |
| Fl1nt | Indeed, I myself don't need a retry as it's like with github, it always answer and we don't retry on github :-) | 08:49 |
| mnasiadka | and instead of ranting, could you use your energy to make code better and review other people changes? | 08:49 |
| Fl1nt | Well, that's exactly what I'm doing :D | 08:50 |
| mnasiadka | Exactly you're not doing that | 08:50 |
| mnasiadka | You're coming every n months, complaining about things, instead of working on making things better - that's not what people usually do. | 08:50 |
| Fl1nt | excuse me but each time I've got something wrong I do push patches, then you guys spend 3 months discussing fucking annoying details such as a missing S or spelling and then push things like that, how are we supposed to react????? | 08:52 |
| mnasiadka | Fl1nt: first of all, stop swearing, we're not your local drink buddies | 08:52 |
| mnasiadka | and go blow off your steam somewhere else | 08:52 |
| Fl1nt | I'm not venting, at first it was supposed to be a joke (Don't you read the lol). | 08:56 |
| mnasiadka | "WTF is this ??" is nowhere near being a joke | 08:57 |
| Fl1nt | It is when you read the other part of the sentence, you know, context. | 08:58 |
| opendevreview | Mark Goddard proposed openstack/kolla master: mariadb-clustercheck: ensure /var/log/kolla/mariadb exists https://review.opendev.org/c/openstack/kolla/+/884208 | 08:58 |
| Fl1nt | anyway, I'm currently creating the patch upstream for this but the real issue here is, why do we have retry when it comes to ansible-galaxy when we don't have it on github? Why does this isn't a controlable block? | 09:00 |
| mnasiadka | I don't understand the question, why github is in this context? | 09:01 |
| SvenKieske | I guess, what they try to say is, we don't have retry blocks when pulling stuff from github - aside: do we? - | 09:02 |
| Fl1nt | SvenKieske, exact | 09:02 |
| SvenKieske | I needed to read that 3 times to understand it though. | 09:02 |
| SvenKieske | and regarding spelling mistakes etc in changesets: I sure understand it can be annoying - I was sometimes annoyed by the thorough reviews myself in the past - but it keeps code quality up and the code maintainable | 09:03 |
| Fl1nt | SvenKieske, that exactly the thing that piss me up a bit here, when it comes to some of our (contributors) patches, everyone is focusing on those details, but then when it comes to core contribs, a lot of that quality isn't required anymore, as for wallaby I currently have three different exemples, so ok, I can deal with requirements on spellings and attention to details, but when it's for everyone. | 09:05 |
| SvenKieske | and I have also seen codebases with even more rigor in standards, so it depends where you're coming from. In my old world each bugfix without a clear linked bugreport would not have been merged at all. | 09:05 |
| Fl1nt | SvenKieske, Hence why literally ALL my patches comes with bugreports on launchpad. | 09:06 |
| SvenKieske | it's hard to always apply the same standard, that's true. given that we lack reviewers, especially core, it's sadly natural that core reviewer code tends to get less rigor in code review I would say, because you can't review your own code | 09:07 |
| SvenKieske | so that's always one strict code review missing, by definition, if the code comes from a core reviewer | 09:07 |
| SvenKieske | and of course there's nuance: if it's a new feature it's not as urgent as fixing security bugs etc. | 09:08 |
| SvenKieske | and I guess if you can point out omissions in code review - in a polite way - people will be happy to learn from you :) | 09:09 |
| mnasiadka | we do have retries when pulling from github | 09:10 |
| mnasiadka | it's in curlrc in base image | 09:10 |
| Fl1nt | I guess I didn't had it the nicest way yes, but those things are a bit annoying, just for Wallaby/Xena I'm having over 6 different (minor) patches. | 09:12 |
| Fl1nt | Ok, lets make it more polite then. | 09:13 |
| Fl1nt | so I do propose, that we perform the same way for galaxy, that we do for github. | 09:13 |
| Fl1nt | meaning | 09:13 |
| Fl1nt | retrieve from URL | 09:13 |
| SvenKieske | If I would criticise this retry mechanism I would say the commit is clearly missing _why_ the timeout was increased - probably because there where errors during ansible-galaxy installation due to network problems out of our control - but we'll never know :) | 09:13 |
| Fl1nt | then call ansible-galaxy with local | 09:13 |
| Fl1nt | SvenKieske, I've assumed the why was because ansible-galaxy didn't responded correctly and in time within CI, that's not what actually annoyed me tbh | 09:14 |
| SvenKieske | that's actually maybe an improvement, you could reuse the curl retry semantics from the curlrc. | 09:15 |
| Fl1nt | yes, I'll push the patch today | 09:15 |
| SvenKieske | the downside might be increased code complexity, dunno which one is higher, we'll see in the patch which one is worse I guess :) | 09:19 |
| Fl1nt | TBH, kolla is a professional tool, it should provide ways for enterprise to do things without having to rely on internet anytime, most of enterprise, especially lately, have to conform with executive orders and SBOM etc, to do so we are required to build everything internally, sure we can keep downstream patch for ever, but the more downstream you have the more you drift from community and the more your infra is late in terms of | 09:25 |
| Fl1nt | features/upgrades etc. | 09:25 |
| mnasiadka | kolla is an open source project, leave enterprises out of it | 09:25 |
| Fl1nt | oooh c'mon... | 09:25 |
| Fl1nt | oh many individuals use kolla seriously? | 09:26 |
| Fl1nt | *how | 09:26 |
| mnasiadka | stop thinking kolla is a product | 09:26 |
| Fl1nt | Openstack is a product, kolla is, of course it's open source and community driven, but let's be honest, it's not GNU software era anymore. | 09:26 |
| mnasiadka | I'm fine with improvements for doing installation from local sources, just propose it and let's discuss it in Gerrit if it's the best way forward | 09:27 |
| mnasiadka | but we also have a plan to stop using curl for GitHub | 09:27 |
| mnasiadka | and moving it to kolla/common/sources.py | 09:28 |
| mnasiadka | which you can then easily override in your local installation | 09:28 |
| Fl1nt | mnasiadka, I'm perfecly fine to contribute back to opensources the way it is currently, I'm kinda enjoying it, and the company is letting us do it, so it's win/win. | 09:28 |
| SvenKieske | if enterprises need kolla without internet access, enterprises need to pay devs to make it work I guess? | 09:30 |
| Fl1nt | SvenKieske, yes, that's our job | 09:30 |
| mnasiadka | That would be idiocy to use an open source project in your commercial work and don't allow your staff to contribute back | 09:31 |
| SvenKieske | so as mnasiadka said: kolla is no enterprise tool, unless you paid an enterprise price with an enterpri{s|c}e support contract :D | 09:31 |
| SvenKieske | you would be surprised how many people only use something, never contribute back and then are surprised when the thing stops existing | 09:32 |
| mnasiadka | SvenKieske: I'm not surprised, on every Summit there's a whole room of people using Kolla and not contributing back | 09:32 |
| Fl1nt | SvenKieske, that's definitely not the way we do use it, I complain a lot YES, but I do contribute on all parts that we can improve, and that's the deal with the company, we use Opensource, we do contribute heavily to it. | 09:32 |
| mnasiadka | (and everytime we drop something that people use, but nobody wants to maintain it - they demand that we bring it back, but they don't want to maintain it) | 09:33 |
| Fl1nt | I'm not online everyday for sure, but we do contribute on openstack core/Kubernetes/Linux/OpenVswitch/etc I can't be on all meetings and do patch everything daily, it's not possible by any means. | 09:34 |
| Fl1nt | mnasiadka, I'm happy to maintain everything we've contributed and pushed to kolla, and yes, we do not ask something we won't maintain as it would create dead roles. I was happy we drop a few of them such as qinling/karbor/etc | 09:35 |
| SvenKieske | wasn't there a whole book about this? "tragedy of the commons"? | 09:36 |
| Fl1nt | yes | 09:36 |
| Fl1nt | mnasiadka, regarding the curl drop, what's the reasoning behind that? It looks like kolla-build is more and more becoming a tool of its own. | 09:39 |
| mnasiadka | Fl1nt: we are downloading all openstack sources using that mechanism, so that's nothing new | 09:41 |
| Fl1nt | yes, good reason. | 09:41 |
| mnasiadka | Fl1nt: and we're struggling with updating all components downloaded using curl - this way everything will be in one file and we can easily write a script to check for new versions | 09:41 |
| Fl1nt | At that point, shouldn't we consider having kolla-build a fully ansible based project rather than reinventing the wheel with our own code? | 09:42 |
| Fl1nt | it would bring us the whole ansible power with templating, blocks, conditional etc | 09:43 |
| Fl1nt | and then make it easier for everyone to contribute, that's actually one strength of kolla-ansible | 09:43 |
| mnasiadka | rewriting everything just to achieve the same? :) | 09:44 |
| Fl1nt | That wouldn't be made in a night for sure, but can be made step by step. | 09:44 |
| Fl1nt | I'm fine with both as I can contribute to python code too, I was just thinking to OPS that use kolla/kolla-ansible and that currently contribute because of ansible playbooks but can't on python. | 09:45 |
| Fl1nt | Actually, kolla-toolbox is the perfect exemple, here for what I'm trying to do, being able to leverage jinja on requirements.yml would have been a bliss, as instead of having a cluttered Dockerfile I would continue to call for the current Dockerfile but would have just templated the requirements file. | 09:54 |
| SvenKieske | you can use jinja in python also ;) that being said I have some sympathy for your argument from an ops perspective, there are some ops who can't/won't contribute to python | 10:56 |
| opendevreview | Mark Goddard proposed openstack/kayobe master: firewalld: make changes less disruptive https://review.opendev.org/c/openstack/kayobe/+/884360 | 11:33 |
| opendevreview | Maksim Malchuk proposed openstack/kayobe master: Fix an issue when user forgot combine custom passwords https://review.opendev.org/c/openstack/kayobe/+/861397 | 11:40 |
| opendevreview | Mark Goddard proposed openstack/kolla-ansible master: Refactor MariaDB and RabbitMQ restart procedure https://review.opendev.org/c/openstack/kolla-ansible/+/884182 | 11:44 |
| opendevreview | Mark Goddard proposed openstack/kolla-ansible master: Apply public firewalld rules immediately https://review.opendev.org/c/openstack/kolla-ansible/+/884365 | 11:49 |
| opendevreview | Gaël THEROND proposed openstack/kolla master: Improve kolla-toolbox offline support. * Use structure that allow for custom package version and base URL. https://review.opendev.org/c/openstack/kolla/+/884368 | 11:55 |
| Fl1nt | SvenKieske, yep, I meant that with the current form of how do we craft the dockerfile, we can't make files that we copy onto the container templated file as it would require us to implement a way for kolla-build to know that he need to process the requirements.yml.j2 first. | 12:00 |
| Fl1nt | mnasiadka, thx, will fix | 12:05 |
| opendevreview | Gaël THEROND proposed openstack/kolla master: Improve kolla-toolbox offline support. https://review.opendev.org/c/openstack/kolla/+/884368 | 12:06 |
| mmalchuk | Fl1nt please read my comments | 12:10 |
| mmalchuk | we shouldn't drop requirements.yml support | 12:11 |
| grami[m] | I thought the whole idea of the override template was to allow people to customise the sections to suit the environments. the above review feels like a single use case rather then a benefit to everyone. | 12:22 |
| Fl1nt | mmalchuk, yes, but it means that for airgapped environment ops have to keep a downstream patched (requirements.yml) file on their directory tree, this can be prone to issues/incompatibilities on version upgrade. | 12:24 |
| Fl1nt | or did I missed something? | 12:24 |
| Fl1nt | grami[m], you mean my review? | 12:24 |
| grami[m] | Fl1nt: Sorry yes your review. | 12:26 |
| Fl1nt | 'cause that's exactly what it do, it create two variables that you can override using template-overrides, don't get it. | 12:26 |
| mmalchuk | Fl1nt you missed mnasiadka comment about enterprises))) | 12:27 |
| Fl1nt | basically, it reproduce the default online behavior and add ability to anyone to change the source URL and package. | 12:27 |
| Fl1nt | mmalchuk, meh? | 12:28 |
| mmalchuk | this is not a solution of the timeouts at first glance! this is completely brokes the default galaxy usage | 12:28 |
| mmalchuk | to work with galaxy server you SHOULD use ansible-galaxy (client) | 12:29 |
| Fl1nt | and?? | 12:29 |
| Fl1nt | this patch do use ansible-galaxy | 12:29 |
| mmalchuk | the requirements.yml is the only place of the requirements | 12:30 |
| mmalchuk | and there are complex syntax | 12:30 |
| Fl1nt | no it's not, per ansible-galaxy documentation: https://docs.ansible.com/ansible/latest/galaxy/user_guide.html#downloading-a-collection-for-offline-use | 12:30 |
| mmalchuk | you can use requirements.yml to leverage timeouts | 12:30 |
| Fl1nt | https://docs.ansible.com/ansible/latest/galaxy/user_guide.html#id10 | 12:31 |
| mmalchuk | complex I mean it support: file, galaxy, git, url, dir, or subdirs. | 12:31 |
| mmalchuk | sorry, please don't teach me galaxy) | 12:32 |
| mmalchuk | CURL is not a way to solve network timeouts for galaxy | 12:32 |
| Fl1nt | yes sure, but in our case what is the issue? I propose a way for offline people to be able to have kolla-toolbox build offline, BUT it keep the default way for kolla to call for upstream galaxy if needed. | 12:32 |
| Fl1nt | I don't care about the timeout, this review doesn't even try to fix that. | 12:33 |
| mmalchuk | AFAIK no issues) change requirements.yml to local resources and tmeouts gone! | 12:33 |
| mmalchuk | don't really understand what it fixes! please create the BUG on launchpad and describe an issue | 12:34 |
| Fl1nt | mmalchuk, once again changing requirements.yml means you've got as OPS/platform to keep it downstream, so each time there is an upgrade you broke it, in here you can do whatever you want without having to keep both template + file that you need to change. | 12:34 |
| mmalchuk | I've read here your mention about bad code and timeouts | 12:35 |
| Fl1nt | mmalchuk, I already created the bugtrack | 12:35 |
| mmalchuk | thanks, will read | 12:35 |
| Fl1nt | yes, cause the offline issue lead me to read the Dockerfile, saw a missing block and mix between PIP install and ansible collections packages, then I saw that because of retry and timeout we have this for loop with a fixed range hardcoded. | 12:36 |
| mmalchuk | but anyway, galaxy solves dependencies your code - not! | 12:36 |
| mmalchuk | you should provide ansible.utils and ansible.netcommon whisch is not described in requirements.yml because openstack.cloud use them! | 12:37 |
| Fl1nt | mmalchuk, there we have an issue then. Cause 9 out of 10 of kolla users that are in offline/security tied environment won't be able to build kolla-toolbox. | 12:37 |
| Fl1nt | I can yes | 12:37 |
| mmalchuk | because we don't have correct documentation about how-to work in airgapped envs | 12:38 |
| mmalchuk | not because the code is bad) | 12:38 |
| Fl1nt | Telling users that they need an internal galaxy server when the documentation of galaxy itself tell them they can use galaxy to install from archives won't be a real documentation or solution IMHO. | 12:39 |
| mmalchuk | I'm build and deploy openstack always in airgapped envs and solved all the issues in kolla/kolla-ansible/kayobe | 12:40 |
| mmalchuk | and all using IaC pattern | 12:40 |
| Fl1nt | because you keep stacking downstream patch. | 12:40 |
| mmalchuk | 99,9% using the configiration and overrides | 12:40 |
| mmalchuk | because I've use the ansible galaxy the right way in this case | 12:42 |
| Fl1nt | ok so tell me, how do you convince kolla-toolbox in here to work? Out of overriding the Dockerfile? | 12:43 |
| mmalchuk | the only issue - the current code don't have the ability to merge requirements.yml with external source from the k-a/kayobe variables | 12:43 |
| Fl1nt | nice... exactly what I've told 20 lines upper. | 12:43 |
| mmalchuk | ok than, but Iэму ещдв about CURL usage) | 12:43 |
| mmalchuk | ok than, but I've told about CURL usage) | 12:44 |
| Fl1nt | what is the problem with curl? | 12:44 |
| mmalchuk | we should use requirements.yml as a source and the only way to use is galaxy client | 12:44 |
| Fl1nt | that is a take of you guys, it's not enforced by neither ansible nor anything, why means, is there a real technical reason? Technical answer is no. | 12:45 |
| mmalchuk | the problem named 'dependency resolution' which you can't realize in your code | 12:46 |
| Fl1nt | ok, so. Here we've an issue | 12:49 |
| mmalchuk | also your code drop the ability to use wide range of methods: file, galaxy, git, url, dir, or subdirs. | 12:49 |
| mmalchuk | leaves only http | 12:49 |
| Fl1nt | that isn't the biggest issue as I can improve it to deal with that | 12:50 |
| Fl1nt | however | 12:50 |
| mmalchuk | okay, what if https://galaxy.ansible.com/download is changed, or some auth added, or whatever | 12:51 |
| mmalchuk | you should always support this | 12:51 |
| Fl1nt | hence why the base url is within a overridable URL??? | 12:52 |
| Fl1nt | I think you're playing fools as the initial method, even if it can deal with 'Various methods' actually block anyone building kolla offline, last time I was told "Kolla is highly opiniated" when I asked for something, then now we're playing the generic way, what is the purpose of all that guys? | 12:52 |
| Fl1nt | we build a nice tool that can only build over internet? | 12:52 |
| Fl1nt | then what? | 12:52 |
| Fl1nt | everyone do have to fork it, maintain local downstream patches that stack up? | 12:53 |
| mmalchuk | not exactly. galaxy and client can work locally | 12:53 |
| Fl1nt | so you force everyone to get another mirror for galaxy right? | 12:53 |
| mmalchuk | only one pice is absent in the docker/kolla-toolbox/Dockerfile.j2 - the overrides block for folks like us) | 12:54 |
| Fl1nt | Ok, that is a better answer | 12:54 |
| mmalchuk | no! I'm force to use standard tools and correct code) | 12:54 |
| mmalchuk | your code breaks all things | 12:54 |
| Fl1nt | Sorry but mixing ansible-collection packages installation with pip package and using a hardcoded for range loop is correct code??? | 12:55 |
| mmalchuk | you provide the new and completely not extensible way to install collection | 12:55 |
| mmalchuk | we shouldn't break the current way providing may be the working but only one way... galaxy have the ability to download using http, file, local etc. as I said before | 12:58 |
| Fl1nt | It break only dependencies, that can be dealt using a macros, it's just a matter of improving the review, plus this review in its current for do respect the usual kolla standard introduced by prometheus exporter, so either you told me,"we should have a ansible-collection-install function call on macros.j2" or "Let's broke all prometheus roles" it's more coherent that just throwing away mixed things. | 12:58 |
| Fl1nt | mmalchuk, alright, I'll just surround the way it is on its on block then, but next time someone complain about the fact that I want to support all generic way a core service is working I'll remind you guys this discussion and please, we should remove "Opiniated" from the kolla doc then. | 13:00 |
| mmalchuk | working with dependencies would be complex issue, but you always can write the python code to use)) this means write your own galaxy client))) | 13:00 |
| mmalchuk | ok, generic) lets wrap the code with overrides blocks. anyone can use their code | 13:01 |
| mmalchuk | you, for example can put the code with curl in your ovverides) | 13:02 |
| Fl1nt | yes, I'll do that | 13:02 |
| Fl1nt | I was planning to do so at first. | 13:02 |
| mmalchuk | and lets rewrite this another way to support all possible methods and support airgapped envs | 13:03 |
| Fl1nt | sure | 13:03 |
| mmalchuk | lets write our own mini galaxy client in python | 13:04 |
| mmalchuk | which should work as we want | 13:04 |
| mmalchuk | and support standard way too | 13:05 |
| opendevreview | Gaël THEROND proposed openstack/kolla master: Improve kolla-toolbox offline support. https://review.opendev.org/c/openstack/kolla/+/884368 | 13:09 |
| Fl1nt | mmalchuk, it's not about rewriting galaxy client, it's about the way we don't get clear guideline with kolla/kolla-ansible, one version we use curl because we introduce prometheus, the next one we introduce ansible-galaxy but with another way to do things, it constantly broke from one release to another, although you're right with the dependencies. | 13:12 |
| mmalchuk | understand. and agree! lets fix the issue the right way! | 13:16 |
| Fl1nt | yes | 13:16 |
| mmalchuk | thank you for your patience and for my rude words if any | 13:19 |
| Fl1nt | No worries, I live by the conway law, you can be harsh as long as you want, what matter to me is technicalities, not human blabla. | 13:24 |
| mmalchuk | cool | 13:25 |
| Fl1nt | ok, fluentd is having the same issue, gonna patch it too. | 13:47 |
| Fl1nt | mmalchuk, btw, dependencies resolution isn't performed when using archives as source, neither do openstack.cloud require dependencies anymore and ansible.x or community.y are provided with pip install ansible. | 13:51 |
| opendevreview | Mark Goddard proposed openstack/kolla-ansible master: Refactor MariaDB and RabbitMQ restart procedure https://review.opendev.org/c/openstack/kolla-ansible/+/884182 | 14:09 |
| mnasiadka | mgoddard: rabbitmq as well? uh | 14:10 |
| opendevreview | Merged openstack/kayobe master: Bump up Ansible supported versions to 6.x/7.x https://review.opendev.org/c/openstack/kayobe/+/878207 | 14:13 |
| mnasiadka | yay | 14:13 |
| mmalchuk | Fl1nt sure. I didn't said that sources solves an issue with dependencies. only a thing that was on the way you go) we have sources not only to solve the airgapped issue but we have own patches for toolbox) | 14:25 |
| Fl1nt | No sure, but it was more to emphasis that at the moment dependencies aren't really an issue. But I'm fine with the block way for now. | 14:27 |
| mmalchuk | btw I provide a snippet where version: '1.5.2' not '<2' ;) | 14:27 |
| Fl1nt | You mean on the patch review? | 14:28 |
| mmalchuk | yep. I've solve dependencies my way with external tool and use static requirements.yml with pinned versions of my sources | 14:28 |
| Fl1nt | yes it's how I'm ending up in here too | 14:28 |
| mmalchuk | lol | 14:28 |
| mmalchuk | invent bicycle) | 14:29 |
| Fl1nt | but it's kinda a pain, we have an internal tool in here, that do pretty much everything, build containers, push them to registry, deploy them on host, however everything is 100% ansible based and variabilized. | 14:30 |
| Fl1nt | so you can do generic + custom the way you want | 14:30 |
| mmalchuk | so we need write a plugin for kolla on python which got an json/yaml data of sources, do any downloads, solve dependencies and install the collection | 14:30 |
| darkkilla | and then you could name that ansible-galaxy? XD | 14:31 |
| Fl1nt | I don't think that doing it that way is the best option, it's kinda reinvent the wheel tbh and add up code that we surely don't need as it's already written in ansible. | 14:32 |
| mmalchuk | thanks a lot for the block of overrides) now I can drop one custom commit and use overrides from the box) | 14:32 |
| mmalchuk | written in ansible but don't support airgapped envs. we can contribute in ansible but this is a very long way) | 14:33 |
| Fl1nt | see! my point! collection of local downstream patches ^^ I've calculated ours, we have 12 of it so far, one that I can't really upstream now as it's related to SSO and that I'm not going into that fight for now | 14:33 |
| mmalchuk | 12) cool! | 14:33 |
| Fl1nt | mmalchuk, what do you mean by that? | 14:33 |
| mmalchuk | interesting | 14:34 |
| mmalchuk | you can send me directly | 14:34 |
| Fl1nt | SAML SSO ? yep | 14:34 |
| mmalchuk | for now I need to go, sorry | 14:34 |
| Fl1nt | sure no biggies | 14:34 |
| mmalchuk | fell free to write me directly. Im here always, now use bouncer and don't lost any message | 14:35 |
| Fl1nt | ok ok, noticed, I'll tgz my patch and give it to you later on. | 14:36 |
| opendevreview | Gaël THEROND proposed openstack/kolla master: Improve kolla-toolbox offline support. https://review.opendev.org/c/openstack/kolla/+/884368 | 14:39 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: veryWIP: Add syslog for Neutron agents https://review.opendev.org/c/openstack/kolla-ansible/+/884408 | 14:55 |
| opendevreview | Mark Goddard proposed openstack/kolla-ansible master: Fix passwords.yml permissions https://review.opendev.org/c/openstack/kolla-ansible/+/882100 | 15:29 |
| opendevreview | Mark Goddard proposed openstack/kolla stable/yoga: opensearch: move to yum/apt repos https://review.opendev.org/c/openstack/kolla/+/883716 | 15:46 |
| opendevreview | Mark Goddard proposed openstack/kolla stable/yoga: opensearch-dashboards: Fix permissions https://review.opendev.org/c/openstack/kolla/+/884375 | 15:46 |
| opendevreview | Mark Goddard proposed openstack/kolla stable/yoga: opensearch-dashboards: Fix permissions https://review.opendev.org/c/openstack/kolla/+/884375 | 15:47 |
| opendevreview | Mark Goddard proposed openstack/kolla-ansible stable/yoga: opensearch: alter path after using rpm/deb packaging https://review.opendev.org/c/openstack/kolla-ansible/+/884376 | 15:48 |
| opendevreview | Mark Goddard proposed openstack/kolla-ansible stable/yoga: opensearch: alter path after using rpm/deb packaging https://review.opendev.org/c/openstack/kolla-ansible/+/884376 | 15:48 |
| opendevreview | Merged openstack/kolla-ansible stable/zed: Correct ovn-ctl --db-nb-pidfile usage in templates https://review.opendev.org/c/openstack/kolla-ansible/+/882290 | 16:46 |
| opendevreview | Merged openstack/kolla-ansible stable/yoga: Correct ovn-ctl --db-nb-pidfile usage in templates https://review.opendev.org/c/openstack/kolla-ansible/+/882291 | 16:48 |
| opendevreview | Merged openstack/kayobe master: Limit interface names to 15 characters https://review.opendev.org/c/openstack/kayobe/+/869744 | 17:15 |
| opendevreview | Mark Goddard proposed openstack/kayobe master: firewalld: make changes less disruptive https://review.opendev.org/c/openstack/kayobe/+/884360 | 18:54 |
| opendevreview | Maksim Malchuk proposed openstack/kolla-ansible master: Fix passwords.yml permissions https://review.opendev.org/c/openstack/kolla-ansible/+/882100 | 21:31 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!