Okay, so I believe that this is no longer appropriate for a fast track,
at least not under the "familiarity" guidelines. This is *not* a
familiarity case, but a case intending to create new architecture for
Solaris upon which other projects will build.
As such, one of my concerns is the use of Tcl as the *exposed* interface
to end-users and administrators. Without picking on Tcl's merits or
concerns specifically, one of my major concerns is that this might be
the first time that we expect users to have to write Tcl scripts to use
the system. I think such a precedent deserves proper review and
consideration, rather than sliding in as a familiarity case.
Additionally, the exported interfaces must include all of the syntax of
the modulefile.4 content. You've not expressed that in the interface
table, and I think it has to be included.
I do have to say, it seems unfortunate that this project creates a
dependency upon Tcl -- modification of user environments is a pretty
simple thing to do, and I've done this at other sites using shell
scripts or even a very small C program. Bringing in the entire Tcl
interpreter (and its dependencies) for something that is so basically
simple, seems like not the best engineering choice that could have been
made. Especially since many sites might elect not to install Tcl by
default.
- Garrett
Bruce Rothermal wrote:
> Not much more other than to say that the project involves an automated
> deployment and management system for large scale grid/cloud computing
> architecture. It is a component of the HPC Developer community
> http://opensolaris.org/os/community/hpcdev/ but there are still some
> contractual agreements in the works so I can not say more.
>
> Bruce
>
>
> On Aug 24, 2009, at 10:07 AM, Garrett D'Amore wrote:
>
>> Bruce Rothermal wrote:
>>> This package is needed for a $Supported code project we are working
>>> on in HPC. Since we are already porting this for our project we are
>>> directed to make the package available to all and also so it is
>>> available via the IPS package server on opensolaris.org.
>>
>> Does this mean that we should be scrutinizing this project much more
>> closely? If the project is being put into use as a building block by
>> our own developers, then it is no longer a "familiarity" project, and
>> probably deserves much closer consideration for architectural
>> correctness and completeness.
>>
>> Can you provide more detail about this other project?
>>
>> - Garrett
>>>
>>> Bruce
>>>
>>> On Aug 24, 2009, at 1:37 AM, Joep Vesseur wrote:
>>>
>>>> On 08/21/09 22:31, John Fischer wrote:
>>>>
>>>>> This project proposes to integrate the Environment Modules within a
>>>>> Minor release of Solaris (i.e., Open Solaris). The environment
>>>>> modules
>>>>> provides an easy modification to a user's environment via TCL
>>>>> scripts.
>>>>> These scripts set various environmental variables such as PATH,
>>>>> MANPATH,
>>>>> etc.
>>>>
>>>> I'm not sure my remarks make any PSARC sense, but since there is no
>>>> rationale mentioned for integrating this, I'm inclined to ask anyway:
>>>>
>>>> Does it really make sense to force people into being able to read/
>>>> write TCL in order for them to configure their shell? I imagine
>>>> that most of the modulefile(4)s would be written by administrators
>>>> (how many of them speak TCL?), but users will have to debug/override
>>>> any settings they want to tweak.
>>>>
>>>> I'm just wondering why we pick a TCL-based configuration tool for
>>>> something like this. If the answer is Linux-compatibility, I think
>>>> there is enough precedent, whether I like it or not. Otherwise, I'm
>>>> not sure that we build a useful architecture here.
>>>>
>>>> Joep
>>>
>>>
>>>
>>> Bruce Rothermal
>>> Email: bruce.rothermal at sun.com
>>> Skype: bruce.rothermal
>>> Google Talk: bruce.rothermal at gmail.com
>>>
>>>
>>>
>>>
>>
>
>
>
> Bruce Rothermal
> Email: bruce.rothermal at sun.com
> Skype: bruce.rothermal
> Google Talk: bruce.rothermal at gmail.com
>
>
>
>
