This repository has been archived by the owner on May 21, 2024. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Wait for secondaries before installing #1533
Wait for secondaries before installing #1533
Changes from all commits
a3dba35
f50eebf
6444360
0556925
fba444f
e0d4f60
3da6079
98860c3
f495ed9
c8f6ff1
b1c226a
72b47fb
15034ce
95b9d9b
ba40f33
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Passing in the Aktualizr object here seems like a big change, but I don't see any immediate concerns. Are there other ways to do this that would simplify this?
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.
Maybe the new methods to Aktualizr is the biggest change in this context. We're coming from
initSecondaries
that already takes anAktualizr
instance. But these are the two sides of the same problemThe alternatives that I know of would be:
Aktualizr::GetStorage()
would be quite ugly.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.
Back then when I introduced this 'Primary::initSecondaries' my intention/plan was and still is to consider it as an initial version of generic Abstract Factory that is part of Secondary Registry mechanism that we might introduce in the future. So, I consider 'Primary::initSecondaries' as something that belongs to Primary/main namespace and it's OK to pass an instance of Aktualizr to it. Having said that, I think that it's not OK to pass this instance to a specific secondary factory method, like createIPSecondaries() as it should belong IpUptaneSecondary namespace. Also, createIPSecondaries() should be under IpUptaneSecondary namespace too, I did not put it there in the first place because we didn't want to spend much time to implementation of some secondary registration mechanism (e.g. something similar to what Laurent proposes for the package manager registry).
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's probably fine as is, but my concern is that the Aktualizr class is mostly meant to be an API for library users, and I think we're extending that a bit here. I fear that something similar is happening to what has happened to SotaUptaneClient. I'm not sure how to fix that, and it might just take some time to step back and figure out a good refactoring strategy. Or maybe I'm worrying too much about things that don't matter.
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 share your concern but in this case, adding a secondary implementation is expected by our library users, so this might be in the scope. But it's indeed not clear cut.
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 Mike suggested that if we want to wait for secondaries, we could so in the implementation of
install()
for example. I don't think he advocates having abstract notions ofwait()
andping()
as virtual methods (@mike-sul please correct me if I'm wrong).In principle I think it's a good design and I also agree that it's dangerous to make this interface grow too much but there are things that would be harder to implement this way:
We might rethink these things or just decide that we don't need it but I think that the clean solution is also less powerful.
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.
that's correct. I strongly against it :).
No, I disagree. IMHO, we already have functionality that kind of "waits" for IP Secondary, it's all software stack running under Asn1Rpc(). What we need is just extend/wrap this functionality in order to add additional policy(ies) into it, e.g. desired timeout/wait time as in this specific case and then use parametrized Asn1Rpc() from IpUptaneSecondary methods. For example, in this specific case, we could call Asn1Rpc(timeout=10m) in IpUptaneSecondary::install() and Asn1Rpc(timeout=60s) in another IpUptaneSecondary's methods (but this is also questionable since we might wanna wait "longer" at the stage of sending metadata too).
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.
The solution you're describing just doesn't have the same behavior as what we've agreed on when we took on this task. The two points I've raised are what we want to satisfy right now.
I sympathize with you as you want to keep away the bloat and coupling and I see that this change can seem to go in the wrong direction and might make things more difficult to untangle later.
However after discussing with @patrickvacek , we still think the best way forward right now is to try to get this merged first. The two main reasons are:
install()
step is not sufficient. As we are giving more fine-grained control on the installation process, we will inevitably need more fine-grained interfaces. It does not necessarily have to be something low-level likeping()
, we could also imagine having aglobalPreInstall()
step inSecondaryInterface()
but that would maybe require more careful design, that we haven't yet startedThere 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 won't be exactly the same internally, but effect/outcome from an external standpoint of view will be the same.
I don't think we need to override install() step, we were mistaken referring to install() method at all, it should be rather sendFirmware() or putMetadata() or both.
I am not sure if I understand if we need to have it at all. I think this idea about "waiting" for secondaries prior to sending firmware to it is conceptually flawed if to look into it from a broader perspective and take into account other aspects such as layered nature on networking stack and potential use-case of "dynamic" secondary support.
That's fair enough and makes sense in many cases but in this particular case the implementation option that goes in line with an all-encompassing plan (proper design) is simpler and easier compared to the given implementation.
@lbonn @patrickvacek There is no need to persuade me :). We've had a great and constructive discussion around this PR and it's absolutely OK that different people have different opinions. I fully understand that discussions cannot last forever, and a decision should be made. What worked the best for me at my previous companies if there was no full consensus among peers is to let a tech lead/architect (or owner of software under discussion) to make a final decision and everyone else should accept and comply to it.
So, that's absolutely fine with me if this change is merged :) as long as this change fulfill the original goal/issue and the CI jobs are happy.
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 appreciate the robust discussion; I think that leads us to a better solution in the end and helps keep us aware of the trade-offs and alternatives. My suggestion for now is to move forward with this PR as is to satisfy our immediate product goals, and then have a followup discussion (perhaps at the sprint review or the next relevant grooming) to consider the longer-term product goals and then decide where to go from here.