-
Notifications
You must be signed in to change notification settings - Fork 61
Conversation
e583ca1
to
766d9db
Compare
Codecov Report
@@ Coverage Diff @@
## master #1074 +/- ##
===========================================
- Coverage 75.32% 43.84% -31.48%
===========================================
Files 157 158 +1
Lines 9137 9258 +121
===========================================
- Hits 6882 4059 -2823
- Misses 2255 5199 +2944
Continue to review full report at Codecov.
|
05618c6
to
bca0cc5
Compare
return; | ||
} | ||
|
||
auto del_statement = db.prepareStatement<std::string>("DELETE FROM delegations WHERE role_name=?;", role.ToString()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it could be replace by a single "INSERT OR REPLACE"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point. I copied the style of the NonRoot
functions. Why don't those do the same?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
meta
has a UNIQUE(repo, meta_type, version)
but the delete is DELETE FROM meta WHERE (repo=? AND meta_type=?);
.
With the current schema, INSERT OR REPLACE
would allow multiple versions to accumulate while the current storeNonRoot
only keep the last updated version. To be honest, I'm not sure which would be the preferred semantics, knowing that loadNonRoot
only takes the last version (with ORDER BY and LIMIT 1). @OYTIS, any input?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lbonn Yes, the preferred semantics was to only keep the last version. Again ORDER BY
and LIMIT
are just for precaution, also known as defensive programming, which is not always considered a good style. We can delete them if you feel like it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not necessarily against defensive programming. Thing is, in this case the schema doesn't protect against multiple version. So should the unique constraint be only UNIQUE(repo, meta_type)
? I find it weird that we keep this constraint in code only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok so after discussion with @OYTIS, it results from the old behavior where different versions could accumulate. The schema migration from UNIQUE(repo, meta_type, version)
to UNIQUE(repo, meta_type)
was postponed because it requires a bit of care: only the last version should be migrated, otherwise it would trigger db conflicts.
bca0cc5
to
98ab4c0
Compare
if (it == targets.targets.cend()) { | ||
return std::unique_ptr<Uptane::Target>(nullptr); | ||
} else { | ||
// Search for the target in the top-level targets metadata. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be nice (but I can try after this is merged) to turn this logic into an iterator. Then I think the logic of this function would become a std::find call to the new iterator
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds feasible. But just so you know, I'm expecting this particular function to get reworked again when we actually get around to supporting nested delegations. It may also get more complex if/when we support prioritization and/or TAP 3 (multi-role delegations).
58b2cec
to
161d95b
Compare
@@ -1,3 +1,4 @@ | |||
-- Don't modify this! Create a new migration instead--see docs/schema-migrations.adoc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
161d95b
to
3fe0697
Compare
Signed-off-by: Patrick Vacek <[email protected]>
Signed-off-by: Patrick Vacek <[email protected]>
Signed-off-by: Patrick Vacek <[email protected]>
Signed-off-by: Patrick Vacek <[email protected]>
Signed-off-by: Patrick Vacek <[email protected]>
Signed-off-by: Patrick Vacek <[email protected]>
Signed-off-by: Patrick Vacek <[email protected]>
Signed-off-by: Patrick Vacek <[email protected]>
Copied shamelessly from the full_no_correlation_id test. Signed-off-by: Patrick Vacek <[email protected]>
Signed-off-by: Patrick Vacek <[email protected]>
Targets can also sign. Signed-off-by: Patrick Vacek <[email protected]>
Signed-off-by: Patrick Vacek <[email protected]>
This matches my understanding of the expected behavior for directory structures in target names. Signed-off-by: Patrick Vacek <[email protected]>
Delegated targets do not have their hashes stored in their parent. Signed-off-by: Patrick Vacek <[email protected]>
Signed-off-by: Patrick Vacek <[email protected]>
Signed-off-by: Patrick Vacek <[email protected]>
Signed-off-by: Patrick Vacek <[email protected]>
Based on clang-tidy's advice. Signed-off-by: Patrick Vacek <[email protected]>
3fe0697
to
f949868
Compare
* Simplify SQL logic for delegations. * Reduce if/for nesting for target searching. Signed-off-by: Patrick Vacek <[email protected]>
f949868
to
e51c532
Compare
last_exception = Uptane::ExpiredMetadata("repo", "targets"); | ||
return false; | ||
} | ||
} | ||
|
||
// Update Images delegated Targets Metadata | ||
for (const std::string &delegation : images_repo.delegations("targets")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC @heartsucker had an idea that the delegation tree can be huge and we only want to download what is relevant on this particular update. Also one of the drivers to add support for delegations now was the idea to save space/bandwidth on potentially huge targets.json
for maps by splitting them by region.
So something like an optional (to also support tuf-only scenario) parameter specifying list of targets from director would be useful. Or as an alternative (and probably closer to the spirit of TUF spec) solution, we could only download delegations when intending to download a target or are explicitly asked to.
It may better be left for a next PR though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I recall the same conversations and had similar concerns. For the moment, we've "avoided" the problem by only processing first-order delegations. On one hand, I'm not sure how likely it really is that we will have more than a couple layers of delegation in the automotive world, but on the other hand I think it makes sense to be flexible with our design goals and thus careful and efficient in our implementation.
I agree that we probably shouldn't download all delegations and instead only get what we need. However, that would require a fairly substantial refactoring and I wasn't willing to do it for this PR. Perhaps that should be a requirement for the nested delegation support, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@patrickvacek
I think these issues somewhat correlate, but we can also run into bandwidth problems with simple non-nested delegations. For the aforementioned example of region-based delegation for maps, these don't necessarily need to be nested.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point. Sounds like a higher-priority chunk of work than nesting, then. It shouldn't be too hard, but since I'm unlikely to be able to get it done in the next week or so, would it be possible to merge this as it is and then do that as a follow-up? Others are welcome to contribute; I'm just a bit loathe to let this languish for a week while I'm away.
In other news, it sounds like the backend puts delegated_targets.json into a special delegations/
subdirectory in the images repo.
These Travis errors are pretty annoying. It's failing to download an Ubuntu package in Docker. Not related to my PR; every Travis run is currently failing in a similar manner. By the way, I've gotten as far as testing this PR against the server to the point that aktualizr goes looking for the delegated_targets.json, but it gets a 404. |
Yes, it's really here! However, there are still open questions and more work to be done:
delegation_basic
test I wrote is mostly a copy of thefull_no_correlation_id
. Should these be combined?Role
objects vs. just their names. This could probably be improved.Anything else missing or wrong?