[Engine] Runtime log controll script
Ever wanted to raise level of the engine logs and wanted to to that fast and runtime? This is a small wrapper around wildfly mgmt interface, called *log-control* to do the trick[1] Example, debug the db interaction layer: ./log-control org.ovirt.engine.core.dal debug It will first try blantly to add the log category and then will set the log level according to what you set. It is simple and stupid. More interesting logger categories: business logic (commands, queries) - org.ovirt.engine.core.bll hosts interaction - org.ovirt.engine.core.vdsbroker various utilities - org.ovirt.engine.core.utils aaa - org.ovirt.engine.exttool.aaa General suggestion - I think is is it time for *ovirt-engine-contrib* so mini-helpers like that can exists and when they are solid can go into mainstream repo, if needed in there. [1] https://gist.github.com/rgolangh/1cb9f9b3b7f7f0a1d16b5a976d90bd55 Thanks, Roy
On Tue, Apr 18, 2017 at 9:52 AM, Roy Golan <rgolan@redhat.com> wrote:
Ever wanted to raise level of the engine logs and wanted to to that fast and runtime?
This is a small wrapper around wildfly mgmt interface, called *log-control* to do the trick[1]
Example, debug the db interaction layer:
./log-control org.ovirt.engine.core.dal debug
It will first try blantly to add the log category and then will set the log level according to what you set. It is simple and stupid.
More interesting logger categories:
business logic (commands, queries) - org.ovirt.engine.core.bll hosts interaction - org.ovirt.engine.core.vdsbroker various utilities - org.ovirt.engine.core.utils aaa - org.ovirt.engine.exttool.aaa
General suggestion - I think is is it time for *ovirt-engine-contrib* so mini-helpers like that can exists and when they are solid can go into mainstream repo, if needed in there.
Nice job, Roy! +1 to the "ovirt-engine-contrib" idea.
[1] https://gist.github.com/rgolangh/1cb9f9b3b7f7f0a1d16b5a976d90bd55
Thanks, Roy
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Thanks! I would mention it in the main ovirt-engine README file, its basic usage and very useful. On Tue, Apr 18, 2017 at 2:41 PM Martin Betak <mbetak@redhat.com> wrote:
On Tue, Apr 18, 2017 at 9:52 AM, Roy Golan <rgolan@redhat.com> wrote:
Ever wanted to raise level of the engine logs and wanted to to that fast and runtime?
This is a small wrapper around wildfly mgmt interface, called *log-control* to do the trick[1]
Example, debug the db interaction layer:
./log-control org.ovirt.engine.core.dal debug
It will first try blantly to add the log category and then will set the log level according to what you set. It is simple and stupid.
More interesting logger categories:
business logic (commands, queries) - org.ovirt.engine.core.bll hosts interaction - org.ovirt.engine.core.vdsbroker various utilities - org.ovirt.engine.core.utils aaa - org.ovirt.engine.exttool.aaa
General suggestion - I think is is it time for *ovirt-engine-contrib* so mini-helpers like that can exists and when they are solid can go into mainstream repo, if needed in there.
Nice job, Roy! +1 to the "ovirt-engine-contrib" idea.
[1] https://gist.github.com/rgolangh/1cb9f9b3b7f7f0a1d16b5a976d90bd55
Thanks, Roy
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Yaniv Bronhaim.
On Tue, Apr 18, 2017 at 7:40 AM, Martin Betak <mbetak@redhat.com> wrote:
On Tue, Apr 18, 2017 at 9:52 AM, Roy Golan <rgolan@redhat.com> wrote:
Ever wanted to raise level of the engine logs and wanted to to that fast and runtime?
This is a small wrapper around wildfly mgmt interface, called *log-control* to do the trick[1]
Example, debug the db interaction layer:
./log-control org.ovirt.engine.core.dal debug
It will first try blantly to add the log category and then will set the log level according to what you set. It is simple and stupid.
More interesting logger categories:
business logic (commands, queries) - org.ovirt.engine.core.bll hosts interaction - org.ovirt.engine.core.vdsbroker various utilities - org.ovirt.engine.core.utils aaa - org.ovirt.engine.exttool.aaa
General suggestion - I think is is it time for *ovirt-engine-contrib* so mini-helpers like that can exists and when they are solid can go into mainstream repo, if needed in there.
Nice job, Roy! +1 to the "ovirt-engine-contrib" idea.
+1 [aside -- suggest adding engine build aliases, git aliases, shell functions for building / maintaining multiple engine compilations and databases, etc.]
[1] https://gist.github.com/rgolangh/1cb9f9b3b7f7f0a1d16b5a976d90bd55
Thanks, Roy
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Greg Sheremeta, MBA Sr. Software Engineer Red Hat, Inc. gshereme@redhat.com
On Tue, Apr 18, 2017 at 6:04 PM Greg Sheremeta <gshereme@redhat.com> wrote:
On Tue, Apr 18, 2017 at 7:40 AM, Martin Betak <mbetak@redhat.com> wrote:
On Tue, Apr 18, 2017 at 9:52 AM, Roy Golan <rgolan@redhat.com> wrote:
Ever wanted to raise level of the engine logs and wanted to to that fast and runtime?
This is a small wrapper around wildfly mgmt interface, called *log-control* to do the trick[1]
Example, debug the db interaction layer:
./log-control org.ovirt.engine.core.dal debug
It will first try blantly to add the log category and then will set the log level according to what you set. It is simple and stupid.
More interesting logger categories:
business logic (commands, queries) - org.ovirt.engine.core.bll hosts interaction - org.ovirt.engine.core.vdsbroker various utilities - org.ovirt.engine.core.utils aaa - org.ovirt.engine.exttool.aaa
General suggestion - I think is is it time for *ovirt-engine-contrib* so mini-helpers like that can exists and when they are solid can go into mainstream repo, if needed in there.
Nice job, Roy! +1 to the "ovirt-engine-contrib" idea.
+1 [aside -- suggest adding engine build aliases, git aliases, shell functions for building / maintaining multiple engine compilations and databases, etc.]
Exactly. Should it be a 'contrib' folder under the repo and then later we can create an rpm out of it if we want? Btw VDSM has a contrib folder as well with interesting stuff (just stumbled upon profile-stats which I was completely unaware of)
[1] https://gist.github.com/rgolangh/1cb9f9b3b7f7f0a1d16b5a976d90bd55
Thanks, Roy
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Greg Sheremeta, MBA Sr. Software Engineer Red Hat, Inc. gshereme@redhat.com
Hi! On Tue, Apr 18, 2017 at 6:40 PM, Roy Golan <rgolan@redhat.com> wrote:
General suggestion - I think is is it time for ovirt-engine-contrib so mini-helpers like that can exists and when they are solid can go into mainstream repo, if needed in there.
Nice job, Roy! +1 to the "ovirt-engine-contrib" idea.
+1 [aside -- suggest adding engine build aliases, git aliases, shell functions for building / maintaining multiple engine compilations and databases, etc.]
Exactly. Should it be a 'contrib' folder under the repo and then later we can create an rpm out of it if we want?
I collect my utilities here https://github.com/smelamud/ovirt-engine-dev-scripts. And there are some other collections AFAIK. Shmuel
On Wed, Apr 19, 2017 at 3:09 PM Shmuel Melamud <smelamud@redhat.com> wrote:
Hi!
General suggestion - I think is is it time for ovirt-engine-contrib so mini-helpers like
On Tue, Apr 18, 2017 at 6:40 PM, Roy Golan <rgolan@redhat.com> wrote: that
can exists and when they are solid can go into mainstream repo, if needed in there.
Nice job, Roy! +1 to the "ovirt-engine-contrib" idea.
+1 [aside -- suggest adding engine build aliases, git aliases, shell functions for building / maintaining multiple engine compilations and databases, etc.]
Exactly. Should it be a 'contrib' folder under the repo and then later we can create an rpm out of it if we want?
I collect my utilities here https://github.com/smelamud/ovirt-engine-dev-scripts. And there are some other collections AFAIK.
Shmuel
I'm proposing a contrib folder for a start. All, please review and comment: https://gerrit.ovirt.org/76652 contrib: Introduce contrib folder
On Wed, May 10, 2017 at 11:17 AM Roy Golan <rgolan@redhat.com> wrote:
On Wed, Apr 19, 2017 at 3:09 PM Shmuel Melamud <smelamud@redhat.com> wrote:
Hi!
General suggestion - I think is is it time for ovirt-engine-contrib so mini-helpers like
On Tue, Apr 18, 2017 at 6:40 PM, Roy Golan <rgolan@redhat.com> wrote: that
can exists and when they are solid can go into mainstream repo, if needed in there.
Nice job, Roy! +1 to the "ovirt-engine-contrib" idea.
+1 [aside -- suggest adding engine build aliases, git aliases, shell functions for building / maintaining multiple engine compilations and databases, etc.]
Exactly. Should it be a 'contrib' folder under the repo and then later we can create an rpm out of it if we want?
I collect my utilities here https://github.com/smelamud/ovirt-engine-dev-scripts. And there are some other collections AFAIK.
Shmuel
I'm proposing a contrib folder for a start. All, please review and comment:
https://gerrit.ovirt.org/76652 contrib: Introduce contrib folder
This patch is merged and you can find the 'contrib' folder under the root of the engine repo. Please read the contrib/README.adoc before contributing. Thanks all for the feedback and review.
participants (5)
-
Greg Sheremeta -
Martin Betak -
Roy Golan -
Shmuel Melamud -
Yaniv Bronheim