Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The JWS installation option should allow you to exclude natives #73

Closed
csutherl opened this issue Apr 8, 2022 · 4 comments · Fixed by #97
Closed

The JWS installation option should allow you to exclude natives #73

csutherl opened this issue Apr 8, 2022 · 4 comments · Fixed by #97
Assignees
Labels
bugfixes Fixes that resolve issues. SHOULD not be used for minor enhancements minor_changes New parameters added to modules, or non-breaking behavior changes to existing parameters; no bugfix

Comments

@csutherl
Copy link
Collaborator

csutherl commented Apr 8, 2022

SUMMARY

Not everyone wants to deploy the natives zip in their environment, so we should easily allow you to disable that requirement. I don't see an easy way to do so in the current setup. I've tried setting the jws_native_zipfile_url to an empty string but it still tries.

TASK [middleware_automation.jws.jws : Install JWS native dependencies with zipfile from RHN:] ********************************************************************************************************************************************************************************************************************************
skipping: [localhost]

TASK [middleware_automation.jws.jws : Copy archives to target nodes] *********************************************************************************************************************************************************************************************************************************************************
ok: [localhost] => (item=jws-5.6.0-application-server.zip)
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: If you are using a module and expect the file to exist on the remote, see the remote_src option
failed: [localhost] (item=jws-5.6.0-application-server-RHEL35-x86_64.zip) => {"ansible_loop_var": "item", "changed": false, "item": "jws-5.6.0-application-server-RHEL35-x86_64.zip", "msg": "Could not find or access '/root/jws-5.6.0-application-server-RHEL35-x86_64.zip' on the Ansible Controller.\nIf you are using a module and expect the file to exist on the remote, see the remote_src option"}

Note that I'm testing on Fedora and even though it's an unsupported configuration I expected the JWS java only zip to install and run correctly.

ISSUE TYPE
  • Feature Idea
@rpelisse rpelisse self-assigned this Apr 11, 2022
@rpelisse
Copy link
Contributor

@csutherl I was surprised, because I remember adding something about that. Checking the code, there is this check:

 set_fact:
    zipfiles: "{{ zipfiles + [{ 'src': native_zipfile, 'creates': tomcat.home + '/lib/libtcnative-1.so' }] }}"
  when:
    - native_zipfile is defined
    - native_zipfile | length > 0

So, if you define native_zipfile as an empty array, it should do the tricks:

native_zipfile: []

If this indeed works for you, we'll add the much needed documentation about it (and maybe default this value to []).

@rpelisse rpelisse added the documentation Improvements or additions to documentation label Apr 13, 2022
@csutherl
Copy link
Collaborator Author

csutherl commented Apr 13, 2022

It doesn't matter what I set native_zipfile to in the playbook, it doesn't change the value and results in failure :( Looking into that a bit further, you can't set native_zipfile at all because it doesn't get set in the defatults, it gets set in the rhn.yml so you can't override it. I think either we have to move that value to the defaults so you can override, or add another option to allow explicit exclusion. We could add a tomcat_native_enabled setting which then requires the native zip.

@rpelisse rpelisse added bugfixes Fixes that resolve issues. SHOULD not be used for minor enhancements minor_changes New parameters added to modules, or non-breaking behavior changes to existing parameters; no bugfix and removed documentation Improvements or additions to documentation labels Apr 14, 2022
@rpelisse
Copy link
Contributor

Darn! But thanks for checking this. I'll try to reproduce and fix asap.

@rpelisse
Copy link
Contributor

Fixed by PR97

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugfixes Fixes that resolve issues. SHOULD not be used for minor enhancements minor_changes New parameters added to modules, or non-breaking behavior changes to existing parameters; no bugfix
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants