RFC: chaos engineering as a service#14
Conversation
| two seperate programs that serve similar purpose. | ||
| **Goal is to unify the two.** | ||
| 2. Poor observability of experiment results from within the dashboard | ||
| **Goal is to collect the metrics by Prometheus and show in dashboard.** |
There was a problem hiding this comment.
maybe collect the metrics by Prometheus and show in dashboard is just one way of improve the observability. 😃
There was a problem hiding this comment.
@WangXiangUSTC What do you suggest we could do besides Prometheus integration for this?
There was a problem hiding this comment.
maybe some data of the chaos experiment itself. In fact, I don’t have a definite idea yet
There was a problem hiding this comment.
Good examples of metrics from Litmus as mentioned in this blog.
I think we must have metrics around pass/fail/awaited for all chaos operations which client is going to perform. We already have one pass metric but we certainly can have more metric around this (like per namespace) to make data more visible and easy to consume.
There was a problem hiding this comment.
Yeah, I agree with you
Signed-off-by: Shivansh Saini <shivanshs9@gmail.com>
Signed-off-by: Shivansh Saini <shivanshs9@gmail.com>
WangXiangUSTC
left a comment
There was a problem hiding this comment.
In addition, do we need to describe how to control some role's privileges in this RFC?
| Chaosd runs on physic nodes outside kubernetes cluster, so it is vulnerable to attack | ||
| from internet. To prevent misuse of chaosd, it needs to allow only authenticated | ||
| requests. The easiest and secure setup is to use SSL certificates to both encrypt | ||
| the request data and for authentication. |
There was a problem hiding this comment.
should unit them into one line
There was a problem hiding this comment.
have some problems below
There was a problem hiding this comment.
umm.. basically combine to one sentence??
| In this setup, private key of the certificate will be generated and kept with the | ||
| dashboard and public key would be stored on chaosd nodes. On any request, | ||
| chaosd would first verify the digital signatures presented by the client to | ||
| authenticate the request. |
There was a problem hiding this comment.
I have a question, the private key is kept by client(dashboard),is it looks strange?
There was a problem hiding this comment.
For authentication using certificates, the requesting entity must have the private key. Since dashboard will be calling http endpoints of chaosd, it'll have private key
|
@WangXiangUSTC that's a discussion in itself since it corresponds to what actions can be taken on the dashboard. I don't have the full clarity on everything so we could probably discuss it in a team meeting? |
OK |
Related issue: chaos-mesh/chaos-mesh#1462