container-service-extension
container-service-extension copied to clipboard
CSE with PKS installation / check error - 'access_token'
Hello, during installation or configuration check with PKS I get red error message 'access_token'. CSE version: 2.6.1 Cloud Director: 10.1.1 PKS: 1.8
Can somebody please explain what error message 'access_token' means?
There is more detailed output from cse check:
[root@lab-cse ~]# cse check config.yaml -p pks.yaml --skip-config-decryption
Required Python version: >= 3.7.3
Installed Python version: 3.7.3 (default, Aug 10 2020, 09:53:38)
[GCC 8.3.1 20191121 (Red Hat 8.3.1-5)]
Validating config file 'config.yaml'
Connected to AMQP server (lab-rmq01.lab.cloud:5672)
InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised.
Connected to vCloud Director (vcd.lab.cloud:443)
Connected to vCenter Server 'lab-vc03' as '[email protected]' (lab-vc03.lab.cloud:None)
Connected to vCenter Server 'LAB-VC01' as '[email protected]' (lab-vc01.lab.cloud:None)
Connected to vCenter Server 'lab-vc04.lab.cloud' as '[email protected]' (lab-vc04.lab.cloud:None)
Config file 'config.yaml' is valid
Validating PKS config file 'pks.yaml'
'access_token'
CSE without PKS is running OK.
Thanks Miro
Hi @mirres
PKS 1.8 is not supported by CSE 2.6.1. CSE 2.6.1 only supports PKS 1.7.
Regards Aritra Sen
Hi @rocknes, Thanks, I know, there is missing official support. But 'access_token' error I get during PKS yaml file validation. That why I need explain this error.
Miro
CSE internally uses PKS client to communicate with PKS instances. The PKS client is auto generated and is PKS version sensitive. Right now CSE 2.6.1 has a copy of PKS 1.7 client. If this client is used to communicate with PKS 1.8, it is expected that things will go wrong.
Now coming back to PKS yaml. When CSE first parses the yaml file, it processes it and tries to connect to the PKS server using the 'secret' specified in the yaml file. Once the 'secret' is accepted by the PKS server it sends back an access token that CSE uses in subsequent communication with PKS. I think the login call to PKS isn't going through (maybe the endpoint has changed or the payload structure has changed). And the response CSE is receiving doesn't have the field named 'access_token'.
The error message could have been a little better but we have never tested against PKS 1.8, so this sort of weird message is in the realm of possibility.
Regards Aritra Sen
@rocknes , thank you for detailed explanation. There I have one question - when I can expect availability of next version CSE compatible with PKS 1.8 or newer? I have to use PKS at least a 1.8 version because of connection to other technologies.
Regards Miro Kis
Mira His - PKS 1.8 is not on the roadmap yet.
Aashima
Hi @goelaashima @rocknes , how is it with PKS 1.8 or newer support?