[yast-devel] A Plan for YaST: Project Amaranth
A Plan for YaST: Project Amaranth ================================= Why --- YaST as a platform has been stagnant for the past few years. Half of the original team has been busy with WebYaST and other web projects. Since relicensing to GPL in 2004 we got very few contributions - Benjiman's One Click Install being a notable exception - Oracle contacted us with their patches (based on a previous version of SLE), but we did not follow up. Much of the code has no tests, patching it is risky. Linux around evolves, a recent example being systemd, so YaST must keep up. If we don't provide a direction for YaST, it will rot and die. What ---- Amaranth is a project to open up YaST and realize its potential: Deprecate YCP, a custom YaST language, in favor of Ruby(*), a widespread one. Thus gain contributors from openSUSE and possibly other distro communities. *) see a followup mail about the language choice How --- Take the existing unfinished attempts yast2-ruby-bindings, yast2-libyui, ruby-yui, bind libstorage to ruby. - loudly state the intent to make them usable, including a timeline (see When) - provide good and up-to-date documentation - integrate with the Ruby ecosystem: -- document in form usual for Ruby developers (rdoc/yard) -- get found at rubygems (if only as a stub to point to the real package) - move from Subversion to Git (host at Gitorious, Github, or both) (see Why Git) - give good examples of usage, by converting a couple of production YaST modules to the new platform When ---- Have it all ready by the release of openSUSE 12.0 (November 2011) at the latest. Better, do it for an earlier milestone and have 12.0 feature independent contributions. Don't try hasty fixes for 11.4, now we still can't guarantee the API. Possibly do a backport. Who --- The long term goal is "hackers from around the Tux world". For now, it's myself, looking for you, the YaST hackers, to join, and for the team leads, project and product managers to give us time for it. Why Git ------- Git enables fearless hacking, power to the people, easy merging. Code Name --------- Amaranth is a purple (read .py.rb.pl) flower whose name means 'unwithering'. The tool is still branded YaST. Amaranth is the project to make the transition to world domination. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
On 02/09/2011 03:05 PM, Martin Vidner wrote:
Take the existing unfinished attempts yast2-ruby-bindings, yast2-libyui, ruby-yui, bind libstorage to ruby.
- loudly state the intent to make them usable, including a timeline (see When) - provide good and up-to-date documentation - integrate with the Ruby ecosystem: -- document in form usual for Ruby developers (rdoc/yard) -- get found at rubygems (if only as a stub to point to the real package) - move from Subversion to Git (host at Gitorious, Github, or both) (see Why Git) - give good examples of usage, by converting a couple of production YaST modules to the new platform
Hey Martin, this is a great start. While I have to admit I am biased because I love ruby, There are other reasons: - We have done already a lot of ruby investments in the team. - Rails is great to have. WebYaST The plan looks great. Just some comments: - May be separate the ruby/UI part from the ruby/YCP bridges, that is, not access the UI using YCP but direct ruby bindings. Rethink how this API is exposed to the language. - Migrate/Document current use cases (y2log, y2doc, y2tools) with native ruby equivalents - Look at what will replace SCR. Look at COMAR. Good stuff. Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Wednesday 09 February 2011 22:56:45 Duncan Mac-Vicar P. wrote:
On 02/09/2011 03:05 PM, Martin Vidner wrote:
Take the existing unfinished attempts yast2-ruby-bindings,
yast2-libyui, ruby-yui, bind libstorage to ruby.
- loudly state the intent to make them usable, including a timeline (see When) - provide good and up-to-date documentation - integrate with the Ruby ecosystem: -- document in form usual for Ruby developers (rdoc/yard) -- get found at rubygems (if only as a stub to point to the real package) - move from Subversion to Git (host at Gitorious, Github, or both) (see Why Git) - give good examples of usage, by converting a couple of production
YaST modules to the new platform
Hey Martin, this is a great start.
While I have to admit I am biased because I love ruby, There are other reasons:
- We have done already a lot of ruby investments in the team. - Rails is great to have. WebYaST
The plan looks great. Just some comments:
- May be separate the ruby/UI part from the ruby/YCP bridges, that is, not access the UI using YCP but direct ruby bindings. Rethink how this API is exposed to the language. - Migrate/Document current use cases (y2log, y2doc, y2tools) with native ruby equivalents - Look at what will replace SCR. Look at COMAR. Good stuff.
I'd target higher here: D-Bus based interface can be only local, for WebYaST we have the REST API on top of D-Bus anyway, so why not use it? Using desktop YaST for managing machines remotely could be a nice bonus for rather low price (meaning added to what you plan to invest), you would not have to have the UI libraries installed on each system. I have one concern about D-Bus, probably coming from lack of knowledge: SCR is able to run an instance in chroot, which is used during installation; while I can imagine any kind of web service run in chroot as well, can D-Bus handle this? Jiri -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.cz Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 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
On Thu, Feb 10, 2011 at 08:58:48AM +0100, Jiri Srain wrote:
On Wednesday 09 February 2011 22:56:45 Duncan Mac-Vicar P. wrote:
Hey Martin, this is a great start.
While I have to admit I am biased because I love ruby, There are other reasons:
- We have done already a lot of ruby investments in the team. - Rails is great to have. WebYaST
The plan looks great. Just some comments:
- May be separate the ruby/UI part from the ruby/YCP bridges, that is, not access the UI using YCP but direct ruby bindings. Rethink how this API is exposed to the language.
Yes
- Migrate/Document current use cases (y2log, y2doc, y2tools) with native ruby equivalents
Yes
- Look at what will replace SCR. Look at COMAR. Good stuff.
Right.
I'd target higher here: D-Bus based interface can be only local, for WebYaST we have the REST API on top of D-Bus anyway, so why not use it? Using desktop YaST for managing machines remotely could be a nice bonus for rather low price (meaning added to what you plan to invest), you would not have to have the UI libraries installed on each system.
It feels a bit too much, but I'll remember to consider it.
I have one concern about D-Bus, probably coming from lack of knowledge: SCR is able to run an instance in chroot, which is used during installation; while I can imagine any kind of web service run in chroot as well, can D-Bus handle this?
Not out of the box, but for the installation it is simple to reconfigure the daemon to listen on a socket visible from the chroot or on a localhost TCP socket. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
On Thursday, February 10, 2011 08:58:48 am Jiri Srain wrote:
On Wednesday 09 February 2011 22:56:45 Duncan Mac-Vicar P. wrote:
On 02/09/2011 03:05 PM, Martin Vidner wrote:
Take the existing unfinished attempts yast2-ruby-bindings,
yast2-libyui, ruby-yui, bind libstorage to ruby.
- loudly state the intent to make them usable, including a timeline (see When) - provide good and up-to-date documentation - integrate with the Ruby ecosystem: -- document in form usual for Ruby developers (rdoc/yard) -- get found at rubygems (if only as a stub to point to the real package) - move from Subversion to Git (host at Gitorious, Github, or both) (see Why Git) - give good examples of usage, by converting a couple of production
YaST modules to the new platform
Hey Martin, this is a great start.
While I have to admit I am biased because I love ruby, There are other reasons:
- We have done already a lot of ruby investments in the team. - Rails is great to have. WebYaST
The plan looks great. Just some comments:
- May be separate the ruby/UI part from the ruby/YCP bridges, that is, not access the UI using YCP but direct ruby bindings. Rethink how this API is exposed to the language. - Migrate/Document current use cases (y2log, y2doc, y2tools) with native ruby equivalents - Look at what will replace SCR. Look at COMAR. Good stuff.
I'd target higher here: D-Bus based interface can be only local, for WebYaST we have the REST API on top of D-Bus anyway, so why not use it? Using desktop YaST for managing machines remotely could be a nice bonus for rather low price (meaning added to what you plan to invest), you would not have to have the UI libraries installed on each system. I think there should be a common library for system access (e.g. COMAR). Both webyast backend and desktop yast link against it. Dunno if dbus is appropriate here. Doesn't every layer slow down interaction.
I have one concern about D-Bus, probably coming from lack of knowledge: SCR is able to run an instance in chroot, which is used during installation; while I can imagine any kind of web service run in chroot as well, can D-Bus handle this?
Jiri
-- Thomas Goettlicher SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Thursday 10 February 2011 11:08:53 Thomas Goettlicher wrote:
On Thursday, February 10, 2011 08:58:48 am Jiri Srain wrote:
On Wednesday 09 February 2011 22:56:45 Duncan Mac-Vicar P. wrote:
On 02/09/2011 03:05 PM, Martin Vidner wrote:
Take the existing unfinished attempts yast2-ruby-bindings,
yast2-libyui, ruby-yui, bind libstorage to ruby.
- loudly state the intent to make them usable, including a timeline (see When) - provide good and up-to-date documentation - integrate with the Ruby ecosystem: -- document in form usual for Ruby developers (rdoc/yard) -- get found at rubygems (if only as a stub to point to the real package) - move from Subversion to Git (host at Gitorious, Github, or both) (see Why Git) - give good examples of usage, by converting a couple of production
YaST modules to the new platform
Hey Martin, this is a great start.
While I have to admit I am biased because I love ruby, There are other reasons:
- We have done already a lot of ruby investments in the team. - Rails is great to have. WebYaST
The plan looks great. Just some comments:
- May be separate the ruby/UI part from the ruby/YCP bridges, that is, not access the UI using YCP but direct ruby bindings. Rethink how this API is exposed to the language. - Migrate/Document current use cases (y2log, y2doc, y2tools) with native ruby equivalents - Look at what will replace SCR. Look at COMAR. Good stuff.
I'd target higher here: D-Bus based interface can be only local, for WebYaST we have the REST API on top of D-Bus anyway, so why not use it? Using desktop YaST for managing machines remotely could be a nice bonus for rather low price (meaning added to what you plan to invest), you would not have to have the UI libraries installed on each system.
I think there should be a common library for system access (e.g. COMAR). Both webyast backend and desktop yast link against it. Dunno if dbus is appropriate here. Doesn't every layer slow down interaction.
I'm not sure either. We need an interface because of two reasons: - have only the back-end runing as root - provide network transparency (to have the client - e.g. yastwc - run remotely) That was why I mentioned the REST API as a better solution. Regarding Klaus' comment from other reply on this email: I fully agree, we should definitely target more high level than what we have now. Jiri -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.cz Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 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
* Jiri Srain <jsrain@suse.cz> [Feb 10. 2011 08:59]:
I'd target higher here: D-Bus based interface can be only local, for WebYaST we have the REST API on top of D-Bus anyway, so why not use it?
Thinking about it, I would propose to drop the WebYaST REST API as it is currently. It is too low-level and should be replaced by a richer / more functional approach. It exposes YaSTs SCR layer, while it should expose the YaST 'module' layer. The SCR layer handles 'disks', 'shell commands' and 'config files'. Installing a new disk requires detection ('disk'), partitioning ('shell'), formatting ('shell'), mount point creation ('shell'), mounting ('shell') and editing the fstab ('config'). On the module layer, installing a new disk would be a single REST call. The example might not be typical, but you get the idea. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Dne čtvrtek 10 Únor 2011 11:28:08 Klaus Kaempf napsal(a):
* Jiri Srain <jsrain@suse.cz> [Feb 10. 2011 08:59]:
I'd target higher here: D-Bus based interface can be only local, for WebYaST we have the REST API on top of D-Bus anyway, so why not use it?
Thinking about it, I would propose to drop the WebYaST REST API as it is currently.
It is too low-level and should be replaced by a richer / more functional approach. It exposes YaSTs SCR layer, while it should expose the YaST 'module' layer.
This is not true, at least not generally. Current webYaST has tasks like - list all services - start/stop given service - add a user - read/write network settings - read/setup new LDAP configuration These actually are high level tasks, and mostly are mapped to YaPI, which actually is YaST 'module' layer. (I know this part of the thread is a bit off topic) 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
On Thursday 10 February 2011 14:36:07 Jiri Suchomel wrote:
Dne čtvrtek 10 Únor 2011 11:28:08 Klaus Kaempf napsal(a):
* Jiri Srain <jsrain@suse.cz> [Feb 10. 2011 08:59]:
I'd target higher here: D-Bus based interface can be only local, for WebYaST we have the REST API on top of D-Bus anyway, so why not use it?
Thinking about it, I would propose to drop the WebYaST REST API as it is currently.
It is too low-level and should be replaced by a richer / more functional approach. It exposes YaSTs SCR layer, while it should expose the YaST 'module' layer.
This is not true, at least not generally. Current webYaST has tasks like - list all services - start/stop given service - add a user - read/write network settings - read/setup new LDAP configuration
These actually are high level tasks, and mostly are mapped to YaPI, which actually is YaST 'module' layer.
That's right, the question is what exactly YaPI offers. There is no generic answer, as a consequence of the way YaPI was designed in its beginnings. In many (NOT ALL) cases YaST modules just store parsed configuration files, which YaPI then exposes through the interface. In such cases it would be possible provide API on higher level than configuration file structured as XML or YCP structure (I may overexpress a bit). As I wrote, the above is not valid for every module. But it definitely is something worth looking into. Jiri -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.cz Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 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
On 02/10/2011 11:28 AM, Klaus Kaempf wrote:
* Jiri Srain<jsrain@suse.cz> [Feb 10. 2011 08:59]:
I'd target higher here: D-Bus based interface can be only local, for WebYaST we have the REST API on top of D-Bus anyway, so why not use it?
Thinking about it, I would propose to drop the WebYaST REST API as it is currently.
It is too low-level and should be replaced by a richer / more functional approach. It exposes YaSTs SCR layer, while it should expose the YaST 'module' layer.
The SCR layer handles 'disks', 'shell commands' and 'config files'.
Right now the WebYaST REST API is a CRUD REST API for the the models: User, Service. I think what can be dropped is having the API in a separate server and have the API in the same server as the web UI (same controllers /different content-type). Then the controllers and YaST could reuse this "models" (ie: if written in ruby), those models could be grouped in standard gems, and implemented on top of dbus, comar, or plain augeas. WebClient def index render Service.all :format => content-type end Desktop YaST dialog printing Service.all as table CLI YaST colored ANSI table printing Service.all class Service def find ... augeas or dbus code ... end end If one day you need remoting capabilities like Jiri suggested, you provide a implementation of class Service consuming the REST API WebClient exposes, or remote dbus, whatever. You can tackle that problem when you need it. It is not like we used much the current YaST remoting capabilities until now. Lets not limit ourselves because something we don't need right now. -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Wednesday, February 09, 2011 10:56:45 pm Duncan Mac-Vicar P. wrote:
On 02/09/2011 03:05 PM, Martin Vidner wrote:
Take the existing unfinished attempts yast2-ruby-bindings,
yast2-libyui, ruby-yui, bind libstorage to ruby.
- loudly state the intent to make them usable, including a timeline (see When) - provide good and up-to-date documentation - integrate with the Ruby ecosystem: -- document in form usual for Ruby developers (rdoc/yard) -- get found at rubygems (if only as a stub to point to the real package) - move from Subversion to Git (host at Gitorious, Github, or both) (see Why Git) - give good examples of usage, by converting a couple of production
YaST modules to the new platform
Hey Martin, this is a great start.
While I have to admit I am biased because I love ruby, There are other reasons:
- We have done already a lot of ruby investments in the team. - Rails is great to have. WebYaST
The plan looks great. Just some comments:
- May be separate the ruby/UI part from the ruby/YCP bridges, that is, not access the UI using YCP but direct ruby bindings. Rethink how this API is exposed to the language. - Migrate/Document current use cases (y2log, y2doc, y2tools) with native ruby equivalents - Look at what will replace SCR. Look at COMAR. Good stuff. Which alternatives to COMAR are available? COMAR is used by pardus only right now. In a perfect world we use stuff that's popular and (web)yast is aviable for all distros.
Duncan
-- Thomas Goettlicher SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
2011/2/9 Martin Vidner <mvidner@suse.cz>:
A Plan for YaST: Project Amaranth =================================
Why ---
YaST as a platform has been stagnant for the past few years. Half of the original team has been busy with WebYaST and other web projects. Since relicensing to GPL in 2004 we got very few contributions - Benjiman's One Click Install being a notable exception - Oracle contacted us with their patches (based on a previous version of SLE), but we did not follow up. Much of the code has no tests, patching it is risky. Linux around evolves, a recent example being systemd, so YaST must keep up. If we don't provide a direction for YaST, it will rot and die.
What ----
Amaranth is a project to open up YaST and realize its potential: Deprecate YCP, a custom YaST language, in favor of Ruby(*), a widespread one. Thus gain contributors from openSUSE and possibly other distro communities.
*) see a followup mail about the language choice
How ---
Take the existing unfinished attempts yast2-ruby-bindings, yast2-libyui, ruby-yui, bind libstorage to ruby.
- loudly state the intent to make them usable, including a timeline (see When) - provide good and up-to-date documentation - integrate with the Ruby ecosystem: -- document in form usual for Ruby developers (rdoc/yard) -- get found at rubygems (if only as a stub to point to the real package) - move from Subversion to Git (host at Gitorious, Github, or both) (see Why Git) - give good examples of usage, by converting a couple of production YaST modules to the new platform
When ----
Have it all ready by the release of openSUSE 12.0 (November 2011) at the latest. Better, do it for an earlier milestone and have 12.0 feature independent contributions. Don't try hasty fixes for 11.4, now we still can't guarantee the API. Possibly do a backport.
Who ---
The long term goal is "hackers from around the Tux world". For now, it's myself, looking for you, the YaST hackers, to join, and for the team leads, project and product managers to give us time for it.
Why Git -------
Git enables fearless hacking, power to the people, easy merging.
Code Name ---------
Amaranth is a purple (read .py.rb.pl) flower whose name means 'unwithering'. The tool is still branded YaST. Amaranth is the project to make the transition to world domination.
Why is a separate project needed? Why not combine forces with already existing mature environments? Especially when a major change is to be done anyway? I think that it can be done faster and safer if the creative forces are combined in stead of duplicating existing work. Kind regards Birger -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (7)
-
Birger Kollstrand -
Duncan Mac-Vicar P. -
Jiri Srain -
Jiri Suchomel -
Klaus Kaempf -
Martin Vidner -
Thomas Goettlicher