On 11.08.2016 10:48, Tomáš Smetana wrote:
On Wed, 10 Aug 2016 13:19:47 -0400
Stephen John Smoogen <smooge(a)gmail.com> wrote:
>> Isn't this a step backwards? I perceive Ansible as yet another variation
>> of ssh-in-a-for-loop... And I was hoping better system manageability
>> would be among the Fedora Server goals too. To me that implies new,
>> improved, more consistent management APIs.
>>
>
> The great things about management API's is that as soon you make them,
> no one will ever use them (even the people who wrote them as they
> usually want to write something to fix all the problems they had with
> the first set.)
I spent several years on OpenLMI project and currently happen to maintain
storaged. I think I understand the necessity of having the APIs developed
with their consumers on mind and ideally in parallel. So that's what I (at
least try to) do today. I think this effort should not be given up since
Linux has fallen asleep on its laurels and most of its management and
configuration solutions feel rather hackish.
> What is the "better system manageability" that you have in mind?
Cockpit and its architecture for example: The original idea was that there
exist local system D-Bus APIs for various management tasks (NetworkManager,
systemd, udisks/storaged, realmd, ...) and the local D-Bus messages are then
exposed on the network by a small lightweight daemon that does not need to
understand them at all: just do the D-Bus <-> JSON translations. This way the
remote client gets an ability to configure and monitor the system, even
respond to events like failure alerts. Cockpit parses the JSON by JavaScript
in the browser and presents the user pretty web management interface. The
logic is on the client not on the managed machine and might be tailored to
the intended user type.
One of the ideas I've been discussing with Lars Karlitski is
generalizing the code we have to remotely call DBus and other remotable
API over HTTP/REST and friends. This will make it far easier to compose
these APIs into larger solutions.
Lars will be talking at systemd.conf about this, and it seems like a
pragmatic approach.
Stef