Add more sophisticated .net example about demo-projects HOT 10 CLOSED

I am not sure that "provide credentials with env vars" matches the mongo model. They authenticate (at least partially) using trusted IP addresses. I assume in that the requests to mongo will come from our actions and so I think the "trusted ip address" would have to be something that our backend would use. But, of course, this would not be individualized.

They do have a concept of "database users" on top of this, and perhaps we can individualize that way, in which case some creds would again be part of the env vars. But ....

I'm currently using a free tier mongo (deployed in GCP). I think even if I figure out what IP address would be originating the requests on nimgcp we would not want to use that unless we can add another layer of authentication that would keep absolutely any action from using the instance.

More generally, if this becomes a useful demo and users want to deploy it with their own mongo instances, I don't see how that would work. Do we publish the originating IP address? Is that even a stable piece of information?

from demo-projects.

I decided to set aside mongoDb issues for now and focus on porting the code. If I'm lucky I'll get something that works except for DB access and then someone can help me figure out the DB access. The code is available in https://github.com/willvelida/serverless-mongodb-api.

The service appears to be (in our terms) a package with five actions. The actions share some model code (modest amount). The build for Azure looks like it makes a single executable with all five actions (I know so little about .net that I'm not completely sure).

The signature of each action will have to be changed to fit the conventions dictated by the OW .net runtime (this uses a third-party package NewtonSoft.JSON). Then, the question will be whether it pays to try to break up the code or just run the build five times and declare different Mains. Obviously, the latter is inefficient but I know we've resorted to that at times (e.g. with lambda ports).

from demo-projects.

PR #44 represents progress to date. Not mergeable yet because the actions don't initialize correctly (I don't know why yet). The approach I followed was to include only one of the original Azure functions in each action but to copy other material (the csproj file and the models code) from a common place.

So far I have ported two actions, GetAlbum and CreateAlbum. If those two work, the other three should be easy to add.

I was hoping to get where the actions could be invoked but would simply fail on the database access. There are three environment parameters MONGO_CONNECTION_STRING, DATABASE_NAME, COLLECTION_NAME which need to be filled in for the database access to work and I'm not sure I created the Mongo instance correctly for the exercise.

But, in any case, the actions don't get that far yet. I am getting a failure to initialize with this activation record:

{
  "activationId": "67160e5054da40ce960e5054da80cea4",
  "annotations": [
    {
      "key": "path",
      "value": "wbtestni-grinjpsjnuh/mongo-music/GetAlbum"
    },
    {
      "key": "waitTime",
      "value": 652
    },
    {
      "key": "entry",
      "value": "MongoMusic.API::MongoMusic.API.GetAlbum::Main"
    },
    {
      "key": "kind",
      "value": "dotnet:3.1"
    },
    {
      "key": "timeout",
      "value": false
    },
    {
      "key": "limits",
      "value": {
        "concurrency": 1,
        "logs": 16,
        "memory": 256,
        "timeout": 3000
      }
    },
    {
      "key": "initTime",
      "value": 593
    }
  ],
  "duration": 593,
  "end": 1607987704231,
  "logs": [
    "2020-12-14T23:15:04.232294Z    stderr: The action did not initialize or run as expected. Log data might be missing."
  ],
  "name": "GetAlbum",
  "namespace": "wbtestni-grinjpsjnuh",
  "publish": false,
  "response": {
    "result": {
      "error": "Unable to decompress package."
    },
    "size": 41,
    "status": "action developer error",
    "success": false
  },
  "start": 1607987703638,
  "subject": "[email protected]",
  "version": "0.0.1",
  "date": "2020-12-14 18:15:03"
}

from demo-projects.

"result": {
  "error": "Unable to decompress package."
},

This comes from the following code in the dotnet runtime:

try
{
     System.IO.Compression.ZipFile.ExtractToDirectory(tempFile, tempPath);
}
catch (Exception)
{
     await httpContext.Response.WriteError("Unable to decompress package.");
     return (null);
}

So, it is apparently unhappy with the format of the zip file produced by the deployer's autowrap feature. Curious, since the older example (hello-dotnet) also uses that feature but the zip file is accepted in that case.

In the Apache quickstart, they show the file being zipped with -0 ("store only"), that is, with no compression. The deployer autowrap will zip with whatever the default compression is for archiver('zip'). There is an option to suppress compression but we don't use it currently. Things to try next

• try using the 'store' flag in the deployer. Then consider whether this change is the new default, or to be turned on optionally with a command line flag
• stop using autozip in this example (and, for the moment, discourage its use with the dotnet runtime)

Will experiment down those lines.

from demo-projects.

I wasn't, on first try, able to change the behavior of the autozipper, so I will leave that for another day. I changed the action builds to use zip -0 (make the zip file manually in the build script). That got past the initial problem. Next: it's not accepting my main so investigating that.

from demo-projects.

The problem with main was trivial (namespace mismatch). Then things began to work, although for a while I was confused by the fact that the dotnet runtime is especially nasty about actions that leak exceptions. They don't report the exception and make it look like an initialization error. I finally realized initialization was working and I was making an error in a catch block that caused a second exception.

Now the two actions I have are "sorta kinda" working without mongo. I can't really tell whether they do the right thing in all respects until we have mongo hooked up.

from demo-projects.

This example now works and the PR that adds it has been merged. More work can be done here but is deferred for the moment.

• The README should be updated to show invocation via URL using curl, more similar to how the actions would be used when considered as an API
• Once the newest .NET runtime is in production, supporting "environment parameters", the example should change to segregate "system" parameters in the environment so that the input JObject has only user-specified parameters
• Test scaffolding should be added so that the logic of the actions can be tested locally
• The existing two actions should be refactored so that common initialization code is segregated in a separate class and not duplicated
• The remaining three actions from the original code should be translated

from demo-projects.

For reference - not more sophisticated but this setup works with Visual Studio https://github.com/rabbah/hello.net.

from demo-projects.

After discussion with @bhageena , who has dotnet experience, I'm transferring this issue to him.

from demo-projects.

Closing because this is way below the radar for available developers at the moment.

Could be reopened if new motivations appear to raise the priority.

from demo-projects.