[yast-devel] Vendor configuration service ?!
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@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Tuesday 18 August 2009 10:37:44 Klaus Kaempf wrote:
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 ;-)
I was talking with Björn about this earlier, because the status has to show a custom package list that needs to be stored in a configuration file. So the installed packages resources should be able to filter by this custom setting. I propose this: http://www.gliffy.com/pubdoc/1795703/L.jpg Use cases: imagine appliance CoolDb with a shiny moon logo, they have a custom bug reporting site - The service is running in the same appliance machine. The webclient may be not. - If you call /installed_packages?filter=custom, the service is running in the same appliance, so it can use the API to get the custom packages to display. The API will provide access to this collection of customization files. - If the client is in another machine, there will be other settings that the client will need to retrieve _from_ the appliance in order to make some sense in the user interface, example: * If the client is in another machine, and a module crashes, you want still to show the link to the bug page of the vendor, which is configuration in the server side, therefore we need to expose those settings in a core settings controller/resource. - If the client is local to the appliance you get the branding. If the client is remote, I think it is a reasonable to leave the branding out What do you think? -- 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@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Duncan Mac-Vicar Prett <dmacvicar@suse.de> [Aug 18. 2009 12:51]:
I was talking with Björn about this earlier, because the status has to show a custom package list that needs to be stored in a configuration file. So the installed packages resources should be able to filter by this custom setting.
[...]
What do you think?
I just added it to the TODO list at http://en.opensuse.org/YaST/Web/TODO (and assigned it to Björn ;-)) 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
On 08/18/2009 10:37 AM, Klaus Kaempf wrote:
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
Yes, I agree. We should have allocated place (like somewhere in /etc/YaST2) I only need read permissions to this file. Also if we abstract above loader we should in future improve it or change it and it affects all code. So I agree.
--- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
-- Josef Reidinger YaST team maintainer of perl-Bootloader, YaST2-Repair, webyast modules language and time -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Josef Reidinger <jreidinger@suse.cz> [Aug 18. 2009 15:53]:
On 08/18/2009 10:37 AM, Klaus Kaempf wrote:
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
Yes, I agree. We should have allocated place (like somewhere in /etc/YaST2) I only need read permissions to this file.
Actually, I would suggest to use /etc/webyast as to not confuse it with other YaST2 settings. 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
On 08/18/2009 04:51 PM, Klaus Kaempf wrote:
* Josef Reidinger <jreidinger@suse.cz> [Aug 18. 2009 15:53]:
On 08/18/2009 10:37 AM, Klaus Kaempf wrote:
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
Yes, I agree. We should have allocated place (like somewhere in /etc/YaST2) I only need read permissions to this file.
Actually, I would suggest to use /etc/webyast as to not confuse it with other YaST2 settings.
Yes, and I think that this path should be enclosed in that abstract class for loading configuration, so you use just conf = ConfLoader.load("basesystem.conf") and doesn't care where is real destination (and we can easy change it in future if we agree on better location). -- Josef Reidinger YaST team maintainer of perl-Bootloader, YaST2-Repair, webyast modules language and time -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Josef Reidinger <jreidinger@suse.cz> [Aug 18. 2009 17:02]:
Actually, I would suggest to use /etc/webyast as to not confuse it with other YaST2 settings.
Yes, and I think that this path should be enclosed in that abstract class for loading configuration, so you use just conf = ConfLoader.load("basesystem.conf") and doesn't care where is real destination (and we can easy change it in future if we agree on better location).
Exactly ! 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
On utorok 18 August 2009 16:51:54 Klaus Kaempf wrote:
* Josef Reidinger <jreidinger@suse.cz> [Aug 18. 2009 15:53]:
On 08/18/2009 10:37 AM, Klaus Kaempf wrote:
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
Yes, I agree. We should have allocated place (like somewhere in /etc/YaST2) I only need read permissions to this file.
Actually, I would suggest to use /etc/webyast as to not confuse it with other YaST2 settings.
Just to be sure, /etc/webyast is directory with configuration snippets, correct? Stano -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Stanislav Visnovsky <visnov@suse.cz> [Aug 19. 2009 11:12]:
Just to be sure, /etc/webyast is directory with configuration snippets, correct?
Right. And we must be careful as we have three configuration areas 1. Service configuration (stored in the backend system) 2. Client configuration (stored in the frontend system) 3. Branding (stored in the frontend system) I'd suggest to put 1 and 2 into /etc/webyast but use different names (subdirectories?) to tell them apart. #3 would belong into $RAILS_ROOT/public/{images, stylesheets} 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
participants (4)
-
Duncan Mac-Vicar Prett -
Josef Reidinger -
Klaus Kaempf -
Stanislav Visnovsky