Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: add STCI component to OMPI/RTE framework
From: Edgar Gabriel (gabriel_at_[hidden])
Date: 2014-05-27 16:13:01


not really, I stated my case, there is not much more to add. Its up to
the group to decide, and I am fine with any decision.

Edgar

On 5/27/2014 2:57 PM, Ralph Castain wrote:
> Forgot to add: would it help to discuss this over the phone instead?
>
>
> On May 27, 2014, at 12:56 PM, Ralph Castain <rhc_at_[hidden]
> <mailto:rhc_at_[hidden]>> wrote:
>
>>
>> On May 27, 2014, at 12:50 PM, Edgar Gabriel <gabriel_at_[hidden]
>> <mailto:gabriel_at_[hidden]>> wrote:
>>
>>>
>>>
>>> On 5/27/2014 2:46 PM, Ralph Castain wrote:
>>>>
>>>> On May 27, 2014, at 12:27 PM, Edgar Gabriel <gabriel_at_[hidden]
>>>> <mailto:gabriel_at_[hidden]>>
>>>> wrote:
>>>>
>>>>> I'll let ORNL talk about the STCI component itself (which might
>>>>> have additional reasons), but keeping the code in trunk vs. an
>>>>> outside github/mercurial repository has two advantages in my
>>>>> opinion: i) it simplifies the propagation of know-how between the
>>>>> groups,
>>>>
>>>> Afraid I don't understand that - this is just glue, right?
>>>
>>>
>>> yes, but its easier to look in one place vs. n places for every features.
>>>
>>>>> and ii) avoids having to keep a separate branch up to date. (We did
>>>>> the second part with OMPIO for a couple of years, and that was
>>>>> really painful).
>>>>
>>>> Ah, perhaps this is the "rub" - are you saying that you expect us to
>>>> propagate any changes in the RTE interface to your component? If so,
>>>> then that violates the original agreement about this framework. It
>>>> was solely to provide a point-of-interface for *external* groups to
>>>> connect their RTE's into OMPI. We agreed that we would notify people
>>>> of changes to that interface, and give them a chance to provide input
>>>> on those changes - but under no conditions were we wiling to accept
>>>> responsibility for maintaining those branch interfaces.
>>>>
>>>> Given that the interface is wholly contained in the ompi/rte
>>>> component, I guess I struggle to understand the code conflict issue.
>>>> There is no change in the OMPI code base that can possibly conflict
>>>> with your component. The only things that could impact you are
>>>> changes in the OMPI layer that require modification to your
>>>> component, which is something you'd have to do regardless. We will
>>>> not test nor update that component for you.
>>>
>>>
>>> no, not all. My point was that we invested enormous efforts at that time
>>> to just do the svn merge from the changes on trunk to our branch, that's
>>> all.
>>>
>>
>> If you are on a branch that contains an svn checkout of the trunk,
>> plus one component directory in one framework, then I'm afraid I
>> cannot understand how you get merge conflicts. I've been doing this
>> for years and haven't hit one yet. The only possible source of a
>> conflict is if I touch code that is common to the two repos - i.e.,
>> outside of the area that I'm adding. In this case, that should never
>> happen, yes?
>>
>> If it does, then you touched code outside your component, and you
>> either (a) are going to encounter this no matter what because you
>> haven't pushed it up yet, or (b) couldn't commit that up to the main
>> repo anyway if it impacted the RTE interface.
>>
>> Sorry, but I'm really struggling to understand how adding only this
>> one component, which you solely modify and control, can possibly help
>> with maintaining your branch.
>>
>>
>>> Thanks
>>> Edgar
>>>
>>>>
>>>>>
>>>>> In addition, IANAL, but I was actually wandering about the
>>>>> implications of using separate code repositories outside of ompi
>>>>> for sharing code, and whether that is truly still covered by the
>>>>> contributors agreement that we all signed.
>>>>
>>>> Of course not - OMPI's license only declares that anything you push
>>>> into the main OMPI code repo (and hence, our official releases) is
>>>> covered by that agreement. Anything you add or distribute externally
>>>> is on your own. You can *choose* to license that code in accordance
>>>> with the OMPI license, but you aren't *required* to do so.
>>>>
>>>>>
>>>>> Anyway, I don't have strong feelings either way as well, just would
>>>>> see a couple of advantages (for us) if the code was in the trunk.
>>>>
>>>> I'm still trying to understand those - sorry to be a pain, but my
>>>> biggest fear at this point is that the perceived advantage is based
>>>> on a misunderstanding, and I'd like to head that off before it causes
>>>> problems.
>>>>
>>>>>
>>>>> Thanks Edgar
>>>>>
>>>>> On 5/27/2014 1:45 PM, Ralph Castain wrote:
>>>>>> I think so long as we leave these components out of any release,
>>>>>> there is a limited potential for problems (probably most
>>>>>> importantly, we sidestep all the issues about syncing
>>>>>> releases!).
>>>>>>
>>>>>> However, that said, I'm not sure what it gains anyone to include
>>>>>> a component that *isn't* going in a release. Nobody outside your
>>>>>> organizations is going to build against it - so what did it
>>>>>> accomplish to push the code into the repo?
>>>>>>
>>>>>> Mind you, I'm not saying I'm staunchly opposed - just trying to
>>>>>> understand how it benefits anyone.
>>>>>>
>>>>>>
>>>>>> On May 27, 2014, at 11:28 AM, Edgar Gabriel <gabriel_at_[hidden]
>>>>>> <mailto:gabriel_at_[hidden]>>
>>>>>> wrote:
>>>>>>
>>>>>>> To through in my $0.02, I would see a benefit in adding the
>>>>>>> component to the trunk. As I mentioned in the last teleconf, we
>>>>>>> are currently working on adding support for the HPX runtime
>>>>>>> environment to Open MPI, and for various reasons (that I can
>>>>>>> explain if somebody is interested), we think at the moment that
>>>>>>> using the RTE abstraction layer could be easier for achieving
>>>>>>> what we want to do. That is not at all a judgment on ORTE, but
>>>>>>> a combination of what HPX offers and what we want to achieve
>>>>>>> within that project.
>>>>>>>
>>>>>>> I do not foresee at this point that our component would be
>>>>>>> production quality or part of an upcoming OMPI release, having
>>>>>>> however another component in the rte framework could be
>>>>>>> useful from our point of view. (And yes, the person that asked
>>>>>>> the pmi/rte question on the mailing list was my student who
>>>>>>> tried to make the pmi component work, and was confused about
>>>>>>> the fact that other emails said that the pmi stuff is working,
>>>>>>> while he couldn't even get it to compile :)
>>>>>>>
>>>>>>> Edgar
>>>>>>>
>>>>>>> On 5/27/2014 12:23 PM, Ralph Castain wrote:
>>>>>>>> I have mixed thoughts on this request. We have a policy of
>>>>>>>> only including things in the code base that are of general
>>>>>>>> utility - i.e., that should be generally distributed across
>>>>>>>> the community. This component is only applicable to ORNL, and
>>>>>>>> it would therefore seem more sensible to have it continue to
>>>>>>>> be maintained there.
>>>>>>>>
>>>>>>>> I'm unaware of anyone outside of ORNL that regularly tests
>>>>>>>> for ompi-rte abstraction violations, and I suspect that your
>>>>>>>> internal tests are the right place for catching them as
>>>>>>>> nobody else really seems to care. It isn't clear to me how
>>>>>>>> adding this component directly to the general code base
>>>>>>>> impacts that operation. The original PMI component in the
>>>>>>>> ompi/rte framework wasn't intended to provide an alternative
>>>>>>>> method for building OMPI - it was solely created to support
>>>>>>>> the development of that framework and had no intended utility
>>>>>>>> beyond that time (hence the RFC to remove it to avoid user
>>>>>>>> confusion as we just saw on the user mailing list).
>>>>>>>>
>>>>>>>>
>>>>>>>> On May 27, 2014, at 9:25 AM, Thomas Naughton
>>>>>>>> <naughtont_at_[hidden] <mailto:naughtont_at_[hidden]>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> WHAT: add new component to ompi/rte framework
>>>>>>>>>
>>>>>>>>> WHY: because it will simplify our maintenance & provide
>>>>>>>>> an alt. reference
>>>>>>>>>
>>>>>>>>> WHEN: no rush, soon-ish? (June 12?)
>>>>>>>>>
>>>>>>>>> This is a component we currently maintain outside of the
>>>>>>>>> ompi tree to support using OMPI with an alternate runtime
>>>>>>>>> system. This will also provide an alternate component to
>>>>>>>>> ORTE, which was motivation for PMI component in related
>>>>>>>>> RFC. We build/test nightly and it occasionally catches
>>>>>>>>> ompi-rte abstraction violations, etc.
>>>>>>>>>
>>>>>>>>> Thomas
>>>>>>>>>
>>>>>>>>> _________________________________________________________________________
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>
>>>>>>>>>
>>> Thomas Naughton
>>> naughtont_at_[hidden]
>>> <mailto:naughtont_at_[hidden]>
>>>>>>>>> Research Associate (865)
>>>>>>>>> 576-4184
>>>>>>>>>
>>>>>>>>> _______________________________________________ devel
>>>>>>>>> mailing list devel_at_[hidden]
>>>>>>>>> <mailto:devel_at_[hidden]> Subscription:
>>>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel Link to
>>>>>>>>> this post:
>>>>>>>>> http://www.open-mpi.org/community/lists/devel/2014/05/14852.php
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>
>>>>>>>>>
>>> _______________________________________________ devel mailing list
>>>>>>>> devel_at_[hidden] <mailto:devel_at_[hidden]> Subscription:
>>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel Link to
>>>>>>>> this post:
>>>>>>>> http://www.open-mpi.org/community/lists/devel/2014/05/14854.php
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>> -- Edgar Gabriel Associate Professor Parallel Software Technologies
>>>>>>> Lab http://pstl.cs.uh.edu
>>>>>>> <http://pstl.cs.uh.edu/> Department of Computer Science
>>>>>>> University of Houston Philip G. Hoffman Hall, Room 524 Houston,
>>>>>>> TX-77204, USA Tel: +1 (713) 743-3857 Fax: +1
>>>>>>> (713) 743-3335
>>>>>>>
>>>>>>> _______________________________________________ devel mailing
>>>>>>> list devel_at_[hidden] <mailto:devel_at_[hidden]> Subscription:
>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel Link to
>>>>>>> this post:
>>>>>>> http://www.open-mpi.org/community/lists/devel/2014/05/14856.php
>>>>>>
>>>>>>
>>>>>>>
>>> _______________________________________________ devel mailing list
>>>>>> devel_at_[hidden] <mailto:devel_at_[hidden]> Subscription:
>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel Link to this
>>>>>> post:
>>>>>> http://www.open-mpi.org/community/lists/devel/2014/05/14857.php
>>>>>>
>>>>>
>>>>> -- Edgar Gabriel Associate Professor Parallel Software Technologies
>>>>> Lab http://pstl.cs.uh.edu <http://pstl.cs.uh.edu/> Department
>>>>> of Computer Science
>>>>> University of Houston Philip G. Hoffman Hall, Room 524
>>>>> Houston, TX-77204, USA Tel: +1 (713) 743-3857 Fax:
>>>>> +1 (713) 743-3335
>>>>>
>>>>> _______________________________________________ devel mailing list
>>>>> devel_at_[hidden] <mailto:devel_at_[hidden]> Subscription:
>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel Link to this
>>>>> post:
>>>>> http://www.open-mpi.org/community/lists/devel/2014/05/14858.php
>>>>
>>>> _______________________________________________ devel mailing list
>>>> devel_at_[hidden] <mailto:devel_at_[hidden]> Subscription:
>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel Link to this post:
>>>> http://www.open-mpi.org/community/lists/devel/2014/05/14859.php
>>>>
>>>
>>> --
>>> Edgar Gabriel
>>> Associate Professor
>>> Parallel Software Technologies Lab http://pstl.cs.uh.edu
>>> <http://pstl.cs.uh.edu/>
>>> Department of Computer Science University of Houston
>>> Philip G. Hoffman Hall, Room 524 Houston, TX-77204, USA
>>> Tel: +1 (713) 743-3857 Fax: +1 (713) 743-3335
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel_at_[hidden] <mailto:devel_at_[hidden]>
>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>> Link to this
>>> post: http://www.open-mpi.org/community/lists/devel/2014/05/14860.php
>
>
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: http://www.open-mpi.org/community/lists/devel/2014/05/14863.php
>

-- 
Edgar Gabriel
Associate Professor
Parallel Software Technologies Lab      http://pstl.cs.uh.edu
Department of Computer Science          University of Houston
Philip G. Hoffman Hall, Room 524        Houston, TX-77204, USA
Tel: +1 (713) 743-3857                  Fax: +1 (713) 743-3335