Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] Q: project based MCA param files
From: Thomas Naughton (naughtont_at_[hidden])
Date: 2013-05-07 14:44:13


Hi,

Ok, looks like this may just do the trick. We briefly discussed this today
and probably can change our use case to make use of this mechanism instead
and avoid any further enhancments.

  Question: If you do a setenv for this MCA param, does that extend the
            default search path? Or does it replace/override the default?

Thanks Jeff for forwarding info to devel list to get broader feedback, and
to Ralph for providing the suggestion.

--tjn

  _________________________________________________________________________
   Thomas Naughton naughtont_at_[hidden]
   Research Associate (865) 576-4184

On Tue, 7 May 2013, Ralph Castain wrote:

> I believe we already have a way of defining where to get the default mca params:
>
> ret = mca_base_var_register ("opal", "mca", "base", "param_files", "Path for MCA "
> "configuration files containing variable values",
> MCA_BASE_VAR_TYPE_STRING, NULL, 0, 0, OPAL_INFO_LVL_2,
> MCA_BASE_VAR_SCOPE_READONLY, &mca_base_var_files);
>
>
> So wouldn't it be as easy as defining an envar? It's what we did when using the OMPI code with ORCM a couple of years ago, and we used it again for a recent project in Greenplum where the default mca param was specified in a different location than usual.
>
>
> On May 7, 2013, at 6:28 AM, Jeff Squyres (jsquyres) <jsquyres_at_[hidden]> wrote:
>
>> 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" <bohms_at_[hidden]>
>>> Subject: Re: Q: project based MCA param files
>>> Date: May 3, 2013 5:03:43 PM EDT
>>> To: "Jeff Squyres (jsquyres)" <jsquyres_at_[hidden]>
>>> Cc: Nathan Hjelm <hjelmn_at_[hidden]>, "Vallee, Geoffroy R." <valleegr_at_[hidden]>, "Naughton III, Thomas J." <naughtont_at_[hidden]>
>>>
>>> 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: bohms_at_[hidden]
>>> Oak Ridge National Laboratory | Phone: +1 865-576-6125
>>>
>>>
>>> On Apr 26, 2013, at 7:50 PM, Thomas Naughton <naughtont_at_[hidden]> wrote:
>>>
>>>> Hi,
>>>>
>>>> Ok, sounds good. We'll check on this next week and get back to you.
>>>>
>>>> Thanks,
>>>> --tjn
>>>>
>>>> _________________________________________________________________________
>>>> Thomas Naughton naughtont_at_[hidden]
>>>> 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 <naughtont_at_[hidden]>
>>>>> 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 naughtont_at_[hidden]
>>>>>> 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 <naughtont_at_[hidden]> 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 naughtont_at_[hidden]
>>>>>>>> Research Associate (865) 576-4184
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jeff Squyres
>>>>>>> jsquyres_at_[hidden]
>>>>>>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jeff Squyres
>>>>> jsquyres_at_[hidden]
>>>>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
>>>>>
>>>>>
>>>
>>
>>
>> --
>> Jeff Squyres
>> jsquyres_at_[hidden]
>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>