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
Zone collecting only one server logs n times #1277
Zone collecting only one server logs n times #1277
Conversation
I'm confused how this solves the problem. Can you describe how it works now. I would expect that the thing putting the items on the queue would just put one item per server, and use the server_guid column of the queue to ensure it gets to that one server. This seems to queue an item and then modify the queue item? I think? |
The underlying LogFile code was written when logs could be requested from the smartproxy or a server so server_guid was not an option at the time. It works now in this way:
I changed MiqServer#synchronize_logs to insert the server instance into the args passed to LogFile.logs_from_server so it's not defaulted to MiqServer.my_server. Much of this complexity can eliminated when MiqProxy is completely gone. |
In the current code, LogFile.logs_from_server gets called X times in a zone (1 time for each server in the zone), but MiqServer.my_server is the only one that gets the request, since no servers are ever passed in, so it defaults to MiqServer.my_server. |
https://bugzilla.redhat.com/show_bug.cgi?id=1174855 If initiated from a zone, we want to create one miq_queue and miq_tasks row for each server in the Zone. Without this change, it will create N number of rows for the server receiving the web request, MiqServer.my_server, where N is the number of active servers in the zone. It will never request logs for the other servers in the zone. This is fairly easy to recreate: 1) Setup a Zone with 2 or more "active" appliances (miq_servers) 2) Request log collection for the Zone 3) Look at the log depot and find only the logs from the server receiving the web request.
c5041ff
to
e3fd51d
Compare
Checked commits jrafanie@4511cac .. jrafanie@e3fd51d with rubocop 0.27.1 |
@Fryguy Does this look ok? I think I explained the issue, let me know if I should give a better example. |
ping @Fryguy is this ok? |
Ugh what a mess that is. It seems to put an item on the queue to put another item on the queue to actually collect it. For now, this fixes the bug, so merging...we definitely need to clean up the rest. |
…r_logs_n_times Zone collecting only one server logs n times
Pass the server receiving the synchronize_logs message. …
https://bugzilla.redhat.com/show_bug.cgi?id=1174855
If initiated from a zone, we want to create one miq_queue and miq_tasks row for each server in the Zone.
Without this change, it will create N number of rows for the server receiving the web request, MiqServer.my_server, where N is the number of active servers in the zone. It will never request logs for the other servers in the zone.
This is fairly easy to recreate: