OLPSUP-9046: Handle expired Director's target metadata #1548

mike-sul · 2020-02-03T11:43:36Z

Apply pending update even if its metadata are expired provided that it
was installed before the expiration
Add tests for the target metadata expiration use-case

Signed-off-by: Mike Sul [email protected]

mike-sul · 2020-02-03T11:45:37Z

@lbonn Please, see if it makes sense to you, I am just not sure if this is the right fix for https://saeljira.it.here.com/browse/OLPSUP-9046, as an alternative we could "cancel" a pending update if its metadata are expired.

lbonn · 2020-02-03T13:48:17Z

src/libaktualizr/uptane/directorrepository.cc

@@ -63,6 +63,7 @@ bool DirectorRepository::checkMetaOffline(INvStorage& storage) {
    }

    if (targetsExpired()) {
+      last_exception = Uptane::ExpiredMetadata(type.toString(), Role::Targets().ToString());


lbonn · 2020-02-03T13:50:49Z

src/libaktualizr/primary/sotauptaneclient.cc

    return;
  }

-  LOG_INFO << "Device has been rebooted after an update";
+  LOG_INFO << "Check if there is any pending update for Primary ECU to be applied.";


This text reads like a suggestion to the user, whereas it's a description of the current operation.

Suggested change

LOG_INFO << "Check if there is any pending update for Primary ECU to be applied.";

LOG_INFO << "Checking for pending update for primary ECU to apply";

ok, will update accordingly

lbonn · 2020-02-03T14:40:36Z

src/libaktualizr/package_manager/packagemanagerinterface.h

@@ -35,47 +35,24 @@ enum class TargetStatus {

 class PackageManagerInterface {
 public:
-  PackageManagerInterface(PackageConfig pconfig, BootloaderConfig bconfig, std::shared_ptr<INvStorage> storage,


As you mentioned in your comment, this would break #1498. Do you then have an alternative design to propose? Also, the exception in this PR is the Debian package manager which we don't really care about.

Maybe an intermediate solution would just be to pass a const reference to the full config here, so that implementations can pick what's needed.

In any case, I would prefer if we kept this change in another PR since it's independent from the other changes.

It's not independent, the interface cleanup depends on the fix implementation.

I thought that this is what Eugene intended eventually to do with moving the bootloader instance under the ostree package manager.

I will remove the pack man interface cleanup from this PR and create another PR, although the later will depend on this PR.

- Apply pending update even if its metadata are expired provided that it was installed before the expiration - Add tests for the target metadata expiration use-case Signed-off-by: Mike Sul <[email protected]>

codecov-io · 2020-02-03T17:28:13Z

Codecov Report

Merging #1548 into master will increase coverage by 0.15%.
The diff coverage is 93.33%.

@@            Coverage Diff             @@
##           master    #1548      +/-   ##
==========================================
+ Coverage   81.89%   82.05%   +0.15%     
==========================================
  Files         186      186              
  Lines       11424    11451      +27     
==========================================
+ Hits         9356     9396      +40     
+ Misses       2068     2055      -13

Impacted Files	Coverage Δ
src/uptane_generator/director_repo.h	`100% <ø> (ø)`	⬆️
.../libaktualizr/package_manager/packagemanagerfake.h	`100% <ø> (ø)`	⬆️
src/libaktualizr/package_manager/ostreemanager.h	`100% <ø> (ø)`	⬆️
src/libaktualizr/utilities/types.h	`83.92% <ø> (ø)`	⬆️
src/uptane_generator/uptane_repo.h	`100% <ø> (ø)`	⬆️
...ktualizr/package_manager/packagemanagerinterface.h	`80% <ø> (-10%)`	⬇️
src/libaktualizr/package_manager/debianmanager.h	`66.66% <0%> (ø)`	⬆️
...libaktualizr/package_manager/packagemanagerfake.cc	`91.52% <100%> (+0.61%)`	⬆️
src/aktualizr_secondary/aktualizr_secondary.cc	`76.56% <100%> (ø)`	⬆️
src/uptane_generator/uptane_repo.cc	`100% <100%> (ø)`	⬆️
... and 19 more

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 05fee03...461f7b6. Read the comment docs.

lbonn · 2020-02-04T10:09:56Z

src/aktualizr_secondary/update_agent_ostree.cc

-  // e.g. the pacman will reset/clear the flag by itself
-  _ostreePackMan->rebootFlagClear();
-  return install_result;
+  return _ostreePackMan->finalizeInstall(target);


Not related to this PR really but according to good sources, identifiers starting with underscores should be avoided as they are reserved for "C++ implementations": https://stackoverflow.com/a/20496955/1931271

It actually contradicts the google coding guidelines that we supposed to follow, I found out about it just after this change was merged. I will change this underscore naming to make it consistent with our coding style in another PR.

But personally I prefer/like this code guideline https://www.appinf.com/download/CppCodingStyleGuide.pdf which says the following in regard of underscore usage:

"

Rule 30 Global names must not begin with one or two underscores (“_” or “__”). This is forbidden by the C++ standard as such names are reserved for use by the compiler. Rule 31 With the exceptions of constants and enumeration values, there are no underscores in names (after the first character of the name). 2 " Rule 33 The name of a private or protected member variable begins with a single underscore.3 This is the only underscore in such a name (see Rule 31).

Ah cool, this guide might have interesting insights as well.

In this case, however, even the C++ standard has something to say (2.10):

In addition, some identifiers are reserved for use by C++implementations and shall not be used otherwise;no diagnostic is required.
— Each identifier that contains a double underscore__or begins with an underscore followed by an uppercase letter is reserved to the implementation for any use.
— Each identifier that begins with an underscore is reserved to the implementation for use as a name int he global namespace.

It doesn't exactly conflict as these are not in the global namespace and do not follow the underscore by an uppercase letter but that's quite close.

src/libaktualizr/package_manager/ostreemanager.cc

lbonn · 2020-02-04T10:23:57Z

src/libaktualizr/package_manager/ostreemanager.h

@@ -65,6 +65,7 @@ class OstreeManager : public PackageManagerInterface {

 private:
  TargetStatus verifyTargetInternal(const Uptane::Target &target) const;
+  data::InstallationResult applyInstall(const Uptane::Target &target);


Do we need this new method? We would have install, completeInstall, finalizeInstall and applyInstall. This is starting to get a bit confusing. Or maybe it's missing some docs and/or comments?

It's a private helper method and is not part of the class interface as the other listed methods are, but it, indeed is not really useful now and can be removed

src/libaktualizr/primary/sotauptaneclient.cc

lbonn · 2020-02-04T10:34:47Z

Looks good, just had some minor comments.
The tests are also nice 👍.

Signed-off-by: Mike Sul <[email protected]>

mike-sul · 2020-02-04T12:19:58Z

@lbonn Updated

simao · 2020-02-05T09:49:08Z

I am not sure we should merge this. The backend is returning expired metadata, which is wrong, there is fix in sit right now for this

mike-sul · 2020-02-05T10:04:15Z

I am not sure we should merge this. The backend is returning expired metadata, which is wrong, there is fix in sit right now for this

Without this fix the issue will persists even if the backend returns correctly refreshed metadata (not expired date stamp and incremented version). I emulated the correct back-end behavior by using uptane-generator utility and could reproduce the issue, changes in this PR fixes this issue. I actually managed to get exactly the same error log sequence that Carmeq reported against aktualizr version that they use and this error log sequence is kind of unique and can happen only in one specific scenario - locally stored targets metadata are expired after installation but before a device is rebooted.
This error logs sequence is (important to notice 'check' which makes it unique):

Failed to check director metadata: The targets metadata was expired. Invalid UPTANE metadata in storage.

lbonn · 2020-02-05T10:04:44Z

This is a different issue than the backend one.

The scenario is:

aktualizr deploys a tree from valid metadata but does not reboot
targets metadata used for the install expire
the device reboots, see that some install was ongoing, check the metadata stored on the device (no interaction with backend here). Since the metadata is expired, aktualizr panics.

simao · 2020-02-05T10:15:02Z

@lbonn ah ok, my mistake.

mike-sul requested review from lbonn, pattivacek and eu-siemann February 3, 2020 11:43

mike-sul added the not-ready label Feb 3, 2020

mike-sul force-pushed the fix/OLPSUP-9046/handle-expired-metadata branch from e1ac39e to 748d6e8 Compare February 3, 2020 13:29

lbonn reviewed Feb 3, 2020

View reviewed changes

mike-sul force-pushed the fix/OLPSUP-9046/handle-expired-metadata branch from 6fffd1e to 470a297 Compare February 3, 2020 17:05

OLPSUP-9046: Handle expired Director's target metadata

51a0e4b

- Apply pending update even if its metadata are expired provided that it was installed before the expiration - Add tests for the target metadata expiration use-case Signed-off-by: Mike Sul <[email protected]>

mike-sul force-pushed the fix/OLPSUP-9046/handle-expired-metadata branch from 470a297 to 230c905 Compare February 3, 2020 17:28

mike-sul mentioned this pull request Feb 3, 2020

Refact/packman/cleanup interface #1549

Merged

mike-sul force-pushed the fix/OLPSUP-9046/handle-expired-metadata branch 2 times, most recently from c45055f to 2d66e5a Compare February 3, 2020 18:58

mike-sul removed the not-ready label Feb 3, 2020

lbonn reviewed Feb 4, 2020

View reviewed changes

src/libaktualizr/package_manager/ostreemanager.cc Outdated Show resolved Hide resolved

lbonn reviewed Feb 4, 2020

View reviewed changes

src/libaktualizr/primary/sotauptaneclient.cc Outdated Show resolved Hide resolved

OLPSUP-9046: High-level tests for the target expiration case

461f7b6

Signed-off-by: Mike Sul <[email protected]>

mike-sul force-pushed the fix/OLPSUP-9046/handle-expired-metadata branch from 2d66e5a to 461f7b6 Compare February 4, 2020 12:18

lbonn approved these changes Feb 4, 2020

View reviewed changes

lbonn merged commit c196f1f into master Feb 4, 2020

lbonn deleted the fix/OLPSUP-9046/handle-expired-metadata branch February 4, 2020 12:53

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

OLPSUP-9046: Handle expired Director's target metadata #1548

OLPSUP-9046: Handle expired Director's target metadata #1548

mike-sul commented Feb 3, 2020 •

edited

Loading

mike-sul commented Feb 3, 2020

lbonn Feb 3, 2020

lbonn Feb 3, 2020

mike-sul Feb 3, 2020

lbonn Feb 3, 2020

mike-sul Feb 3, 2020

codecov-io commented Feb 3, 2020 •

edited

Loading

lbonn Feb 4, 2020

mike-sul Feb 4, 2020

lbonn Feb 4, 2020

lbonn Feb 4, 2020

mike-sul Feb 4, 2020

mike-sul Feb 4, 2020

lbonn commented Feb 4, 2020

mike-sul commented Feb 4, 2020

simao commented Feb 5, 2020

mike-sul commented Feb 5, 2020 •

edited

Loading

lbonn commented Feb 5, 2020

simao commented Feb 5, 2020

	LOG_INFO << "Check if there is any pending update for Primary ECU to be applied.";
	LOG_INFO << "Checking for pending update for primary ECU to apply";

OLPSUP-9046: Handle expired Director's target metadata #1548

OLPSUP-9046: Handle expired Director's target metadata #1548

Conversation

mike-sul commented Feb 3, 2020 • edited Loading

mike-sul commented Feb 3, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov-io commented Feb 3, 2020 • edited Loading

Codecov Report

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lbonn commented Feb 4, 2020

mike-sul commented Feb 4, 2020

simao commented Feb 5, 2020

mike-sul commented Feb 5, 2020 • edited Loading

lbonn commented Feb 5, 2020

simao commented Feb 5, 2020

mike-sul commented Feb 3, 2020 •

edited

Loading

codecov-io commented Feb 3, 2020 •

edited

Loading

mike-sul commented Feb 5, 2020 •

edited

Loading