Skip to content
This repository has been archived by the owner on May 21, 2024. It is now read-only.

Add image without actual file #1035

Merged
merged 5 commits into from
Jan 8, 2019
Merged

Conversation

patriotyk
Copy link
Contributor

No description provided.

@patriotyk patriotyk force-pushed the feat/altualizr_repo_more_improvements branch from feea82f to ead765c Compare December 17, 2018 10:10
@patriotyk
Copy link
Contributor Author

patriotyk commented Dec 17, 2018

I don't understand two other tasks:
'setting director's targets to be empty.'
And
'setting staging (unsigned) director targets to be the same as current director targets.'

@pattivacek
Copy link
Collaborator

@OYTIS can probably explain better than I can!

@OYTIS
Copy link
Contributor

OYTIS commented Dec 17, 2018

@patriotyk

Current workflow of scheduling an update to director in aktualizr-repo is as following:

  1. Add several targets to director with aktualizr-repo --command addtarget. The targets are added to the staged version of diretor/targets.json that is not accessible to remote clients.
  2. Sign all the added targets scheduling and update aktualizr-repo --command signtargets

So there are two problems here:

  1. We can't clear targets.json. The only way to create a new staging targets.json is to issue addtarget command, after which it will obviously be non-empty.
  2. We're starting from scratch every time. It would be convenient to be able to take the current (signed) targets.json and use it as a base.

So I imagined two new commands:

  • emptytargets will make staging targets empty, if the user signs it immediately with signtargets, it will schedule an empty update (what our backend currently does when no update is scheduled).
  • oldtargets will populate staging targets with what is currently signed (stripping the signature of course). User can then use addtarget command to add new targets to it. I think we'll need deltarget as well, but that belongs to another task.

@codecov-io
Copy link

codecov-io commented Dec 17, 2018

Codecov Report

Merging #1035 into master will increase coverage by 0.07%.
The diff coverage is 89.13%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1035      +/-   ##
==========================================
+ Coverage   82.26%   82.33%   +0.07%     
==========================================
  Files         196      196              
  Lines       13794    13928     +134     
==========================================
+ Hits        11347    11467     +120     
- Misses       2447     2461      +14
Impacted Files Coverage Δ
src/aktualizr_repo/director_repo.h 100% <ø> (ø) ⬆️
src/aktualizr_repo/image_repo.h 100% <ø> (ø) ⬆️
src/aktualizr_repo/uptane_repo.h 100% <ø> (ø) ⬆️
src/aktualizr_repo/uptane_repo.cc 95% <ø> (+1.66%) ⬆️
src/aktualizr_repo/main.cc 81.11% <85.71%> (+1.94%) ⬆️
src/aktualizr_repo/repo_test.cc 92.39% <89.02%> (-2.71%) ⬇️
src/aktualizr_repo/image_repo.cc 96.07% <89.47%> (-3.93%) ⬇️
src/aktualizr_repo/director_repo.cc 82.22% <93.75%> (+6.36%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f1adff1...e79fa6f. Read the comment docs.

Copy link
Collaborator

@pattivacek pattivacek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So far, looks good!

("keytype", po::value<std::string>()->default_value("RSA2048"), "UPTANE key type")
("targetname", po::value<std::string>(), "target's name")
("targethash", po::value<std::string>(), "target's hash")
("targetlength", po::value<uint64_t>(), "target's length");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These three new options should have some explanation here that they are intended for a special purpose. Something like "target name (for adding metadata without an actual file)".

@@ -44,4 +50,17 @@ void ImageRepo::addImage(const boost::filesystem::path &image_path) {
timestamp["meta"]["snapshot.json"]["version"] = snapshot["version"].asUInt();
Utils::writeFile(repo_dir / "timestamp.json",
Utils::jsonToCanonicalStr(signTuf(Uptane::Role::Timestamp(), timestamp)));
}

void ImageRepo::addImage(const std::string &name, const std::string &hash, uint64_t length) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not big, but looks like length can be const.

@patriotyk
Copy link
Contributor Author

@OYTIS Thanks, now I understand.

@patriotyk patriotyk force-pushed the feat/altualizr_repo_more_improvements branch from ead765c to 6805d65 Compare December 17, 2018 23:15
@patriotyk
Copy link
Contributor Author

Looks like I have added all commands

@pattivacek
Copy link
Collaborator

@patriotyk if Travis is giving you trouble, rebase so that you get Laurent's fix to speed up the aktualizr-repo test.

@patriotyk
Copy link
Contributor Author

Are there is something to fix?

@@ -8,6 +8,10 @@ class ImageRepo : public Repo {
ImageRepo(boost::filesystem::path path, const std::string &expires, std::string correlation_id)
: Repo(Uptane::RepositoryType::Image(), std::move(path), expires, std::move(correlation_id)) {}
void addImage(const boost::filesystem::path &image_path);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels like too much overloading of this addImage.

Could be helpful to give them different names.

void ImageRepo::addImage(const std::string &name, const std::string &hash, const uint64_t length) {
Json::Value target;
target["length"] = Json::UInt(length);
if (hash.size() == 64) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really elegant... Could we use Uptane::Hash and have too separate arguments on the commandline, like targetsha256 and targetsha512, or does it make cli handling too complicated?

@lbonn
Copy link
Contributor

lbonn commented Dec 19, 2018

Looks fine to me, except for the two small comments.

If you make changes again, I can take a quick look on Friday.

Signed-off-by: Serhiy Stetskovych <patriotyk@gmail.com>
Signed-off-by: Serhiy Stetskovych <patriotyk@gmail.com>
Signed-off-by: Serhiy Stetskovych <patriotyk@gmail.com>
@patriotyk patriotyk force-pushed the feat/altualizr_repo_more_improvements branch 4 times, most recently from e892cb3 to b634fb5 Compare December 24, 2018 13:53
Signed-off-by: Serhiy Stetskovych <patriotyk@gmail.com>
@patriotyk patriotyk force-pushed the feat/altualizr_repo_more_improvements branch from b634fb5 to f577ed0 Compare December 24, 2018 15:12
Signed-off-by: Serhiy Stetskovych <patriotyk@gmail.com>
@patriotyk patriotyk force-pushed the feat/altualizr_repo_more_improvements branch from f577ed0 to e79fa6f Compare December 26, 2018 10:26
@lbonn lbonn merged commit 45d8053 into master Jan 8, 2019
@lbonn lbonn deleted the feat/altualizr_repo_more_improvements branch January 8, 2019 12:32
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants