Open Stack

On Wed, Jul 10, 2019 at 2:23 AM Jean-Philippe Evrard <
jean-philippe at evrard.me> wrote:

> On Fri, 2019-06-28 at 16:30 +0530, Chandan kumar wrote:
> > With os_tempest project, TripleO and Openstack Ansible projects
> > started collaborating together to reuse the tools
> > developed by each other to avoid duplicates and enable more
> > collaboration.
>
> ... And that's amazing!
>

Good stuff :) Agreed.


>
> > In TripleO, we have ansible-role-collect-logs[1.] role for the same
> > and in OSA we have logs_collect.sh[2.] script for
> > the same. But once the logs gets collected at each other projects, It
> > is very hard to navigate and find out where
> > is the respective files.
>
> Agreed.
>
> > By Keeping the same structure at all places
> > It would be easier.
>
> Agreed again
>
> > So moving ahead what we are going to do:
> > * Refactor collect-logs role to pass defaults list of files at one
> > place
>
> It seems the role is doing a lot of things, but things can be
> conditionally triggered. Wondering if this role shouldn't be split into
> multiple roles... But that's a different story.
>
> > * Pass the list of different logs files based on deployment tools
>
> I think this doesn't need to be in the role. Make the role the simplest
> as possible, and flexible enough to get passed the list of things to
> log/not log, and the destination. OSA can pass a list of files it wants
> to gather. But isn't that what the role already does? Or did I
> misunderstood?
>

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.

upstream config
https://github.com/openstack/tripleo-ci/blob/master/toci-quickstart/config/collect-logs.yml

default config
https://github.com/openstack/ansible-role-collect-logs/blob/master/defaults/main.yml

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?



>
> > * Put system/containers related commands at one place
>
> Can we simply rely on ansible inventory, and running a play with the
> role (targetting all) would gather logs for all systems (aio,
> multinodes, containers), each system
> could go into their own directory (log folder would be <something>/{{
> inventory_hostname }}/...) for example:
>
> aio1/<files gathered>
> aio1-nova/<files gathered>
> machine2/<files gathered>
>
> It simple enough. But I am happy to see a different approach.
>

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.


>
> > * Replace the collect_logs.sh script with playbook in OSA and replace
> > it.
>
> :thumbsup:
>
> > Thanks for reading, We are looking for the comments on the above
> > suggestion.
>
> Thanks for tackling that up!
> I am looking forward a simple common file gathering :)
>
> If you need to do changes in the role (to implement new features),
> maybe it can help you if I give you a prio list :)
>
> What I am _generally_ looking for in the logs:
> - The ara reports
> - The tempest report
> - The /etc/openstack_deploy/
> - The /var/log/ for containers/hosts
>

Agree, having a table of contents in the footer is nice for users as well.
https://github.com/openstack/tripleo-ci/blob/master/docs/tripleo-quickstart-logs.html
Which is added by infra via
https://opendev.org/opendev/system-config/src/branch/master/modules/openstack_project/manifests/static.pp


>
> What I am _sometimes_ looking for in the logs (so less important/more
> contextual for me):
> - ram/disk usage per host
> - NICs details
> - cpu features (but I am not sure we really need this anymore)
> - host details (generally zuul does that for me, so no need to
> implement something there)
>
>
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.

Any thoughts on additional work that I am not seeing?

Thanks for responding! I know our team is very excited about the continued
collaboration with other upstream projects, so thanks!!


> Regards,
> Jean-Philippe Evrard (evrardjp)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190710/afec36e1/attachment-0001.html>