August 2009 - YaST Development - openSUSE Mailing Lists

[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