zowe config auto-init provides unusable definition

[dkelosky]

using zowe config auto-init built this configuration:

{
    "$schema": "./zowe.schema.json",
    "profiles": {
        "zosmf": {
            "type": "zosmf",
            "properties": {
                "basePath": "/zosmf/api/v1"
            }
        },
        "ibmzosmf": {
            "type": "zosmf",
            "properties": {
                "basePath": "/ibmzosmf/api/v1"
            }
        },
        "base": {
            "type": "base",
            "properties": {
                "host": "some.host.com",
                "port": 60004,
                "tokenType": "apimlAuthenticationToken"
            },
            "secure": [
                "tokenValue"
            ]
        }
    },
    "defaults": {
        // Multiple services were detected.
        // Uncomment one of the lines below to set a different default.
        // "zosmf": "ibmzosmf",
        "zosmf": "zosmf",
        "base": "base"
    }
}

running zowe jobs list jobs from here gives a HTTP 404 response:

←[31m←[39mz/OSMF REST API Error:
Rest API failure with HTTP(S) status 404

Error Details:
HTTP(S) error status "404" received.
Review request details (resource, base path, credentials, payload) and ensure correctness.

changing this:

        "zosmf": {
            "type": "zosmf",
            "properties": {
                "basePath": "/zosmf/api/v1"
            }
        },

to this (removing zosmf) "fixes" the problem:

        "zosmf": {
            "type": "zosmf",
            "properties": {
                "basePath": "/api/v1"
            }
        },

Likely the static definition from this config is incorrect. However, should we detect this condition and report how to notify system admins that our server config is incorrect?

[MikeBauerCA]

Consider using the header approach that was discussed in refinement so that we could verify all services... perhaps a separate command as well like zowe config validate... research likely needed... can be post v2

[MarkAckert]

When I reproduced this using our build infrastructure, the /api/v1 basePath did not work for me; I had to use /ibmzosmf/api/v1. This already exists in the generated config and you can use it by switching the default zosmf profile to ibmzosmf. But which is the correct API URL format? Both?

[dkelosky]

I think it depends on how they've statically configured z/OSMF to APIML. In our case, it looks like some old, residual static configs to z/OSMF are still defined to APIML but are invalid.

Perhaps it's really a flaw in our APIML config to non-existing z/OSMF instances. But, should the client try to detect invalid definitions through something like a zowe config validate command (or other process).

[github-actions[bot]]

Thank you for raising this enhancement request. The community has 90 days to vote on it. If the enhancement receives at least 5 upvotes, it is added to our development backlog. If it receives fewer votes, the issue is closed.