The two SHA256 sums printed above from a) the downloaded CDN image and b) the locally built image, must be identical, and must match the SHA256 from the payload of the NNS proposal.
The two SHA256 sums printed above from a) the downloaded CDN image and b) the locally built image, must be identical, and must match the SHA256 from the payload of the NNS proposal.
Thanks for posting this release @DRE-Team. I have a few questions about the proposal summary if thatās okay:
Can I ask why 8e7a89e4 wasnāt referenced by the proposal summary (deprecating ECDSA-specific fields)
Not all commits that have made changes to ārs/tests/src/orchestratorā, ārs/tests/src/tecdsaā, ārs/tests/src/consensusā and ārs/tests/src/driver/ā files are included in this proposal summary. Iām guessing that lack of an entry in the CODEOWNERS lookup file for ārs/tests/src/driver/ā is the reason for one of these omissions (first point above). But Iām not sure about the others. Are you able to clarify?
Interestingly, a change to the registry canister has been picked up as a relevant change and referenced in this proposal summary (but as far as I understand, it doesnāt actually modify GuestOS). Accepting this proposal wont actually deploy this change. Is it right to include this change in the proposal summary? (I suspect itās due to the proposal summary tooling picking up on the change to the test file, but still)
This proposal summary also references a commit which is then later reverted by another commit. Is there any chance of excluding (or marking) commits that have been reverted within the same proposal in future summaries (to avoid confusion)?
Thanks in advance. I always find your responses very helpful
As a separate question, I noticed that node exporter is being downgraded to an earlier version, but thereās no mention of why (that Iāve been able to find). The commit references an internal GitLab MR. Can I ask how far away DFINITY are from making this sort of information public? @basvandijk
Hopefully this thread is the correct place for discussing the HostOS election proposal that accompanies these GuestOS proposals.
Iām left feeling a little confused by the HostOS proposal summary. Iām hoping to treat this as a learning opportunity. If I had to wrap up my confusion into a simple question, itās - which of the commits referenced in the HostOS proposal summary actually modify the behaviour of HostOS, and why are other commits included in the proposal summary? Is the adjustment to boundary node firewall configuration actually considered a HostOS change? What about the change to allow journal file relabelling?
Which of the changes actually voted in by this proposal actually take affect via this proposal?
At the time of this comment on the forum there are still 2 days left in the voting period, which means there is still plenty of time for others to review the proposal and vote independently.
We had several very good reviews of the Release Notes on these proposals by @Zane, @cyberowl, @ZackDS, @massimoalbarello, @ilbert, @hpeebles and @Lorimer. The IC-OS Verification was also performed by @tiago89. I recommend folks take a look and see the excellent work that was performed on these reviews by the entire CodeGov team. Feel free to comment here or in the thread of each respective proposal in our community on OpenChat if you have any questions or suggestions about these reviews.
Hi @Lorimer , thanks for asking the questions HostOS rollouts are still not fully automated since we submit these proposals much less frequently and we only submitted a few of them so far. But weāll get there. In the meantimeā¦ a few more messages on these forum posts should be fine I think.
To discover which changes affect HostOS, we find all commits that may impact the HostOS update image (since the last release):
In particular the adjustment to boundary node firewall is indeed a component that is shared between the boundary nodes and the HostOS. The journal selinux relabeling very likely takes effect on the HostOS as well ā node team would have to confirm that if you consider this question important?
All changes in the proposal should take effect after the HostOS upgrade. At least if we ask Bazel (build system). And itās hard to argue against the tooling
Since I have your attentionā¦ with CodeGov review the HostOS proposals as well? The release cadence should be approximately once per quarter, although we donāt have anything set in stone yet.
Yes, CodeGov will review these HostOS upgrade proposals since they fall under the IC-OS Version Election proposal topic. We are committed to review all proposals that fall under this topic as well as the System Canister Management proposal topic. Itās very helpful to know the cadence of each type of proposal and for it to be consistent, so thank you for giving that consideration.
Iāve had the impression that the build system isnāt the most reliable judge for what changes are actually modifying the target system for a specific proposal. This came up a few weeks ago when discussing why the proposal summary generation tool needs to filter various things out.
The boundary node firewall caught my eye because firewall changes have previously been deployed via GuestOS proposals. Iām curious why some firewall changes take effect via HostOS proposals and others via GuestOS (which runs inside a VM spun up by HostOS). Itās not too important, but if someone from the node team is able to take 5 mins to clarify/explain this, that would be awesome.
The change to the registry canister is another example (mentioned in my first post above). I donāt believe that change actually modifies GuestOS behaviour - does it?
Would I be overstepping if I created a new forum topic with an aim to discuss and brainstorm ways of making proposal summaries more reliable and/or easier for the community to follow/understand/validate? I think this sort of conversation spans more proposals than just this weeks ones. Having a consistent place to catalogue proposal accuracy issues and discuss/rule out potential ways to improve things would be useful (I hope other in the community may get involved also - hopefully constructively).
Hey @Lorimer, absolutely no problem to create another forum post to discuss release notes generation. Actually, you would also be more than welcome to create PRs for the release notes generation tooling.
Also, the reason we have tooling for this (instead of doing it by hand) is because tooling gives us much better cost-benefit ratio. I wouldnāt be against other options as long as it doesnāt cost us a lot more.
Regarding the node questions, let me poke @andrewbattat, he should be able to provide the information you ask for.
Thanks @andrewbattat, but are you able to provide a little more detail? Are you confirming that the correct deployment target for this commit was HostOS or GuestOS?
The nftables config that youāve linked to doesnāt appear to have been modified since the repository reorganisation a month ago. The last meaningful modification appears to have been this one back in May. Note that this wasnāt referenced in the HostOS proposal, and was instead referenced in this GuestOS proposal (130134).
But note that this commit is not a firewall change. Instead, this change whitelists an additional IPv6 prefix for tests that depend on an SSH connection to a development GuestOS imageāthis change will have no practical effect on production GuestOS images as SSH is disabled. No changes have actually been made to the firewall itself. So youāre correct that the nftables config that I linked to is rarely modified, as it should be
You are getting at something important, and something that Iāve pushed for internally, which is better organization of our proposal releases. Many changes to the HostOS are included in GuestOS proposals (and same for changes to SetupOS). This is because we release GuestOS proposals every week, so it defaults as our release notes for the whole IC-OS. Then, every few months when we do HostOS releases, the HostOS proposal only includes ic-os changes from the last week or so (and it includes GuestOS changes, as weāve just seen). This system is imperfect.
My personal vision is to have a weekly āIC-OSā release that would include changes for all IC-OS images, and then after the release is approved by the community, we would do GuestOS/HostOS upgrades based on the latest approved IC-OS release. This is more of DREās domain though (@sat)
