Try using sqlite in production #32
Conversation
major
force-pushed
the
try-sqlite
branch
2 times, most recently
from
e1fc518
to
9698112
Compare
Switch over to using sqlite in production and add a step during the container build to pack the initial image data in the container. This speeds up the startup time and also makes it work better in air-gapped environments. We're able to remove the threading/scheduling from the main module by using this method. Signed-off-by: Major Hayden <[email protected]>
|
@FKolwa This is kinda disgusting for now and could use some clean-up, but it's working. I can split it tomorrow if needed. |
There was a problem hiding this comment.
I like the approach.
You're touching on a lot of stuff in here but I can't see a good way to split this up.
In the long run I'd like to have an update function in place or at least an easy way to check whether your image data is out dated. Something that doesn't necessarily require you to pull a new image from our repository.
|
|
||
|
|
||
| @repeat(every(24).hours) | ||
| def self_update_image_data() -> None: |
There was a problem hiding this comment.
Would a regular update of image data still make sense?
This could be configurable in some way so that air gapped instances wouldn't try to reach our servers.
Or should we move to a "pull on demand"?
E.g. downloading data, mounting it into the container and restart / trigger a reload function.
There was a problem hiding this comment.
I know we've talked about having daily updated builds available with fresh data, but I could see a scenario in which it would be easier for customers to just inject new data instead of pulling a new container and moving it into an air gapped box. WDYT?
Switch over to using sqlite in production and add a step during the container build to pack the initial image data in the container. This speeds up the startup time and also makes it work better in air-gapped environments.
We're able to remove the threading/scheduling from the main module by using this method.