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

launch_ansible_job doesn't write to the logfile #730

Open
BrGitHub11 opened this issue Apr 28, 2023 · 14 comments
Open

launch_ansible_job doesn't write to the logfile #730

BrGitHub11 opened this issue Apr 28, 2023 · 14 comments
Assignees

Comments

@BrGitHub11
Copy link

We're using oparin-1.1.20230105135506_44ec8c4 installed on a VM.

I'm trying to call an ansible job in tower in the post provisioning phase of my vm. The VM is created successfully and the job is started in tower. But there's no limit set. I tried to debug what's happening but it seems like there's no log output. When I look at the launch_ansible_job there are some log messages, like "Processing Job Template". But journalctl doesn't show this even after the job is started in Tower. I could see a line that says "Calling template.run_with_miq_job for template: #<ManageIQ::Providers::AnsibleTower::AutomationManager::ConfigurationScript".
I tried to overwrite the method by copying it to my own domain but seems like mine is never called.

I'm looking for someone who could help me understand:

  1. why there is no limit set in the job call
  2. why there's no log output
  3. why I can't overwrite this method

Already tried to reach out to the community but seems that no one could help me.

@Fryguy
Copy link
Member

Fryguy commented May 10, 2023

Can you give more details of your setup, perhaps a way we can replicate what you're seeing? Tower runs independently, but we do fetch the run over their API. Or were you expecting something else in the MIQ logs?

@BrGitHub11
Copy link
Author

Hi,

thanks for your help! I'm really grateful for any help!

I tried to reproduce all steps. Here's what I've done. Please reach out
to me if I should add more details:

Installed a new instance of MIQ using docker.

Added a VMware provider.
Refreshed the provider.

Added a new service dialog, which asks for the VMname.

Added a new catalog.

Added a new catalog item, type VMware. Used the dialog from above.

Went to the MIQ UI and ordered one VM using my catalog item.
VM was provisioned successfully.

Deleted the VM using VSphere.

Added a new automation provider and pointed it to our tower instance.
Refreshed the provider.

Added a new domain to the datastore.

Copied
ManageIQ-Infrastructure-VM-Provisioning-State Machine-Methods-PostProvision
to my domain.

Added a new method (towerjob) that call a test job in tower.
I've set Hosts to Localhost.

Modified the PostProvision Instance and put towerjob as value in
common_meth1.

Went to the MIQ UI and ordered one VM using my catalog item.
VM was provisioned successfully.
I could see that my playbook in Tower was called. But of course it failed
because no limit was set.

I could see info log level messages in the docker logs output. But
nothing related to my deployment. In the other instance I could see
more debug output. Don't know why this is not showing up here?

When looking into the
ManageIQ-AutomationManagement-Ansible Tower-Operations-StateMachines-Job-launch_ansible_job
method I would expect a log output like
Processing Job Template towerjob

In the end my question is how to modify the call to Tower so that I could
add the ip address to the extra-vars.

@Fryguy
Copy link
Member

Fryguy commented May 11, 2023

This is great details. Thanks! We'll have to look into this specific combination, which will take some time, but I'll have to see what's going on. cc @agrare

@BrGitHub11
Copy link
Author

BrGitHub11 commented May 12, 2023

Just one question: why can't I see my deployment in the docker logs? In the standalone version journalctl -f shows a lot more information.

Inside the system logs are not shown at all
Screenshot 2023-05-12 at 11 49 48

@BrGitHub11
Copy link
Author

I installed a new version of ManageIQ in docker. I still can't see automation log output in docker logs.
But now I could see some output on the Service Requests page.

@Fryguy
Copy link
Member

Fryguy commented May 26, 2023

@BrGitHub11 In containerized deployments the logs get written to stdout and are not written to disk (journalctl doesn't exist in containers). That page should be hidden in containerized deployments, so if that's showing that's a bug. You should enable a log aggregator such as an EFK stack if running in a containerized deployment.

@BrGitHub11
Copy link
Author

Hi Jason,
I'm looking at the docker logs output which should capture the STDOUT of the container. I could see other outputs of ManageIQ but no automation log output.

@BrGitHub11
Copy link
Author

Hi, do you need some additional information?

@BrGitHub11
Copy link
Author

Hi, is there an estimate when someone could start working on this?

@miq-bot miq-bot added the stale label Sep 25, 2023
@miq-bot
Copy link
Member

miq-bot commented Sep 25, 2023

This issue has been automatically marked as stale because it has not been updated for at least 3 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation.

@Fryguy
Copy link
Member

Fryguy commented Oct 11, 2023

Sorry @BrGitHub11 I just haven't had any cycles to dig into this one :(

@miq-bot miq-bot added the stale label Jan 15, 2024
@miq-bot
Copy link
Member

miq-bot commented Jan 15, 2024

This issue has been automatically marked as stale because it has not been updated for at least 3 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

2 similar comments
@miq-bot
Copy link
Member

miq-bot commented Apr 22, 2024

This issue has been automatically marked as stale because it has not been updated for at least 3 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

@miq-bot
Copy link
Member

miq-bot commented Jul 29, 2024

This issue has been automatically marked as stale because it has not been updated for at least 3 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants