reef-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Inglis <>
Subject Re: [DISCUSS] Proposal for supporting different platforms with .NET Core runtime
Date Wed, 18 Apr 2018 17:57:03 GMT
In order for that to work, this will put the requirement of users to ensure
that .NET Core is installed not only on the cluster but also the machine
that is doing the job submission. Really this is probably just a few lines
in a script to automate the process, but is having to install .NET Core on
a large cluster a problem?

You could argue that they already do this with Java, but I would say that
Java is very prevalent in this case simply because distributed frameworks
already require it. Therefore running REEF on Java just plays naturally
into those requirements of the distributed framework without adding
anything new. Even looking at the .net framework, we also shipped on .net
framework 4.52 -- this too did not add any new install requirements as the
.net framework was installed by default since Windows Server 2012.

This is different with .Net Core, so I took the approach of trying to
maintain no new dependencies and putting the work into managing runtime
binaries on the reef developers and the build system.

With all that said, I do agree with you though -- not having to deal with
runtimes does ensure that we can just run anywhere. So if the .NET Core
install is an acceptable requirement, then we can close this discussion and
the changes that I am proposing can be disregarded.

On Tue, Apr 17, 2018 at 4:08 PM, Markus Weimer <> wrote:

> I am all for supporting cross-platform job submission and run. This
> has been a long standing issue in the HDI runtime, for example:
> What I don't understand is the need for multiple different builds of
> REEF, one per platform. Once we move to .NET Core, we no longer have
> any native code in the project. Hence, we should run wherever we have
> .NET Core installed. The one hiccup are the Windows- and UNIX-isms
> around path and list separators. But I don't see how that creates a
> need for multiple builds.
> Markus

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message