On 11 August 2016 at 04:48, Tomáš Smetana <tsmetana(a)redhat.com> 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.
I apologize if my comments came across as personal to the work you
have done. In the 90's, the groups I worked with got burned by many
things similar to OpenLMI and the fact that by the time we had gotten
to the point of deployment.. which was usually 2-3 years after the
product or standard was deployed.. it was considered dead (partially
because the company supporting it could not wait 2-3 years for people
to actually deploy or that the developers of the standard could only
see all the mistakes htey had in product-1.0 and had completely
'fixed' them all in product-2.0 which wasn't anyway compatible with
1.0)
> 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.
I am guessing I am as unfamiliar with cockpit as you are with ansible
(eg it is more than a ssh on a loop). The ansible playbook to me is
the yaml to your cockpit json. How it is implemented on the client is
up to the python ball brought over and could just as easily talk to a
predefined dbus daemon to do its work as seperately running each
bundled .pyc to complete various complex commands.
Regards,
--
Tomáš Smetana
Platform Engineering, Red Hat
_______________________________________________
server mailing list
server(a)lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/server@lists.fedoraproject.org
--
Stephen J Smoogen.