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

[Matthew Jones]

Right Steve, this is what I meant. The defaults would be defined similar to
how they are now (unless we switch to apache commons config but thats for a
later decision and more investigation). This tool really just needs a way
for the individual tools to define what they provide in terms of properties
in a standardized way so config viewer/editor knows what they are (the name,
the type, the description, applicable versions default values, possible
values). These things are all currently defined in a huge properties file
within config viewer right now but really should be on a tool by tool basis
if we adopted config viewer/editor as a core project. I will probably *keep*
the centralized file but come up with some standard so local tools can
override this properties file with more "up-to-date' properties.

The problem is since we don't have any real standard way of identifying
which property goes to which tool, initially it will be a little work moving
these around, but once this is all done, the interface will be really nice
and hierarchial. We will be able to have a nice collapsable tree in the
admin interface like:

+ sakai.assignments -> <Assignment properties>
 . . .
+ sakai.gradebook -> <Grade book properties>
+ sakai.rwiki -> <RWiki properties>

Longer Term: Tool designers will see how easy this is and *want* to use this
over writing their own UI for defining admin properties. It's entirely
possible that these properties could be extended beyond simple properties to
allow a tool to easily create an complex configuration screen by just
writing properties/xml, similar in looks to the evaluation admin
interface<http://lh3.ggpht.com/_7w26Vq3qK3Y/S0Zo2Y37M2I/AAAAAAAAASg/Wg6MWwCr-9E/s912/Evaluations.png>.
These would all be in the same admin area for the user.

I don't believe many tools currently have this many options mostly because
we don't make it very easy to configure them, And the tools are basically
set up the way the tool or ux designer believes it will be used. Some people
like to turn options off or try out different settings, and that isn't easy
now as it requires research and reboot.

And you're right, some settings will not be editable or viewable. Will
probably have a flag such as hidden or read only that can be applied to
these special properties.

-Matthew

On Thu, Jan 7, 2010 at 5:48 PM, Steve Swinsburg
<steve.swinsburg at gmail.com>wrote:

> 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/20100107/c241760d/attachment-0001.html