On Tuesday 18 of August 2009 08:01:58 Jiri Srain wrote:
Dne pondělí 17 Srpen 2009 16:58:36 Jiří Suchomel napsal(a):
On Monday 17 of August 2009 16:20:22 Klaus Kaempf wrote:
* Duncan Mac-Vicar Prett <dmacvicar@suse.de> [Aug 17. 2009 11:20]:
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.
Well, so could I return to the rest-API service plugin that was using YaPI, and was able to call /etc/init.d scripts as well as user customized ones?
That means, the original approach of services, written by schubi and mvidner would be lost with some of its features that my simpler approach did not have.
I summarize again my original approach:
YaPI layer: provides call to show and manipulate given services, be it from /etc/init.d or custom service defined in /etc/YaST2/webyast_services.yml
rest-service: basically encapsulating YaPI calls
web-client: showing the services provided by rest API (= those found in webyast_services.yml)
Now there could be 2 different UI parts, using the same rest service, one for /etc/init.d/ services (substituting current 'services' plugin), and the other for one (or any number) user defined service.
Just remember that at current stage, we only concentrate on the 'single service' web-client plug-in.
Sure, that's what I mean by that second UI. We should probably have 2 web clients, one "services" for /etc/init.d services and one ("custom_services"?) for vendor specific service. Both would use the same "services" REST API, with "index", "show" and "update" paths. There were discussions about YaPI usage and configuration file parsing: - if REST API should access all services, not only custom one, but also /etc/init.d, this is one more reason for YaPI as we can reuse existing Service.ycp module - proposed functions in YaPI are: SERVICES::Read (boolean custom) - to get either list of all /etc/init.d services OR vendor service(s) described in the file /etc/YaST2/custom_services.yml SERVICES::Get (string name) - get the status of given service (if name does not exist under /etc/init.d/, it is searched in custom_services.yml) SERVICES::Execute (string name, string action) - call the given command (start/stop/restart/...) on given service - each YaPI function has its own policy: org.opensuse.yast.modules.yapi.services.read org.opensuse.yast.modules.yapi.services.get org.opensuse.yast.modules.yapi.services.execute - this proposal includes parsing config file from YaPI, there were also ideas about parsing it from rest service. The pro for parser in YaPI is security, as already discussed: see that API have just service names as arguments. When the config file would be parsed by ruby, it would probably need to call YaPI with path to script that needs to be executed. Yes, maybe the security question is not that important and we could say that admin who has rights to execute service is equivalent to root. But the security provided here is basically for free, with this proposal, the granularity of rights is easily implementable. - well, it almost free. On the minus side, the YaPI part needs perl-YAML package as requirement. - which brings the question where the YaPI part should be packaged. My temporary implementation has it in yast2 package (which contains Services.ycp), but it basically could be anywhere. Maybe even in yast2-webservice-services package... Are there any objections against this proposal? Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org