| opendevreview | Doug Goldstein proposed openstack/sushy master: drop usage of pkg_resource for newer python compat https://review.opendev.org/c/openstack/sushy/+/925304 | 01:48 |
|---|---|---|
| cardoe | So I think that'll pass now that the requirements landed. If we haven't made a sushy release yet, it might be good to pull that in because that'll make sushy work on Python 3.12 | 01:49 |
| cardoe | Lemme tell you Python 3.9... <shake fist> | 01:51 |
| cardoe | I would flip openstack-tox-py312 to voting in that patch set but no idea how. | 01:53 |
| opendevreview | Doug Goldstein proposed openstack/sushy master: fix spelling and make codespell pass https://review.opendev.org/c/openstack/sushy/+/927444 | 02:02 |
| cardoe | There codespell can be voting too. | 02:02 |
| cardoe | Also worth noting that the Python 3.12 support patch despite not being tested on Python 3.8 by Zuul, I did test it on there. Which is what the hold up was for global-requirements | 02:09 |
| opendevreview | Iury Gregory Melo Ferreira proposed openstack/ironic master: Firmware Update via Firmware Interface Docs https://review.opendev.org/c/openstack/ironic/+/926961 | 02:25 |
| opendevreview | Merged openstack/ironic master: idrac: inherit driver interface from redfish https://review.opendev.org/c/openstack/ironic/+/926227 | 04:55 |
| SvenKieske | Hi, if I run multiple ironic hosts behind haproxy, what would be the best API endpoint to monitor that the backend is still alive (so haproxy http check, basically) just get "/", or something else? | 08:23 |
| dtantsur | SvenKieske: with or without authentication? | 09:47 |
| dtantsur | cardoe: my IRC disconnected, and I lost some of the scrollback, but if you're interested in ironic-standalone-operator, here's the design document: https://github.com/metal3-io/metal3-docs/pull/461 | 09:48 |
| SvenKieske | dtantsur: ideally without auth if possible, but afaik colleagues over in kolla already figured it out | 09:54 |
| dtantsur | SvenKieske: without auth you're limited to /v1 | 09:57 |
| dtantsur | with auth you can list conductors at /v1/conductors and optionally check that more than 1 is present | 09:57 |
| dtantsur | or /v1/drivers if you know which drivers have to be loaded | 09:58 |
| SvenKieske | I think we don't need that much detail, it's only to know that haproxy can reach the configured backends, so API routes respond | 10:00 |
| cardoe | Thanks dtantsur | 13:21 |
| JayF | cardoe: that py312 job is defined in the templates. I think you just have to repeat the name in the check and the gate config with voting: true | 13:54 |
| JayF | Given how zuul works if you pushed a patch you get immediate feedback on if it worked or not | 13:55 |
| opendevreview | Merged openstack/sushy master: drop usage of pkg_resource for newer python compat https://review.opendev.org/c/openstack/sushy/+/925304 | 14:07 |
| TheJulia | Has anyone been running into the fun perceptions created by /dev/sd[x] device ordering with kernels changing device initialization style ? | 14:25 |
| dtantsur | I've definitely heard about the disks getting reordered | 14:42 |
| dtantsur | Meanwhile, could I get a 2nd +2? https://review.opendev.org/c/openstack/ironic/+/927265 | 14:45 |
| dtantsur | and https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/925981 if possible | 14:46 |
| JayF | this is one of those problems that just recurs every ten years or so. this why root device hints isn't just about the device | 14:48 |
| kubajj | Recently, I am dealing with an issue on a node with 4 devices - 2 of them in a RAID with 'is_root_volume' set to false and it always being picked as a root device (all 4 disks are the same). Root device hints can be tricky | 14:51 |
| TheJulia | dtantsur: I'm proposing a doc update shortly | 15:01 |
| TheJulia | Did anyone see the email about our docs to the mailing list? | 15:04 |
| opendevreview | Doug Goldstein proposed openstack/sushy master: fix spelling and make codespell pass https://review.opendev.org/c/openstack/sushy/+/927444 | 15:09 |
| TheJulia | Oh joy, Sphinx 9 is going to drop support for paths as strings | 15:13 |
| TheJulia | filed a bug | 15:15 |
| opendevreview | Julia Kreger proposed openstack/ironic master: docs: Add context around asynchronous device initialization https://review.opendev.org/c/openstack/ironic/+/927518 | 15:17 |
| dtantsur | another silly issue in the ironic-tempest-plugin btw: https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/927029 | 15:39 |
| TheJulia | heh, likely can just run with the default | 15:49 |
| opendevreview | Merged openstack/ironic master: Temporarily disable PXE booting test in the standalone job https://review.opendev.org/c/openstack/ironic/+/927265 | 16:06 |
| frickler | TheJulia: I didn't see a mail about ironic doc issues, just the nova one, which got fixed. | 16:35 |
| TheJulia | noted use of blockdiag | 16:36 |
| JayF | I think we commit the results of the diagram today | 16:42 |
| JayF | but still have a tox target to generate them | 16:42 |
| TheJulia | Has anyone run into gpt issues with images and 4k disk controllers? | 17:08 |
| cardoe | JayF: i'm assuming the job templates are in another repo? | 18:43 |
| JayF | opendev.org/openstack/openstack-zuul-jobs ? | 18:43 |
| cardoe | Would you guys want me to forcibly enabled py312 as voting in sushy? | 18:43 |
| JayF | yeah that's it | 18:44 |
| cardoe | Or just wait until that template repo turns it on? | 18:44 |
| JayF | I am onboard for that; but I think we'll get it for "free" soon with the next openstack platform requiring it | 18:44 |
| JayF | the template is based on https://review.opendev.org/c/openstack/governance/+/926150 when it lands | 18:44 |
| cardoe | okay then I'll skip it. my codespell change however deletes the override that makes codespell non-voting in sushy. | 18:44 |
| cid | o/ | 20:03 |
| JayF | \o | 20:04 |
| JayF | We need to still switch to pyproject.yaml for Ironic projects, yeah? | 20:08 |
| JayF | I almost want to make a topic for PTG of like ... "neglected Ironic-specific maintenance" including things like that | 20:08 |
| JayF | to make sure that any of the item's we are holding in our head as tech debt get documented and surfaced | 20:09 |
| cardoe | +1 from me pyproject.toml. It's the way of the future. Now I'm curious how pbr handles that with a setup.py | 20:46 |
| JayF | nova is landing one, or has landed one, I believe | 20:46 |
| JayF | so I think it's a jfdi (just do it) thing at this point? | 20:46 |
| * JayF is going to take a swing at it right now, in fact | 20:47 | |
| JayF | https://review.opendev.org/c/openstack/nova/+/899753 is the nova one, landing now | 20:48 |
| cardoe | I need eye bleach | 20:48 |
| cardoe | I thought you meant convert to pyproject.toml from setup.cfg and setup.py | 20:49 |
| JayF | I mainly just want our stuff working with modern pip :) | 20:49 |
| cardoe | Yeah +1 | 20:50 |
| cardoe | pbr though... | 20:50 |
| opendevreview | Jay Faulkner proposed openstack/ironic master: add pyproject.toml to support pip 23.1 https://review.opendev.org/c/openstack/ironic/+/927544 | 20:51 |
| JayF | talk about changing pbr or from pbr probably needs to be in a channel with an audience beyond just ironic | 20:51 |
| cardoe | oh not talking about changing but just saying how they added modern pip support. | 20:52 |
| JayF | in a way, we are they :) | 20:52 |
| JayF | I don't remember who exactly did it, but it was opendev/openstack folks | 20:52 |
| clarkb | you can use pyproject.toml with PBR, but yo ucan't get rid of setup.cfg and setup.py in that case | 20:53 |
| clarkb | the way it works is that you tell pyproject.toml to use the setuptools hooks for installation then that ends up running pbr | 20:53 |
| clarkb | https://opendev.org/openstack/pbr/src/branch/master/pyproject.toml.future is PBRs file that we meant to switch to after a release or two of other people using it since the chikcen and egg there is weird | 20:54 |
| clarkb | oh ya we use backend-path = ["."] to avoid the chicken and egg | 20:54 |
| clarkb | https://opendev.org/openstack/pbr/src/branch/master/doc/source/user/using.rst#pyproject.toml and there are docs | 20:55 |
| clarkb | fwiw you can almost get away with pyproject.toml + setuptools + setuptools-scm instead of pbr as well. But then you lose out on a couple of features that people may be using | 20:56 |
| clarkb | (automatic version string generation based on commit message comments, authors generation, and the wsgi scripts stuff come to mind, there may be more) | 20:56 |
| JayF | so likely ironic could migrate from pbr; but I don't see any upside to that while other projects use pbr | 20:57 |
| clarkb | I'm not sure what the problems with pbr are though. I mean I personally have a hope we can drop it so that I can stop maintaining it but PBR has done for like 12 years now what the pypa and related tooling is only now just figuring out that people need | 20:57 |
| cardoe | Yeah pypa dropped the ball for so long. | 20:58 |
| clarkb | things like configuration based packaging instead of code based packaging | 20:58 |
| clarkb | and integration with vcs | 20:58 |
| cardoe | Yeah that should have been there day 1 | 20:58 |
| cardoe | Like we (as a society) knew better | 20:59 |
| clarkb | oh pbr also records the commit you built off of in metadata | 20:59 |
| JayF | clarkb: you hit the nail on the head, no problems, just a general feeling that the more pots we can get our hands out of the more time we'll have for stuff that's in the cloud wheelhouse | 20:59 |
| cardoe | That's my sentiment, JayF | 20:59 |
| clarkb | I'm not sure if anything else does that. I saw there was a recent discussion somewhere in the python world about accepting git hashes in pep 440 versions strings after they explicitly made that a no no so people are beginning to realize this is important info again | 20:59 |
| cardoe | Another thing OpenStack does well is recording the licenses for dependencies. | 21:00 |
| JayF | Who would've thought the governance process of a giant project could lead to strange, undesired outcomes ;) | 21:00 |
| cardoe | That's just a comment in the requirements file but that should really be recorded in the package. | 21:00 |
| JayF | hehe, that's what happens when you start an OSS project with corporate lawyers :P | 21:00 |
| cardoe | But I don't think pypa has that on their roadmap | 21:00 |
| clarkb | I think for me I could live without the wsgi scripts (just install them like any other data file or command line script, people update their config management and move on). But not needing to deal with version bump commits is a really nice feature as is recording the hash of what you built off of | 21:01 |
| cardoe | Agreed. I think hatch is doing that now? | 21:03 |
| cardoe | ah. why did I go look at the setuptools code. | 21:04 |
| JayF | I'm trying to think of the right way to ask this .... why does pbr still require setup.cfg instead of allowing those bits in pyproject.toml? Is there an answer other than "it's busywork" (which would be a fine answer) | 21:04 |
| clarkb | JayF: I think the primary reason is yes its work for PBR to be modified and then for everyone to move, but also setuptools still does setup.cfg (side note they copied that from pbr then seem to have intentionally chosen an incompatible syntax yay) and there really isn't any benefit in terms of what you are trying to represent. You can do it just fine in ini | 21:05 |
| JayF | wait WHAT pbr was first to setup.cfg? | 21:06 |
| JayF | I have a weird perspective because I basically learned python in openstack | 21:06 |
| JayF | I never realized that was a pbrism first | 21:06 |
| clarkb | JayF: "yes" there was a distutils2 spec that someone wrote (probably in whatever came before pypa) and they had some good ideas in it. Then they said we're not doing that anymore because they are bad ideas | 21:07 |
| clarkb | monty said no wait those are good ideas and PBR was born. So yes I think PBR was the first implementation that used setup.cfg but distutils2 may have specced it first | 21:07 |
| clarkb | then like 10 years later they realized oh ya those were good ideas and implemented them all but made sure to be incompatbile | 21:08 |
| JayF | I think the timeline around that, I was in a server closet at Rackspace SF inventing "decomissioning" which eventually became cleaning | 21:09 |
| clarkb | (and actually on the timeline I think monty was trying to make a library that could implement distutils2 before everyone upgraded to the version of python that included it then discovered they had cancelled the project before it even started) | 21:09 |
| JayF | barely doing any python at all other then glue between the various linux bits | 21:09 |
| clarkb | and when monty tried to resurrect it the reception wasn't nice | 21:09 |
| clarkb | at the time openstack had serious struggles with package builds for openstack projects breaking constantly. The motivation was to get behaviors encoded into single library then you'd just configure things for a far more consistent experience | 21:11 |
| clarkb | and PBR solved that problem pretty well. There have been a couple of unexpected hiccups but like the total number of break the world in our packaging went from 2 a week to 2 in a decade | 21:11 |
| clarkb | one thing that is annoying is pbr is a setup_requires and setup_requires is handled by distutils (maybe python3.11 doesn't do this anymore I don't know) but that means you don't get python version handling from pypi metadata. Anyway long story short PBR still supports python2.7 because we can't reliably prevent people with 2.7 packages from using latest PBR. If everyone | 21:13 |
| clarkb | changes to pyproject.toml or if we made a PBRLite library we could fix that, but it turns out python2.7 support isn't a big deal | 21:14 |
| JayF | if someone is still using python 2.7 at this point, i'd have no qualms whatsoever about breaking them and handing over the pieces | 21:14 |
| clarkb | JayF: I think swift still supports 2.7 on master unless they finally landed the code to remove that | 21:15 |
| cardoe | You hit the nail on my original comment above to jay about the bleach. The setup_requires stuff. | 21:15 |
| JayF | my opinion does not change, and yes they still do https://github.com/openstack/swift/blob/master/setup.cfg#L24 | 21:15 |
| cardoe | I'd love if the built wheels encoded the supported Python versions. | 21:15 |
| clarkb | we'll probably use swift stable branches dropping support for 2.7 as an indicator we can probably drop support in pbr now | 21:16 |
| JayF | I am +1 to breaking workflows that use out of date, insecure platforms rather than enabling people to do bad stuff. | 21:16 |
| clarkb | JayF: they aren't necessarily insecure | 21:16 |
| clarkb | the distros in theory maintain them in some capacity | 21:16 |
| clarkb | and PyPy (not really at issue here) is properly maintained and does 2.7 | 21:16 |
| JayF | clarkb: My confidence in such things actually being well-supported when they are *this old* even if someone tries is very, very, very low | 21:16 |
| JayF | clarkb: meaning like, I buy that someone will sell you a python 2.7 they say is security supported in a way that checks boxes, but I would not trust such a promise in my production environments | 21:17 |
| clarkb | JayF: oh I would trust that if PyPy was doing it | 21:17 |
| JayF | ah, so you're saying the 27 support is for pypy's 2.7 api | 21:18 |
| JayF | how dare you bring a grey area into my beautiful binary argument :P | 21:18 |
| clarkb | but ya about once a year or so someone tries to delete 2.7 and half the 3.x versions from PBR support and I have to reexplain why this isn't simple and we're not going to do it until some indeterminate time in the future. We will in theory reach that point but unfortunately we haven't reach it yet | 21:19 |
| clarkb | cardoe: I think the python requires info should be in the wheel somewhere, but that doesn't help if you are pip installing as it needs the info from the index | 21:20 |
| clarkb | https://review.opendev.org/c/openstack/swift/+/853590 the change is there and CI is happy with it but they aren't ready yet I guess | 21:22 |
| opendevreview | Jay Faulkner proposed openstack/ironic-tempest-plugin master: Validate automatic lessee https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/927545 | 21:30 |
| opendevreview | Jay Faulkner proposed openstack/ironic-tempest-plugin master: Validate automatic lessee https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/927545 | 21:31 |
| clarkb | cardoe: hatch has a plugin to pull version info from vcs (hatch-vcs). I still haven't found anything that will record git shas somewhere but maybe it is a feature of one of these plugins | 21:32 |
| cardoe | ah I swear I read something about it. | 21:32 |
| clarkb | oh ya https://github.com/ofek/hatch-vcs?tab=readme-ov-file#metadata-hook | 21:32 |
| clarkb | its a feature of that same plugin so you just have to configure things to do it. Not ideal because then half the repos won't do it, but at least workable in that it is a feature | 21:33 |
| cardoe | Still not something that's out of the box | 21:33 |
| cardoe | Ultimately I agree. PBR trail blazed things that should have been in Python from ages ago. They knew they were wrong in the 2.x days and they should have really made those things happen with 3.0 | 21:34 |
| cardoe | I tell my team all the time... you've only got X tokens to spend on things. Writing your own has a constant cost forever. | 21:38 |
| cardoe | At some point if pypa catches up maybe it's less headache to give a migration path. | 21:39 |
| cardoe | Right now I'm battling sushy and redfish. | 21:39 |
| cardoe | EthernetInterfaces is very lacking. | 21:39 |
| cardoe | We use the Port interface for all our redfish stuff. | 21:40 |
| cardoe | Wanting us to contribute that to sushy for example. | 21:40 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!