Bug: asoctl import error: a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters

[hmi12]

Version of Azure Service Operator

azure_service_operator:v2.0.0-beta.2
asoctl: asoctl v2.8.0 linux

Describe the bug
When import an existing Azure postgresql flexible server, we encountered the following error:

Error from server (Invalid): error when creating "aso.yaml": FlexibleServersConfiguration.dbforpostgresql.azure.com "testpgb01-archive_command" is invalid: metadata.name: Invalid value: "testpgb01-archive_command": a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is 'a-z0-9?(.a-z0-9?)')
Error from server (Invalid): error when creating "aso.yaml": FlexibleServersConfiguration.dbforpostgresql.azure.com "testpgb01-archive_mode" is invalid: metadata.name: Invalid value: "testpgb01-archive_mode": a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is 'a-z0-9?(.a-z0-9?)')
Error from server (Invalid): error when creating "aso.yaml": FlexibleServersConfiguration.dbforpostgresql.azure.com "testpgb01-authentication_timeout" is invalid: metadata.name: Invalid value: "testpgb01-authentication_timeout": a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is 'a-z0-9?(.a-z0-9?)*')

To Reproduce

Steps to reproduce the behavior:

1. manually create an Azure postgresql flexible server from portal.
2. use asoctl import the Azure postgresql flexible server to ASO.

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

[matthchr]

The issue you are seeing here is that asoctl isn't smart about what it chooses to name the resources in Kubernetes - it just uses what they're named in Azure, which can be an invalid Kubernetes name. This is maybe not ideal behavior and @theunrepentantgeek will file a bug to improve the asoctl behavior.

In the meantime though, the easiest thing for you to do would be to set the .metadata.name field of the resource testpgb01-archive_command to instead be testpgb01-archive-command (replacing the underscore with a hyphen) so as to comply with the RFC1123 rules, and ensure that you set .spec.azureName for that resource to be testpgb01-archive_command (the real name of the resource in Azure, with the _).

Then you should be able to apply the resource without error.

[matthchr]

Also, I noticed you're using a quite old version of ASO and a new version of asoctl. Probably should upgrade to a newer version of ASOv2.

[matthchr]

Oh wait, I just realized you already opened an issue about how to upgrade, so clearly you're trying to do just that!

[hmi12]

Yes, we're testing the behavior of asoctl to prepare for the ASO upgrade. There is one more thing I want to ask: is it possible to make asoctl allow users to specify certain configuration items for import? I'm not sure if this would make sense for most users. When we tested importing an Azure PostgreSQL Flexible Server, the generated YAML file was about 15,000 lines long, which included all configurations and role definitions. It is quite tedious to modify or manage this file. In our case, we actually only need a few important parameters to be managed through ASO, such as max_connections and other similar settings.