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

Thu Jan 7 11:39:35 PST 2010

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"
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100107/558b6965/attachment.html 