GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
init: Only nest btrfs if container is on btrfs
Signed-off-by: Stéphane Graber <firstname.lastname@example.org>
tests: Fix shell return value masking
images: Respect disabled cache expiry
images: Store UploadedAt as RFC3399
patches: Convert UploadedAt to RFC3399
tests: Fix image expiry test
daemon: Simplify time channels
daemon: Fix handling of config triggers
tests: Fix bad raw.lxc test
daemon: Don't update images while pruning
images: Actually get the list of images to remove
test: Setup basic channel handler for triggers
lxc/storage: Fix remote operations
That's a potpourri of a branch. :)
@brauner this went unnoticed despite the review (#3817), unit tests! :)
I was trying to find this bug in issue #3904, but I found a problem with the unit/integration test instead :)
IMO you need both (integration AND unit). Since integration tests are more complex, they are more likely to be broken by themselves or miss corner cases.
I'm a concerned about doing database work/fixes/migrations using the patches system, because:
It's not transactional, if a single db.XXX api of the one above fails, but the previous ones have succeeded, you are in an undetermined state, in principle. This might not be a practical concern now, but it will be more with clustering.
More importantly, these patches are run after all database updates have been applied, so for example the statement "UPDATE images SET upload_date=? WHERE id=?" could fail if at some point (say) we change the schema of the images table or something like that, and the user upgrades from a version that had a schema compatible with the query in the patch to a version with a schema that is incompatible with the query. We could change the statement to match the new schema, but it could be easily missed since we don't cover each and every upgrade path with integration tests.
In this case, I see no reason for not writing a regular database update instead of a patch.
A DB schema update cannot be backported to 2.0, patches can, that's why this is a patch.
It's true I should probably have used this within a transaction, that being said this particular patch can be re-executed perfectly safely so it doesn't actually matter in the end.
I see. It's something we'll need to fix then, because in a cluster we'll want patches to be something that is applied locally once per-node, while database changes like this should be applied once cluster-wide by the leader using dqlite.
@freeekanayaka I think keeping the DB updates for schema changes makes sense, but we may want to expand the patches system to allow for different scopes. So a patch could be marked as either needing to apply to all the nodes individually (when moving stuff on the filesystem or doing other node-local actions) or be run once for the whole cluster (data migration, changing default profiles, ...)