Closed b-rowan closed 2 months ago
Took my third attempt to wrap my head around this PR - with limited success. I think there are three things in this PR
3. Preparation work for implementing the "initial update for device without unique identifier" use case through a plugin mechanism. It could help to describe this as a feature request - even if the idea is to implement it as a plug-in. This could allow to understand how this can fit into gooseBit. Maybe the feature should even be part of the regular code base and that can be activated through a configuration?
It's not specifically that, I actually had a cloudflare integration in mind. Right now with our internal version (which is very outdated), we have a cloudflare integration which creates tunnels to devices automatically based on UUIDs. This requires configuring cloudflared
on the device with a specific private key, and in order to do that we are generating a custom SWU that only writes to that config file, then pushing it to the device. So the idea would be to check for gooseBit updates for a device, then check for custom SWU file from plugin, and to do that we need a standard internal interface that doesn't require creating a DB entry (as I would like to delete these SWU's off disk ASAP, we can always regenerate them later).
Simplify the Pydantic model instantiation relying on from_attributes. As an independent commit I think it would be an obvious valuable refactoring.
I think you're right about this for now. I have made this PR a bit more atomic by removing 2 and 3. I would really like to be able to get a plugin interface of some kind included here, I want to have our internal stuff up to date, but it seems every foothold I've tried to gain on that side of things causes one issue or another. If you have any ideas on that side of things LMK.
Simplify the Pydantic model instantiation relying on from_attributes. As an independent commit I think it would be an obvious valuable refactoring.
I think you're right about this for now. I have made this PR a bit more atomic by removing 2 and 3. I would really like to be able to get a plugin interface of some kind included here, I want to have our internal stuff up to date, but it seems every foothold I've tried to gain on that side of things causes one issue or another. If you have any ideas on that side of things LMK.
@b-rowan let's discuss this through another channel. Can you send me an email to the address from my commits?
Can you send me an email to the address from my commits?
Done. Sent from my upstreamdata.ca email.
pydantic
models have a deprecatedfrom_orm
method, which is designed to parse DB models into the schema. This was superseded bymodel_validate
, which does the same thing when the schema configfrom_attributes
value is true. Migrating to using this simplifies the method of parsing DB models, and will eventually allow the schemas to be used internally instead of the DB models.Reference here - https://docs.pydantic.dev/2.0/usage/models/#arbitrary-class-instances
The goal here is to get to the point where we can pass around arbitrary abstract software types internally, which will allow hooking the software that a device should receive.