Mailinglist Archive: yast-devel (246 mails)

< Previous Next >
Re: [yast-devel] Re: about the services module direction
  • From: Klaus Kaempf <kkaempf@xxxxxxx>
  • Date: Mon, 17 Aug 2009 16:09:57 +0200
  • Message-id: <20090817140957.GA3042@xxxxxxxxxxxxx>
* Jiří Suchomel <jsuchome@xxxxxxx> [Aug 17. 2009 13:04]:
On Monday 17 of August 2009 12:39:31 Duncan Mac-Vicar Prett wrote:
On Monday 17 August 2009 12:15:34 Jiří Suchomel wrote:
However, it was pointed by Klaus that current mandatory feature is to
start and stop just one vendor specific service (fate 306696). That's why
I commited new plugin that should do just such work: showing status of
one given service, starting and stopping it.

Jiri

Klaus pointed that we need to support one vendor specific service, how is
this implemented is different.


My original version was able to support any number of vendor specific
services, together with a vendor specific list of /etc/init.d scripts.

Klaus, could you clear it, so it we know what is really required?

Required is
- from a user pov: A simple UI to start/stop the vendor application
- from a vendor pov: A simple way to set this up, without having to
provide an lsb-compliant init script.

(Vendors are lazy ;-) as they don't want to make building an appliance
a huge investment. And we want to put the bar as low as possible.
Thats why Studio offers to include files or tarballs into an appliance
instead of requesting everything to be packaged as an RPM).


My understanding from your last (+fate) comments is that you actually do not
want to mix standard LSB-complaint services with that given customer one and
only thing needed is the way to start and stop one custom service (or, maybe
better, application).

The request is to have a separate, dedicated, dead-easy UI to start/stop the
vendor application. It should _not_ be mixed with a 'services' module
with a huge list of Linux-internal services (e.g. /etc/init.d, resp.
/etc/xinet.d).

The request is also not to require lsb-compliant scripts but allow
vendors to supply any kind of command line call for starting and
stopping the application.

I think the current confusion comes from the fact that these
requirements were understood as "completely different front- and
backend", which is not the case. The backend api should be generic to
allow for managing /etc/init.d services as well as vendor-supplied
services (eventually outside of /etc/init.d).

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 >