Given Ralph's questions about
rhttps://svn.open-mpi.org/trac/ompi/changeset/28456, ORNL's second question to
me/Nathan about MCA params is probably worth forwarding to the list -- see
below.
Thoughts on this proposal?
Begin forwarded message:
> From: "Boehm, Swen" <bo...@ornl.gov>
> Subject: Re: Q: project based MCA param files
> Date: May 3, 2013 5:03:43 PM EDT
> To: "Jeff Squyres (jsquyres)" <jsquy...@cisco.com>
> Cc: Nathan Hjelm <hje...@lanl.gov>, "Vallee, Geoffroy R."
> <valle...@ornl.gov>, "Naughton III, Thomas J." <naught...@ornl.gov>
>
> Hi Jeff,
>
> Here is a short description of the enhancement we would like to contribute.
> Let us know what you think.
>
> The purpose of the suggested improvements is to enable "projects" to read
> MCA parameters from project specific locations. This enables the usage
> of OPAL and the MCA Frameworks outside the OpenMPI project without
> interfering with OpenMPI specific parameters and removes the need to
> patch OPAL (e.g., to pick up params from different locations).
>
> The possible scenarios would be the following:
>
> a) adding the option to pick up a project specific mca-param.conf file
> Example:
> $HOME/.mca/${project}-mca-param.conf
> and /etc/mca/${project}-mca-param.conf)
>
> b) add the option to pick up the mca-param.conf file from a project specific
> directory
> Example:
> $HOME/.${project}/mca-param.conf
> and /etc/${project}/mca-param.conf
> and/or /etc/${project}/${project}-mca-param.conf)
>
> c) prefixing the mca param with the project name in the existing
> mca-param.conf
> file and therefore following the new MCA variable system naming scheme.
> Example:
> mca_${project}_${framework}_${component}_${var_name}
>
> The implementation has to be compatible with the current system, that is,
> it should work as it does today without any added burden to the user. The
> suggested approach is to provide an addition to the MCA API (something like
> mca_base_add_config_file_path ()) to add lookup paths to the MCA system.
> This way additional files can be picked up for the MCA param parsing if
> needed.
>
> To wrap it up:
> 1) Is the motivation clear?
> 2) Is it possible to implement the desired capability within a
> reasonable time and without changing the current behavior?
> 3) Does it line up with the planning / future capabilities?
> 4) Which of the above options (A, B, C) would you prefer?
>
> --
> Swen Boehm | Email: bo...@ornl.gov
> Oak Ridge National Laboratory | Phone: +1 865-576-6125
>
>
> On Apr 26, 2013, at 7:50 PM, Thomas Naughton <naught...@ornl.gov> wrote:
>
>> Hi,
>>
>> Ok, sounds good. We'll check on this next week and get back to you.
>>
>> Thanks,
>> --tjn
>>
>> _________________________________________________________________________
>> Thomas Naughton naught...@ornl.gov
>> Research Associate (865) 576-4184
>>
>>
>> On Fri, 26 Apr 2013, Jeff Squyres (jsquyres) wrote:
>>
>>> Email would probably be easiest -- I will need to page in/refresh this area
>>> of the code, anyway, so if you guys do the initial homework and submit some
>>> ideas, that would probably be easiest (For me). :-D
>>>
>>>
>>> On Apr 26, 2013, at 6:33 PM, Thomas Naughton <naught...@ornl.gov>
>>> wrote:
>>>
>>>> Hi Jeff,
>>>>
>>>> We don't have one yet but we can code something up and submit a patch.
>>>>
>>>> If useful we could quickly sync up beforehand to ensure we are on the same
>>>> page. Phone or email, whatever would be easiest.
>>>>
>>>> What do you think?
>>>> --tjn
>>>>
>>>> _________________________________________________________________________
>>>> Thomas Naughton naught...@ornl.gov
>>>> Research Associate (865) 576-4184
>>>>
>>>>
>>>> On Fri, 26 Apr 2013, Jeff Squyres (jsquyres) wrote:
>>>>
>>>>> I'm not aware of any plans to do this.
>>>>>
>>>>> Do you guys have a patch to submit, perchance? :-D
>>>>>
>>>>>
>>>>> On Apr 22, 2013, at 6:30 PM, Thomas Naughton <naught...@ornl.gov> wrote:
>>>>>
>>>>>> Hi Nathan & Jeff,
>>>>>>
>>>>>> You guys have done some MCA updates lately and we were curious if there
>>>>>> are
>>>>>> any plans or thoughts about an enhancement regarding MCA param files.
>>>>>>
>>>>>> Briefly speaking, we were curious if there were plans for either having
>>>>>> project specific MCA param files, or having a generic mca param file that
>>>>>> would use the projects as part of the namespace. I think an example
>>>>>> would
>>>>>> help clarify.
>>>>>>
>>>>>> We currently change things to have "$HOME/.stci/mca-params.conf". This
>>>>>> is
>>>>>> pretty much the only remaining modification we have for OPAL after recent
>>>>>> updates. If there was a way to have something like
>>>>>> "$HOME/.${project}/mca-params.conf", or
>>>>>> "$HOME/.mca/${project}-mca-params.conf", it would remove this remaining
>>>>>> customization we do to OPAL.
>>>>>>
>>>>>> This sort of thing seems like it could be a useful if OPAL became
>>>>>> stand-alone in the future -- it seems like you guys might be moving that
>>>>>> way?
>>>>>>
>>>>>> We didn't know if you guys had plans for anything related to this and/or
>>>>>> if
>>>>>> you'd be receptive to changes to support something along this line.
>>>>>>
>>>>>> We would be very interested to get your comments/thoughts.
>>>>>>
>>>>>> Thanks,
>>>>>> --tjn
>>>>>>
>>>>>> _________________________________________________________________________
>>>>>> Thomas Naughton naught...@ornl.gov
>>>>>> Research Associate (865) 576-4184
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jeff Squyres
>>>>> jsquy...@cisco.com
>>>>> For corporate legal information go to:
>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Jeff Squyres
>>> jsquy...@cisco.com
>>> For corporate legal information go to:
>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>>
>>>
>
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
