date:20180608

[OMPI devel] ARM failure on PR to master

2018-06-08 Thread r...@open-mpi.org

Can someone who knows/cares about ARM perhaps take a look at PR 
https://github.com/open-mpi/ompi/pull/5247 
? I’m hitting an error in the ARM 
CI tests that I can’t understand:

--> Running example: hello_c
--
Failed to create a completion queue (CQ):

Hostname: juno001
Requested CQE: 16384
Error:Cannot allocate memory

Check the CQE attribute.
--
--
Open MPI has detected that there are UD-capable Verbs devices on your
system, but none of them were able to be setup properly.  This may
indicate a problem on this system.

You job will continue, but Open MPI will ignore the "ud" oob component
in this run.

Hostname: juno001
--
vsetenv PMIX_SERVER_TMPDIR failed
vsetenv PMIX_SERVER_TMPDIR failed
vsetenv PMIX_SERVER_TMPDIR failed
vsetenv PMIX_SERVER_TMPDIR failed

I get the UD error - that has been around for years since nobody seems to care 
about or maintain the ud/oob component. What I don’t understand is why setting 
an envar would fail solely in the ARM environment.

Could someone maybe at least provide a hint as to what is going on?

Thanks
Ralph

___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] Shared object dependencies

2018-06-08 Thread Gabriel, Edgar

I wanted to add one item before I forget (although I agree with what Jeff 
said): The error messages shown reminds me of the problem that we had with 
ompio  in 1.8/1.10 series when the RTLD_GLOBAL  option was not correctly set. 
However, that was fixed in the 2.0 series and going forward, so if that shows 
up with later releases, it might an indication of something else.

Edgar 

> -Original Message-
> From: devel [mailto:devel-boun...@lists.open-mpi.org] On Behalf Of Jeff
> Squyres (jsquyres) via devel
> Sent: Friday, June 8, 2018 4:54 PM
> To: Open MPI Developers List 
> Cc: Jeff Squyres (jsquyres) 
> Subject: Re: [OMPI devel] Shared object dependencies
> 
> Before digging any deeper, did you perchance install multiple versions of Open
> MPI into the same prefix?
> 
> If so, remember that Open MPI installs lots of plugins.  The exact set of 
> plugins
> changes every release.  So if you install version A.B.C in to /opt/openmpi, 
> and
> then install version X.Y.Z in to /opt/openmpi, note that the installation of 
> X.Y.Z
> did not *uninstall* A.B.C first.  Hence, you might still have some stale A.B.C
> components in the tree that Open MPI X.Y.Z may try to open.  Since the
> underlying libraries that these plugins use have now been upgraded to X.Y.Z,
> the stale A.B.C component may (and likely will) fail to open.
> 
> If that's not what is happening, let us know and we can dig deeper.
> 
> 
> > On Jun 8, 2018, at 5:37 PM, Tyson Whitehead 
> wrote:
> >
> > This email starts out talking about version 1.10.7 to give a complete
> > picture.  I tested 2.1.3 as well, it also exhibits this issue,
> > although to a lesser extent though, and am asking for help on that
> > release.
> >
> > I was compiling the OpenMPI 1.10.7 shipped with NixOS against a newer
> > libibverbs with a large set of drivers and get some strange errors
> > when when running opmi_info (I've replaced the common prefix
> > /nix/store/9zm0pqsh67fw0xi5cpnybnd7hgzryffs-openmpi-1.10.7 with ...)
> >
> > [mon241:04077] mca: base: component_find: unable to open
> > .../lib/openmpi/mca_btl_openib: .../lib/openmpi/mca_btl_openib.so:
> > undefined symbol: mca_mpool_grdma_evict (ignored) [mon241:04077] mca:
> > base: component_find: unable to open
> > .../lib/openmpi/mca_fcoll_individual:
> > .../lib/openmpi/mca_fcoll_individual.so: undefined symbol:
> > mca_io_ompio_file_write (ignored)
> > [mon241:04077] mca: base: component_find: unable to open
> > .../lib/openmpi/mca_fcoll_ylib: .../lib/openmpi/mca_fcoll_ylib.so:
> > undefined symbol: ompi_io_ompio_scatter_data (ignored) [mon241:04077]
> > mca: base: component_find: unable to open
> > .../lib/openmpi/mca_fcoll_dynamic:
> > .../lib/openmpi/mca_fcoll_dynamic.so: undefined symbol:
> > ompi_io_ompio_allgatherv_array (ignored) [mon241:04077] mca: base:
> > component_find: unable to open
> > .../lib/openmpi/mca_fcoll_two_phase:
> > .../lib/openmpi/mca_fcoll_two_phase.so: undefined symbol:
> > ompi_io_ompio_set_aggregator_props (ignored) [mon241:04077] mca: base:
> > component_find: unable to open
> > .../lib/openmpi/mca_fcoll_static: .../lib/openmpi/mca_fcoll_static.so:
> > undefined symbol: ompi_io_ompio_allgather_array (ignored)
> > Package: Open MPI nixbld@ Distribution
> >   Open MPI: 1.10.7
> > Open MPI repo revision: v1.10.6-48-g5e373bf  Open MPI release date:
> > May 16, 2017
> >   Open RTE: 1.10.7
> > Open RTE repo revision: v1.10.6-48-g5e373bf  Open RTE release date:
> > May 16, 2017
> >   OPAL: 1.10.7
> > OPAL repo revision: v1.10.6-48-g5e373bf
> >  OPAL release date: May 16, 2017
> > ...
> >
> > I dug into the first of these (figured out what library provided it,
> > looked at the declared dependencies, poked around in the automake
> > file) , and, as far as I could determine, it seems that
> > mca_btl_openib.so simply isn't linked to list mca_mpool_grdma.so
> > (which provides the symbol) as a dependency.
> >
> > Seeing as 1.10.7 is no longer supported.  I figured I would try 2.1.3
> > in case this has been fixed.  I compiled it up as well, and it seems
> > all but the mca_fcoll_individual one have been resolved (I've replaced
> > /nix/store/4kh0zbn8pmdqhvwagicswg70rwnpm570-openmpi-2.1.3 with ...)
> >
> > [mon241:05544] mca_base_component_repository_open: unable to open
> > mca_fcoll_individual: .../lib/openmpi/mca_fcoll_individual.so:
> > undefined symbol: ompio_io_ompio_file_read (ignored)
> > Package: Open MPI nixbld@ Distribution
> >   Open MPI: 2.1.3
> > Open MPI repo revision: v2.1.2-129-gcfd8f3f  Open MPI release date:
> > Mar 13, 2018
> >   Open RTE: 2.1.3
> > Open RTE repo revision: v2.1.2-129-gcfd8f3f  Open RTE release date:
> > Mar 13, 2018
> >   OPAL: 2.1.3
> > OPAL repo revision: v2.1.2-129-gcfd8f3f
> >  OPAL release date: Mar 13, 2018
> > ...
> >
> > Again I was able to find this symbol in the mca_io_ompio.so library.
> > I looked through the

Re: [OMPI devel] Shared object dependencies

2018-06-08 Thread gilles

Assuming this is a fresh install, and at first glance, there is an 
abstraction violation here

fcoll/individual should not directly call a function of io/ompio

NixOS linker might be very strict and that could explain why this 
mistake was unnoticed until now.

Would you mind giving the latest Open MPI 3.1 a try ?

Cheers,

Gilles

- Original Message -
> Before digging any deeper, did you perchance install multiple versions 
of Open MPI into the same prefix?
> 
> If so, remember that Open MPI installs lots of plugins.  The exact set 
of plugins changes every release.  So if you install version A.B.C in to 
/opt/openmpi, and then install version X.Y.Z in to /opt/openmpi, note 
that the installation of X.Y.Z did not *uninstall* A.B.C first.  Hence, 
you might still have some stale A.B.C components in the tree that Open 
MPI X.Y.Z may try to open.  Since the underlying libraries that these 
plugins use have now been upgraded to X.Y.Z, the stale A.B.C component 
may (and likely will) fail to open.
> 
> If that's not what is happening, let us know and we can dig deeper.
> 
> 
> > On Jun 8, 2018, at 5:37 PM, Tyson Whitehead  
wrote:
> > 
> > This email starts out talking about version 1.10.7 to give a 
complete
> > picture.  I tested 2.1.3 as well, it also exhibits this issue,
> > although to a lesser extent though, and am asking for help on that
> > release.
> > 
> > I was compiling the OpenMPI 1.10.7 shipped with NixOS against a 
newer
> > libibverbs with a large set of drivers and get some strange errors
> > when when running opmi_info (I've replaced the common prefix
> > /nix/store/9zm0pqsh67fw0xi5cpnybnd7hgzryffs-openmpi-1.10.7 with ...)
> > 
> > [mon241:04077] mca: base: component_find: unable to open
> > .../lib/openmpi/mca_btl_openib: .../lib/openmpi/mca_btl_openib.so:
> > undefined symbol: mca_mpool_grdma_evict (ignored)
> > [mon241:04077] mca: base: component_find: unable to open
> > .../lib/openmpi/mca_fcoll_individual:
> > .../lib/openmpi/mca_fcoll_individual.so: undefined symbol:
> > mca_io_ompio_file_write (ignored)
> > [mon241:04077] mca: base: component_find: unable to open
> > .../lib/openmpi/mca_fcoll_ylib: .../lib/openmpi/mca_fcoll_ylib.so:
> > undefined symbol: ompi_io_ompio_scatter_data (ignored)
> > [mon241:04077] mca: base: component_find: unable to open
> > .../lib/openmpi/mca_fcoll_dynamic:
> > .../lib/openmpi/mca_fcoll_dynamic.so: undefined symbol:
> > ompi_io_ompio_allgatherv_array (ignored)
> > [mon241:04077] mca: base: component_find: unable to open
> > .../lib/openmpi/mca_fcoll_two_phase:
> > .../lib/openmpi/mca_fcoll_two_phase.so: undefined symbol:
> > ompi_io_ompio_set_aggregator_props (ignored)
> > [mon241:04077] mca: base: component_find: unable to open
> > .../lib/openmpi/mca_fcoll_static: .../lib/openmpi/mca_fcoll_static.
so:
> > undefined symbol: ompi_io_ompio_allgather_array (ignored)
> > Package: Open MPI nixbld@ Distribution
> >   Open MPI: 1.10.7
> > Open MPI repo revision: v1.10.6-48-g5e373bf
> >  Open MPI release date: May 16, 2017
> >   Open RTE: 1.10.7
> > Open RTE repo revision: v1.10.6-48-g5e373bf
> >  Open RTE release date: May 16, 2017
> >   OPAL: 1.10.7
> > OPAL repo revision: v1.10.6-48-g5e373bf
> >  OPAL release date: May 16, 2017
> > ...
> > 
> > I dug into the first of these (figured out what library provided it,
> > looked at the declared dependencies, poked around in the automake
> > file) , and, as far as I could determine, it seems that
> > mca_btl_openib.so simply isn't linked to list mca_mpool_grdma.so
> > (which provides the symbol) as a dependency.
> > 
> > Seeing as 1.10.7 is no longer supported.  I figured I would try 2.1.
3
> > in case this has been fixed.  I compiled it up as well, and it seems
> > all but the mca_fcoll_individual one have been resolved (I've 
replaced
> > /nix/store/4kh0zbn8pmdqhvwagicswg70rwnpm570-openmpi-2.1.3 with ...)
> > 
> > [mon241:05544] mca_base_component_repository_open: unable to open
> > mca_fcoll_individual: .../lib/openmpi/mca_fcoll_individual.so:
> > undefined symbol: ompio_io_ompio_file_read (ignored)
> > Package: Open MPI nixbld@ Distribution
> >   Open MPI: 2.1.3
> > Open MPI repo revision: v2.1.2-129-gcfd8f3f
> >  Open MPI release date: Mar 13, 2018
> >   Open RTE: 2.1.3
> > Open RTE repo revision: v2.1.2-129-gcfd8f3f
> >  Open RTE release date: Mar 13, 2018
> >   OPAL: 2.1.3
> > OPAL repo revision: v2.1.2-129-gcfd8f3f
> >  OPAL release date: Mar 13, 2018
> > ...
> > 
> > Again I was able to find this symbol in the mca_io_ompio.so library.
> > I looked through the source again, and it seems pretty clear that 
the
> > function is indeed called, but the library isn't linked to list the
> > mca_io_ompio.so library as a dependency
> > 
> > Looking through the various shared libraries in the .../lib/openmpi
> > directory though, and it seems none of them have dependencies on 
each

Re: [OMPI devel] Shared object dependencies

2018-06-08 Thread Jeff Squyres (jsquyres) via devel

Before digging any deeper, did you perchance install multiple versions of Open 
MPI into the same prefix?

If so, remember that Open MPI installs lots of plugins.  The exact set of 
plugins changes every release.  So if you install version A.B.C in to 
/opt/openmpi, and then install version X.Y.Z in to /opt/openmpi, note that the 
installation of X.Y.Z did not *uninstall* A.B.C first.  Hence, you might still 
have some stale A.B.C components in the tree that Open MPI X.Y.Z may try to 
open.  Since the underlying libraries that these plugins use have now been 
upgraded to X.Y.Z, the stale A.B.C component may (and likely will) fail to open.

If that's not what is happening, let us know and we can dig deeper.


> On Jun 8, 2018, at 5:37 PM, Tyson Whitehead  wrote:
> 
> This email starts out talking about version 1.10.7 to give a complete
> picture.  I tested 2.1.3 as well, it also exhibits this issue,
> although to a lesser extent though, and am asking for help on that
> release.
> 
> I was compiling the OpenMPI 1.10.7 shipped with NixOS against a newer
> libibverbs with a large set of drivers and get some strange errors
> when when running opmi_info (I've replaced the common prefix
> /nix/store/9zm0pqsh67fw0xi5cpnybnd7hgzryffs-openmpi-1.10.7 with ...)
> 
> [mon241:04077] mca: base: component_find: unable to open
> .../lib/openmpi/mca_btl_openib: .../lib/openmpi/mca_btl_openib.so:
> undefined symbol: mca_mpool_grdma_evict (ignored)
> [mon241:04077] mca: base: component_find: unable to open
> .../lib/openmpi/mca_fcoll_individual:
> .../lib/openmpi/mca_fcoll_individual.so: undefined symbol:
> mca_io_ompio_file_write (ignored)
> [mon241:04077] mca: base: component_find: unable to open
> .../lib/openmpi/mca_fcoll_ylib: .../lib/openmpi/mca_fcoll_ylib.so:
> undefined symbol: ompi_io_ompio_scatter_data (ignored)
> [mon241:04077] mca: base: component_find: unable to open
> .../lib/openmpi/mca_fcoll_dynamic:
> .../lib/openmpi/mca_fcoll_dynamic.so: undefined symbol:
> ompi_io_ompio_allgatherv_array (ignored)
> [mon241:04077] mca: base: component_find: unable to open
> .../lib/openmpi/mca_fcoll_two_phase:
> .../lib/openmpi/mca_fcoll_two_phase.so: undefined symbol:
> ompi_io_ompio_set_aggregator_props (ignored)
> [mon241:04077] mca: base: component_find: unable to open
> .../lib/openmpi/mca_fcoll_static: .../lib/openmpi/mca_fcoll_static.so:
> undefined symbol: ompi_io_ompio_allgather_array (ignored)
> Package: Open MPI nixbld@ Distribution
>   Open MPI: 1.10.7
> Open MPI repo revision: v1.10.6-48-g5e373bf
>  Open MPI release date: May 16, 2017
>   Open RTE: 1.10.7
> Open RTE repo revision: v1.10.6-48-g5e373bf
>  Open RTE release date: May 16, 2017
>   OPAL: 1.10.7
> OPAL repo revision: v1.10.6-48-g5e373bf
>  OPAL release date: May 16, 2017
> ...
> 
> I dug into the first of these (figured out what library provided it,
> looked at the declared dependencies, poked around in the automake
> file) , and, as far as I could determine, it seems that
> mca_btl_openib.so simply isn't linked to list mca_mpool_grdma.so
> (which provides the symbol) as a dependency.
> 
> Seeing as 1.10.7 is no longer supported.  I figured I would try 2.1.3
> in case this has been fixed.  I compiled it up as well, and it seems
> all but the mca_fcoll_individual one have been resolved (I've replaced
> /nix/store/4kh0zbn8pmdqhvwagicswg70rwnpm570-openmpi-2.1.3 with ...)
> 
> [mon241:05544] mca_base_component_repository_open: unable to open
> mca_fcoll_individual: .../lib/openmpi/mca_fcoll_individual.so:
> undefined symbol: ompio_io_ompio_file_read (ignored)
> Package: Open MPI nixbld@ Distribution
>   Open MPI: 2.1.3
> Open MPI repo revision: v2.1.2-129-gcfd8f3f
>  Open MPI release date: Mar 13, 2018
>   Open RTE: 2.1.3
> Open RTE repo revision: v2.1.2-129-gcfd8f3f
>  Open RTE release date: Mar 13, 2018
>   OPAL: 2.1.3
> OPAL repo revision: v2.1.2-129-gcfd8f3f
>  OPAL release date: Mar 13, 2018
> ...
> 
> Again I was able to find this symbol in the mca_io_ompio.so library.
> I looked through the source again, and it seems pretty clear that the
> function is indeed called, but the library isn't linked to list the
> mca_io_ompio.so library as a dependency
> 
> Looking through the various shared libraries in the .../lib/openmpi
> directory though, and it seems none of them have dependencies on each
> other.  How is this suppose to work?  Is the component library just
> suppose to load everything so all symbols get resolved?  Is the above
> error I'm seeing an error then?
> 
> Any insight would be appreciated.
> 
> Thanks!  -Tyson
> 
> PS:  Please note that the openmpi code was compiled without any
> patches and without any special configure flags other than
> --prefix= (NixOS also adds --diasble-static and
> --disable-dependency-tracking by default, but I removed those, it
> didn't make a difference)..
>

[OMPI devel] Shared object dependencies

2018-06-08 Thread Tyson Whitehead

This email starts out talking about version 1.10.7 to give a complete
picture.  I tested 2.1.3 as well, it also exhibits this issue,
although to a lesser extent though, and am asking for help on that
release.

I was compiling the OpenMPI 1.10.7 shipped with NixOS against a newer
libibverbs with a large set of drivers and get some strange errors
when when running opmi_info (I've replaced the common prefix
/nix/store/9zm0pqsh67fw0xi5cpnybnd7hgzryffs-openmpi-1.10.7 with ...)

[mon241:04077] mca: base: component_find: unable to open
.../lib/openmpi/mca_btl_openib: .../lib/openmpi/mca_btl_openib.so:
undefined symbol: mca_mpool_grdma_evict (ignored)
[mon241:04077] mca: base: component_find: unable to open
.../lib/openmpi/mca_fcoll_individual:
.../lib/openmpi/mca_fcoll_individual.so: undefined symbol:
mca_io_ompio_file_write (ignored)
[mon241:04077] mca: base: component_find: unable to open
.../lib/openmpi/mca_fcoll_ylib: .../lib/openmpi/mca_fcoll_ylib.so:
undefined symbol: ompi_io_ompio_scatter_data (ignored)
[mon241:04077] mca: base: component_find: unable to open
.../lib/openmpi/mca_fcoll_dynamic:
.../lib/openmpi/mca_fcoll_dynamic.so: undefined symbol:
ompi_io_ompio_allgatherv_array (ignored)
[mon241:04077] mca: base: component_find: unable to open
.../lib/openmpi/mca_fcoll_two_phase:
.../lib/openmpi/mca_fcoll_two_phase.so: undefined symbol:
ompi_io_ompio_set_aggregator_props (ignored)
[mon241:04077] mca: base: component_find: unable to open
.../lib/openmpi/mca_fcoll_static: .../lib/openmpi/mca_fcoll_static.so:
undefined symbol: ompi_io_ompio_allgather_array (ignored)
 Package: Open MPI nixbld@ Distribution
   Open MPI: 1.10.7
 Open MPI repo revision: v1.10.6-48-g5e373bf
  Open MPI release date: May 16, 2017
   Open RTE: 1.10.7
 Open RTE repo revision: v1.10.6-48-g5e373bf
  Open RTE release date: May 16, 2017
   OPAL: 1.10.7
 OPAL repo revision: v1.10.6-48-g5e373bf
  OPAL release date: May 16, 2017
...

I dug into the first of these (figured out what library provided it,
looked at the declared dependencies, poked around in the automake
file) , and, as far as I could determine, it seems that
mca_btl_openib.so simply isn't linked to list mca_mpool_grdma.so
(which provides the symbol) as a dependency.

Seeing as 1.10.7 is no longer supported.  I figured I would try 2.1.3
in case this has been fixed.  I compiled it up as well, and it seems
all but the mca_fcoll_individual one have been resolved (I've replaced
/nix/store/4kh0zbn8pmdqhvwagicswg70rwnpm570-openmpi-2.1.3 with ...)

[mon241:05544] mca_base_component_repository_open: unable to open
mca_fcoll_individual: .../lib/openmpi/mca_fcoll_individual.so:
undefined symbol: ompio_io_ompio_file_read (ignored)
 Package: Open MPI nixbld@ Distribution
   Open MPI: 2.1.3
 Open MPI repo revision: v2.1.2-129-gcfd8f3f
  Open MPI release date: Mar 13, 2018
   Open RTE: 2.1.3
 Open RTE repo revision: v2.1.2-129-gcfd8f3f
  Open RTE release date: Mar 13, 2018
   OPAL: 2.1.3
 OPAL repo revision: v2.1.2-129-gcfd8f3f
  OPAL release date: Mar 13, 2018
...

Again I was able to find this symbol in the mca_io_ompio.so library.
I looked through the source again, and it seems pretty clear that the
function is indeed called, but the library isn't linked to list the
mca_io_ompio.so library as a dependency

Looking through the various shared libraries in the .../lib/openmpi
directory though, and it seems none of them have dependencies on each
other.  How is this suppose to work?  Is the component library just
suppose to load everything so all symbols get resolved?  Is the above
error I'm seeing an error then?

Any insight would be appreciated.

Thanks!  -Tyson

PS:  Please note that the openmpi code was compiled without any
patches and without any special configure flags other than
--prefix= (NixOS also adds --diasble-static and
--disable-dependency-tracking by default, but I removed those, it
didn't make a difference)..
___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] Running on Kubernetes

2018-06-08 Thread Rong Ou

Thanks Ralph! I created an issue to track this:
https://github.com/kubeflow/mpi-operator/issues/12.

On Mon, May 28, 2018 at 5:25 AM r...@open-mpi.org  wrote:

> One suggestion: this approach requires that the job be executed using
> “mpirun”. Another approach would be to integrate PMIx into Kubernetes, thus
> allowing any job to call MPI_Init regardless of how it was started. The
> advantage would be that it enables the use of MPI by workflow-based
> applications that really aren’t supported by mpirun and require their own
> application manager.
>
> See https://pmix.org for more info
>
> Ralph
>
>
> On May 24, 2018, at 9:02 PM, Rong Ou  wrote:
>
> Hi guys,
>
> Thanks for all the suggestions! It's been a while but we finally got it
> approved for open sourcing. I've submitted a proposal to kubeflow:
> https://github.com/kubeflow/community/blob/master/proposals/mpi-operator-proposal.md.
> In this version we've managed to not use ssh, relying on `kubectl exec`
> instead. It's still pretty "ghetto", but at least we've managed to train
> some tensorflow models with it. :) Please take a look and let me know what
> you think.
>
> Thanks,
>
> Rong
>
> On Fri, Mar 16, 2018 at 11:38 AM r...@open-mpi.org 
> wrote:
>
>> I haven’t really spent any time with Kubernetes, but it seems to me you
>> could just write a Kubernetes plm (and maybe an odls) component and bypass
>> the ssh stuff completely given that you say there is a launcher API.
>>
>> > On Mar 16, 2018, at 11:02 AM, Jeff Squyres (jsquyres) <
>> jsquy...@cisco.com> wrote:
>> >
>> > On Mar 16, 2018, at 10:01 AM, Gilles Gouaillardet <
>> gilles.gouaillar...@gmail.com> wrote:
>> >>
>> >> By default, Open MPI uses the rsh PLM in order to start a job.
>> >
>> > To clarify one thing here: the name of our plugin is "rsh" for
>> historical reasons, but it defaults to looking to looking for "ssh" first.
>> If it finds ssh, it uses it.  Otherwise, it tries to find rsh and use that.
>> >
>> > --
>> > Jeff Squyres
>> > jsquy...@cisco.com
>> >
>> > ___
>> > devel mailing list
>> > devel@lists.open-mpi.org
>> > https://lists.open-mpi.org/mailman/listinfo/devel
>>
>> ___
>> devel mailing list
>> devel@lists.open-mpi.org
>> https://lists.open-mpi.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://lists.open-mpi.org/mailman/listinfo/devel
>
>
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://lists.open-mpi.org/mailman/listinfo/devel
___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] Github deprecated "Github services" Does this affect us?

2018-06-08 Thread Jeff Squyres (jsquyres) via devel

The only thing it affects that we were using was Travis.

But a) we're no longer using Travis, and b) I'm sure Travis will address the 
issue, anyway.


> On Jun 7, 2018, at 10:06 AM, Geoffrey Paulsen  wrote:
> 
> Devel,
>  
>I just came across Github's deprecation announcement of Github Services.
> https://developer.github.com/changes/2018-04-25-github-services-deprecation/
> 
>Does anyone know if this will affect Open-MPI at all, and do we need to 
> change any processes because of this?
> 
> ---
> Geoffrey Paulsen
> 
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://lists.open-mpi.org/mailman/listinfo/devel


-- 
Jeff Squyres
jsquy...@cisco.com

___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

[OMPI devel] ARM failure on PR to master

Re: [OMPI devel] Shared object dependencies

Re: [OMPI devel] Shared object dependencies

Re: [OMPI devel] Shared object dependencies

[OMPI devel] Shared object dependencies

Re: [OMPI devel] Running on Kubernetes

Re: [OMPI devel] Github deprecated "Github services" Does this affect us?

7 matches

Site Navigation

Mail list logo

Footer information