ref: disable dropping director's targets in the install's call

[kbushgit]

Signed-off-by: Kostiantyn Bushko kostiantyn.bushko@yahoo.com

By moving dropping director's targets into the SotaUptaneClient:::AssembleManifest(), means that any failure in the SotaUptaneClient::uptaneInstall(...) call, will lead to drop the director's targets.
Any installation result code, except kOk is considered as a state when we must drop the director's target.

[pattivacek]

Looks promising! I'm glad none of the tests broke, but I'm still trying to make sure this won't change anything unexpected. Probably not. :)

[kbushgit]

We already have a test which cowers case when we process each update(Uptane::Target) separately:

aktualizr/src/libaktualizr/primary/aktualizr_test.cc

Line 416 in f459193

TEST(Aktualizr, SplitUpdates) {

But this test covers the case only with two ECU and with the scenario when both ECU updated successfully, this scenario works fine since we dropping director target only in case of installation failing or completion is needed.

An undefined behavior can occurs in the next scenario:

• we have 3 or more updates(Uptane::Target)
• we process each update one by one (download/install)
• one ECU reports installation failing (important not last one ECU, the first or the second one)

Expected behavior is: the updating process must continue even if one ECU reports failing during installation process.

[pattivacek]

But this test covers the case only with two ECU and with the scenario when both ECU updated successfully, this scenario works fine since we dropping director target only in case of installation failing or completion is needed.

An undefined behavior can occurs in the next scenario:

* we have 3 or more updates(`Uptane::Target`)

* we process each update one by one (download/install)

* one ECU reports installation failing (important not last one ECU, the first or the second one)

Yep, I agree, we don't test what happens if one of them fails. I never had considered that a requirement before.

Expected behavior is: the updating process must continue even if one ECU reports failing during installation process.

I thought for this use case we actually wanted to abort and possibly even rollback the updates that had succeeded. Are you suggesting we should be able to continue updating ECUs after one reports a failure? I think we might need a new test case that demonstrates the functionality you are expecting.

[pattivacek]

Just realized this fixes a bug I ran into (because of targets not getting dropped in all failure cases). @kbushgit can you rebase so we can merge this? I'd still like to see the test case we'd discussed here, but it doesn't have to be part of this PR.

[pattivacek]

Thanks!