| opendevreview | Antony Messerli proposed openstack/kolla master: Moves fluentd_binary and fluentd_user labels https://review.opendev.org/c/openstack/kolla/+/911014 | 00:22 |
|---|---|---|
| mnasiadka | mnaser: not really, but I’ll add that topic to ptg | 06:48 |
| mnasiadka | SvenKieske: and dependencies to those modules like rabbitmq and ovs libs | 06:49 |
| frickler | mnasiadka: I have the feeling that I keep forgetting this, but do we really have to have support for weird 3rd party drivers like purestorage in kolla? | 07:28 |
| mnasiadka | frickler: pure is a driver in cinder support matrix, isn’t it? | 07:44 |
| mnasiadka | I’m not sure if it’s in tree or not | 07:44 |
| mnasiadka | (On the tram now, can check later) | 07:45 |
| frickler | mnasiadka: cinder does support it via 3rd party testing, but IMHO that doesn't mean that kolla needs to support it | 07:56 |
| mnasiadka | frickler: let's start from the beginning - what is the problem with it? | 07:58 |
| kevko | frickler: well, I think kolla can support it ..but we don't need to test it as I suppose that folks who used to use it will handle the functionality | 07:59 |
| frickler | mnasiadka: my problem is a) I don't like to have untested features in kolla and b) I don't want to review non-free things | 08:00 |
| mnasiadka | I agree with a), but since we have a contributor that is interested in that - I don't see a problem | 08:01 |
| mnasiadka | frickler: what do you mean non free? that you need to buy a storage array or is the driver closed source? | 08:02 |
| frickler | if the only contributor is the company that is producing the hardware, I'm sceptical whether that is enough. cf. the vmware situation | 08:04 |
| frickler | but ok, if other reviewers are fine with this kind of support, I can just try to ignore those reviews and that's it | 08:06 |
| mnasiadka | things like vmware will happen either way if you review it or not ;-) | 08:12 |
| opendevreview | Uwe Jäger proposed openstack/kolla-ansible master: Allow customizing of Skyline configuration https://review.opendev.org/c/openstack/kolla-ansible/+/905861 | 08:17 |
| SvenKieske | the thing with the kolla_toolbox container is, it needs access to all kind of ovs things and this somehow fails in the ovn exporter CI, not sure yet what is the root cause. it feels like a reinvention of shared libraries in a docker context. weird. | 09:32 |
| opendevreview | Ivan Halomi proposed openstack/kolla-ansible master: Refactor of docker worker https://review.opendev.org/c/openstack/kolla-ansible/+/908295 | 09:49 |
| kevko | For one of our customers we are using CADF audit in openstack services ... CADF configuration (for most of services) need to be done in api-paste.ini (define audit filter and add to app pipeline) ...and then just to define messaging driver and url ....etc ..etc | 09:56 |
| kevko | I wrote a script which adding this to api-paste based on ENV variable ... but wondering if we can't add this by default to api-paste files and then just to set a driver noop/messagingv2 etc .. | 09:58 |
| kevko | I've been pulling it for several releases in dowsntream repos ..and I will be glad if I will solve this in this cycle | 09:58 |
| kevko | frickler mnasiadka ^ ? | 09:59 |
| frickler | kevko: sounds like a pretty obscure downstream use case to me. but maybe seeing an actual example would help | 10:04 |
| opendevreview | Sven Kieske proposed openstack/kolla-ansible master: [doc] document --limit limitations https://review.opendev.org/c/openstack/kolla-ansible/+/911082 | 10:30 |
| SvenKieske | I just noticed it would be helpful if we used the "action item" thingy in meetbot during meetings, our minutes are void of any action items and one has to check the full logs :D | 10:31 |
| kevko | frickler: Okay, openstack services can generate CADF events sent to some system (rabbitmq, kafka , log ..etc) ...problem is that you need to change api-paste.ini file to include WSGI middleware filter (https://docs.openstack.org/keystonemiddleware/latest/audit.html) ...point is that api-paste.ini is not modified by user in 99% cases ... | 10:31 |
| SvenKieske | kevko: frickler: there was this old patch for CADF, was something wrong with it? it was abandoned. https://review.opendev.org/c/openstack/kolla-ansible/+/674579 | 10:33 |
| kevko | frickler: moreover ..it's not good idea to define api-paste.ini for services in kolla-ansible ... in current kolla-ansible code there are only few services which has also api-paste.ini in k-a ...and because nobody cares ..they are in old version ... for example for masakari | 10:33 |
| SvenKieske | kevko: what would you recommend regarding api-paste.ini in general? I also noticed it seems to be brittle. should we use just upstreams defaults? but I guess we have at least some reasonable patches in some projects? | 10:34 |
| kevko | SvenKieske: api-paste.ini file is not something that should be modified by user as it is configuration for wsgi ... from paste deploy doc - > Paste Deployment is a system for finding and configuring WSGI applications and servers. For WSGI application consumers it provides a single, simple function (loadapp) for loading a WSGI application from a | 10:36 |
| kevko | configuration file or a Python Egg. | 10:36 |
| kevko | SvenKieske: simply said, developers who are developing the code also provides api-paste ..and we of course copying that api-paste.ini into images ... | 10:37 |
| SvenKieske | kevko: I have a modest understanding of api-paste.ini, my question was what you think we should do. I did not ask about an explanation what it does. | 10:38 |
| frickler | kevko: so first you are saying we should change it and now you are saying we should not change it? | 10:38 |
| kevko | frickler: No, I said that I have a script which is modifiing api-paste.ini file on start based on some variable (in my case ENABLE_CADF) ...or another option is to modify api-paste.ini during the build process ... | 10:39 |
| kevko | frickler: and I just asked what do you think guys ... I think the script approach is better ...as you can then configure for example ignored requests as per documentation ... | 10:40 |
| kevko | for now I only know two cases when you need to modify api-paste.ini ... CADF audit and healthcheck (but this is really not needed as you can check if 200 is returned on /) | 10:41 |
| kevko | frickler: SvenKieske: this is my testing version -> https://paste.openstack.org/show/boweQChOXHCTcIO1OBWo/ | 10:42 |
| frickler | ah, adding deeper healthchecks is another nice topic. like verifying that DB connection and messaging are alive | 10:42 |
| SvenKieske | from an architectural pov and a security pov it seems prudent to do this at the container build layer until there is a strong reason not to, e.g. making this configurable by the end user at runtime. reason being is you can also fiddle with security sensitive stuff there like cors, authtoken etc and make things insecure by accident | 10:44 |
| frickler | and I don't like the idea of modifying config within the container | 10:45 |
| kevko | frickler: I meant this healthcheck for API ...as this is another filter configurable via api-paste.ini https://github.com/openstack/oslo.middleware/tree/master/oslo_middleware/healthcheck | 10:45 |
| SvenKieske | so currently we have two api-paste.ini.j2 in k-a one is cyborg: https://review.opendev.org/c/openstack/kolla-ansible/+/728688/2/ansible/roles/cyborg/templates/cyborg-api-paste.ini.j2 | 10:45 |
| frickler | kevko: yes, I know | 10:45 |
| SvenKieske | but this seems to be the same than latest upstream, so can probably be removed? https://github.com/openstack/cyborg/blob/master/etc/cyborg/api-paste.ini | 10:46 |
| SvenKieske | the other is masakari | 10:46 |
| kevko | SvenKieske: yeah ...and I really don't like that we have api-paste.ini in kolla-ansible ..because firstly it is same as upstream ..and secondly ..from time to time upstream developers just change it ...and we really don't track it ... | 10:47 |
| kevko | SvenKieske: example is this https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/masakari/templates/masakari-api-paste.ini.j2 | 10:47 |
| kevko | SvenKieske: https://github.com/openstack/masakari/blob/master/etc/masakari/api-paste.ini << this is upstream default | 10:47 |
| SvenKieske | so if there is no reason to configure this during runtime it should not be configured during runtime imho. just remove it in k-a with reference to upstream and if we need to change it, e.g. for your CADF thingy do that at build time instead? :) | 10:47 |
| kevko | SvenKieske: User can configure CADF -> ignore_req_list ---> what requests will not be audited | 10:49 |
| SvenKieske | maybe put it on the whiteboard agenda for tomorrow? | 10:49 |
| SvenKieske | okay, so then it makes sense maybe to make this configurable during runtime, unless we mandate users always to build their own containers :D | 10:49 |
| kevko | frickler: I am not saying that I reeeallly like the idea of modifiing the config ...but why not ? | 10:49 |
| SvenKieske | well in an ideal world containers are immutable ;) | 10:50 |
| kevko | frickler: redis-sentinel is modifiing his startup configuration by default ! :D | 10:50 |
| kevko | SvenKieske: ^^ | 10:50 |
| kevko | SvenKieske: Well, fortunately, this is not the topic because we don't live in an ideal world :) | 10:52 |
| SvenKieske | well I said "ideal world", we don't seem to live over there just yet :D | 10:52 |
| kevko | SvenKieske: "reason being is you can also fiddle with security sensitive stuff there like cors, authtoken etc and make things insecure by accident" -> How ? If your script is bulletproof ..you are safe | 10:55 |
| kevko | frickler: btw, have you ever encountered that during the RabbitMQ upgrade using Kolla-Ansible (where all nodes are first shut down except the first one, then the first one is shut down, and then all are gradually started)... the first node didn't start up? I've never been able to replicate it anywhere in testing... but on a highly loaded cloud, it | 11:03 |
| kevko | happened to us during an upgrade last week... we had to call force_start via rabbitmqctl and then manually start the others... we had to act quickly... I suspect that the default pause_minority parameter for partition handling in Kolla-Ansible may have caused this | 11:03 |
| kevko | frickler: I agree that pause_minority is good to avoid split-brain ...but I was wondering that there should be few restarts before upgrade with autoheal partition handling -> upgrade -> switch again to pause_minority | 11:04 |
| kevko | frickler: OR provide playbook to recover from this situation ..as we have for mariadb_recovery | 11:07 |
| SvenKieske | kevko: most scripts aren't bulletproof. I try to remove stuff that can be misused where I can. :) | 11:12 |
| frickler | kevko: I haven't done upgrades myself in a long time | 11:13 |
| opendevreview | Michal Arbet proposed openstack/kolla-ansible master: Remove api-paste config files for masakari, cyborg https://review.opendev.org/c/openstack/kolla-ansible/+/911087 | 11:13 |
| kevko | SvenKieske: really dirty is kolla-venv in containers ... | 11:14 |
| kevko | SvenKieske: it's really ok we have venv for python ...but then we changing PATH to PATH /var/lib/kolla/venv/bin:$PATH in openstack-base and moreover we are using "python3 -m venv --system-site-packages" | 11:16 |
| kevko | SvenKieske: then I am really wondering why we are using venv :D | 11:17 |
| SvenKieske | the first one I kind of understand, but why system-site-packages? I guess to reuse distro based packages? mhmm python packaging is still a mess.. | 11:17 |
| SvenKieske | kevko: I guess it reduces maybe download time during build? what does the commit message say? :D | 11:18 |
| SvenKieske | https://review.opendev.org/c/openstack/kolla/+/877986 | 11:20 |
| SvenKieske | ah it was --system-site-packages before as well | 11:20 |
| SvenKieske | https://review.opendev.org/c/openstack/kolla/+/368973 | 11:22 |
| kevko | SvenKieske: nope ..it wasn't https://review.opendev.org/c/openstack/kolla/+/246762 | 11:23 |
| mnasiadka | we use --system-site-packages for example because this: https://review.opendev.org/c/openstack/kolla/+/830844 | 11:23 |
| kevko | mnasiadka: for example this is buggy ...i've fixed downstream in our repo | 11:24 |
| kevko | mnasiadka: i wanted to point that also ..you were first | 11:24 |
| mnasiadka | what is buggy, where is the bug report, and why is it not fixed yet? | 11:24 |
| kevko | mnasiadka: If I remember correctly, ovs was correcly installed in some container which really needed ovs in same version as openvswitch package ... but different version in another container | 11:25 |
| kevko | mnasiadka: base vs openstack/base | 11:26 |
| kevko | mnasiadka: and childs ... | 11:26 |
| mnasiadka | so why didn't you publish a patch upstream? ;-) | 11:26 |
| kevko | mnasiadka: if I am correct it was openvswitch vs neutron-openvswitch-agent ...or something like that ... | 11:26 |
| kevko | mnasiadka: Sometimes I really need to fix something quickly and wait for bugfix in kolla kolla/ansible with all those comments in review ... :D ..i just can't wait ...but *everything* i am sending to upstream ..but it takes some time ... | 11:29 |
| mnasiadka | kevko: well, at least a bug would be helpful, because I see that now you're not really sure where the problem was :) | 11:29 |
| kevko | mnasiadka: https://paste.openstack.org/show/bDw1vFlC858JBdz8pKIa/ | 11:30 |
| kevko | mnasiadka: I know ... two versions of OVS in two containers :D | 11:31 |
| SvenKieske | well it _seems_ the usage of system-site-packages in the above ovs example is really a workaround of conflicting requirements on which versions we should really install. another solution would just be to patch uc to the correct version (we do patch it anyway in that change) | 11:31 |
| kevko | SvenKieske: if I am correct ..we are removing ovs from uc ... as a workaround to a workaround :D | 11:32 |
| SvenKieske | But I'm also not sure system-site-packages is a problem per se. Currently reading: https://packaging.python.org/en/latest/specifications/externally-managed-environments/#externally-managed-environments | 11:32 |
| SvenKieske | from a maintainers persepective it would be nice to have a file _somewhere_ where we can find an aggregated list of all the dependencies we have. this should be conflict free and consistent of course. | 11:33 |
| kevko | Oh, where are those times when I didn't have to deal with this and packages were installed from the APT repository :D :D At least I have a clear conscience that I protested back then :D | 11:34 |
| SvenKieske | this is also complicated by the fact that some of our upstream fellow openstack projects are really not fast when it comes to updating their requirements files or their constraints files. | 11:34 |
| mnasiadka | SvenKieske: correct python3-openvswitch version will never show up in UC, because depending on distro - we have a different version of OVS | 11:34 |
| mnasiadka | and a different version is used for testing in CI | 11:35 |
| mnasiadka | Neutron team recommended to install the correct version of ovs lib, and that's it - we can't rely on u-c for everything | 11:35 |
| kevko | mnasiadka: +1 | 11:35 |
| SvenKieske | mnasiadka: I can't find this recommendation at least in these docs? https://docs.openstack.org/neutron/latest/install/ovn/manual_install.html#controller-nodes it just tells me to install ovs somehow :D | 11:37 |
| kevko | mnasiadka: SvenKieske: my idea was install all from git ...from latest version tag included in stable/branch OR head of stable/branch (if user requested) ...and other stuff from packages ... ovs ..rbd .. | 11:37 |
| kevko | SvenKieske: yeah, but it's little problem if you have openvswitch in version X.Y.Z and python3-openvswitch is X+3.Y.Z ... | 11:38 |
| SvenKieske | sure sure, afaik we still do build our ovs downstream ourselves | 11:39 |
| kevko | SvenKieske: we are also building everything downstream ..because kolla don't have a patching system ..we have it in downstream kolla | 11:40 |
| kevko | SvenKieske: wallaby (or xena ...) ...had really ugly bug that services didn't reconnect to rabbitmq after lost connection ... it was bug in oslo.messaging ..it was one line fix ...but upstream just placed into stable branch and that's it :D | 11:41 |
| kevko | SvenKieske: as kolla is installing dependencies from pip ...I've implemented patching system for kolla ..so I have patches folder where I have folders for containers and there I have classic patches ... | 11:42 |
| kevko | I was packaging openstack in debian :D ..I know how many patches I need to add to packages to be working :D ... that was the reason why I protested against removal binary support ...now we need to maintain ourselves | 11:43 |
| kevko | *maintain the code | 11:43 |
| kevko | I'm glad when there's no silence in this channel. :D | 11:44 |
| mnasiadka | SvenKieske: https://bugs.launchpad.net/neutron/+bug/1961874/comments/3 | 11:48 |
| SvenKieske | good to know it's written down somewhere.. do you happen to know the book "the hitchhikers guide to the galaxy"? | 11:52 |
| mnasiadka | yes, 42 | 11:52 |
| SvenKieske | I was more referring to: “Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.” | 11:54 |
| SvenKieske | https://www.goodreads.com/quotes/40705-but-the-plans-were-on-display-on-display-i-eventually | 11:54 |
| SvenKieske | but good to know it's "documented" :D | 11:54 |
| SvenKieske | in a closed bug report in a comment where the bug report is not about supported versions of ovs but about ovn nb db timeouts. but it's written down..somewhere :D | 11:55 |
| * SvenKieske is going for a walk. o/ | 11:55 | |
| opendevreview | Michal Nasiadka proposed openstack/kolla master: Bump rabbitmq to 3.13 https://review.opendev.org/c/openstack/kolla/+/911093 | 11:59 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: rabbitmq: Add 3.12 feature flags (for upgrade to 3.13) https://review.opendev.org/c/openstack/kolla-ansible/+/911094 | 12:02 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: rabbitmq: Add 3.12 feature flags (for upgrade to 3.13) https://review.opendev.org/c/openstack/kolla-ansible/+/911094 | 12:05 |
| SvenKieske | mnasiadka: do you use any service or subscribe to some rabbitmq announcements or how do you get notified of new releases? or are you checking manually? just curious! | 13:02 |
| mnasiadka | SvenKieske: checking manually twice a cycle ;-) | 13:16 |
| mnasiadka | (and the latest RMQ mirror issue was related to some mirror script bumps because of 3.13) | 13:16 |
| kevko | have u ever used pipgrip ? btw ? | 13:24 |
| SvenKieske | do you mean ripgrep? I use it very often. I don't know pipgrep, if that is not a typo :) | 13:28 |
| SvenKieske | seems you are talking about https://pypi.org/project/pipgrip/ ? never heard of it before | 13:29 |
| kevko | https://github.com/ddelange/pipgrip | 13:30 |
| SvenKieske | ah, it's basically poetry without the pip incompatibilities? | 13:30 |
| SvenKieske | seems interesting | 13:30 |
| kevko | (pipdeptree) michalarbet@pixla:~/ultimum/git/ultimum/kolla-ansible$ pipgrip --json python-keystoneclient | 13:30 |
| kevko | {"python-keystoneclient": "5.4.0", "debtcollector": "3.0.0", "wrapt": "1.16.0", "keystoneauth1": "5.6.0", "iso8601": "2.1.0", "os-service-types": "1.7.0", "pbr": "6.0.0", "requests": "2.31.0", "certifi": "2024.2.2", "charset-normalizer": "3.3.2", "idna": "3.6", "urllib3": "2.2.1", "stevedore": "5.2.0", "oslo-config": "9.4.0", "netaddr": "1.2.1", | 13:30 |
| kevko | "oslo-i18n": "6.3.0", "pyyaml": "6.0.1", "rfc3986": "2.0.0", "oslo-serialization": "5.4.0", "msgpack": "1.0.8", "oslo-utils": "7.1.0", "netifaces": "0.11.0", "packaging": "23.2", "pyparsing": "3.1.1", "tzdata": "2024.1"} | 13:30 |
| kevko | SvenKieske: I am doing some research to finally install openstack python packages in correct way ... | 13:31 |
| SvenKieske | I was recently more looking into https://github.com/astral-sh/uv because it claims to be a drop in replacement for pip but faster (10-100 times) so that seems interesting from openstack pov | 13:31 |
| SvenKieske | so far most stuff seems to work, but it still has not every pip function under the sun, I don't know if we need them all though | 13:32 |
| SvenKieske | so maybe add that to your research list, I was also looking into this stuff as a side project, maybe we can share notes somewhere? I feel the current pip ecosystem still somewhat lacking. It certainly got better than 10 years ago but it could still get better imho | 13:33 |
| SvenKieske | I personally think pyproject.toml is a good step in the right direction. I just don't know about all the backwards incompatibilities that python introduces along the way (setuptools deprecation, etc) | 13:34 |
| kevko | SvenKieske: well, i am not expert ..but what I've found is pipgrip and poetry ...but openstack projects don't have pyproject.toml | 13:35 |
| SvenKieske | kevko: there are some mailinglist postings and some patches floating around to introduce pyproject.toml, because pip upstream is forced to introduce it..wait a second | 13:36 |
| kevko | SvenKieske: yep, please share | 13:37 |
| SvenKieske | kevko: this is the thread that started this all: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/HVFN5RBSHRTM3B2UUKPAWKH6H6AT6CYR/ | 13:37 |
| SvenKieske | ah sorry, this is the complete thread, the above is only the first message: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/HVFN5RBSHRTM3B2UUKPAWKH6H6AT6CYR/#HVFN5RBSHRTM3B2UUKPAWKH6H6AT6CYR | 13:38 |
| kevko | SvenKieske: from my perspective I would like to : | 13:38 |
| kevko | 1. Ability to install from stable head git | 13:38 |
| kevko | 2. From tag from git | 13:38 |
| kevko | 3. From released version | 13:38 |
| kevko | 4. Configurable | 13:38 |
| kevko | 5. Ideally reproducible | 13:38 |
| SvenKieske | that works in "uv" ;) | 13:39 |
| SvenKieske | for the pyproject.toml stuff there's at least a patch in nova, but not yet merged: https://review.opendev.org/c/openstack/nova/+/899753 | 13:39 |
| SvenKieske | there are some problems related to wsgi I guess | 13:40 |
| SvenKieske | but the really gory details are all in the above thread, I have to reread some of it myself to remember | 13:41 |
| SvenKieske | but I guess that thread is highly relevant to us, because some paths for wsgi might change and how to configure stuff.. | 13:41 |
| SvenKieske | to be honest as this ML discussion was tagged with "all, packaging, release, qa" I expected at least some people in here to know about it, I hope that's still the case? :) I can understand though if it got missed, too many communication channels these days.. | 13:44 |
| kevko | SvenKieske: yep ... i've also seen some test patches from mnasiadka | 13:44 |
| opendevreview | Martin Hiner proposed openstack/kolla-ansible master: Add container engine migration scenario https://review.opendev.org/c/openstack/kolla-ansible/+/836941 | 13:59 |
| kevko | SvenKieske: this gonna be a fun :D :D | 14:12 |
| kevko | SvenKieske: looking deeper and deeper | 14:12 |
| opendevreview | Jakub Darmach proposed openstack/kayobe master: Use new collections in Kayobe https://review.opendev.org/c/openstack/kayobe/+/910742 | 14:18 |
| opendevreview | Rafal Lewandowski proposed openstack/kayobe master: Add Redfish rules to Ironic and Bifrost introspection https://review.opendev.org/c/openstack/kayobe/+/902772 | 14:23 |
| opendevreview | Sven Kieske proposed openstack/kolla-ansible master: [doc] document --limit limitations https://review.opendev.org/c/openstack/kolla-ansible/+/911082 | 14:25 |
| opendevreview | Kevin Tindall proposed openstack/kolla-ansible master: Add TLS proxy for novncproxy https://review.opendev.org/c/openstack/kolla-ansible/+/911141 | 15:25 |
| opendevreview | Michal Nasiadka proposed openstack/kolla master: Bump rabbitmq to 3.13 https://review.opendev.org/c/openstack/kolla/+/911093 | 15:42 |
| kevko | mnasiadka: https://paste.openstack.org/show/b9xT2T1F9938PCpTlK4h/ << my local pipeline ..but probably upstream bug also | 15:43 |
| mnasiadka | kevko: sorry, what is a bug in this output? ;-) | 15:46 |
| kevko | mnasiadka: 2024-03-05T12:43:56.7620059Z ERROR: Could not open requirements file: [Errno 2] No such file or directory: '-c{env:TOX_CONSTRAINTS_FILE:https://releases.openstack.org/constraints/upper/master}' | 15:47 |
| SvenKieske | kevko: I can't see that error in the above paste? am I missing something (probably)? | 15:49 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: CI: Replace etcd with redis in GATE_IMAGES for cephadm scenario https://review.opendev.org/c/openstack/kolla-ansible/+/911143 | 15:49 |
| kevko | SvenKieske: probably bad paste ... the line above | 15:49 |
| kevko | SvenKieske: probably bad paste ... the line above | 16:10 |
| SvenKieske | ok :) | 16:34 |
| opendevreview | Pierre Riteau proposed openstack/kolla-ansible stable/2023.2: Configure missing nova services to expose vendordata over configdrive https://review.opendev.org/c/openstack/kolla-ansible/+/911067 | 16:46 |
| mnasiadka | frickler: willing to have a look in ^^? I know it's feature-ish - but there's no other way to supply that today (config overrides won't work) | 16:52 |
| opendevreview | Pierre Riteau proposed openstack/kolla-ansible stable/2023.1: Configure missing nova services to expose vendordata over configdrive https://review.opendev.org/c/openstack/kolla-ansible/+/911068 | 16:52 |
| opendevreview | Pierre Riteau proposed openstack/kolla-ansible stable/zed: Configure missing nova services to expose vendordata over configdrive https://review.opendev.org/c/openstack/kolla-ansible/+/911069 | 16:52 |
| SvenKieske | mnasiadka: why does config override in combination with providing the file not work? | 17:11 |
| mnasiadka | SvenKieske: the only way to provide the file is to copy that manually on the hosts (or write some separate playbook) and add an extra bind mount or something like that? | 17:12 |
| mnasiadka | sounds like a drama ;) | 17:13 |
| opendevreview | Pierre Riteau proposed openstack/kayobe master: Remove default value from sample configuration https://review.opendev.org/c/openstack/kayobe/+/911155 | 17:13 |
| SvenKieske | yeah, so why doesn't this work? it's surely not nice, but it works? I'm not against merging this, but stated facts should be correct, I'm a big fan of that :) | 17:13 |
| SvenKieske | I haven't used config drives for cloudinit in a long time, old memories. :) thanks for the clarification. | 17:15 |
| SvenKieske | looking at it from a feature vs bug angle you could still argue that it's more of a bug fix. ¯\_(ツ)_/¯ | 17:18 |
| SvenKieske | reading the code, vendordata was never exposed before, so from this angle it's a "feature". depending on how we view the vendordata feature (mandatory vs optional) I would judge this as a bugfix (if providing vendordata is considered a "must") or a feature (if it's optional). | 17:21 |
| SvenKieske | commented on the change | 17:23 |
| mnasiadka | it's optional - https://docs.openstack.org/nova/latest/user/metadata.html#vendordata | 17:24 |
| mnasiadka | but useful :) | 17:24 |
| SvenKieske | sure, I know a lot about configdrive and vendordata - more than I like to admit - so I'm not against it. | 17:26 |
| SvenKieske | tbh I find the openstack backporting rules to be "difficult" to say the least, because, like most rules, they miss many nuances of actual proposed backports. an invasive "bugfix" can bear much higher risk like e.g. this little feature backport | 17:27 |
| SvenKieske | this is just one of many things that's missing from the backports rules, they have a very heavy good/bad approach which is often just wrong "bugfix? good" "feature: regressions! high risk! bad!" this is just not what the real world is like. | 17:28 |
| mnasiadka | That's why we usually agreed to backport small features if they don't break anything, do not require new inventory groups, etc | 17:31 |
| SvenKieske | if we follow generic rules to the letter they should be very very well thought out and be backed by some actual numbers showing that they are right. everything else is just cargo culting. but I guess I should stop the heresy here now ;) | 17:31 |
| mnasiadka | I’ll add that as PTG topic so we can have a documented policy | 19:26 |
| kevko | mnasiadka: SvenKieske: i am open to merge it :D ... I'm merging huge stuff downstream and everything is good :D | 20:56 |
| opendevreview | Merged openstack/kayobe master: Remove default value from sample configuration https://review.opendev.org/c/openstack/kayobe/+/911155 | 22:58 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!