ansible-middleware / wildfly

A collection of roles to help install, setup and maintain Java JEE appserver Wildfly
GNU General Public License v2.0
11 stars 22 forks source link

Inconsistent local download archive path - causing issue with local_path_to_archive #249

Open iamgini opened 2 weeks ago

iamgini commented 2 weeks ago
SUMMARY

Noticed the controller and EE getting different paths when running from controller and running locally using automation controller (the dev and testing stage)

ISSUE TYPE
ANSIBLE VERSION
$ ansible-navigator exec -- ansible --version
ansible [core 2.15.3]
  config file = /home/iamgini/ansible-bau/ansible-jboss-automation/ansible.cfg
  configured module search path = ['/home/runner/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.9/site-packages/ansible
  ansible collection location = /home/iamgini/ansible-bau/ansible-jboss-automation/collections:/home/runner/.ansible/collections/ansible_collections:/usr/share/ansible/collections/ansible_collections
  executable location = /usr/bin/ansible
  python version = 3.9.16 (main, May 31 2023, 12:21:58) [GCC 8.5.0 20210514 (Red Hat 8.5.0-18)] (/usr/bin/python3.9)
  jinja version = 3.1.2
  libyaml = True

ansible-navigator.yml

---
ansible-navigator:
  execution-environment:
    container-engine: podman
    image: registry.redhat.io/ansible-automation-platform-24/ee-supported-rhel8:1.0.0-395
    # image: localhost/ee-supported-rhel8-expect:1.0
    enabled: true
    pull:
      policy: missing
    # volume-mounts:
    #   - src: "/home/iamgini/projects/Scripts"
    #     dest: "/opt/apps"
    #     options: "Z"
  editor:
    command: code-server {filename}
    console: false

  logging:
    # level: debug
    append: false

  mode: stdout

  playbook-artifact:
    enable: false
    replay: artifacts/ansible_artifact.json
    save-as: artifacts/ansible_artifact.json
COLLECTION VERSION
$ ansible-galaxy collection list | grep eap
redhat.eap                                    1.4.3  
STEPS TO REPRODUCE
---
- name: Ensure eap is install and running as a service
  hosts: all
  vars_files:
    - vars/vars.yml
  vars:
    eap_offline_install: true
    eap_version: 8.0.0
    eap_apply_cp: false
  roles:
    - eap_install
    - eap_systemd
  tasks:
    - name: Install second driver with eap_driver role
      ansible.builtin.include_role:
        name: eap_driver
      when: jdbc_drivers is defined and jdbc_drivers | length > 0
      vars:
        eap_driver_module_name: "{{ item.name }}"
        eap_driver_version: "{{ item.version }}"
        eap_driver_jar_filename: "{{ item.jar_file }}"
        eap_driver_jar_url: "{{ item.url }}"
      loop: "{{ jdbc_drivers }}"
EXPECTED RESULTS

The local_path.stat.path should be consistent when we run it from the controller and ansible-navigator.

ACTUAL RESULTS
$ ansible-navigator run jboss_eap_deployment.yaml -e "nodes=jboss"  -vvv

The suspected task:

in roles/eap_install/tasks/install.yml

- name: Check local download archive path
  ansible.builtin.stat:
    path: "{{ lookup('env', 'PWD') }}"
  register: local_path
  delegate_to: localhost

Running from automation controller

{
  "ansible_facts": {
    "full_path_to_archive": "/opt/jboss_eap//jboss-eap-8.0.0.zip",
    "local_path_to_archive": "/runner/project/jboss-eap-8.0.0.zip"
  },
  "_ansible_no_log": null,
  "changed": false
}

Running local using ansible-navigatror

ok: [rhel8-jboss] => {
    "ansible_facts": {
        "full_path_to_archive": "/opt/jboss_eap//jboss-eap-8.0.0.zip",
        "local_path_to_archive": "/home/iamgini/ansible-bau/ansible-jboss-automation/jboss-eap-8.0.0.zip"
    },
    "changed": false
}
RanabirChakraborty commented 2 weeks ago

Hello, @iamgini looks like you are using the old eap collection, Can you please use the latest one? in the latest collection, we have introduced a new variable wildfly_install_download_controller_download_dir which can probably help you in this scenario.

- name: Check local download archive path
  ansible.builtin.stat:
    path: "{{ wildfly_install_download_controller_download_dir | default(lookup('env', 'PWD')) }}"
  register: local_path
  delegate_to: localhost

Checkout the PR as well - https://github.com/ansible-middleware/wildfly/pull/216

iamgini commented 2 weeks ago

@RanabirChakraborty oh ok. Thanks for letting me know. Actually, the customer is using an old EE and might be using the old collection inside. I will try this and update the issue.

rpelisse commented 2 weeks ago

@sabre1041 @guidograzioli do we provided our collection within an execution environment? If so, we probably need to update this one.

iamgini commented 1 week ago

I can see the following check fails.

The task should check wildfly_install_download_controller_download_dir/eap_archive_filename_local right?

- name: "Validate existing zipfiles {{ eap_archive_filename }} for offline installs"
  ansible.builtin.assert:
    that:
      - eap_version is defined and eap_archive_filename_local is exists
    quiet: True
    fail_msg: "An offline install was requested, but files are not present on the controller: {{ eap_archive_filename }}"
  when:
    - eap_offline_install
rpelisse commented 1 week ago

@iamgini That really points toward the fact that the zipfile is NOT on the controller (or not at the right place).

I recall from our discussion elsewhere, that you mentioned you could NOT put the zipfile on the controller (so I suspect you put it on the target). If so, we need to change this check because the following stmt only works on the controller:

Can you simply remove this part of the code in our local testing env (just edit the file in ~/.ansible/collections/...) and test, to confirm this is the culprit?

iamgini commented 1 week ago

@rpelisse correct. Yes, I removed that assert task in the collection and playbook + collection worked without any issue. (I need to test it with correct path)

The path: "{{ lookup('env', 'PWD') }}" is giving different result for me (local using ansible-navigator, using different EE images etc) don't know why.

There are a few things we can do.

  1. Use full path in assert - wildfly_install_download_controller_download_dir/eap_archive_filename_local
  2. An additional option/feature to Download the zip from a specified URL (original eap_download_baseurl: https://github.com/eap/eap/releases/download) with username password options. Assume customer's using artifactory or some servers with auth. See below sample I used in my playbook for offline installation.

can remove localhost, if the download is happening directly on target server (avoid multi-hop)

    - name: Download {{ eap_archive_filename }}
      # no_log: true
      ansible.builtin.get_url:
        url: "{{ artifactory_server }}/{{ eap_archive_filename }}"
        dest: "{{ eap_install_download_controller_download_dir }}/{{ eap_archive_filename }}"
        username: "{{ lookup('ansible.builtin.env', 'ARTIFACTORY_ACCESS_USERNAME') | default(omit) }}"
        password: "{{ lookup('ansible.builtin.env', 'ARTIFACTORY_ACCESS_PASSWORD') | default(omit) }}"
        mode: '06400'
        force: true
        validate_certs: false
      delegate_to: localhost

I will try some of those later anyway :)

rpelisse commented 1 week ago

About 2) : The idea is that customers would implement this kind of things (like you did) in the pre_tasks: of the playbook, so that zipfile is in place when the collection. I don't think we should add this sort of commidity to the collection, because, in essence, we would just be wrapping ansible.builtin.get_url: and having to deal with ALL the options (like auth) coming with it.

However, we do need to fix that the collection assumes the zipfile will be on the controller. It's better and it makes sens (avoid download the zipfile on EACH target is smoother for performance), but it should be possible for user to use zipfile already available on targets (for instance, if the zipfile is mounted from a remote file system on the target).

iamgini commented 1 week ago

@rpelisse you are right; I agree on item 2.

Yeah, for offline files, maybe some logic to tell the collection that, "file is on controller" or "file is on target node already". And yes, a full/absolute path validation for "exist" check 😉

Thanks