Skip to content

[WIP] Refactor cloud-init.sh to use standardized logging functions#1166

Closed
MickLesk with Copilot wants to merge 1 commit into
mainfrom
copilot/refactor-cloud-init-log-messages
Closed

[WIP] Refactor cloud-init.sh to use standardized logging functions#1166
MickLesk with Copilot wants to merge 1 commit into
mainfrom
copilot/refactor-cloud-init-log-messages

Conversation

Copilot AI commented Nov 29, 2025

Copy link
Copy Markdown
Contributor

Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.

Original prompt

Goal: Refactor misc/cloud-init.sh to source a shared core.func (if available) and to replace direct echo/printf log messages with standardized msg_* functions (msg_info, msg_ok, msg_warn, msg_err). Provide a robust fallback so the script remains standalone if core.func is not present.

Changes to make in misc/cloud-init.sh:

  1. At the top of the file (after the shebang and license header), add logic to source core.func from multiple candidate locations and allow an environment override. The code should:

    • Check environment variable MSG_CORE_PATH and source it if set and file exists.
    • Otherwise check a list of candidate paths:
      /usr/local/lib/core.func
      /usr/lib/core.func
      $(dirname "${BASH_SOURCE[0]}")/core.func
    • Source the first existing file (use # shellcheck source=/dev/null when sourcing dynamic paths).
  2. If no core.func was sourced (or if msg_info is not defined), define fallback msg_* functions: msg_info, msg_ok, msg_warn, msg_err. The fallback should use printf and include a simple prefix (e.g., [INFO], [OK], [WARN], [ERROR]). Keep them simple and POSIX/CIT log friendly (no colors/emoji by default). Example fallback:
    if ! type msg_info >/dev/null 2>&1; then
    msg_info(){ printf "[INFO] %s\n" "$"; }
    msg_ok(){ printf "[OK] %s\n" "$
    "; }
    msg_warn(){ printf "[WARN] %s\n" "$"; }
    msg_err(){ printf "[ERROR] %s\n" "$
    "; }
    fi

  3. Replace all direct echo/printf invocations used for informational or status messages with the appropriate msg_* wrapper. Specific replacements in the file:

    • msg_info "Configuring Cloud-Init" instead of echo "[INFO] Configuring Cloud-Init" (preserve behavior when msg_info exists).
    • Replace other occurrences: "[OK] Cloud-Init configured (User: ${ciuser})", warnings like "Warning: whiptail not available...", "[INFO] Cloud-Init Configuration:" block in display_cloud_init_info, "Warning: VM $vmid does not have Cloud-Init configured", "Warning: Unable to determine VM IP address", "Warning: Cloud-Init did not complete within ${timeout}s" — use msg_warn or msg_info/msg_err as appropriate.
    • For informational multi-line outputs that previously used echo and manual formatting (like the credentials file creation and display_cloud_init_info), prefer msg_info/msg_ok for header/status lines and keep file creation unchanged. For display_cloud_init_info's non-colored branch (else branch), replace the leading "[INFO] Cloud-Init Configuration:" and subsequent single-line informational echos with msg_info/msg_ok/msg_warn as appropriate.
  4. Do not alter functional behavior other than output changes. All qm set commands, ipconfig handling, file writes, exports, and the logic of whiptail interactions should remain identical.

  5. Add a short comment in the file header describing the new sourcing behavior and the fallback (1-2 lines) so future maintainers understand the change.

  6. Testing & quality:

    • Run shellcheck on the modified file and fix any obvious issues (avoid using -n flags in shellcheck comments; use shellcheck recommended fixes where unambiguous).
    • Test the script manually in two modes:
      a) With MSG_CORE_PATH or one of the candidate core.func files present (simulate by creating a minimal core.func that defines msg_info/msg_ok/msg_warn/msg_err) to ensure the script uses those functions.
      b) Without any core.func available to ensure fallback functions are used and the script runs standalone.
  7. Commit & PR:

    • Create a branch named refactor/cloud-init-msg-corefunc.
    • Commit the modified misc/cloud-init.sh with a clear commit message: "refactor(cloud-init): source core.func if available and use msg_* wrappers with fallback".
    • Open a pull request against the repository default branch with the same title as the commit message and a description summarizing the change and test steps (include examples of how to override MSG_CORE_PATH).

Notes / rationale to include in PR description:

  • Centralizes logging/formatting to core.func when available to keep consistent UX across scripts.
  • Keeps the script usable standalone by providing a lightweight fallback.
  • Makes future changes to output formatting (colors, quiet mode) centralized.

If any part of this plan needs clarification (preferred core.func path, whether colors/emojis should be enabled in fallbacks, or preferred commit message/PR reviewer), ask before creating the PR.

This pull request was created as a result of the following prompt from Copilot chat.

Goal: Refactor misc/cloud-init.sh to source a shared core.func (if available) and to replace direct echo/printf log messages with standardized msg_* functions (msg_info, msg_ok, msg_warn, msg_err). Provide a robust fallback so the script remains standalone if core.func is not present.

Changes to make in misc/cloud-init.sh:

  1. At the top of the file (after the shebang and license header), add logic to source core.func from multiple candidate locations and allow an environment override. The code should:

    • Check environment variable MSG_CORE_PATH and source it if set and file exists.
    • Otherwise check a list of candidate paths:
      /usr/local/lib/core.func
      /usr/lib/core.func
      $(dirname "${BASH_SOURCE[0]}")/core.func
    • Source the first existing file (use # shellcheck source=/dev/null when sourcing dynamic paths).
  2. If no core.func was sourced (or if msg_info is not defined), define fallback msg_* functions: msg_info, msg_ok, msg_warn, msg_err. The fallback should use printf and include a simple prefix (e.g., [INFO], [OK], [WARN], [ERROR]). Keep them simple and POSIX/CIT log friendly (no colors/emoji by default). Example fallback:
    if ! type msg_info >/dev/null 2>&1; then
    msg_info(){ printf "[INFO] %s\n" "$"; }
    msg_ok(){ printf "[OK] %s\n" "$
    "; }
    msg_warn(){ printf "[WARN] %s\n" "$"; }
    msg_err(){ printf "[ERROR] %s\n" "$
    "; }
    fi

  3. Replace all direct echo/printf invocations used for informational or status messages with the appropriate msg_* wrapper. Specific replacements in the file:

    • msg_info "Configuring Cloud-Init" instead of echo "[INFO] Configuring Cloud-Init" (preserve behavior when msg_info exists).
    • Replace other occurrences: "[OK] Cloud-Init configured (User: ${ciuser})", warnings like "Warning: whiptail not available...", "[INFO] Cloud-Init Configuration:" block in display_cloud_init_info, "Warning: VM $vmid does not have Cloud-Init configured", "Warning: Unable to determine VM IP address", "Warning: Cloud-Init did not complete within ${timeout}s" — use msg_warn or msg_info/msg_err as appropriate.
    • For informational multi-line outputs that previously used echo and manual formatting (like the credentials file creation and display_cloud_init_info), prefer msg_info/msg_ok for header/status lines and keep file creation unchanged. For display_cloud_init_info's non-colored branch (else branch), replace the leading "[INFO] Cloud-Init Configuration:" and subsequent single-line informational echos with msg_info/msg_ok/msg_warn as appropriate.
  4. Do not alter functional behavior other than output changes. All qm set commands, ipconfig handling, file writes, exports, and the logic of whiptail interactions should remain identical.

  5. Add a short comment in the file header describing the new sourcing behavior and the fallback (1-2 lines) so future maintainers understand the change.

  6. Testing & quality:

    • Run shellcheck on the modified file and fix any obvious issues (avoid using -n flags in shellcheck comments; use shellcheck recommended fixes where unambiguous).
    • Test the script manually in two modes:
      a) With MSG_CORE_PATH or one of the candidate core.func files present (simulate by creating a minimal core.func that defines msg_info/msg_ok/msg_warn/msg_err) to ensure the script uses those functions.
      b) Without any core.func available to ensure fallback functions are used and the script runs standalone.
  7. Commit & PR:

    • Create a branch named refactor/cloud-init-msg-corefunc.
    • Commit the modified misc/cloud-init.sh with a clear commit message: "refactor(cloud-init): source core.func if available and use msg_* wrappers with fallback".
    • Open a pull request against the repository default branch with the same title as the commit message and a description summarizing the change and test steps (include examples of how to override MSG_CORE_PATH).

Notes / rationale to include in PR description:

  • Centralizes logging/formatting to core.func when available to keep consistent UX across scripts.
  • Keeps the script usable standalone by providing a lightweight fallback.
  • Makes future changes to output formatting (colors, quiet mode) centralized.

If any part of this plan needs clarification (preferred core.func path, whether colors/emojis should be enabled in fallbacks, or preferred commit message/PR reviewer), ask before creating the PR.


✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

@michelroegl-brunner michelroegl-brunner deleted the copilot/refactor-cloud-init-log-messages branch November 29, 2025 20:04
Copilot AI requested a review from MickLesk November 29, 2025 20:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants