Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] v1.3 RM: need a ruling
From: Terry Dontje (Terry.Dontje_at_[hidden])
Date: 2008-07-11 10:26:28


Ralph H Castain wrote:
>
> On 7/11/08 7:48 AM, "Terry Dontje" <Terry.Dontje_at_[hidden]> wrote:
>
>
>> Jeff Squyres wrote:
>>
>>> Check that -- Ralph and I talked more about #1383 and have come up
>>> with a decent/better solution that a) is not wonky and b) does not
>>> involve MCA parameter synonyms. We're working on it in an hg and will
>>> put it back when done (probably within a business day or three).
>>>
>>> So I think the MCA synonym stuff *isn't* needed for v1.3 after all.
>>>
>>>
>> I am not dead yet!!!
>>
>> So, there was also the name change of pls_rsh_agent to plm_rsh_agent
>> because the pls's were sucked into plm's (or so I believe). Anyways,
>> this seems like another case to support synonyms. Also are there other
>> pls mca parameters that have had their names changed to plm?
>>
>
> I think you're opening a really ugly can of worms. How far back do you want
> to go? v1.0? v0.1? We have a history of changing mca param names across
> major releases, so trying to keep everything alive could well become a
> nightmare.
>
>
I am only asking to be compatible with the last release (however that
might have an interpretation of inifinity :-). Seriously, though I
think we need to be very careful about renaming mca parameters because
this will screw production sites and ISV's which use scripts to launch
their apps. So a change could render their scripts useless (the
paffinity param is a perfect example of this).

I don't really want to promote keeping everything alive forever but in
cases where the only change is a 3-4 letter prefix it almost looks
random to people outside of the community.

> I would hate to try and figure out all the changes - and what about the
> params that simply have disappeared, or had their functionality absorbed by
> some combination of other params?
>
>
So, I think if a functionality is not supported or the way you drive it
is completely different then I agree with you trying to support a round
peg to fit in a square hole is silly. But if the feature is one for one
except in name only then I think we need to ask ourselves if we really
want/need to drop the original name.
> My head aches already... :-)
>
>
Take two aspirins...

--td
> Ralph
>
>
>> --td
>>
>>> I think the MCA param synonyms and "deprecated" stuff is useful for
>>> the future, but at this point, nothing in v1.3 would use it. So my
>>> $0.02 is that we should leave it out.
>>>
>>>
>>>
>>> On Jul 10, 2008, at 2:00 PM, Jeff Squyres (jsquyres) wrote:
>>>
>>>
>>>> K, will do. Note that it turns out that we did not yet solve the
>>>> mpi_paffinity_alone issue, but we're working on it. I'm working on
>>>> the IOF issue ATM; will return to mpi_paffinity_alone in a bit...
>>>>
>>>>
>>>> On Jul 10, 2008, at 1:56 PM, George Bosilca wrote:
>>>>
>>>>
>>>>> I'm 100% with Brad on this. Please go ahead and include this feature
>>>>> in the 1.3.
>>>>>
>>>>> george.
>>>>>
>>>>> On Jul 10, 2008, at 11:33 AM, Brad Benton wrote:
>>>>>
>>>>>
>>>>>> I think this is very reasonable to go ahead and include for 1.3. I
>>>>>> find that preferable to a 1.3-specific "wonky" workaround. Plus,
>>>>>> this sounds like something that is very good to have in general.
>>>>>>
>>>>>> --brad
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 9, 2008 at 8:49 PM, Jeff Squyres <jsquyres_at_[hidden]>
>>>>>> wrote:
>>>>>> v1.3 RMs: Due to some recent work, the MCA parameter
>>>>>> mpi_paffinity_alone disappeared -- it was moved and renamed to be
>>>>>> opal_paffinity_alone. This is Bad because we have a lot of
>>>>>> historical precent based on the MCA param name
>>>>>> "mpi_paffinity_alone" (FAQ, PPT presentations, e-mails on public
>>>>>> lists, etc.). So it needed to be restored for v1.3. I just
>>>>>> noticed that I hadn't opened a ticket on this -- sorry -- I opened
>>>>>> #1383 tonight.
>>>>>>
>>>>>> For a variety of reasons described in the commit message r1383,
>>>>>> Lenny and I first decided that it would be best to fix this problem
>>>>>> by the functionality committed in r18770 (have the ability to find
>>>>>> out where an MCA parameter was set). This would allow us to
>>>>>> register two MCA params: mpi_paffinity_alone and
>>>>>> opal_paffinity_alone, and generally do the Right Thing (because we
>>>>>> could then tell if a user had set a value or whether it was a
>>>>>> default MCA param value). This functionality will also be useful
>>>>>> in the openib BTL, where there is a blend of MCA parameters and INI
>>>>>> file parameters.
>>>>>>
>>>>>> However, after doing that, it seemed like only a few more steps to
>>>>>> implement an overall better solution: implement "synonyms" for MCA
>>>>>> parameters. I.e., register the name "mpi_paffinity_alone" as a
>>>>>> synonym for opal_paffinity_alone. Along the way, it was trivial to
>>>>>> add a "deprecated" flag for MCA parameters that we no longer want
>>>>>> to use anymore (this deprecated flag is also useful in the OB1 PML
>>>>>> and openib BTL).
>>>>>>
>>>>>> So to fix a problem that needed to be fixed for v1.3 (restore the
>>>>>> MCA parameter "mpi_paffinity_alone"), I ended up implementing new
>>>>>> functionality.
>>>>>>
>>>>>> Can this go into v1.3, or do we need to implement some kind of
>>>>>> alternate fix? (I admit to not having thought through what it
>>>>>> would take to fix without the new MCA parameter functionality -- it
>>>>>> might be kinda wonky)
>>>>>>
>>>>>> --
>>>>>> Jeff Squyres
>>>>>> Cisco Systems
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>> _______________________________________________
>>>>> devel mailing list
>>>>> devel_at_[hidden]
>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>>>
>>>> --
>>>> Jeff Squyres
>>>> Cisco Systems
>>>>
>>>> _______________________________________________
>>>> 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
>>
>
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>