[Deploying Sakai] [Building Sakai] What do you think about Config Viewer?

Thu Jan 7 14:48:52 PST 2010

I think what Matthew meant about separating the properties files for each webapp, is that those would be the initial properties and the Config Viewer would be able to register them from each webapp. It would then have an editing interface so that you can make changes live.

One thing that would need to be addressed are properties that must be configured *before* startup, and ones that cannot be changed *after* start up, although these are most likely a limited subset (database connection details etc).

Sounds like a great plan, +1.

cheers,
Steve

On 08/01/2010, at 8:12 AM, David Haines wrote:

> A few thoughts:
> 
> - There are two kinds of properties, some values are injected when the bean is created, some are looked up during processing.  They have different semantics.  E.g. cluster propagation of values that are looked up would be straightforward.  Cluster propagation of values that are injected and not assumed to change would be a lot more difficult.
> 
> - The "injected" properties could be documented via annotations, which would keep the documentation in the source file where they are used and should make extracting the documentation easier.
> 
> - It needs to be an easy way to override properties without requiring a new build.  If property overrides need to be scattered around the webapps directories then setup will become a lot more fragile.  Scattering the property overrides probably isn't what is being suggested but I'm not sure that is clear.
> 
> - Any runtime changes to properties need to be logged so that, when it is time to diagnose a problem, it is clear what values an instance was really using.
> 
> - Dave
> 
> 
> David Haines
> CTools Developer
> Digital Media Commons
> University of Michigan 
> dlhaines at umich.edu
> 
> 
> 
> 
> On Jan 7, 2010, at 2:39 PM, Matthew Jones wrote:
> 
>> I echo most of what Noah has said, mostly because I've spent quite a bit of time discussing with him and Anthony on this issue. I'm very interested in easier configuration and annoyed with the current state of sakai configuration. There are some properties that I only discover by searching through JIRA's or even worse, through source code. This is not something that the average or even above average user is likely to do. There are many advanced features of tools people don't even know about. 
>> 
>> I'm lucky because I sit right next to the developers of many of the sakai tools and also go pay more attention to the jiras so if I have questions I *usually* can just ask them. ;)
>> 
>> The effort that Tony put into assembling the original config viewer, looking at it was pretty impressive. There's a properties file containing 429 properties that list all of the current known configuration variables available at the time of release. Yes, at *least* 429 settings that you can alter in sakai.properties.
>> 
>> There are a few steps on the top of my head to getting this under control because maintaining this property file is not something that anyone can do for the future, though the structure is nice. 
>> 
>> Here's what I'd propose (I'll flesh this out a little more), comments obviously welcome, I'm just throwing this out there so we have some discussion?
>> 
>> Once this is done, making a system for viewing AND runtime cluster-wide modification of properties for sakai 2 (and most likely 3 if it uses a similar system) will be easier to handle.
>> 
>> The people that know the properties best are the individual tool developers. Most of this work can be accomplished relatively quickly if undertaken by multiple people that know the tools, and it's mostly just some code cleanup
>> 
>> 1) Get the properties names associated with the tools they modify.
>>  - *Nearly* tools have to go through registration and have an id (sakai.configviewer). For these tools the property should be
>>   <toolid>.propertyname (i.e. sakai.configviewer.enabled)
>> - The tools that use beans are named fine and can stay as they are
>> (allowGroupAssignments at org.sakaiproject.assignment.api.AssignmentService)
>> - For non tools (Like portal?) We'll have to come up with some base names for these.
>> 
>> 2) Either create a new properties files deployed with the tool (webapps/<tool package>/tool.properties) that has a properties definition like (3). Either that or possibly add it as XML to the tools.xml registration for the tool. This seems like it would be easier than adding new code to take care of it. This way the tool can be responsible for defining the properties it has and each maintainer can keep this file up-to-date
>> 
>> 3) Note the properties files are defined in configViewer like this.
>> properties.name.1=affiliatesubjects
>> properties.type.1=getStrings
>> properties.tool.1=site-manage
>> properties.version.1=2.2,2.3,2.4,2.5,2.6
>> properties.configurable.1=N
>> properties.rule.1=none
>> properties.qualifier.1=affiliate subjects
>> properties.nullable.1=N
>> 
>> -- Note: There will still the same properties types. Integer(s)/Boolean(s)/String(s).
>> 
>> In XML it would of course look like
>> <properties>
>> <property>
>> <name>affiliatessubjects</name>
>> . . .
>> </property>
>> </properties>
>> 
>> . . . Maybe this is better?
>> 
>> I can do the initial work and split this large properties files into individual project tool files, so nobody would have to do anything yet.
>> 
>> Anyway, I just wanted to throw that out there to let people know that we *are* thinking about it, but it's not the highest priority.
>> 
>> -Matthew
>> 
>> On Thu, Jan 7, 2010 at 1:14 PM, Noah Botimer <botimer at umich.edu> wrote:
>> I'll let others be pragmatic. What I'd be most interested in for the 2.8 timeline is an honest look at our configuration mechanism. I would consider improving it and just reflecting on what it does well and less well (for future) to be valuable outputs.
>> 
>> Some have heard my complaints about the "just make another property" practice and some the other configuration friction. Let me try to phrase this as a positive-looking request...
>> 
>> I would like to see an easy way to establish and document the existence of possible settings in one pass, with valid data types/ranges indicated. I would like there to be some categorization (if only one level for "section"/tool/whatever). I would like to see differentiation between "system-level" things like hostname or other nuts&bolts startup parameters from things that deal with the runtime application. I would like to see a live, consolidated control panel, maybe a la Webmin. I would like there to be effective cluster-wide propagation of these runtime settings.
>> 
>> So, while I will not disregard enthusiasm for maintaining a good tool, I ask that we pause and consider what it means to maintain a community-evolved enterprise application on campus on a daily basis. Much of this conversation parlays into understanding how we want our world to be in the next round (Sakai 3).
>> 
>> Thanks,
>> -Noah
>> 
>> 
>> On Jan 7, 2010, at 12:25 PM, Jean-Francois Leveque wrote:
>> 
>> Hi all,
>> 
>> It's been 12 months since Tony Atkins released the last tag for Config
>> Viewer. I really like this tool and I've heard others also do.
>> 
>> Matthew Jones has contributed useful fixes in trunk and in a umich_2.6.x
>> branch.
>> 
>> I think we can do better as a community if we want to be able to use
>> this tool in the future.
>> 
>> Are you using it in production?
>> 
>> Do you want it to be maintained?
>> 
>> Would you like it to be part of Sakai 2.8.0?
>> 
>> Would you like to help?
>> 
>> My answer to all these questions is yes. What do you think?
>> 
>> Cheers,
>> 
>> Jean-François Lévêque
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>> 
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>> 
>> 
>> 
>> 
>> _______________________________________________
>> production mailing list
>> production at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/production
>> 
>> TO UNSUBSCRIBE: send email to production-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
> _______________________________________________
> production mailing list
> production at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/production
> 
> TO UNSUBSCRIBE: send email to production-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/production/attachments/20100108/142b7177/attachment.html 