During bootup, for existing applications with RW images, avoid waiting for verification of downloaded images.

[kalyan-nidumolu]

During bootup, for existing applications with RW images, avoid waiting for verification of downloaded images.

1. DomainMgr should publish AppUUID for the images in ImageStatus
2. Zedmanager, when creating an App instance, should check if
   the image is already available in ImageStatus for RW images.
   if yes, it should just add Verifier config and skip waiting for
   verifier
3. Verifier - Skip verifying images on bootup
   • These can be verified with the first verifier config is added.

Signed-off-by: Kalyan Nidumolu kalyan@zadeda.com

Fix Verifier to not wait for images in verified/ dir to be re-verified
after bootup.

Signed-off-by: Kalyan Nidumolu kalyan@zadeda.com

[kalyan-nidumolu]

Am still testing the fix. Please review the fix.

[eriknordmark]

I don't understand the design.
zedmanager doesn't need to wait for a verified image when a RW image already exists. That's OK

But you also seem to be removing the code in verifier which re-runs the verification and publication of the verified images on boot. I don't understand why (assuming that is what you are removing; didn't complete the review due to my lack of understanding of what you are trying to do)

[eriknordmark]

3. Verifier - Skip verifying images on bootup

* These can be verified with the first verifier config is added.

Doesn't zedmanager look for a VerifyImageStatus (after it has looked for a RW image), and if none found it creates a DownloaderConfig? If so change #3 will result in a duplicate/unneeded download.

[kalyan-nidumolu]

I don't understand the design.
zedmanager doesn't need to wait for a verified image when a RW image already exists. That's OK

But you also seem to be removing the code in verifier which re-runs the verification and publication of the verified images on boot. I don't understand why (assuming that is what you are removing; didn't complete the review due to my lack of understanding of what you are trying to do)

Here is the design - basically what we discussed:

1. Verifier - on bootup - published VerifiedImageStatus with state set to Download.
2. When Zedmanager reacts to VerifiedImageStatus, it adds VerifierImageConfig
   -- Existing Code - No changes here
3. Verifier reacts to VerifierImageConfig ( sees it as Modify ) - Does the Actual verification here..
4. Zedmanager - When creating an app Instance - checks if the imageStatus already exists for the APP UUID - if yes - directly uses it. If not - Falls through the existing code path..

With these changes - verification of previously verified images happen in verifier.go -- handleModify --- And happens through the triggers explained above. Hence removed the current special code for verification..

This is the gist of the design..

[kalyan-nidumolu]

3. Verifier - Skip verifying images on bootup

* These can be verified with the first verifier config is added.

Doesn't zedmanager look for a VerifyImageStatus (after it has looked for a RW image), and if none found it creates a DownloaderConfig? If so change #3 will result in a duplicate/unneeded download.

No..Because currently, we check for VerifierImageStatus in zedmanager.. And verifier - during bootup - publishes VerifyImageStatus with State set too DOWNLOADED. this moved to DELIVERED ( practivally immediately as explained above ) .. But irrespective on when this move, the VerifyImageStatus ensures the image doesn't gett downloaded again..

[eriknordmark]

• Verifier reacts to VerifierImageConfig ( sees it as Modify ) - Does the Actual verification here..

That requires new code paths AFAIK.
When verifier handles a VerifyImageConfig it assumes the file is in /persist/downloaded/pending (and moves it via the verifying to the verified directories). If you want it to look in the verified directory and run the verification there you need that logic. Otherwise things are likely to break with failures about /persist/download/pending/ missing.

[kalyan-nidumolu]

• Verifier reacts to VerifierImageConfig ( sees it as Modify ) - Does the Actual verification here..

That requires new code paths AFAIK.
When verifier handles a VerifyImageConfig it assumes the file is in /persist/downloaded/pending (and moves it via the verifying to the verified directories). If you want it to look in the verified directory and run the verification there you need that logic. Otherwise things are likely to break with failures about /persist/download/pending/ missing.

I handled it in verifier.handleModify -- The code that was being executed during init - that just takes the image in the verified directory - and verifies it - I added similar code in handleModify. So, don't need to move it through pending/verifier/verified again..

[eriknordmark]

Mostly nits