Inconsistent deployment of files about jws HOT 9 CLOSED

@csutherl Your first impression was correct. I may have mistakenly suggested that vault was part of the collection. What I was thinking about is that we want users to deploy(copy, get_url) the keystore themselves, then we make them have the vault on the controller and the collection copies(the copying part is in the collection) it to the target host. And then, the user deploys(copy, get_url) the web app.

I understand @rpelisse's position that users might want to use get_url rather than copy, but not to forget forget, we make them have the zipfiles on the controller in a specific folder(or they can also only be on target host in install dir, psst don't tell anyone).

Also, not sure how used this scenario is: what if I want to keystore in my tomcat/conf folder? Is it possible to do that/?

I don't mind keeping it as it is as we don't know how users will use the collection. It would be nice to know how users have their servers set up.

from jws.

Yep (and nice catch). We also need to allow to override "pwd" (I'm currently working on this for the patch part). I'll try to give it a stab in the next days, as I'm poking around this part of the collection anyway.

from jws.

I concur.

from jws.

One note: as far as I know, HTTPS is not required to use Tomcat Vault. So I've removed tomcat_listen_https_enabled: True, in my attempt to reproduce the issue.

Also two details are incorrect in the description of this issue: "On the other hand, tomcat-vault files(vault.keystore, vault.properties, VAULT.DAT) are copied as part of the collection and need to be located on the controller in PWD."

Assests to be deployed are NOT part of the collection

The assets for tomcat_vault are NOT part of the collection we provided (nor should they). User needs to generate those files and deploy them before calling the collection.

Note: It's same rationale as for the webapp deployment: Ansible users will want to deploy those files themselves, using Ansible primitives such as copy: or url: that they are used to.

So here is a correct playbook to test the feature with redhat.jws:1.1.1

---
- name: Install JWS with ZIPs
  hosts: all
  vars:
    jws_version: "5.6.0"
    tomcat_setup: True
    tomcat_install_dir: /opt
    tomcat_home: "{{ tomcat_install_dir }}/jws-{{ jws_version[0:3] }}/tomcat"
    tomcat_zipfile: "jws-{{ jws_version }}-application-server.zip"
    tomcat_native_zipfile: "jws-{{ jws_version }}-application-server-RHEL8-x86_64.zip" 
    tomcat_native: True
    #tomcat_listen_https_enabled: True
    tomcat_vault_enabled: True
    tomcat_java_version: 1.8.0
    tomcat_systemd_enabled: True
    tomcat_vault_properties: ./vault_files/vault.properties
    tomcat_vault_data: ./vault_files/VAULT.dat
    tomcat_vault_name: ./vault_files/vault.keystore
  collections:
    - redhat.jws
  tasks:
    - name: Import JWS role
      ansible.builtin.include_role:
        name: "jws"
  post_tasks:
    - name: "Deploy testapp"
      ansible.builtin.copy:
        src: ./vault_files/testapp
        dest: "{{ tomcat_home }}/webapps/"

Note: the testapp and the vault_files can be found in the jws-dot project. The molecule scenario there (jws_features) demonstrate this features.

I've fixed up the documentation accordingly in this commit.

Note this documentation already uses the new names for the required variables. I'll add a playbook using the new varnames to this issue later on, to document here how tomcat_vault is configured in the next version (a bit less variables).

Assets are not bound to current working directory on the controller (pwd)

The files to deploy for tomcat_vault don't need to be located in the current working directory (pwd) on the controller. In the example provided above the assets are, for instance, located in directory called "./vault_files" which is relative to pwd, but they could also be /etc/tomcat_vault or even fetch from a remote system using a url: task.

from jws.

Here is the playbook with the recents changes in naming that will be introduced by the next version (1.2.0):

---
- name: Install JWS with ZIPs
  hosts: all
  vars:
    jws_version: "5.6.0"
    jws_java_version: 1.8.0
    jws_home: "/opt/jws-{{ jws_version[0:3] }}/tomcat"
    jws_tomcat_vault_enabled: True
    jws_systemd_enabled: True

    jws_tomcat_vault_properties: ./vault_files/vault.properties
    jws_tomcat_vault_data: ./vault_files/VAULT.dat
    jws_tomcat_vault_keystore: ./vault_files/vault.keystore
  collections:
    - redhat.jws
  tasks:
    - name: Import JWS role
      ansible.builtin.include_role:
        name: "jws"
  post_tasks:
    - name: "Deploy testapp"
      ansible.builtin.copy:
        src: ./vault_files/testapp
        dest: "{{ jws_home }}/webapps/"

Note: for clarity purpose the tomcat_vault_name variable has been renamed jws_tomcat_vault_keystore variable.

from jws.

@csutherl unless you see something else, I think we can close this issue.

from jws.

The only difference I see here now is that we expect for users to create a pre_task to copy the keystore into place for the HTTPS Connector, but we do it for them with the tomcat-vault required files. My initial reading of the issue was that this was the problem, but after reading again I think @defeatedbylife's complaint was about where the files where located? Can you clarify @defeatedbylife? Would you prefer that we don't copy the tomcat-vault files into place from their variable names and make users create a pre-task so the experience is consistent? Or that we do copy the HTTPS keystore into place by making it a configurable variable (i.e. jws_listen_https_keystore)?

from jws.

The only difference I see here now is that we expect for users to create a pre_task to copy the keystore into place for the HTTPS Connector, but we do it for them with the tomcat-vault required files.

Yes, but I think it's OK. I think Ansible users will expect to deploy this kind of file by themselves. Especially as we can not really be sure they would want to use copy: to do it. They might want to use url: to retrieve it from somewhere else and the cert could be even mounted by some other part of their infrastructure. It's a bit the same discuss as the webapp deployment, we don't want to wrap Ansible primitive.

Tomcat vault files have very specific to JWS and lives under jws_home, we control where they should be. As shown by the example, the keystore may live in /etc/ or somewhere else.

I think @defeatedbylife's complaint was about where the files where located? Can you clarify @defeatedbylife?

+1

I was a also a bit confused. I focused on make sure Vault works and pointing out the parts that were incorrect, but I'm not sure I understood the intent behind the report.

Would you prefer that we don't copy the tomcat-vault files into place from their variable names and make users create a pre-task so the experience is consistent?

I would not do that, I think the way it is now is how it should be.

Or that we do copy the HTTPS keystore into place by making it a configurable variable (i.e. jws_listen_https_keystore)?

As said, we may end up wrapping a single copy: and we will need to provide a "skip" conditions if user needs to deploy this keystore differently. IMHO, it's fine as it is now.

from jws.

I don't mind keeping it as it is as we don't know how users will use the collection.

I could not agree more. Depending on the feedback we get we might change it completly and leave it as it is (and 50 possible variation between those two options).

It seems we are in agreement, so I'm closing this issue (otherwise, simply reopen it).

from jws.