Feedback Wanted

[natankeddem]

I am looking for feedback on the new file hosting and Ansible Playbook functionality. I am hoping these features will flesh autopve out enough to come close to a fully infrastructure as code type tool. You should be able to now take a Proxmox host from zero to a fully installed a fully configured state utilizing the hooks the Proxmox developers have provided.

1. Are the new features useful for you?
2. Is the usage and documentation clear?
3. Are there any changes in the implementation you would want?
4. Are there additional features you are looking for out of autopve?

[SlothCroissant]

Love this so far, combining a few IaC workflows (install the OS, then switch over to Ansible to configure) into one is brilliant.

Feature ask:

• Ansible Galaxy collection/role install support - as of now, one can plumb into the Dockerfile and rebuild, but love the feature being baked in. Could have the user pass through a file with roles/collections in ansible format and have the initial boot install them? Not sure the best idea, but appreciate the consideration!

[natankeddem]

Hi @SlothCroissant ,
Thank you so much for your feedback. I think allowing role configuration from the webgui would be a great feature to add. I am not an expert in Ansible so I will need to come up to speed on roles and galaxy features. I haven't had a much free time to exercise autopve in this respect yet.

Are you of the mindset that the roles/collections should be global or would playbook specific roles work?

Right now the playbooks will be stored in the data folder. Like this:
/data/playbooks/one
/data/playbooks/two
ect
Each playbook folder contains and inventory.yaml and playbook.yaml at the current time.

Reading the documentation:
https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_reuse_roles.html#role-directory-structure
What I think can be done currently is that you can install roles manually in the /data/playbooks/one/roles folder:
ansible-galaxy role install --roles-path /data/playbooks/one/roles geerlingguy.apache
Then the roles resolution in ansible should be able to pick up these new roles for use in this playbook. Do you want to try this out for me?

What I can implement long term might be to implement a new requirements.yaml that you could edit in the webgui.
https://docs.ansible.com/projects/ansible/latest/galaxy/user_guide.html#installing-roles-and-collections-from-the-same-requirements-yml-file
Then autopve can handle installing the roles for the user automatically per this requirements.yaml file and handle the installation into the /data/playbooks/one/roles folder automagically. I think making this a non-global configuration and specific to a playbook would be the most flexible option?

[SlothCroissant]

Are you of the mindset that the roles/collections should be global or would playbook specific roles work?

Ansible generally will collect requirements in either way - could probably do either and be good. The only downside to per-playbook is that you'd generally want the roles/collections downloaded prior to the playbook being called just for timing reasons (don't want to wait however long to download all the dependencies while the POST request is still pending acknowledgement, after all).

Reading the documentation: https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_reuse_roles.html#role-directory-structure What I think can be done currently is that you can install roles manually in the /data/playbooks/one/roles folder: ansible-galaxy role install --roles-path /data/playbooks/one/roles geerlingguy.apache Then the roles resolution in ansible should be able to pick up these new roles for use in this playbook. Do you want to try this out for me?

This is correct - roles/collections are globally-available by default when installed by ansible-galaxy. For example, I tested this by adding the below snipped to main.py:28 and it was consumable later by the ansible commands:

# install ansible requirements if requirements yml exists
if os.path.exists("data/playbooks/ansible_requirements.yml"):
    logger.warning("Installing Ansible requirements.")
    import subprocess
    subprocess.run(
        ["ansible-galaxy", "install", "--force", "-r", "data/playbooks/ansible_requirements.yml"],
        check=True,
    )
else:
    logger.warning("No Ansible requirements file found, skipping.")

What I can implement long term might be to implement a new requirements.yaml that you could edit in the webgui. https://docs.ansible.com/projects/ansible/latest/galaxy/user_guide.html#installing-roles-and-collections-from-the-same-requirements-yml-file Then autopve can handle installing the roles for the user automatically per this requirements.yaml file and handle the installation into the /data/playbooks/one/roles folder automagically. I think making this a non-global configuration and specific to a playbook would be the most flexible option?

I think this is a good idea and would work, so long as autopve re-runs the ansible-galaxy install once that UI requirements.yml is edited, we'd be good to go. I'd also venture that in the shorter-term, you could add a prerequisite of a requirements.yml like I did above in my test, I assume most folks would be totally cool with this option too, and it's super easy to implement, if a bit less flexible.

Appreciate your brainstorming on this!

[natankeddem]

I have a working prototype for role and collection installation that I am putting the finishing touches on and should be live in the next day or so hopefully. Basically you can edit the requirements.yaml file and then apply it when you are done. Every apply will delete the existing roles and collections for that playbook and will install them again. Some pictures for reference:

[natankeddem]

The playbook requirement installation feature has been added to v2.2.0. I haven't had much time to test it so hopefully I can get some of your guys to exercise it a bit.

[nuxlli]

I'm doing some tests with this feature and have some comments/questions:

• The Docker image is not ready to run Ansible inventory over ssh, openssh-client is not there.

• I'm not sure about running it with post-installation-webhook, at least in proxmox-ve_9.1-1, the installation will restart the machine just after calling this webhook, but even if it does not restart it, I think we want to run the playbook over the proxmox machine, not over the installation, right?

• This can be addressed with a first-boot script that calls the webhook to activate Ansible. It might be helpful to provide a default or example script so that it runs after the first boot and uses the same system info as during installation.

I see great potential in this feature; however, the overall flow remains unclear to me.

[natankeddem]

Hi @nuxlli ,
I will add openssh-client client later today with some other fixes I have planned.

I haven't gotten time to fully flesh out the lifecycle of these mechanics. My plan was something like this:

Boot Installer
   ↓
autopve answers generated
   ↓
Installer completes
   ↓
Post-install webhook → Ansible Playbook started and waiting
   ↓
Reboot
   ↓
Installed OS boots
   ↓
First-boot script installs dependencies and other configuration
   ↓
Ansible continues operation as network becomes accessible on target
   ↓
System fully configured

One idea that I had would be to utilize a wait on the Ansible script, which would delay activation until the target was rebooted. Very roughly, ai assisted (and untested) something like this:

---
# PLAY 1: Parse System Info & Wait for Reboot
- name: Prepare and Wait for Target
  hosts: localhost
  connection: local
  gather_facts: no
  tasks:
    # -------------------------------------------------------------
    # 1. Extract the IP from system_info
    # -------------------------------------------------------------
    - name: Parse Management IP from system_info
      set_fact:
        target_ip: >-
          {{ 
            (system_info['network-interfaces'] 
            | selectattr('is-management', 'defined') 
            | selectattr('is-management', 'equalto', true) 
            | map(attribute='address') 
            | first).split('/')[0] 
          }}

    # Optional: Log what we found based on the webhook data
    - name: Display System Details
      ansible.builtin.debug:
        msg: 
          - "Targeting IP: {{ target_ip }}"
          - "Proxmox Version: {{ system_info.product.version }}"
          - "Kernel: {{ system_info['kernel-version'].release }}"
          - "Boot Mode: {{ system_info['boot-info'].mode }}"

    # -------------------------------------------------------------
    # 2. Add the dynamic host to the inventory
    # -------------------------------------------------------------
    - name: Add host to in-memory inventory
      add_host:
        name: "{{ target_ip }}"
        groups: new_proxmox_install
        # Persist system_info to the host so it's available in Play 2
        system_info: "{{ system_info }}"

    # -------------------------------------------------------------
    # 3. Wait for the physical reboot
    # -------------------------------------------------------------
    - name: Wait for SSH on {{ target_ip }}
      ansible.builtin.wait_for:
        host: "{{ target_ip }}"
        port: 22
        state: started
        timeout: 1200 # Wait up to 20 mins
        delay: 60     # Critical: Wait for installer to shut down first
      delegate_to: localhost

# PLAY 2: Configure the New System
- name: Configure Proxmox
  hosts: new_proxmox_install
  user: root
  gather_facts: yes
  
  tasks:
    - name: Verify Connection and Context
      ansible.builtin.debug:
        msg: "Configuring host {{ inventory_hostname }} (ID: {{ system_info['machine-id'] }})"

    - name: Update System
      ansible.builtin.apt:
        update_cache: yes
        upgrade: dist

In addition, first-boot could be used to setup the target in several different ways:

• Dependencies needed prior to ansible interactions?
• Configuration which is difficult in ansible, ie modifying network setup/configuration?
• You don't want to use ansible at all.
• Alternative trigger for Playbook endpoint activation, rather than using post-installation-webhook, as you stated.

[natankeddem]

It took some time but I fleshed out this example, with some additions to the app, to be fully functional.
Example published:
https://github.com/natankeddem/autopve?tab=readme-ov-file#ansible-playbook-example

You will need to be on v2.2.8 or newer.