[yast-devel] Making systemd and Yast collaborate well
Hi: I just subscribed to this list in order to offer assistance in order to get Yast and systemd to interact in a nicer fashion. I will assist you with patches and a lot of suggestions after the decision of converting the YCP codebase into Ruby is taken and modules are translated. Here is the first and most important suggestion I have and I strongly suggest you to consider it while creating/migrating modules from YCP to Ruby. - You MUST NOT talk (I can't find a way to emphasize this) to any systemd component using systemctl, localectl, timedatectl or whatever other command line utility, those are *human interfaces* and not *programming interfaces*(exception "systemctl show") if you continue in the current direction, it will bite you and rip and piece of your skin pretty soon. Yast MUST communicate with systemd components using the respective D-BUS API.[1][2][3][4] [1] http://www.freedesktop.org/wiki/Software/systemd/dbus [2] http://www.freedesktop.org/wiki/Software/systemd/timedated [3] http://www.freedesktop.org/wiki/Software/systemd/localed [4] http://www.freedesktop.org/wiki/Software/systemd/hostnamed A little bit of googling shows that mvidner has a repo in github containing an implementation of ruby-dbus that will come handy for this purpose. That's all for now :-) Cheers! -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Wed, 24 Apr 2013 00:37:31 -0300
Cristian Rodríguez
Hi:
Hi Christian,
I just subscribed to this list in order to offer assistance in order to get Yast and systemd to interact in a nicer fashion.
Thanks for your offer.
I will assist you with patches and a lot of suggestions after the decision of converting the YCP codebase into Ruby is taken and modules are translated.
Well, *unofficial* plan is to finish it for next opensuse release. Now we work on improve automatic convertor to produce code in same quality as it is before and to improve readability of code.
Here is the first and most important suggestion I have and I strongly suggest you to consider it while creating/migrating modules from YCP to Ruby.
- You MUST NOT talk (I can't find a way to emphasize this) to any systemd component using systemctl, localectl, timedatectl or whatever other command line utility, those are *human interfaces* and not *programming interfaces*(exception "systemctl show") if you continue in the current direction, it will bite you and rip and piece of your skin pretty soon. Yast MUST communicate with systemd components using the respective D-BUS API.[1][2][3][4]
Well, we know dbus, there is also dbus-client yast module that allows easy communication with dbus and we use quite a lot ruby-dbus in webyast, so I think it is quite mature now. But I see one quite big disadvantage of D-Bus. It is different API that is not so easy for users to try it. If something goes wrong, we see in log that systemctl command fail and user can try to run it manually. With D-Bus it is not so easy even if there is some gui helpers for it like D-Feet or qdbusviewer. Using CLI is also for me more unix way, where is CLI and gui is build on top of it, so result is that CLI is central point which is well tested and GUI benefit from it. Josef
[1] http://www.freedesktop.org/wiki/Software/systemd/dbus [2] http://www.freedesktop.org/wiki/Software/systemd/timedated [3] http://www.freedesktop.org/wiki/Software/systemd/localed [4] http://www.freedesktop.org/wiki/Software/systemd/hostnamed
A little bit of googling shows that mvidner has a repo in github containing an implementation of ruby-dbus that will come handy for this purpose.
That's all for now :-)
Cheers!
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 04/24/2013 02:30 AM, Josef Reidinger wrote:
But I see one quite big disadvantage of D-Bus. It is different API that is not so easy for users to try it. If something goes wrong, we see in log that systemctl command fail and user can try to run it manually.
systemd logs its actions and the result of dbus methods calls etc. it is just a matter of increasing the verbosity level. If this is a problem, It can be solved by logging the calls from yast in an structured fashion to the journal. (there is also a rubygem to access and use the journal, but no idea of its state) Using CLI is also for me more unix way,
where is CLI and gui is build on top of it, so result is that CLI is central point which is well tested and GUI benefit from it.
well, fact is systemd is designed this way: - humans interact with it using command line tools,the output changes all the time,return values of these tools are not part of any stability promise. (only the execution "verbs" of systemctl are) - programs interact via d-bus or the C API (the latter is probably not of much use for yast except the logging part) It is "everything is an api" not "everything is command" ;) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 04/24/2013 08:01 AM, Cristian Rodríguez wrote:
On 04/24/2013 02:30 AM, Josef Reidinger wrote:
But I see one quite big disadvantage of D-Bus. It is different API that is not so easy for users to try it. If something goes wrong, we see in log that systemctl command fail and user can try to run it manually.
systemd logs its actions and the result of dbus methods calls etc. it is just a matter of increasing the verbosity level.
If this is a problem, It can be solved by logging the calls from yast in an structured fashion to the journal. (there is also a rubygem to access and use the journal, but no idea of its state)
Using CLI is also for me more unix way,
where is CLI and gui is build on top of it, so result is that CLI is central point which is well tested and GUI benefit from it.
well, fact is systemd is designed this way:
- humans interact with it using command line tools,the output changes all the time,return values of these tools are not part of any stability promise. (only the execution "verbs" of systemctl are)
- programs interact via d-bus or the C API (the latter is probably not of much use for yast except the logging part)
It is "everything is an api" not "everything is command"
Cristian, I appreciate that you help to get better systemd support into YaST. Reading about chancing return values I guess we need a lot of help for a long periode of time until systemd is mature and in a stable state. Thanks, Thomas -- Thomas Goettlicher SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 04/24/2013 09:32 AM, Thomas Goettlicher wrote:
Reading about chancing return values I guess we need a lot of help for a long periode of time until systemd is mature and in a stable state.
The "changing return value" part was just an example of the possible perils of calling tools specifically and intentionally designed as a human only interfaces instead of using the programming API. it was not an example of something that has or will happend. (tools will always return EXIT_SUCCESS when everything is cool, and a positive number on fail) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 04/24/2013 06:15 PM, Cristian Rodríguez wrote:
On 04/24/2013 09:32 AM, Thomas Goettlicher wrote:
Reading about chancing return values I guess we need a lot of help for a long periode of time until systemd is mature and in a stable state.
The "changing return value" part was just an example of the possible perils of calling tools specifically and intentionally designed as a human only interfaces instead of using the programming API. it was not an example of something that has or will happend. (tools will always return EXIT_SUCCESS when everything is cool, and a positive number on fail)
Which is the current Service module implementation: Calls a systemctl command and checks return value (success || not). If it fails, all the output is returned (errors if any are present, additional commands to be called by user). Anyway, using D-BUS might be better at least for querying for available services, targets, and their status. I'd see the target distribution as openSUSE 13.1. Thanks for your offer! Bye Lukas -- Lukas Ocilka, Cloud & Systems Management Department SUSE LINUX s.r.o., Praha -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (4)
-
Cristian Rodríguez -
Josef Reidinger -
Lukas Ocilka -
Thomas Goettlicher