vastai-host-mcp: Instructions file for GitHub Copilot

Ansible Conventions and Best Practices

General Instructions

• Use Ansible to configure and manage infrastructure.
• Use version control for your Ansible configurations.
• Keep things simple; only use advanced features when necessary.
• Ensure all tasks are idempotent - running them multiple times should produce the same result without unintended side effects.
• Follow the standard Ansible role structure (tasks/, handlers/, templates/, defaults/, vars/, meta/).
• Give every play, block, and task a concise but descriptive name:
  • Start names with an action verb that indicates the operation being performed, such as "Install," "Configure," or "Copy"
  • Capitalize the first letter of the task name
  • Omit periods from the end of task names for brevity
  • When writing tasks inside a role (in the role's tasks/ directory), omit the role name from task names since Ansible automatically prefixes them with the role name during execution
  • When including tasks from a separate file, you may include the filename in each task name to make tasks easier to locate (e.g., <TASK_FILENAME> : <TASK_NAME>)
• Use comments to provide additional context about what, how, and/or why something is being done, especially for non-obvious decisions, workarounds, or complex logic
  • Prefer comments that explain reasoning, caveats, or links to external context (e.g., ticket IDs, docs)
  • Avoid comments that simply restate what the task already does (for example, do not add # Install package above a task whose name: is "Install package")
• Use dynamic inventory for cloud resources
  • Use tags to dynamically create groups based on environment, function, location, etc.
  • Use group_vars to set variables based on these attributes
• Use idempotent Ansible modules whenever possible; avoid shell, command, and raw, as they break idempotency.
  • If you must use shell or command, use creates: or removes: to prevent unnecessary execution.
• Use fully qualified collection names (FQCN) everywhere to satisfy ansible-lint (e.g., ansible.builtin.template) and to ensure the correct module or plugin is selected.
  • Use the ansible.builtin collection for builtin modules and plugins.
• Group related tasks together to improve readability and modularity
• For modules where state is optional, explicitly set state: present or state: absent to improve clarity and consistency
• Use the lowest privileges necessary to perform a task.
  • Only set become: true at the play level or on an include: statement if all included tasks require super user privileges; otherwise, set it per task.
  • Only set become: true on a task if it requires super user privileges.