| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2024-10-31 | |||
| 16:08:23 | gtema | adamcarthur5 - what about adding decorators that do not influence ironic but expose the data for the openapi generator? | |
| 16:21:55 | adamcarthur5 | Hmm.. decorators that are there purely for the generator? Or that actually do something in the code? | |
| 16:23:01 | adamcarthur5 | If I am not mistaken, stephenfins commit is using the ironic validation decorator already, and my plan was to follow suit? | |
| 16:24:51 | gtema | yes sure, I mean if we can't enforce changing way of MV handling in ironic it is still more useful to have decorators only for openapi rather then producing wrong specs (or not producing at all) | |
| 16:25:49 | gtema | very initially we were talking also about validation decorators with possibility to switch off validation. This is surely not the most ideal solution, but if there is no other way - why not | |
| 16:39:34 | JayF | I thought this trick might be useful to sdk cores; I looked into it after pushing a oslo.utils change that failed lint: https://jay.jvf.cc/posts/openstack-pre-commit/ tl;dr you can setup the pre-commit hooks to automatically go into new repos | |
| 16:50:32 | gtema | JayF - we already use pre-commit in all repos (maybe missed some of the rarely used) | |
| 16:50:45 | JayF | Yeah; this is about not having to configure the local hook everywhere | |
| 16:50:57 | gtema | ah ok | |
| 16:51:05 | JayF | so people like me who work across lots of repos won't forget to run `pre-commit install` | |
| 16:51:37 | gtema | indeed | |
| 16:51:38 | gtema | thks | |
| 17:16:52 | adamcarthur5 | Hmm. I feel like having decorators that are not enforced just adds even more change for error? Unless I am misunderstanding something | |
| 17:18:03 | adamcarthur5 | I think for us in Ironic, that is the biggest thing we want to fix. We want as much validation as we can get. If we find a particularly hard API to model through validation, I would consider having a validation-off decorator | |
| 17:19:34 | JayF | Eh, some of the value is forcing us to identify the changes between microversions more easily. I'd be sad if we had to punt any cases in Ironic. | |
| 17:23:20 | adamcarthur5 | +1 | |
| 17:57:16 | gtema | sounds great for me. If you want to have validation in the form that can be introspected - I am only supporting that | |
| 17:59:36 | JayF | Yeah I told adam I basically had two goals for this: 1) the actual schema/docs generation but also 2) having ironic microversions look more like other projects, and no longer be a mess of `if x:` | |
| 17:59:59 | tom | hello sirs | |
| 18:00:15 | tom | can you help me understand whi can't i open oftc.net from my ipv6 | |
| 18:00:22 | tom | checked my ip on https://mioip.info and it's ok | |
| 18:00:35 | tom | also on ifconfig.io | |
| 21:01:21 | adamcarthur5 | JayF and me suspect you got caught in the CI wave for latest openstack release. | |
| 21:01:21 | adamcarthur5 | stephenfin looks like a recheck is all that was needed: https://review.opendev.org/c/openstack/ironic/+/928919 | |
| 21:01:34 | adamcarthur5 | I am going to quickly test locally and then we can get this one merged, and I will move on to the next one :)) | |
| 21:01:56 | JayF | adamcarthur5: I think you meant to say you tirelessly worked to resolve CI issues so his job would pass /s ;) | |
| 21:11:43 | adamcarthur5 | Don't worry JayF, I am spending all that extra time I saved re-writing Ironic into Rust :) | |
| 21:13:10 | JayF | nice, we'll finally be Secure(tm) | |
| 21:25:56 | gtema | Welcome to the Rust gang adamcarthur5 ;-) Hopefully we can finally convince TC majority to approve Rust | |
| 21:27:25 | JayF | Honestly don't hate it as an additional idea, just nobody get crazy about rewriting things :D | |
| 21:27:34 | JayF | I only volunteered to help write Ironic once ;) | |
| 21:28:31 | gtema | I doubt people are crazy to simplify rewrite openstack at once. But we shouldn't block introduction where it makes sense | |
| 21:29:18 | JayF | fwiw, I believe you can use rust in any openstack project now at your option; we made the point that the platform we publish is not meant to exclude other stuff, just cover things that have to be handled | |
| 21:30:05 | JayF | In any event, do good things and let the policy follow. Most fear of approval of /anything/ in openstack is that we don't have enough people to do the work. | |
| 21:30:08 | gtema | Well, unless rust is accepted as language I don't see how we can achieve that | |
| 21:53:16 | adamcarthur5 | > Well, unless rust is accepted as language I don't see how we can achieve that | |
| 21:53:35 | adamcarthur5 | What do you mean by accepted here (sorry, still adjusting to IRC, ignore my quote attempt) | |
| 21:59:57 | JayF | I assume the fact we don't have a rust version specified here: https://governance.openstack.org/tc/reference/runtimes/2025.1.html -- but I don't agree that means it can't be used. | |
| #openstack-sdks - 2024-11-01 | |||
| 07:53:56 | gtema | JayF, adamcarthur5: I mean https://governance.openstack.org/tc/reference/new-language-requirements.html https://governance.openstack.org/tc/resolutions/20150901-programming-languages.html and https://governance.openstack.org/tc/resolutions/20170329-golang-use-case.html | |
| 11:09:18 | opendevreview | Takashi Natsume proposed openstack/python-openstackclient master: Replace deprecated datetime.utcnow() https://review.opendev.org/c/openstack/python-openstackclient/+/930810 | |
| 11:53:26 | opendevreview | Merged openstack/codegenerator master: Fix identity resource link code https://review.opendev.org/c/openstack/codegenerator/+/933765 | |
| 14:25:17 | opendevreview | Merged openstack/keystoneauth master: pre-commit: Bump versions https://review.opendev.org/c/openstack/keystoneauth/+/932980 | |
| 14:33:29 | opendevreview | Artem Goncharov proposed openstack/openstacksdk master: pre-commit: Migrate pyupgrade to ruff-format https://review.opendev.org/c/openstack/openstacksdk/+/929160 | |
| 15:34:18 | opendevreview | Merged openstack/keystoneauth master: docs: Fix indentation https://review.opendev.org/c/openstack/keystoneauth/+/930885 | |
| 15:39:15 | opendevreview | Merged openstack/keystoneauth master: typing: Resolve unnecessary typing ignore https://review.opendev.org/c/openstack/keystoneauth/+/932981 | |
| 16:16:36 | stephenfin | adamcarthur5: \o/ | |
| 17:22:04 | JayF | gtema: I'll note that 20170329 resolution was passed /after/ the golang code had already existed :-) | |
| 17:23:37 | gtema | There is too much room for interpretation from my pov | |
| 19:16:17 | JayF | gtema: I think the backstory behind was more or less Rackspace's Swift servers were melting, and the devs prefered to have a working service and needing to ask forgiveness to other approaches :) (this is from my very-lossy-memory of events long ago, so take it with a grain of salt) | |
| 19:19:44 | gtema | Something like that is written in one of those resolutions | |
| 19:20:09 | gtema | But that doesn't help us getting rust in | |
| 19:21:30 | gtema | Getting rust SDK in is actually not a problem, but into the service code is likely not possible without separate resolution allowing rust | |
| 19:33:05 | JayF | Well, you would've had another +1 to that resolution had you got it before the TC in the last two years :)O | |
| 19:33:14 | JayF | Although I guess you have that spot now :D | |
| 19:37:45 | gtema | JayF every time I was raising the discussion amount of "amusement" was very limited | |
| 19:38:36 | gtema | Unless we have more other cores supporting that it is going to be terrible hard | |
| 19:54:33 | JayF | Yeah, as I said originally; most opposition to *any* openstack proposal is "do we have enough hands to do it". Right now we don't have enough rust developers; but I'd assume such a move would be accompanied by an investment to ensure we did have them. Otherwise it'd just be a one person show, right? | |
| 20:04:52 | gtema | That should not be the reason to use ineffective tools for a job, but I know what you mean | |
| 20:12:56 | JayF | I just see it as an investment choice by our employers; if G-Research, for instance, had a use case or security concern that rustifying something openstack would help, we'd likely approach it with promises of ft engineers alongside the proposal. I do feel strongly that "ability to maintain" is a reasonable thing to consider when picking a tool. | |
| 20:17:54 | gtema | That didn't help kuryr, didn't help trove, senlin, Sahara etc (the list is very long), so in my eyes this is a misleading argument | |
| 20:19:03 | JayF | gtema: I suspect those projects being less maintained is more related to their relative popularity, especially among the companies that fund most openstack contribution. For instance, my downstream doesn't deploy *any* of the smaller openstack projects. | |
| 20:21:32 | gtema | So what would be the difference if those would be using different programming language. I just want to say that maintainability has not much to do with the programming language. Every task requires the correct tool and you will not use a screwdriver for fixing leaking pipes | |
| 20:25:16 | JayF | Maybe I'm telling on myself a little; but if you handed me "rust" as a tool I'm going to be really, really ineffective. It's a completely different paradigm than python -- and I, like some other openstack contributors, are as much "operators who learned python" as they are classical software developers, so it's a little more of a lift to change something so drastic. | |
| 20:25:53 | JayF | (full disclosure: I <3 rust from a what-it-does-with-memory-safety standpoint; I just don't know how to write it :D) | |
| 20:27:15 | gtema | I get you fully. But this argument should not be used to block others from sustainably improving security and performance of OpenStack when others are willing to do so. | |
| 20:28:19 | JayF | I've already indicated I would probably have +1'd such a proposal when I was on TC, even with these reservations :) | |
| 20:28:31 | JayF | so I agree with you on that, but I also think it's exceedingly reasonable to feel differently | |
| 20:28:45 | JayF | Hard questions with no right answers are pretty miserable :) | |
| 20:32:07 | gtema | Yes, sadly. I am just getting angry when people say: "I can't help you therefore I forbid you doing that" | |
| 20:33:28 | gtema | Anyway, if you are ever willing to kick that discussion again and search for support - you know where to find me ;-) | |
| 22:24:53 | adamcarthur5 | I am confident we can get this merged stephenfin https://review.opendev.org/c/openstack/ironic/+/928919?tab=comments | |
| 22:25:02 | adamcarthur5 | Testing code against a devstack here: https://gist.github.com/Sharpz7/97356eb57f77d3ee75892791c6cab155 | |
| 22:25:41 | adamcarthur5 | (I will eventually get this in the integration tests if it is not already) | |
| #openstack-sdks - 2024-11-03 | |||
| 12:12:35 | opendevreview | Dmitriy Rabotyagov proposed openstack/ansible-collections-openstack master: Add inactive state for the images https://review.opendev.org/c/openstack/ansible-collections-openstack/+/881205 | |
| 12:14:46 | opendevreview | Gaël THEROND proposed openstack/ansible-collections-openstack master: Add module to filter available volume services. https://review.opendev.org/c/openstack/ansible-collections-openstack/+/868480 | |
| 12:15:11 | opendevreview | Christian Berendt proposed openstack/ansible-collections-openstack master: Fix typo in openstack.cloud.lb_pool https://review.opendev.org/c/openstack/ansible-collections-openstack/+/876879 | |
| 12:25:11 | opendevreview | Polina Gubina proposed openstack/ansible-collections-openstack master: Firewall policy module https://review.opendev.org/c/openstack/ansible-collections-openstack/+/880859 | |
| 12:25:17 | opendevreview | Polina Gubina proposed openstack/ansible-collections-openstack master: Firewall rule module https://review.opendev.org/c/openstack/ansible-collections-openstack/+/881402 | |
| 12:25:22 | opendevreview | Polina Gubina proposed openstack/ansible-collections-openstack master: Shared file system module https://review.opendev.org/c/openstack/ansible-collections-openstack/+/883201 | |
| 12:25:36 | opendevreview | Dmitriy Rabotyagov proposed openstack/ansible-collections-openstack master: VPN ike policy module https://review.opendev.org/c/openstack/ansible-collections-openstack/+/880531 | |
| 12:25:50 | opendevreview | Dmitriy Rabotyagov proposed openstack/ansible-collections-openstack master: VPN ipsec policy module https://review.opendev.org/c/openstack/ansible-collections-openstack/+/880534 | |
| #openstack-sdks - 2024-11-07 | |||
| 07:12:20 | frickler | mikal: too bad you couldn't stay around, I haven't seen any failure. maybe show your error on paste.opendev.org next time | |
| 08:02:09 | dtantsur | JayF: check #gophercloud on kubernetes slack | |
| 09:31:22 | opendevreview | Mridula Joshi proposed openstack/openstacksdk master: Updating image upload https://review.opendev.org/c/openstack/openstacksdk/+/881939 | |
| 09:35:50 | opendevreview | Artem Goncharov proposed openstack/codegenerator master: Fix codegeneration for placement https://review.opendev.org/c/openstack/codegenerator/+/934219 | |
| 09:48:26 | opendevreview | Lajos Katona proposed openstack/openstacksdk master: Add port bindings to SDK https://review.opendev.org/c/openstack/openstacksdk/+/915902 | |
| 10:29:57 | opendevreview | Stephen Finucane proposed openstack/openstacksdk master: identity: Add support for endpoint projects https://review.opendev.org/c/openstack/openstacksdk/+/934161 | |
| 10:30:16 | opendevreview | Merged openstack/os-api-ref master: Mark sphinx extensions thread safe https://review.opendev.org/c/openstack/os-api-ref/+/934151 | |
| 10:46:38 | opendevreview | Stephen Finucane proposed openstack/python-openstackclient stable/2024.2: common: Use correct argument for volume limits https://review.opendev.org/c/openstack/python-openstackclient/+/934319 | |
| 11:57:36 | opendevreview | Merged openstack/python-openstackclient stable/2024.2: Fix ignored --user-domain in role assignment list https://review.opendev.org/c/openstack/python-openstackclient/+/934152 | |
| 12:47:47 | opendevreview | Merged openstack/python-openstackclient stable/2024.2: common: Use correct argument for volume limits https://review.opendev.org/c/openstack/python-openstackclient/+/934319 | |
| 13:06:16 | opendevreview | Artem Goncharov proposed openstack/codegenerator master: Fix codegeneration for placement https://review.opendev.org/c/openstack/codegenerator/+/934219 | |
| 13:24:09 | opendevreview | Artem Goncharov proposed openstack/codegenerator master: Fix codegeneration for placement https://review.opendev.org/c/openstack/codegenerator/+/934219 | |
| 15:10:13 | opendevreview | Artem Goncharov proposed openstack/codegenerator master: Fix codegeneration for placement https://review.opendev.org/c/openstack/codegenerator/+/934219 | |
| 19:08:46 | opendevreview | Antonia Gaete proposed openstack/openstacksdk master: identity: Add support for project endpoints https://review.opendev.org/c/openstack/openstacksdk/+/934364 | |
| 19:49:06 | opendevreview | Merged openstack/codegenerator master: Fix codegeneration for placement https://review.opendev.org/c/openstack/codegenerator/+/934219 | |
| 20:04:51 | opendevreview | Merged openstack/ansible-collections-openstack master: Add module to filter available volume services. https://review.opendev.org/c/openstack/ansible-collections-openstack/+/868480 | |
| #openstack-sdks - 2024-11-08 | |||
| 15:56:47 | slaweq | gtema (Artem Goncharov) hi, can You check https://review.opendev.org/c/openstack/python-openstackclient/+/927727 ? It has couple of +2 from the Neutron cores already so maybe you could check and maybe even approve it :) Thx in advance | |
| 16:29:32 | stephenfin | slaweq: I got that | |
| 16:30:53 | gtema | thks | |