On Fri, Dec 21, 2018 at 10:10 PM Nir Soffer <nsoffer(a)redhat.com> wrote:
On Fri, Dec 21, 2018, 07:42 Germano Veit Michel <germano(a)redhat.com wrote:
> With these 2 changes the ovirt-log-collector will collect storage domain
> metadata from all storage domains of the environment in a more efficient
Can you exolain how using sqlite is more efficient than the text/json
We discussed this in https://gerrit.ovirt.org/#/c/88109/
, you suggested
sqlite so we don't have to write a tool to easily search/visualize the
I think sqlite is the easiest way, json requires additional tools to
parse/read/search and text is simply unsuitable for this task. The current
text output misses several fields and the format may change, parsing text
is not efficient.
Also ignoring the storage domain argument and collecting info for all
domains looks like the wrong approach, as we are more likely to time out an
fail the entire operation.
Yes it can happen. In fact it already happens today. In those cases we just
ask to collect manually, no big deal if it fails and it shouldn't prevent
us from coding more automated collection of this. What we need is this:
Can you describe the use cases that you are trying to solve?
Quite a few: today support needs to ask for storage domain metadata
manually (i.e. dd if=/dev/sd/metadata) to fix LSM/Snapshot cases. The idea
is to place a sqlite database in the log-collector folder, next to the
engine database (not on some random host sosreport) and have a tool to
match both databases, pointing to possible issues. Support can easily use
sqlite3 from command line on the storage domain sqlite3 database to check
what is required to fix the LSM/Snapshot issue. And also serves for us to
reduce the back and forth requesting data on support cases. Also this can
be consumed by the analyzer that runs automatically these days once a
customer uploads logs.
> I'll be away for the next 2 weeks, but reviews are welcome. If there is
> any problem with one of these patches, please don't merge any of them as
> they require each other.
> And if you have extra time, reviews are welcome on this series too =D
> Devel mailing list -- devel(a)ovirt.org
> To unsubscribe send an email to devel-leave(a)ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> List Archives: