August 2009 - YaST Development - openSUSE Mailing Lists

[yast-devel] WebYaST 24-Aug-2009
by Duncan Mac-Vicar Prett 24 Aug '09

24 Aug '09

WebYaST 24-Aug-2009 =================== Status: ----------- present: kkaempf, visnov, bgeuken, mzugec, jiri, mvidner, lslezak, mkudlvasr, jdsn bgeuken: package kit module, listing installed packages. Integrate with vendor settings later dmacvicar: vendor settings controller lslezak: testing services module, testsuite, implement current status of services mzugec: YaPI for network, small problems. Submit some code today, until friday expect complete YaPI and integration with mvidner work mvidner: commited to brach for client and server. merge when test exists and pass. will extend the proxy library for unified policies for multiple sources upstream dbus work mkudlvasr. user interface test, control panel jdsn: looking testsuite and running mocha. Starting with open bugs -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] Re: [yast-commit] <rest-service> master : added exception check
by Klaus Kaempf 24 Aug '09

24 Aug '09

* Ladislav Slezak <lslezak(a)novell.com> [Aug 24. 2009 14:10]: > ref: refs/heads/master > commit fe92f302168a171f01f05f8f12fdad6980d9012e > Author: Ladislav Slezak <lslezak(a)novell.com> > Date: Mon Aug 24 11:00:43 2009 +0200 > > added exception check > --- > .../app/controllers/services_controller.rb | 6 +++++- > 1 files changed, 5 insertions(+), 1 deletions(-) > > diff --git a/plugins/services/app/controllers/services_controller.rb b/plugins/services/app/controllers/services_controller.rb > index c3d5b51..b9803da 100644 > --- a/plugins/services/app/controllers/services_controller.rb > +++ b/plugins/services/app/controllers/services_controller.rb > @@ -8,7 +8,11 @@ class ServicesController < ApplicationController > render ErrorResult.error(403, 1, "no permission") and return > end > > - @services = Service.find_all params > + begin > + @services = Service.find_all params > + rescue Exception => e > + render ErrorResult.error(404, 107, "cannot read services") and return > + end This hides valuable information which might be contained in the original exception. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] Re: [yast-commit] <rest-service> master : service.rb - catch exceptions
by Klaus Kaempf 24 Aug '09

24 Aug '09

* Ladislav Slezak <lslezak(a)novell.com> [Aug 24. 2009 14:10]: > ref: refs/heads/master > commit 1a456b37d160ae603431cd56e1617330047e6a90 > Author: Ladislav Slezak <lslezak(a)novell.com> > Date: Mon Aug 24 10:20:10 2009 +0200 > > service.rb - catch exceptions > --- > plugins/services/app/models/service.rb | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/plugins/services/app/models/service.rb b/plugins/services/app/models/service.rb > index 2904bc0..1632c6a 100644 > --- a/plugins/services/app/models/service.rb > +++ b/plugins/services/app/models/service.rb > @@ -38,7 +38,8 @@ class Service > "runlevel" => [ "i", rl == "S" ? -1 : rl.to_i ], > "read_status" => [ "b", read_status] > } > - yapi_ret = YastService.Call("YaPI::SERVICES::Read", params) > + > + yapi_ret = YastService.Call("YaPI::SERVICES::Read", params) rescue nil > > if yapi_ret.nil? > raise "Can't get services list" This effectively throws away all information which came from the original exception. Don't do that. YastService.Call should never return nil but just raise an exeception (with information about the cause of the failure). You can then either catch it in your controller or let it 'bubble' up to the generic error display. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] Re: [yast-commit] <rest-service> master : patches module: added policikit class, which is parent of package and patch model
by Josef Reidinger 24 Aug '09

24 Aug '09

On 08/24/2009 01:31 PM, Bjoern Geuken wrote: > ref: refs/heads/master > commit 10e502901ee5e98552aa1c701cf7d2d965587fa2 > Author: Bjoern Geuken <bgeuken(a)suse.de> > Date: Mon Aug 24 13:31:19 2009 +0200 > > patches module: added policikit class, which is parent of package and patch model > --- > .../patches/app/controllers/packages_controller.rb | 27 ----- > .../patches/app/controllers/patches_controller.rb | 19 +++- > plugins/patches/app/models/package.rb | 90 ++++------------ > plugins/patches/app/models/patch.rb | 70 ++----------- > plugins/patches/app/models/policykit.rb | 112 ++++++++++++++++++++ > 5 files changed, 159 insertions(+), 159 deletions(-) > > diff --git a/plugins/patches/app/models/policykit.rb b/plugins/patches/app/models/policykit.rb > new file mode 100644 > index 0000000..f5bad05 > --- /dev/null > +++ b/plugins/patches/app/models/policykit.rb > @@ -0,0 +1,112 @@ > +require "dbus" > +require 'socket' > +require 'thread' > + > +# Used to stop DBus::Main loop > +class PKErrorException < Exception; end > +# Used to stop DBus::Main loop > +class PKFinishedException < Exception; end > + > +# Model for patches available via package kit > +class Policykit > + Hi, I don't see any reason for PolicyKit name, maybe you want name it PackageKit? This patch is nice example of DRY refactoring, good job ;) -- Josef Reidinger YaST team maintainer of perl-Bootloader, YaST2-Repair, webyast modules language and time -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 1

[yast-devel] Re: [yast-commit] <web-client> basesystem : Add doc for language plugin
by Klaus Kaempf 24 Aug '09

24 Aug '09

> diff --git a/plugins/language/doc/README_FOR_APP b/plugins/language/doc/README_FOR_APP > new file mode 100644 > index 0000000..cf77cf6 > --- /dev/null > +++ b/plugins/language/doc/README_FOR_APP > @@ -0,0 +1,7 @@ > +Language > +========= > + > +Plugin for setting languages. > + > + > +Copyright (c) 2009 Novell, released under the MIT license I wonder where we will put the REST api and the model documentation for a service plugin. Suggestions anyone ? Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] about the services module direction
by Duncan Mac-Vicar Prett 24 Aug '09

24 Aug '09

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. - 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? - 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. However the LSB services are - Having ONE, and only ONE web client module for the services 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 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? -- Duncan Mac-Vicar P. - Engineering Manager, YaST SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

5 20

[yast-devel] modelling a non trivial REST API
by Martin Vidner 24 Aug '09

24 Aug '09

Hi, I have noticed that ALL existing plugins have a single REST path, a single model, a single controller. How to code the network model? It will have /interfaces/ /routes/ /dns /hostname In particular: - what about routes - how to connect to it in the client, using YaST::ServiceResource Should I create multiple configs in config/resources? I would like them all to share the same YaPI module. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

3 3

[yast-devel] WebYaST 21-Aug-2009
by Bjoern Geuken 21 Aug '09

21 Aug '09

WebYaST 21-Aug-2009 =================== Present: schubi, jdsn, bgeuken, jsrain, lslezak, dmacvicar mvidner, mzugec, jsuchome, jreidinger Status: ----------- bgeuken: - worked on package and patches module - commited patch for patches module (uncaught exception) next: - go one with package module and finish work on status module (xml) dmacvicar: - worked on vendor settings, commited first version - talked with Joseph about config file next: - vendor config controller pending - talk with bgeuken Schubi: - updated all selenium test cases, they are running - rest-interface can be emulated, wrote mail next: - update doku mvidner: - coding skeleton rest-service network next: - contine work, and maybe start skeleton for web-client lslezak: - fixed test suite - initializing web-client - got same problem in rest-service, but more complicated - system service code cleanup next: - write test cases mzugec: - worked on network yapi next: - continue jsuchome: - worked with lslezak on services plugin - used dmacvicars library - placed some YastPackages next: - continue with sevices plugin and ui jsrain: - no update -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] Emulating YaST-REST-Service
by Stefan Schubert 21 Aug '09

21 Aug '09

Hi, in order to test the UI without any environment like a corresponding REST-service (from which data will be received) we can use the REST emulation sinatra: http://www.sinatrarb.com/ A framework has already been defined in web-client/webclient/test/dummy-host Use the following command in order to start the REST-service: ruby host.rb The access of the REST-service will be then http://localhost:4567 and can be used for login, logout, permission, language, time, patch, status, security, user ( to be continued ) UI-module. This feature provides a simple way for testing the UI especially while changing stylesheets, CSS, .... Greetings Stefan -- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi(a)suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] WebYaST - broken 'test' mode setup in webservice plugin testsuites
by Ladislav Slezak 21 Aug '09

21 Aug '09

I wanted to fix test-unit reloading when script/server finishes and I have found that mode 'test' is set quite late in plugin testsuites, after environment.rb is loaded. For this reason test ENV['RAILS_ENV'] == 'test' doesn't work there. The problem is in test_helper.rb files in plugins: # first config rails require File.expand_path(rails_parent + "/config/environment") # then enable testing, this will get the routing right ENV["RAILS_ENV"] = "test" When environment.rb is loaded the setup is: ENV["RAILS_ENV"] = nil RAILS_ENV = 'development' Jozef, this could be the reason why the host testsuite sometimes writes to the development DB during testing... I have fixed this problem in web-client and it's plugins, the webservice packages require more effort, because routing is set there. Reported as bug #533178 -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 1