onpremises icon indicating copy to clipboard operation
onpremises copied to clipboard

Structurizr Onpremises in AKS does not create workspaces correctly

Open mmnavirom opened this issue 1 month ago • 2 comments

Description

I have an instance of structurizr onpremises 2024.03.03 running in Azure's Kubernetes Service that exhibits unexpected behavior when attempting to create or manipulate a workspace. The container uses a persistent volume/persistent volume claim that points to an Azure SMB File share for persistence.

Expected behavior

Ability to upload, manipulate, and view diagrams within a workspace. Ability to delete workspaces.

Observed behavior

On creating a new workspace, the landing page does not display any of the options for loading diagrams into the workspace and the lower corner displays the message "Error error".

[screenshot 1]

The option to export a json or dsl does nothing when selected, the option to import json opens a file picker but does nothing with the selected file. The inspections page lists three errors for the workspace:

[screenshot 2]

The settings page loads and allows me to manage users and rbac, including making the workspace private, and these changes are correctly reflected. Under API details, the API url is listed as "/api" without the base url defined in the structurizr configuration. The base URL is correctly shown in structurizr's invocation logs.

[screenshot 3] [screenshot 4]

When attempting to delete a workspace, I get the error "TypeError: Cannot read properties of undefined (reading 'id') and the workspace is not deleted

[screenshot 5]

Upon investigating the underlying azure file storage that is volume mounted into the container, a folder is created for each workspace containing a "workspace-datetime.json", "workspace.json", and "workspace.properties" files, all of which have contents. The file "structurizr.log" in the "logs" folder inside the storage root is updated with new log entries.

[screenshot 6]

I have set the application logging level to "ALL" in log4j2.properties and there does not appear to be any logging corresponding to the error appearing inside the application or any of the failures involving file imports or exports.

Steps to reproduce

Navigate to the affected structurizr instance, log in as an administrative user, and select "New workspace"

Screenshot

1 image 2 image 3 image 4 image 5 image 6 image

Code sample

structurizr.properties

structurizr.admin=mmadmin

# base url for instance
structurizr.url=https://REDACTED.com
structurizr.replyurl=https://REDACTED.com/saml/SSO

log4j2.properties

appender.console.type = Console
appender.console.name = LogToConsole
appender.console.layout.type = PatternLayout
appender.console.layout.pattern = [%-5level] %d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %c{1} - %msg%n

appender.file.type = File
appender.file.name = LogToFile
appender.file.fileName=${sys:structurizr.dataDirectory}/logs/structurizr.log
appender.file.layout.type=PatternLayout
appender.file.layout.pattern=[%-5level] %d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %c{1} - %msg%n

logger.app.name = com.structurizr
logger.app.level = ALL
logger.app.additivity = false
logger.app.appenderRef.console.ref = LogToConsole
logger.app.appenderRef.file.ref = LogToFile

logger.springSecurity.name = org.springframework.security
logger.springSecurity.level = info
logger.springSecurity.additivity = false
logger.springSecurity.appenderRef.console.ref = LogToConsole
logger.springSecurity.appenderRef.file.ref = LogToFile

rootLogger.level = info
rootLogger.appenderRef.stdout.ref = LogToConsole
rootLogger.appenderRef.file.ref = LogToFile

Configuration

structurizr/onpremises:2024:03:03

Severity

Minor

Priority

I have no budget and there's no rush, please fix this for free

More information

The replyurl is present in the configuration based on some work I'm doing to enable saml separate from this issue. The screenshot containing structurizr invocation lists search as "none" from a previous instance where I disabled it for testing - the behavior persists whether or not search is enabled.

All css and other assets appear to load correctly in the affected instance. I have a local instance of the same container running successfully, with the landing page appearing correctly in a new workspace, the ability to upload workspace json, and the api uri on the settings page including the base url from configuration. I'd be happy to provide further information including sanitized versions of the kubernetes manifests if you feel it'd be helpful.

mmnavirom avatar May 07 '24 19:05 mmnavirom