Open planetf1 opened 2 years ago
Investigating:
Adding '-v10' to any kubectl
command prints out the equivilent curl command to use. For example
kubectl exec lab-odpi-egeria-lab-core-0 -- /bin/ls
becomes
I0210 18:52:39.051518 38389 round_trippers.go:466] curl -v -XGET -H "Accept: application/json, */*" -H "User-Agent: kubectl/v1.23.3 (darwin/amd64) kubernetes/816c97a" 'https://c108-e.eu-gb.containers.cloud.ibm.com:31413/api/v1/namespaces/lab/pods/lab-odpi-egeria-lab-core-0'
I0210 18:52:39.432094 38389 round_trippers.go:466] curl -v -XPOST -H "X-Stream-Protocol-Version: v4.channel.k8s.io" -H "X-Stream-Protocol-Version: v3.channel.k8s.io" -H "X-Stream-Protocol-Version: v2.channel.k8s.io" -H "X-Stream-Protocol-Version: channel.k8s.io" -H "User-Agent: kubectl/v1.23.3 (darwin/amd64) kubernetes/816c97a" 'https://c108-e.eu-gb.containers.cloud.ibm.com:31413/api/v1/namespaces/lab/pods/lab-odpi-egeria-lab-core-0/exec?command=%2Fbin%2Fls&container=egeria&stderr=true&stdout=true'
This is cumbersome.
The intent of this issue was to look at how to invoke commands from the Jupyter container to the egeria - or other containers. If we restrict the change to jupyter only we can now just consider issuing the commands from Python.
Therefore the easiest root is actually to use https://github.com/kubernetes-client/python pip install kubernetes
since the required credentials should be available under /var/run/secrets, placed there automatically by k8s
When building demos in our coco pharma environment, on occasion we need to similar things happening on different systems - outside the scope of egeria operations. In particular this is often in the context of running a demo 'script' via a notebook
For example
viewing logs, files, perhaps grepping out for errors or demonstrating what one might expect to see - not just for egeria
In some cases there are also API possibilities (files, postgres), sometimes not (egeria utilities -- if we want to demonstrate the utility itself, rather than the API)
Ensuring ssh access between these containers USED FOR A DEMO, particularly from the jupyter environment to the other containers, will make it possible to more quickly develop these scenarios, often before more fundamental changes (adding a file server, finding the best python libraries to use etc) is in place - ie more adaptable.
Note that access to the k8s cli is another option (kubectl exec) but in general I would err on using ssh as it's more understandable for most -- unless it is k8s itself being demoed.
Also note that our containers DO NOT RUN AS ROOT, so there are some limits in what can be run. Also containers in general are cut down in what commands are installed.