<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 10, 2019 at 2:23 AM Jean-Philippe Evrard <<a href="mailto:jean-philippe@evrard.me">jean-philippe@evrard.me</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 2019-06-28 at 16:30 +0530, Chandan kumar wrote:<br>
> With os_tempest project, TripleO and Openstack Ansible projects<br>
> started collaborating together to reuse the tools<br>
> developed by each other to avoid duplicates and enable more<br>
> collaboration.<br>
<br>
... And that's amazing!<br></blockquote><div><br></div><div>Good stuff :) Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> In TripleO, we have ansible-role-collect-logs[1.] role for the same<br>
> and in OSA we have logs_collect.sh[2.] script for<br>
> the same. But once the logs gets collected at each other projects, It<br>
> is very hard to navigate and find out where<br>
> is the respective files.<br>
<br>
Agreed.<br>
<br>
> By Keeping the same structure at all places<br>
> It would be easier.<br>
<br>
Agreed again<br>
<br>
> So moving ahead what we are going to do:<br>
> * Refactor collect-logs role to pass defaults list of files at one<br>
> place<br>
<br>
It seems the role is doing a lot of things, but things can be<br>
conditionally triggered. Wondering if this role shouldn't be split into<br>
multiple roles... But that's a different story.<br>
<br>
> * Pass the list of different logs files based on deployment tools<br>
<br>
I think this doesn't need to be in the role. Make the role the simplest<br>
as possible, and flexible enough to get passed the list of things to<br>
log/not log, and the destination. OSA can pass a list of files it wants<br>
to gather. But isn't that what the role already does? Or did I<br>
misunderstood? <br></blockquote><div><br></div><div>The TripleO team passes various config files to the collect roles depending on what the needs and requirements are.  Some of these config files are public some are not.</div><div><br></div><div>upstream config</div><div><a href="https://github.com/openstack/tripleo-ci/blob/master/toci-quickstart/config/collect-logs.yml">https://github.com/openstack/tripleo-ci/blob/master/toci-quickstart/config/collect-logs.yml</a><br></div><div><br></div><div>default config</div><div><a href="https://github.com/openstack/ansible-role-collect-logs/blob/master/defaults/main.yml">https://github.com/openstack/ansible-role-collect-logs/blob/master/defaults/main.yml</a><br></div><div><br></div><div>These are of course just passed in as extra-config.  I think each project would want to define their own list of files and maintain it in their own project.  WDYT?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> * Put system/containers related commands at one place<br>
<br>
Can we simply rely on ansible inventory, and running a play with the<br>
role (targetting all) would gather logs for all systems (aio,<br>
multinodes, containers), each system<br>
could go into their own directory (log folder would be <something>/{{<br>
inventory_hostname }}/...) for example: <br>
<br>
aio1/<files gathered><br>
aio1-nova/<files gathered><br>
machine2/<files gathered><br>
<br>
It simple enough. But I am happy to see a different approach.<br></blockquote><div><br></div><div>Yes, this is exactly how it works today.  We don't break out which files should be collect for each host, but that is just our preference.  </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> * Replace the collect_logs.sh script with playbook in OSA and replace<br>
> it.<br>
<br>
:thumbsup:<br>
<br>
> Thanks for reading, We are looking for the comments on the above<br>
> suggestion.<br>
<br>
Thanks for tackling that up!<br>
I am looking forward a simple common file gathering :)<br>
<br>
If you need to do changes in the role (to implement new features),<br>
maybe it can help you if I give you a prio list :)<br>
<br>
What I am _generally_ looking for in the logs:<br>
- The ara reports<br>
- The tempest report<br>
- The /etc/openstack_deploy/<br>
- The /var/log/ for containers/hosts<br></blockquote><div><br></div><div>Agree, having a table of contents in the footer is nice for users as well.</div><div><a href="https://github.com/openstack/tripleo-ci/blob/master/docs/tripleo-quickstart-logs.html">https://github.com/openstack/tripleo-ci/blob/master/docs/tripleo-quickstart-logs.html</a><br></div><div>Which is added by infra via</div><div><a href="https://opendev.org/opendev/system-config/src/branch/master/modules/openstack_project/manifests/static.pp">https://opendev.org/opendev/system-config/src/branch/master/modules/openstack_project/manifests/static.pp</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
What I am _sometimes_ looking for in the logs (so less important/more<br>
contextual for me):<br>
- ram/disk usage per host<br>
- NICs details<br>
- cpu features (but I am not sure we really need this anymore)<br>
- host details (generally zuul does that for me, so no need to<br>
implement something there)<br>
<br></blockquote><div><br></div><div>AFAICT, if we were to organize the role more aggressively via the tasks we can easily enable or disable features as needed per project.    The majority of the work would around the reorganization to better suit various projects. </div><div><br></div><div>Any thoughts on additional work that I am not seeing?</div><div><br></div><div>Thanks for responding! I know our team is very excited about the continued collaboration with other upstream projects, so thanks!!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Regards,<br>
Jean-Philippe Evrard (evrardjp)<br>
<br>
<br>
</blockquote></div></div>