Skip to content
This repository has been archived by the owner on Jun 10, 2024. It is now read-only.

Operator should always be able to start servers configured #36

Open
1 of 3 tasks
planetf1 opened this issue Apr 29, 2022 · 0 comments
Open
1 of 3 tasks

Operator should always be able to start servers configured #36

planetf1 opened this issue Apr 29, 2022 · 0 comments
Labels
base Interaction with base platform - possibly requiring changes in behaviour containers

Comments

@planetf1
Copy link
Member

planetf1 commented Apr 29, 2022

When using the example 'coco pharma' config files with the operator, the servers do not start (and the platforms fail) with the error

Server startup failed with error: OMAG-PLATFORM-SECURITY-403-003 User system is not authorized to issue operations requests

This is because these config files include the definition of a server security connector where the server operator is defined as 'garygeeke'

However the operator currently uses the base's 'autostart' feature, and with this mechanism the user 'admin' is always used

Potential fixes:

  • The short term fix is to remove the security connector from the configuration to allow demo/devel to continue
  • Change the demo security connector to allow 'system'
  • Always allow 'system'

Even if/when the operator is switched to explicitly starting the server via REST, a userid does need to be passed, so the same issue will arise.

planetf1 added a commit to planetf1/egeria-k8s-operator that referenced this issue Apr 29, 2022
Signed-off-by: Nigel Jones <nigel.l.jones+git@gmail.com>
@planetf1 planetf1 added the base Interaction with base platform - possibly requiring changes in behaviour label May 3, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
base Interaction with base platform - possibly requiring changes in behaviour containers
Projects
No open projects
Status: Todo
Development

No branches or pull requests

1 participant