Deploying Helm chart missing information about docs-ifa

[stijnmoreels]

After some research, I'm also not very sure on how we do this deployment to Microk8s?
How does the helm command know it has to use the local Kubernetes cluster?
Providing a Kubernetes namespace would be my guess.

[stijnmoreels]

Also, I think that we only need to run:

> helm upgrade --install <name> oci://invictusdevacracr.azurecr.io/helm/invictus-on-premise

When getting the Kubernetes pods, you get these already. Maybe we should let the users to inject the values in the values.yaml instead?

[LaurentAerens]

I'm more of a fan to let the use --set with the command an not inject values in values.yaml.
For micok8s you can just do microk8s config > .kube/config an use it as a normal Kubernetes cluster.

[stijnmoreels]

Aha, didn't know that. Thx!

[LaurentAerens]

just clarified with Matthew. That Framework.InvictusDashboardConnectionString is an outdated variable and isn't needed anymore.
All other needed variables should be clear. right?

[stijnmoreels]

just clarified with Matthew. That Framework.InvictusDashboardConnectionString is an outdated variable and isn't needed anymore. All other needed variables should be clear. right?

Some questions on these variables:

• {name}: this is something we can choose freely? Could be anything we want?
• {username}/{password}: 'credentials by Codit products'? So, credentials I still require?
• {rabbitmqpassword}: also an Azure resource I have to deploy manually?
• {erlangcookie}: something we can choose freely?
• {releaseverion}: an existing release version? If so, what are available? If not, can we choose it freely?

Also, if this command succeeds: how do we know if it's ran successfully? Is there a health endpoint or test-scenario for this kind of on-premise deployment to verify success?

[stijnmoreels]

Ok, I think I got the deploy commanded working; now I only need something to see if everything works.

I think this already is something:

[stijnmoreels]

First thought that the mysql pod was some built-in stuff, but apparently, this is part of the deploy. It is the only pod that's failing due to missing file permissions: /opt/mssql/bin/sqlservr: Error: The system directory [/.system] could not be created. File: LinuxDirectory.cpp:420 [Status: 0xC0000022 Access Denied errno = 0xD(13) Permission denied]; this is also via the SQLsapassword stuff, not the SQLexistingconnectionstring one.

When accessing other pods, they seem to rely on this one as they fail, so in that sense the deploy succeeded for the functions, but not for the database.

💡 Does the $USER that runs the stuff have access to the database? Seems like maybe it is the same user that runs the deploy, which may not have enough permissions to do something in the SQL cluster?

[stijnmoreels]

Status report

❌ The timesequencer is failing due to an invalid hostname:

Host.Startup[515]
  A host error has occurred during startup operation '269663c4-7c3e-47a3-97f6-809ee8fd2006'.
  System.UriFormatException: Invalid URI: The hostname could not be parsed.

💡 Reminds me of invalid in-process/isolated configuration of Azure Functions; something to do with package management, maybe.

❌ And the Pubsubconnector is failing with an invalid RabbitMQ config (probably related to the SQL stuff?)

 Host.Startup[402]
      The 'RabbitMQTrigger' function is in error: Microsoft.Azure.WebJobs.Host: Error indexing method 'RabbitMQTrigger'. RabbitMQ.Client: None of the specified endpoints were reachable. RabbitMQ.Client: One or more errors occurred. (Connection failed). RabbitMQ.Client: Connection failed. System.Net.NameResolution: Resource temporarily unavailable.

⚠️ Other ones are related to SQL, and fail by interaction.

[LaurentAerens]

strange,

the SQL one is an issue with the RBAC.

the timesequencer i have no idea what is happening

The pupsub is having an issue with the rabbitmq. can you check if the rabbitmq is deployed successfully?

[stijnmoreels]

--set SQL.persistence.dataSize= 10Gi bijvoorbeeld

This does not change the Forbidden authorization failure on the MSQL pod.
💡 Though, does make me wonder if we should provide minimum machine requirements to deploy the Invictus framework components on?

can you check if the rabbitmq is deployed successfully?

Has the Running status and the logs seem also OK. (started, completed).

the timesequencer i have no idea what is happening

Seems to have to do something with the 'durable task'.

info: Host.Triggers.Warmup[0]                                                                                                                   
      Initializing Warmup Extension.                                                                                                            
dbug: Microsoft.Azure.WebJobs.Host.IDistributedLockManager[0]                                                                                   
      Using InMemoryDistributedLockManager                                                                                                      
info: Host.Triggers.DurableTask[0]                                                                                                              
      Using the mssql storage provider.                                                                                                         
info: Host.Triggers.Warmup[0]                                                                                                                   
      Initializing Warmup Extension.                                                                                                            
fail: Host.Startup[515]                                                                                                                         
      A host error has occurred during startup operation '6430af93-365a-42e3-ab3c-b7b4b11329da'.                                                
      System.UriFormatException: Invalid URI: The hostname could not be parsed.                                                                 
         at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind, UriCreationOptions& creationOptions)                         
         at System.Uri..ctor(String uriString)                                                                                                  
         at Microsoft.Azure.WebJobs.Script.WebHost.DefaultScriptWebHookProvider.GetExtensionWebHookRoute(String extensionName) in /src/azure-fun
ctions-host/src/WebJobs.Script.WebHost/WebHooks/DefaultScriptWebHookProvider.cs:line 58                                                         
         at Microsoft.Azure.WebJobs.Script.WebHost.DefaultScriptWebHookProvider.GetUrl(IExtensionConfigProvider extension) in /src/azure-functio
ns-host/src/WebJobs.Script.WebHost/WebHooks/DefaultScriptWebHookProvider.cs:line 52                                                             
         at Microsoft.Azure.WebJobs.Host.Config.ExtensionConfigContext.GetWebhookHandler() in C:\projects\azure-webjobs-sdk-rqm4t\src\Microsoft.
Azure.WebJobs.Host\Config\ExtensionConfigContext.cs:line 55                                                                                     
         at Microsoft.Azure.WebJobs.Extensions.DurableTask.DurableTaskExtension.Microsoft.Azure.WebJobs.Host.Config.IExtensionConfigProvider.Ini

It's a bit difficult to debug something on my end, of course, 😅 But I'll keep searching.
💡 Seems like it is the only one with non-default settings in the host.json file.
💡 Aha! Matthew already asked this: Azure/azure-functions-durable-extension#2363 Apparently, we need to set the environment name WEBSITE_HOSTNAME to the pod hostname. Something missing from the deployment?

[LaurentAerens]

let me check, all of this should be automated. but maybe There was a change that wasn't applied everywhere.

[LaurentAerens]

about the timesequencer. somewhere that fix was removed from the repo. it think with the switch from github to devops.
I'll add it again.
edit: a fix has been deployed try to remove the helm chart and reinstall it.

[stijnmoreels]

about the timesequencer. somewhere that fix was removed from the repo. it think with the switch from github to devops. I'll add it again. edit: a fix has been deployed try to remove the helm chart and reinstall it.

Something got wrong with the update? Some corrupt secret?

Release "release-name" does not exist. Installing it now.
Pulled: invictusdevacracr.azurecr.io/helm/invictus-on-premise:1.0.0
Digest: sha256:ddfad5eddb3ffc8001176f21251045e8ce4e037abb93d82f1f5a656bd6791f8a
Error: Secret in version "v1" cannot be handled as a Secret: illegal base64 data at input byte 12

Maybe the added secret should be saved as BASE64, like the others? (saw that in the code).

[LaurentAerens]

indeed, fix that. I don't know why the test run didn't fail.

[stijnmoreels]

Additional info on the SQL error: microsoft/mssql-docker#735.
Was thinking, since it is a Linux pod, that we should provide file permissions chown with the non-root user on the pod?

[LaurentAerens]

i already set fsGroup to 10001