| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2024-10-30 | |||
| 20:12:06 | gtema | adamcarthur5: sounds great | |
| 20:13:04 | adamcarthur5 | Cool, I will keep in touch with you guys here, and we can put more permanent discussions of work to complete in the bug | |
| 21:23:42 | opendevreview | Artem Goncharov proposed openstack/codegenerator master: Fix identity resource link code https://review.opendev.org/c/openstack/codegenerator/+/933765 | |
| 21:27:34 | adamcarthur5 | And gtema would you be interested in me reviewing codegenerator patches from you? More of a way for me to learn/stay up to date with the project than anything else | |
| 21:27:34 | adamcarthur5 | https://bugs.launchpad.net/ironic/+bug/2086121 | |
| 21:31:32 | opendevreview | Merged openstack/python-openstackclient master: remove project from network flavor profile https://review.opendev.org/c/openstack/python-openstackclient/+/932328 | |
| 22:36:10 | gtema | adamcarthur5: sure | |
| 22:51:57 | opendevreview | Kevin Carter proposed openstack/ansible-collections-openstack master: Allow wait: false when auto_ip is false https://review.opendev.org/c/openstack/ansible-collections-openstack/+/905308 | |
| #openstack-sdks - 2024-10-31 | |||
| 09:31:05 | opendevreview | Artem Goncharov proposed openstack/codegenerator master: Fix identity resource link code https://review.opendev.org/c/openstack/codegenerator/+/933765 | |
| 11:23:47 | frickler | stephenfin: gtema: there have been multiple sdk job failures now on the reqs bump to latest sdk, so I'm worried that there is an actual regression there, maybe one of you can take a closer look? https://review.opendev.org/c/openstack/requirements/+/932687 | |
| 11:32:18 | frickler | hmm, interestingly no failure in the combined u-c bump, so maybe only bad luck after all https://review.opendev.org/c/openstack/requirements/+/924547 | |
| 11:55:15 | gtema | frickler: ack, looking | |
| 13:38:44 | stephenfin | adamcarthur5: If you could get 928919 passing, that would be super. Alternatively, if you can think of a better approach then please feel free to explore that | |
| 13:40:39 | stephenfin | Virtually all Python web framework appear to provide a routing mechanism and the concept of controller for API endpoints/resources | |
| 13:41:14 | stephenfin | gtema can obviously explain codegenerator better than I can, but both that and the schema validation tests I'm adding to various projects rely on iterating through the routes on a router to find the controllers and ultimately the methods the handle a given HTTP verb + path | |
| 13:43:49 | gtema | correct. For Ironic I can easily access all the routes (http verb + path) and only need to get supported request body, query parameters, information about microversion (either one function that supports different bodies per microversion or one function per microversion) and response description | |
| 13:47:04 | gtema | things like https://opendev.org/openstack/ironic/src/branch/master/ironic/api/controllers/v1/chassis.py#L46 or https://opendev.org/openstack/ironic/src/branch/master/ironic/api/controllers/v1/runbook.py#L72 make it incredibly hard to access the schema and params individually | |
| 13:51:30 | opendevreview | Merged openstack/ansible-collections-openstack master: Enable glance-direct interop image import https://review.opendev.org/c/openstack/ansible-collections-openstack/+/932372 | |
| 15:04:51 | opendevreview | Dmitriy Rabotyagov proposed openstack/ansible-collections-openstack master: Remove default value for interface https://review.opendev.org/c/openstack/ansible-collections-openstack/+/889729 | |
| 15:53:56 | opendevreview | Merged openstack/ansible-collections-openstack master: Allow wait: false when auto_ip is false https://review.opendev.org/c/openstack/ansible-collections-openstack/+/905308 | |
| 16:07:35 | adamcarthur5 | Yeah stephenfin I can get those tests passing. And I'm with gtema, the way Ironic does micro versions makes it tricky to do anything "smarter" than what the current plan is | |
| 16:08:16 | adamcarthur5 | It's also a plan that the Ironic folks were happy with at the PTG, so let's just stay the course. | |
| 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 | |