You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwhisk.apache.org by Shawn Black <en...@yahoo.com.INVALID> on 2020/12/16 05:02:33 UTC
.NET Support in OpenWhisk
Howdy, all!
I wanted to get some feedback on the current state of .NET within the
OpenWhisk ecosystem.
Right now, we support .NET Core 2.2 (not LTS and no longer supported)
and .NET Core 3.1 (LTS).
.NET 5.0 was recently released, but I would like to skip supporting this
version as it is not an LTS release.
I think it would make more sense to wait for .NET 6.0, which will be an
LTS release.
Once that is out, we can add support for it and then deprecate .NET 2.2.
The .NET Core 3.1 runtime supports running .NET Core 2.2 binaries (we
have a unit test to support this).
Thoughts? Concerns?
Thanks!!
Shawn
Re: .NET Support in OpenWhisk
Posted by David P Grove <gr...@us.ibm.com>.
Shawn Black <en...@yahoo.com.INVALID> wrote on 12/16/2020 12:02:33 AM:
>
> I wanted to get some feedback on the current state of .NET within the
> OpenWhisk ecosystem.
>
> Right now, we support .NET Core 2.2 (not LTS and no longer supported)
> and .NET Core 3.1 (LTS).
>
> .NET 5.0 was recently released, but I would like to skip supporting this
> version as it is not an LTS release.
>
> I think it would make more sense to wait for .NET 6.0, which will be an
> LTS release.
>
> Once that is out, we can add support for it and then deprecate .NET 2.2.
>
> The .NET Core 3.1 runtime supports running .NET Core 2.2 binaries (we
> have a unit test to support this).
>
Hi Shawn,
Probably an imperfect comparison, but for Node.js we've only been
putting out runtimes for LTS releases and deprecating/removing them fairly
quickly when the LTS support period ends.
.NET seems to be on a slower cadence (LTS release only every 2 years
vs. 1 year for Node.js).
--dave
Re: .NET Support in OpenWhisk
Posted by Rodric Rabbah <ro...@gmail.com>.
Thanks for the detailed explanations Shawn!
-r
On Wed, Dec 16, 2020 at 10:48 AM Shawn Black <en...@yahoo.com.invalid>
wrote:
> I do --
> https://github.com/apache/openwhisk-runtime-dotnet/issues/34
> - The commends below are based on the code @kamyker pointed out in
> https://github.com/kamyker/openwhisk-dotnet-csharp/commit/f9a739779887b4262c987c0be8bf2b77071c651b#diff-6bc49d26f451cad6d8312deca5a0eadeL89-L96.
> Comments are for everything in the diff, not just the extraction aspect of
> things as mentioned in his comments. - Things to avoid (I think at least,
> please provide comments): + The overall diff will essentially break the
> existing contract and introduce a method not used in any other runtimes
> (AFAIK, I haven't looked at other recently).
> + Right now, we pass a JObject (essentially a class that exposes the
> payload as a JSON object, it is from the Newtonsoft.JSON library, which in
> the .NET world is the most used library for JSON serialization and
> manipulation [That's why I picked it for handling JSON in the runtime]) +
> This change will remove that and essentially pass thru the HttpRequest
> object (the originating object going into calling the function -- this is
> where I don't think we have any other runtimes doing this) - Things to look
> into a bit (since the change is more than just extracting a zip):
> +@kamyker explicitly handles the steps of extracting the payload and that
> might be faster than the helper method provided by the .NET runtime
> https://github.com/apache/openwhisk-runtime-dotnet/issues/39
> - I believe this is resolved with the latest code in GitHub, but I am not
> sure if it has been included in a release.
> https://github.com/apache/openwhisk-runtime-dotnet/issues/35
> - I believe this is also resolved with a change to validating the payload
> size and allowing larger zip files based on configuration. If I recall,
> this is in the latest release.
> In regards to the .NET serialization library used, backwards capability
> always comes to mind. Changing the library used also changes the object
> passed between our runtime and the end user function.
> We might be able to implement some code at Initialization that analyzes
> the end user function to see what object type the function expects and
> route it to a Newtonsoft.JSON handler or another libraries (maybe the one
> included with .NET now, it's gotten a lot better) handler and make a
> recommendation to migrate to the new handler and eventually phase out the
> Newtonsoft.JSON one. Just a thought on how we can handle changing that --
> which is another thing @kamyker pointed out. Again, Newtonsoft.JSON was
> picked since it is the de facto standard for JSON in .NET.
> Thanks!!Shawn
> On Wednesday, December 16, 2020, 08:08:53 AM CST, Rodric Rabbah <
> rodric@gmail.com> wrote:
>
> Deprecating 2.2 makes sense to me being out of support.
> I'm neutral on 5.0 vs waiting for .NET 6.0 (I am not a .NET developer
> though :).
>
> There were a couple of issues in the repo about improving the performance
> of the .NET runtime by reducing dependencies and tweaking the JSON serdes.
> Do you have thoughts on those?
>
> -r
>
> On Wed, Dec 16, 2020 at 12:02 AM Shawn Black <en...@yahoo.com.invalid>
> wrote:
>
> > Howdy, all!
> >
> > I wanted to get some feedback on the current state of .NET within the
> > OpenWhisk ecosystem.
> >
> > Right now, we support .NET Core 2.2 (not LTS and no longer supported)
> > and .NET Core 3.1 (LTS).
> >
> > .NET 5.0 was recently released, but I would like to skip supporting this
> > version as it is not an LTS release.
> >
> > I think it would make more sense to wait for .NET 6.0, which will be an
> > LTS release.
> >
> > Once that is out, we can add support for it and then deprecate .NET 2.2.
> >
> > The .NET Core 3.1 runtime supports running .NET Core 2.2 binaries (we
> > have a unit test to support this).
> >
> > Thoughts? Concerns?
> >
> > Thanks!!
> >
> > Shawn
> >
> >
>
Re: .NET Support in OpenWhisk
Posted by Shawn Black <en...@yahoo.com.INVALID>.
I do --
https://github.com/apache/openwhisk-runtime-dotnet/issues/34
- The commends below are based on the code @kamyker pointed out in https://github.com/kamyker/openwhisk-dotnet-csharp/commit/f9a739779887b4262c987c0be8bf2b77071c651b#diff-6bc49d26f451cad6d8312deca5a0eadeL89-L96. Comments are for everything in the diff, not just the extraction aspect of things as mentioned in his comments. - Things to avoid (I think at least, please provide comments): + The overall diff will essentially break the existing contract and introduce a method not used in any other runtimes (AFAIK, I haven't looked at other recently).
+ Right now, we pass a JObject (essentially a class that exposes the payload as a JSON object, it is from the Newtonsoft.JSON library, which in the .NET world is the most used library for JSON serialization and manipulation [That's why I picked it for handling JSON in the runtime]) + This change will remove that and essentially pass thru the HttpRequest object (the originating object going into calling the function -- this is where I don't think we have any other runtimes doing this) - Things to look into a bit (since the change is more than just extracting a zip): +@kamyker explicitly handles the steps of extracting the payload and that might be faster than the helper method provided by the .NET runtime
https://github.com/apache/openwhisk-runtime-dotnet/issues/39
- I believe this is resolved with the latest code in GitHub, but I am not sure if it has been included in a release.
https://github.com/apache/openwhisk-runtime-dotnet/issues/35
- I believe this is also resolved with a change to validating the payload size and allowing larger zip files based on configuration. If I recall, this is in the latest release.
In regards to the .NET serialization library used, backwards capability always comes to mind. Changing the library used also changes the object passed between our runtime and the end user function.
We might be able to implement some code at Initialization that analyzes the end user function to see what object type the function expects and route it to a Newtonsoft.JSON handler or another libraries (maybe the one included with .NET now, it's gotten a lot better) handler and make a recommendation to migrate to the new handler and eventually phase out the Newtonsoft.JSON one. Just a thought on how we can handle changing that -- which is another thing @kamyker pointed out. Again, Newtonsoft.JSON was picked since it is the de facto standard for JSON in .NET.
Thanks!!Shawn
On Wednesday, December 16, 2020, 08:08:53 AM CST, Rodric Rabbah <ro...@gmail.com> wrote:
Deprecating 2.2 makes sense to me being out of support.
I'm neutral on 5.0 vs waiting for .NET 6.0 (I am not a .NET developer
though :).
There were a couple of issues in the repo about improving the performance
of the .NET runtime by reducing dependencies and tweaking the JSON serdes.
Do you have thoughts on those?
-r
On Wed, Dec 16, 2020 at 12:02 AM Shawn Black <en...@yahoo.com.invalid>
wrote:
> Howdy, all!
>
> I wanted to get some feedback on the current state of .NET within the
> OpenWhisk ecosystem.
>
> Right now, we support .NET Core 2.2 (not LTS and no longer supported)
> and .NET Core 3.1 (LTS).
>
> .NET 5.0 was recently released, but I would like to skip supporting this
> version as it is not an LTS release.
>
> I think it would make more sense to wait for .NET 6.0, which will be an
> LTS release.
>
> Once that is out, we can add support for it and then deprecate .NET 2.2.
>
> The .NET Core 3.1 runtime supports running .NET Core 2.2 binaries (we
> have a unit test to support this).
>
> Thoughts? Concerns?
>
> Thanks!!
>
> Shawn
>
>
Re: .NET Support in OpenWhisk
Posted by Rodric Rabbah <ro...@gmail.com>.
Deprecating 2.2 makes sense to me being out of support.
I'm neutral on 5.0 vs waiting for .NET 6.0 (I am not a .NET developer
though :).
There were a couple of issues in the repo about improving the performance
of the .NET runtime by reducing dependencies and tweaking the JSON serdes.
Do you have thoughts on those?
-r
On Wed, Dec 16, 2020 at 12:02 AM Shawn Black <en...@yahoo.com.invalid>
wrote:
> Howdy, all!
>
> I wanted to get some feedback on the current state of .NET within the
> OpenWhisk ecosystem.
>
> Right now, we support .NET Core 2.2 (not LTS and no longer supported)
> and .NET Core 3.1 (LTS).
>
> .NET 5.0 was recently released, but I would like to skip supporting this
> version as it is not an LTS release.
>
> I think it would make more sense to wait for .NET 6.0, which will be an
> LTS release.
>
> Once that is out, we can add support for it and then deprecate .NET 2.2.
>
> The .NET Core 3.1 runtime supports running .NET Core 2.2 binaries (we
> have a unit test to support this).
>
> Thoughts? Concerns?
>
> Thanks!!
>
> Shawn
>
>