Juan Hernandez has posted comments on this change.
Change subject: core: introduce osinfo service instead of Config values
......................................................................
Patch Set 1: (1 inline comment)
....................................................
File
backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/utils/osinfo/LibosinfoClient.java
Line 86:
Line 87: String options = "-Djava.rmi.server.hostname=localhost";
Line 88: String mainClassName =
"org.ovirt.engine.core.osinfo.server.LibosinfoServer";
Line 89:
Line 90: builder.command(java, "-cp", classpath, options,
mainClassName);
It is not an independent service, as its existence doesn't make sense without
the engine.
The very point of launching the external JVM is being able to tolerate crashes
and restart it when it crashes. Systemd can certainly do this, but we don't
want to depend on systemd, as not all distributions use systemd, and some users
may even want to run the engine without any service manager. We can of course
create a new service script, and then restart the service from that service
script, but then that service script will be as bad (or as good) a native
scheduler as the java code, that only depends on the effort that we put when
developing it.
In addition using an additional service would need the following, which has its
own cost as well:
* An additional service script.
* An additional systemd/SystemV configuration.
* An additional RMI registry (as we can't get the stub from the output of the
external process).
* An additional service script for the RMI registry.
* An additional systemd/SystemV configuration for the RMI registry.
* Additional packaging.
The life cycle of the external process is already managed. It is started by the
engine when needed and killed by the engine when no longer needed. If there are
specific concerns about zombies and leaked file descriptors those should be
solved in the Java code.
Eventually all this can/should be removed, once people is convinced that
calling native methods is not evil. As the rest of the code uses the
OSInfoService interface for everything there is no problem with that, all the
details are hidden, so if we need to use HTTP or whatever the rest of the
application won't be affected. That is decoupling.
Line 91: return builder;
Line 92: }
Line 93:
Line 94: private ProcessBuilder buildShellProcessCmd() {
--
To view, visit http://gerrit.ovirt.org/12936
To unsubscribe, visit http://gerrit.ovirt.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: Ibd75679a1a1af5d5a0925e181b5dfd6e87574a75
Gerrit-PatchSet: 1
Gerrit-Project: ovirt-engine
Gerrit-Branch: master
Gerrit-Owner: Roy Golan <rgo...@redhat.com>
Gerrit-Reviewer: Allon Mureinik <amure...@redhat.com>
Gerrit-Reviewer: Alon Bar-Lev <alo...@redhat.com>
Gerrit-Reviewer: Juan Hernandez <juan.hernan...@redhat.com>
Gerrit-Reviewer: Michal Skrivanek <michal.skriva...@redhat.com>
Gerrit-Reviewer: Omer Frenkel <ofren...@redhat.com>
Gerrit-Reviewer: Roy Golan <rgo...@redhat.com>
_______________________________________________
Engine-patches mailing list
Engine-patches@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-patches
