Mailinglist Archive: yast-devel (246 mails)

< Previous Next >
[yast-devel] Re: about the services module direction
  • From: Klaus Kaempf <kkaempf@xxxxxxx>
  • Date: Mon, 17 Aug 2009 16:20:22 +0200
  • Message-id: <20090817142022.GB3042@xxxxxxxxxxxxx>
* Duncan Mac-Vicar Prett <dmacvicar@xxxxxxx> [Aug 17. 2009 11:20]:

Right now in we have a web-service called services with it corresponding web-
clent part.

On Friday morning this was implemented using the YaPI and on Friday afternoon
it was reverted to the old codebase using some lsbservice.rb code.

Now there is a new custom_services plugin, AFAIK this is because the services
feature has to do with a custom vendor service and not with all system
services, and now nobody knows what will happen to the old services plugin.

I am really confused about the requirements and the design in general (and I
am worried about the direction it is taking), here are my points:

- Are we going to make application vendors have to use a different APIs for
services and for "custom services"? that goes against any UNIX design.

I agree. The services backend (rest service) should allow for both
(init.d and vendor supplied).


- If we want to provide customization or support for non-LSB services, why do
we need a separate API than lsb services instead of making the services API
work with both?

We dont need separate APIs but separate frontend dialogs.


- Are we going to make a plugin just to provide a service API based on a
vendor custom start/stop/status script? Can anyone please compare the effort
of customizing that with actually either forcing the vendor to provide a LSB
init script or to actually provide a lsb wrapper script that can be sourced
after defining 4 variables, and for which we get the quite nice feature of
managing all services through the same interface?

I think the design is escaping simplicity, I would propose this approach:

- Having _one_ and only one services plugin in the service side.

The implementation of this REST API would access the init.d scripts, and
additionally would do the following things:
- also read another directory with yml files where and recognize custom
services there. The vendor provides the variables in those yml, and the
services plugin knows how to handle those.

Yes, thats the most desirable approach.

However the LSB services are

- Having ONE, and only ONE web client module for the services

Displaying just one application to start/stop is different from
displaying a list of services. Something for our web designers. ;-)

But I agree, having this handled by a single modules is the cleanest
approach.


The implementation of the Web client would also recognize a yml file in
certain directory that would allow to hide certain services and allow
branding
of others. That way, the vendor can customize what to show.

If the problem of which services are visible is determined on the client side
(so if you access a remote host from the client you see all services) then
this configuration can then be in the service side, and the API will hint the
client which services need to be hidden, or whatever. This should be a hint,
respected by our client, but we should allow 3rd party consumers

For the initial version, lets focus on a single application. What
you're describing is the future vision the frontend and backend should
allow for.


Benefits of this approach:

- we get a services API that works for all services
- vendors have the choice to use LSB services or a easy way via a config file
- the cient can show the data in the way the vendor wants by respecting the
hints of the API, however a 3rd party API consumer can see all services as
equal.

Comments?

The current restriction to one application was done to simplify the
module design as well as the end user UI. Time runs out quickly to go
any further than this.

Klaus
---
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups