Dotnet 3.0

[shawnallen85]

Support for .NET Core 3.0

[sven-lange-last]

@shawnallen85 thanks for providing this update. I have to admit that my .NET knowledge is pretty poor - so I'm not a proper reviewer for this PR.

But my poor knowledge is the reason for using the opportunity to ask you a question: the default maximum action code size is 48 MiB (see https://github.com/apache/openwhisk/blob/master/docs/reference.md#system-limits) - in reality, it's even smaller because action blobs are base64 encoded. Is it possible to create meaningful .NET actions that use existing libraries with 48 MiB? Or is the only reasonable way to extend the .NET action image with dependencies and run it as blackbox (Docker) action?

[shawnallen85]

@sven-lange-last It sounds like the size limitation should be something handled at the OpenWhisk level rather than at the runtime level. That having been said, I've been writing lambdas for awhile now and I have never seen anything coming near that limit. Part of me thinks that if you have assemblies that large than refactoring might be needed -- maybe migrate resources to some blob storage (S3, Minio, Object Storage, etc.), database, or cache. Would you be able to reference any .NET packages that exceed the limit?

Anyway, I think the code provided here would be a good starting point if anyone wanted to create their own Blackbox image containing their codebase that happens to exceed the limits of what OpenWhisk allows.

[sven-lange-last]

@shawnallen85 Thanks for your off-topic response. It sounds like the restriction to 48 MiB for the action including dependencies should be no problem...

The reason for an action size limit in the openwhisk architecture is that the action binary needs to be stored in an entity store - by default, CouchDB.

Reason for my question was following .NET action which resulted in a package larger than 48 MiB. As far as I understand, it simply runs a PowerShell command.

using Newtonsoft.Json.Linq;
using System;
using System.Management.Automation;

namespace Test
{
    public class Program
    {
        public static void Main()
        {
            JObject message = new JObject();
            try
            {
                using (PowerShell ps = PowerShell.Create())
                {
                    var dateRes = ps.AddScript(@"Get-Date").Invoke();
                    message.Add("date", new JValue(dateRes[0].BaseObject));
                }
            }
            catch (Exception ex)
            {
                message.Add("failure", new JValue(ex.ToString()));
            }

            Console.WriteLine(message);
            return (message);
        }
   }
}

[shawnallen85]

@sven-lange-last The System.Management.Automation package itself (referenced in the code above) is 38.95 MB (This is huge). To provide some additional examples of package sizes, Newtonsoft.Json is 887.74 KB in size. Confluent.Kafka is 613.86 KB. Oracle.ManagedDataAccess is 2.86 MB. Npgsql (Postgres client) is 1.65 MB.

It sounds like PowerShell might warrant it's own runtime, not one tacked onto the .NET Core runtime.

[sven-lange-last]

@shawnallen85 thanks a lot for these details. Very helpful to better understand what .NET means from a runtime perspective.

[rabbah]

Suggested change

[rabbah]

there's no 3.0 release yet. So I think you should remove the below.

@dgrove-oss ?

[dgrove-oss]

I think leaving a stub in that 1.13 is the initial release is fine. Sorry to be slow; didn't realize you were waiting for me...

[dgrove-oss]

ohh, I see. Yes 1.14 would be the first release with .NET 3.0 core. So the 1.13 should be removed here and a 1.14 with initial release added.

[dgrove-oss]

Lets merge this PR before #23 to avoid conflicts (I'll do the rebase on my trivial PR to just change the language from scala to java).

Looks to me like this is ready to merge once travis finishes. Is that right?

[shawnallen85]

I believe so, yeah, I think everything has been accounted for with the various commits.