feat: run unattended upgrades by default

[jackfrancis]

Reason for Change:

This is a follow-up PR from #4217. This PR sets the newly added runUnattendedUpgradesOnBootstrap LinuxProfile configuration to true for Azure cloud environments.

Issue Fixed:

Credit Where Due:

Does this change contain code from or inspired by another project?

• No
• Yes

If "Yes," did you notify that project's maintainers and provide attribution?

• No
• Yes

Requirements:

• uses conventional commit messages
• includes documentation
• adds unit tests
• tested upgrade from previous version

Notes:

[jackfrancis]

cc @jadarsie @JesusAlvarezTorres @Michael-Sinz

[codecov]

Codecov Report

Merging #4231 (4c6e4aa) into master (f5836e0) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #4231   +/-   ##
=======================================
  Coverage   72.07%   72.07%           
=======================================
  Files         141      141           
  Lines       21698    21702    +4     
=======================================
+ Hits        15638    15642    +4     
  Misses       5103     5103           
  Partials      957      957           

Impacted Files	Coverage Δ
pkg/api/defaults.go	93.48% <100.00%> (+0.04%)	⬆️

---

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 f5836e0...4c6e4aa. Read the comment docs.

[Michael-Sinz]

I am a bit concerned about the split personality here. A configuration deployed in public will act differently than that "same" configuration elsewhere. It makes sense as to why we are doing this but it still is concerning.

I also don't know the config management structure very well so will let others do the deeper review.

[jackfrancis]

I am a bit concerned about the split personality here. A configuration deployed in public will act differently than that "same" configuration elsewhere. It makes sense as to why we are doing this but it still is concerning.

I also don't know the config management structure very well so will let others do the deeper review.

Strictly speaking, there is already ample precedent for default configuration between Azure Stack (and other custom clouds) and public Azure cloud being different. I think the larger concern is that, arguably, the value of ensuring apt-updated nodes is more pressing in non-public cloud, because it can be more difficult to do that patching manually.

I trust @jadarsie and others understand that, but it makes sense to give those folks time to test these assumptions in their environments first.

Also cc @DavidParks8 @ericsuhong in case you have any thoughts.

[Michael-Sinz]

I am a bit concerned about the split personality here. A configuration deployed in public will act differently than that "same" configuration elsewhere. It makes sense as to why we are doing this but it still is concerning.

Strictly speaking, there is already ample precedent for default configuration between Azure Stack (and other custom clouds) and public Azure cloud being different. I think the larger concern is that, arguably, the value of ensuring apt-updated nodes is more pressing in non-public cloud, because it can be more difficult to do that patching manually.

I trust @jadarsie and others understand that, but it makes sense to give those folks time to test these assumptions in their environments first.

Also cc @DavidParks8 @ericsuhong in case you have any thoughts.

I fully agree - just pushing for "better security by default" but those environment should call the shots.

[jadarsie]

/lgtm

I could not start the conversation on my side yet. You can wait until I get back with an answer OR merge and then we can later update the code if needed. I will try to raise this conversation this afternoon.

[acs-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jackfrancis, jadarsie

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [jackfrancis,jadarsie]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[jadarsie]

@jackfrancis, false is the preferred default for ASH.