August 2009 - YaST Development - openSUSE Mailing Lists

[yast-devel] Webyast base system model proposal
by Josef Reidinger 25 Aug '09

25 Aug '09

Hi, base system model is something like first boot which ensure basic settings after first login to rest-service of target machine. First I describe how it should look from user perspective. User login to target machine and then he see first module from first boot sequency, after saving settings go to next step until last one is complete and then show standard control panel. Implementation proposal: Create new rest-service for first boot. This module store in database last successfully saved module. It also contains list of modules and its order. So frontend ask only what module is next one. If next one is control panel, then first boot is complete passed. Frontend is implemented mostly in control panel. It ask backend for next module in first boot order. If next module is not control panel, then control panel redirect to that module. The most complicated think is how recognize, that module settings is successfully set. My proposal is set to session in control panel, that modul must set status. If user successfully set settings that corresponding module set status to OK and control panel send this information to rest module and look what is next module to pass. pros: * Minimal changes to current code * Easily manageable order and modules in first boot neg: * Each modules must handle request to status * somehow must be solved returning from module to control panel (redirect after success save?), as browser back doesn't work as expected thanks for opinions and suggestions, Josef -- 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

3 20

[yast-devel] Service plugins and client module 'acceptance criteria'
by Klaus Kaempf 25 Aug '09

25 Aug '09

Hi, looking at recent troubles with getting a clean build in Hudson, I have now started to define 'acceptance criteria' for checkins into the git 'master' branch. For the service plugins, look at http://en.opensuse.org/YaST/Web/Development/Service/ExitCriteria For the client modules, look at http://en.opensuse.org/YaST/Web/Development/Client/ExitCriteria I consider the current criteria as 'preliminary' and 'open for discussion', please comment. 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 : fixing packaging. Copy paste errors mostly
by Josef Reidinger 25 Aug '09

25 Aug '09

On 08/25/2009 11:15 AM, Duncan Mac-Vicar P wrote: > ref: refs/heads/master > commit 92e21ce73c1f73e8e0b2cadc7fc76fd08aebe50a > Author: Duncan Mac-Vicar P <dmacvicar(a)suse.de> > Date: Tue Aug 25 11:15:38 2009 +0200 > > fixing packaging. Copy paste errors mostly > --- > .../package/yast2-webservice-basesystem.spec | 8 ++++---- > .../patches/package/yast2-webservice-patches.spec | 2 +- > .../package/yast2-webservice-services.spec | 10 ++++++---- > .../system/package/yast2-webservice-system.spec | 4 ++-- > 4 files changed, 13 insertions(+), 11 deletions(-) > > diff --git a/plugins/basesystem/package/yast2-webservice-basesystem.spec b/plugins/basesystem/package/yast2-webservice-basesystem.spec > index 3058677..14cfb46 100644 > --- a/plugins/basesystem/package/yast2-webservice-basesystem.spec > +++ b/plugins/basesystem/package/yast2-webservice-basesystem.spec > @@ -27,7 +27,7 @@ Requires: yast2-country >= 2.18.9 > > # > %define pkg_user yastws > -%define plugin_name language > +%define plugin_name basesystem > # > > > @@ -63,7 +63,7 @@ rm -rf $RPM_BUILD_ROOT > %dir /srv/www/%{pkg_user}/vendor/plugins > %dir /srv/www/%{pkg_user}/vendor/plugins/%{plugin_name} > %dir /srv/www/%{pkg_user}/vendor/plugins/%{plugin_name}/doc > -%dir /srv/www/%{pkg_user}/vendor/plugins/%{plugin_name}/var > +#%dir /srv/www/%{pkg_user}/vendor/plugins/%{plugin_name}/var Hi, why you comment out this line? I need this directory for touching file that indicates base system completion. -- 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

1 0

[yast-devel] Summary of code review
by Josef Reidinger 24 Aug '09

24 Aug '09

Hi, during today meeting with Karel (external rails consultant) we do some public code review of my code and we also find some general problems. I try summarize it in this mail. Please ask if you don't understand something. I start with rest-service: We should have some general method in ancestor (e.g. YastApplicationController) of all webyast plugins which do something (so no permissions or resources) some general method permission checker with same behavior (like response permission denied). We in general should eliminate things which is repeating in each plugin. Have one line view is useless and better is use respond_to. webclient: My class LogException is useles if we disable backtrace silencing so logger.info e is enought (btw it looks like our webclient is not generated by rails 2.3, as few files missing, it looks like we generated it by 2.2) http://afreshcup.com/2008/11/29/rails-23-backtrace-silencing/ load_proxy method is good idea how to reduce needed lines of code but should not redirect or set any infos. Instead use throwing exceptions and use rescue_from to display correct page. This also discover why sometime our universal exception handler doesn't work, because some exception is not child of Exception but Error. This also discover how looks our Resource service and it is really unreadable and unmaintainable code, as it is really big, should use e.g. mixins or something else to reduce its size and complexity. Test for this class looks good, so we should try refactor it to better result. We should better structure whole architecture like some part of controller do things in one area which is not close to controller contract, so we should move it to mixin (especially use it in application controller). Karel doesn't like checking for gettext in application controller. some positives from code review - time module is good documented and testing looks good even if designer could recognize it is written after code. Ideas to reduce code size and duplicated code is good, only implementation is not always good. some general knowledge: - testing model is the easiest so move the most of functionality there for easier testing - over-mocking is not good, as it abstract from reality (it is useful when you don't have implemented some functionality) - .railsrc and .irbrc for some general routines available during console session I hope I don't forget much thinks, maybe someone add another knowledge. -- 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 2

[yast-devel] Re: [yast-commit] <web-client> network : Prefer resource.policy to resource.interface for permissions.
by Klaus Kaempf 24 Aug '09

24 Aug '09

* Martin Vidner <mvidner(a)suse.cz> [Aug 24. 2009 15:52]: > > diff --git a/webclient/lib/yast/service_resource.rb b/webclient/lib/yast/service_resource.rb > index 670cb59..8a1fa31 100644 > --- a/webclient/lib/yast/service_resource.rb > +++ b/webclient/lib/yast/service_resource.rb > @@ -146,6 +146,10 @@ module YaST > raise "Can't retrieve permissions. No user specified and not logged in" if not login > > policy_name = nil > + if self.respond_to? :policy and self.policy This test shouldn't be needed as you're implementing 'policy' in the same controller. > + policy_name = self.policy > + end > + > if not policy_name > raise "object does not implement any interface" if not (self.respond_to?(:interface) and self.interface) > policy_name = self.interface > @@ -188,6 +192,14 @@ module YaST > defined?(@interface) ? @interface : nil > end > > + def policy=(policy_name) > + @policy = policy_name > + end > + > + def policy > + defined?(@policy) ? @policy : nil Just do an "attr_reader :policy". The policy attribute will default to 'nil'. > + end > + > def singular=(singular) > @singular = singular > end > @@ -283,6 +295,11 @@ module YaST > # set the interface name of the proxy > # that is used when retrieving permissions > rsrc.instance_variable_set(:@interface, resource.interface) > + begin > + rsrc.instance_variable_set(:@policy, resource.policy) This just doesn't look familiar and the Ruby documentation for instance_variable_set seems to discourage its use. What are you trying to achieve here ? 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] 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

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

20 Aug '09

WebYaST 20-Aug-2009 =================== Present: schubi, jdsn, bgeuken, jsrain, lslezak, mvidner, mzugec, jsuchome, jreidinger, mkudlvasr Status: ----------- Schubi: - continued updating selenium test cases - sinatra and selenium are fine next: - will go on with it bgeuken: - worked on package controller - got stucked with packagekit, but solved it now next: - work on package controller and status module jreidinger: - worked test for private routing, not all modules have it - wrote some mail concerning configuration next: - implement base system mvidner: - simplified rest-service interface mzugec: - worked on Yapi for network next: - will continue lslezak: - solved plugin reloading problems - set up test - fixed some problems next: - need to discuss custom plugin jsuchome: - commited work on service plugin next: - discuss with lslezak how to continue jsrain: - no update mkudlvasr: - worked with jreidinger on backend tests - commited to special branch next: - will continue work on frontend jdsn: - installed rest-service from source - updated wiki (installation from source) next: - look at test suite on hudson -- 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] Proposal how to improve Resource Loader
by Josef Reidinger 20 Aug '09

20 Aug '09

Hi, after critic about resource loader, that is unreadable and non-transparent I suggest this change: Create it as classical child of ActiveResource e.g. YastResource which then is ancestor of plugins models. What model only need define is interface in its body to get same functionality as now. (self.sife is method which get site dynamically). advantages: It is transparent ActiveResource, also it is easier to debug it (it is not dynamically created) It is more common for rails developers Instance have automatic permissions field which is filled in constructor or find call (part of YastResource class) It is easier to understand how it works Developer could move functionality to Model, so it prevent huge controllers and it also allows easier testing (you can easy mockup statically defined class) Removes all duplicity with load proxy and with proper exception and usage of rescue_from for standard page for some exceptions we have unified behavior. Controller looks more usual and removes all magic around proxy from it. disadvantages: Must change current code, but it is not much work (just move interface name to model) example of model code with same functionality as now: Time < YastResource self.interface = "org.opensuse.yast.modules.yapi.time end I welcome any comments and suggestions. I plan do it in next week in separate branch for test usage and then transfer it to trunk. -- 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

1 0

[yast-devel] WebYaST: Vendor customization
by Jiří Suchomel 19 Aug '09

19 Aug '09

Hi! There's already a feature present, it is https://fate.novell.com/307388: Citing from feature description: "Ideally, there should only be a single config dir (or file ?) covering all vendor customization. All customization (the config file, branding images, web style css file(s), etc.) should be contained in a single -branding package." As I'm looking into services module, which should offer Start/Stop options to vendor specific services (fate 306696), I also need some way to provide vendor specific data. Here, the data are: the list of services to show (a must) and optionally custom descriptions and paths to start/stop scripts to such services. So far, I'm using yml file (after Klaus' recommendation) as it is easy to parse and human readable. See attached examples: one is for list of maps (slightly better readable I assume), the second for map of maps (faster access). The file is currently expected under /etc/YaST2 directory. Technically, config file is parsed from YaPI which is called from rest-service, so it is not bound to webYaST usage and theoretically could be used together with YaPI from perl scripts. Comments, ideas? I have one to the feature description above: I'd rather vote for more config files (under same directory) over just one-for-all, as it needs to be parsed for each YaPI call. Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz

5 14

[yast-devel] WebYaST: Network REST Model v2
by Martin Vidner 19 Aug '09

19 Aug '09

WebYaST REST for Network v2: simplified (FATE#306699) * /network http://mschmidkunz.110mb.com/network.html Everything goes under /network But the network services, including a DHCP *server*, will be outside ("/network" may be something else, as specified in config/resources/network.yml) The design principle is: keep the config extremely simple, and let the reading of the actual properties mimic closely the Linux system. That way we can implement the requested feature and not lose time figuring out which level of generalization(+) is appropriate for the yet unknown use cases. +: CIM, NetworkManager, Netconfig, ... Everywhere the root element can instead contain dhcp: true * /interfaces/ The key is the kernel name: eth0, wlan0, br0 * /interfaces/eth0 ipaddr: - 1.2.3.4/24 * /routes/default route: via: 1.2.3.1 * /dns (/etc/resolv.conf) dns: nameservers: - 1.2.2.1 - 1.2.2.2 searches: - bar.com - bar.org * /hostname hostname: name: trikolka domain: suse.cz * /status/{interfaces,routes,dns,hostname} In the same format, read-only shows the current status (eg. actual IP) (In the prototype, we start with the configs and do /status afterwards) -- 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

1 0

[yast-devel] Vendor configuration service ?!
by Klaus Kaempf 19 Aug '09

19 Aug '09

Hi, the requirements for WebYaST contain a couple of vendor-configurable parts. Some are on the frontend (branding), some on the backend (setup workflow, services, ...). The current approach is to implement vendor configurations spread among many backend modules. I wonder if this is the right approach and if it wouldn't be better to have a single, shared implementation (class ? service ?) to cover this all. A single implementation would ensure consistency in file formats and locations as well as a single documentation. This is mostly for Josef and Jiri to agree upon ;-) 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

4 8

[yast-devel] WebYaST daily status, 19-Aug-2009
by Bjoern Geuken 19 Aug '09

19 Aug '09

WebYaST 19-Aug-2009 =================== Present: kkaempf, dmacvicar, schubi, bgeuken, jsrain, lslezak, mvidner, mzugec, jsuchome, jreidinger Status: ----------- kkaempf: - worked on Wiki and Fate - picked down login errors => jrails got it's own authentification next: - going to checkin error controller - not here on Thursday and Friday, will just read mail - likes to have a list of all packages belong to WebYast in the Wiki (-> todo list) dmacvicar: - discussed 2. part of Status (packages, vendor settings) with jreidinger and bgeuken - implemented config class next: - checkin config class - not here on Thursday schubi: - worked on sinatra and selenium next: - make selenium and sinatra useble for hudson mschmidkunz: - concept for basic system next: - meet kkaempf and dmacvicar and rlihm bgeuken: - worked on status module next: - work on package controller mvidner: - abandoned CIM model, it's to complex next: - start coding mzugec: - worked with mvidner next: - help mvidner - work on Yapi jsrain: - no update jsuchome: - worked on sevice plugin - wrote scripts to scr, not Yapi next: - add tests, commit work lsleza: - submitted packages to Hudson next: - work on custom services with jsuchome -- 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] <web-client> master : YAHOO js library not packaged currently, removing its usage for now
by Klaus Kaempf 18 Aug '09

18 Aug '09

* Jiri Suchomel <jsuchome(a)suse.cz> [Aug 18. 2009 15:56]: > ref: refs/heads/master > commit 9acc521133d808cb362876466a7a784859d3050f > Author: Jiri Suchomel <jsuchome(a)suse.cz> > Date: Tue Aug 18 15:54:01 2009 +0200 > > YAHOO js library not packaged currently, removing its usage for now Thanks ! The Yahoo javascript library was used before we agreed on jQuery. So all references to Yahoo js should be removed. 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] WebYaST - automatic plugin reloading!
by Ladislav Slezak 18 Aug '09

18 Aug '09

Hi all, Karel (the RoR consultant) pointed out yesterday that it should be possible to enable reloading of plugins. It's annoying to restart the rails server after each change and then relogin again... Google found some solutions but they didn't work for me, one of them works after a small modification. So, how to achive the automatic reloading? Just put --------------8<------------- # always reload all files in development mode if ENV['RAILS_ENV'] == 'development' # get all subdirectories in app/ dirs = Dir[File.join(directory, 'app', '*')].reject{|x| not File.directory?(x)} dirs.each do |dir| $LOAD_PATH << dir ActiveSupport::Dependencies.load_paths << dir ActiveSupport::Dependencies.load_once_paths.delete(dir) end end --------------8<------------- into your 'init.rb' file in the plugin directory. Then you can just save your changes and hit [Reload] in the web browser, no need to restart/relogin! Enjoy!! Please test it, it works for me, but I don't wont to break something. If it's OK we should add it to _all_ plugins. (BTW I'm not sure if the ENV['RAILS_ENV'] test is really needed, I have added it there to be sure that production server won't be slowed down by reloading files for each request...) -- 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 3

[yast-devel] Some thoughts about modeling
by Klaus Kaempf 18 Aug '09

18 Aug '09

Hi, the recent discussions about the network model enticed me to share some thoughts about modeling with you. There are two approaches to modeling, bottom-up or top-down. Bottom-up here means starting with a blank sheet of paper and design as it fits the requirements. With top-down, I'm referring to starting with an existing model, stripping and refactoring it until it fits. Both approaches have their pros and cons, neither is 'right' or 'wrong' per-se. It all depends. And modeling is hard, sometimes very hard if you have widely spread requirements. Grasping the result can be equaly hard, esp. if the requirements which led to the model are not known. In this situation, doing the bottom-up approach is the easiest and most rewarding as it leads quickly to a result matching current requirements. However, one has to be very aware of the limitations and that extending the model to fit additional needs might be very hard or even impossible. About two years ago, the Open Management Consortium (http://www.openmanagement.org, offline since months) was formed to unify the various open source system management approaches. Founding members included the 'big four', namely Zenoss, Hyperic, GroundWorks, and openQRM. Their initial goal was to agree on a protocol and eventually a single client daemon. So they organized a BarCamp and discussed protocols and models. Someone even showed a presentation bragging about how useless and bloated CIM was. Understandable, knowing that their main focus was on monitoring. Their collaboration approach never resulted in any concrete project. The Open Management Consortium seems to have dissolved in the meantime, I haven't seen any traffic on the mailing list for months. But there's more to system management than just monitoring. A lot more. If the monitoring console shows something red, you want to manage it (restart, re-configure, update, ...) and bring it back to green. If a network router failed, you need to know where it is (physically), what services the outage affects, and how to order a replacement unit. All this is covered in a CIM model. It tries to encompass all requirements of system management, which are many. (ITIL, http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library, gives a nice glimpse into this whole area.) And CIM is a fully normalized model, which is not really helping to make it easily understandable. But its helping to make it flexible and useful for a lot of use cases. (For the curious, here is a nice introduction into CIM modeling: http://www.cisl.ucar.edu/nets/intro/staff/siemsen/nandisc/dmtf/cim-2.5/tuto…) Its interesting to note that all major computing vendors build their management solutions on top of the CIM model. Microsoft, IBM, Dell, HP, Sun, Intel, Cisco, Apple, just to name a few. Now how does all this apply to WebYaST ? Going the easy path of bottom-up is acceptable, if the limitations and consequences for future extensions are known and documented. Its also harder to reuse upstream work. As WebYaST grows and implements more functionality, such a (self-designed) model might quickly reach its limits. Going the harder path of top-down will be more work up front but make it easier in the future to extend it and reuse upstream work. If WebYaST is successful, requirements will come to support discovery, inventory, root cause analysis, more network types, routing, etc. All this is already taken care of in the CIM model, we could be standing on the shoulders of giants. 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] No WebYaST call today
by Klaus Kaempf 18 Aug '09

18 Aug '09

Hi, since all Prague developers work with the Rails consultant today, we won't do a WebYaST call today. 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