Change some log messages from warning to info

[ani-sinha]

Proposed Commit Message

Warning logs tends to alert customers that something is broken! Info log level is more suitable in those cases where we want to inform the user of some actions but not give an impression that something is broken and needs fixing. Convert some warn logs to info logs when handling user account passwords.

Merge type

• Squash merge using "Proposed Commit Message"
• Rebase and merge unique commits. Requires commit messages per-commit each referencing the pull request number (#<PR_NUM>)

[ani-sinha]

@TheRealFalcon what do you think?

[TheRealFalcon]

@ani-sinha

Warning logs tends to alert customers that something is broken

Hmmm, I would say that errors are for alerting that something is broken. In the cases pointed out in this PR, cloud-init was asked to do something that it was not able to. I think that is something worthy of a warning, especially surrounding user passwords. Otherwise the only way somebody would be alerted to this condition is if they go digging through the logs which won't happen unless somebody notices a problem and correctly identifies cloud-init as the cause.

That said, in the case of passwd, I can see the case for downgrading that to INFO, both in that we specifically document that passwd doesn't apply to existing users and to use hashed_passwd instead for that use case, along with the fact that a new instance id or calling of cloud-init clean can wind up triggering this warning without the user having done anything to cause this warning. For the other two though, it seems they can only be triggered if this user is asking for something that doesn't make sense.

May I ask where this request is coming from? Is there a customer on a stable platform that started seeing a return code of 2 after our new warning mechanism was backported? If so, do you think it makes mores sense for the lock_passwd cases to be downstream changes rather than upstream?

[ani-sinha]

May I ask where this request is coming from? Is there a customer on a stable platform that started seeing a return code of 2 after our new warning mechanism was backported?

The request is not yet from a customer but we suspect that once we start rolling this out to the hands of our customers, they will complain and get confused. This has happened before with other logs and the schema validator.

[ani-sinha]

If so, do you think it makes mores sense for the lock_passwd cases to be downstream changes rather than upstream?

If upstream is not willing to change this, we are debating whether to have a downstream only patch or to simply document it and point customers to it if they ask.