filesystem access from [ActivityTrigger]

[vigouredelaruse]

nobody seems to ask about this but i want to know definitively before i start cutting workflows

the referenced url contains code as below (https://www.syncfusion.com/succinctly-free-ebooks/azure-durable-functions-succinctly/stateful-patterns-with-durable-functions)

[FunctionName("Backup_GetFileList")]

public string[] GetFileList([ActivityTrigger] string rootPath,

    ILogger log)

{

    log.LogInformation($"[ACTIVITY Backup_GetFileList] --> rootPath : {rootPath}");

    string[] files = Directory.GetFiles(rootPath, "*", SearchOption.AllDirectories);

    return files;

}

please confirm that Directory.ArbitraryMethod() is a supported scenario for [ActivityTrigger]
regards

[cgillum]

I can confirm that it's perfectly fine to access the file system from activity functions. There's no issue with using these APIs.

[vigouredelaruse]

thank you; there's a part 2 to my query now available

bearing in mind

• https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-code-constraints?tabs=csharp
• https://developers.redhat.com/blog/2019/10/29/the-net-process-class-on-linux
• https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.process.start?view=net-7.0

i would like to

• deploy a linux container hosted (c#) orchestration to an arbitrary kubernetes instance
• launch a linux executable and await the completion of the linux binary

is this scenario supported for [ActivityTrigger] ?
thanks

[cgillum]

Yes, this too is perfectly fine. Your activity trigger can block until the Linux process you launch completes. Since you're running on Kubernetes, you don't need to worry about activity function timeouts like you would when running on the Azure Functions consumption plan.

[vigouredelaruse]

@cgillum thank you.

now the way is therefore clear for a slightly offbook mention of one cloud on this sunny looking orchestrated horizon and i detailed it over here to no avail so far Azure/azure-functions-core-tools#3193

to wit, deployment to kubernetes seems to require an interactive shell session

but the deployment scenarios for my tool call for

• kubernetes orchestrated image pull when new images become available, for instance by using something like portainer to trigger new pulls
• initial deployment via helm or kube manfest deploy of non-kubernetes container registries

in other words is it a true statement that the core tools documented workflow requires building the image on the deployment host?

the reason i ask is i'd prefer not to deploy ci/cd on the deployment environment (don't want to run builds on production hosts)

please advise

[cgillum]

For now, I suggest avoiding using func kubernetes deploy if possible for your use case and instead use standard deployment procedures for apps hosted on kubernetes. Some issues have been discovered with the mechanism that func kubernetes deploy uses to split apps into HTTP and non-HTTP variants that cause startup issues.

[vigouredelaruse]

it's almost 4pm and your assessment seems to allow

• deploying a container to say docker.hub
• helm or such deploy to kubernetes as normal
• proper configuration of associated environment variables like the storage account
• avoidance of kubernetes func deploy for now and alternatives are available

thanks

[vigouredelaruse]

having gotten a suitable roundtuit and dedicated task time to durable functions, kubernetes and kubernetes func deploy

re: contrived triggering of orchestrations using timer triggers activating a rabbitmq producer targetting an orchestration starter with a rabbitmq queue trigger

• according to various github issues func kubernetes deploy is currently confused about triggering orchestrations via http and the scenario is probably to be avoided
• on the other hand using a rabbitmq trigger works well, although the scaledobject for the timer trigger needs to be modified to use the cron trigger, maladroitly applied in this case as below
  

the canonical orchestration starter is nominal although the %parameter_interpolation% is suspect

       [FunctionName("TenantViewFeatureDeploymentListener")]
        public async Task ComandChannelListener(
            [RabbitMQTrigger("%CriticalRabbitMQ:CommandChannelName%", ConnectionStringSetting = "CriticalRabbitMQ:AMQPEndpoint")] TheHorselessNewspaper.Schemas.ContentModel.ContentEntities.ContentCollection contentCollection,
            [DurableClient(ExternalClient = true)] IDurableOrchestrationClient starter,
            ILogger log)
        {
            // Function input comes from the request content.
            string instanceId = await starter.StartNewAsync("TenantViewFeatureDeployment", null);

            log.LogInformation($"Started orchestration with ID = '{instanceId}'.");
            ContentEntities odataClient = new ContentEntities(new System.Uri(""
        }

the following sure resembles the SayHello activity executing

i also seem to remember modifying the project file to include this, of appropriately rated relevance