Making ocp-wrapper compatable with kube-burner v1.9.6

[vishnuchalla]

Type of change

• Refactor
• New feature
• Bug fix
• Optimization
• Documentation Update

Description

Making code changes compatible with latest kb version .i.e. v1.9.6

Checklist before requesting a review

• I have performed a self-review of my code.
• If it is a core feature, I have added thorough tests.

[josecastillolema]

From the web-burner workload perspective lgtm

[afcollins]

Thanks for doing this!

I believe with these changes, the documentation is incorrect.

While we are touching that section, the command oc sa new-token is deprecated. When you run it, it says to use oc create token instead. We should also include that change as part of the docs change.

Also, by hard-coding metricsDirectory in the job config, we are reverting some functionality to generate the local dir with the uuid in the file name. We should preserve that functionality so we are not overwriting the same dir on repeated runs.

      metricsDirectory: reporting-metrics

[afcollins]

I looked and the appending uuid seems to be removed upstream in kube-burner#611 . I guess I missed that there, but it should be fixed before we merge this PR.

[vishnuchalla]

Thanks for doing this!

I believe with these changes, the documentation is incorrect.

While we are touching that section, the command oc sa new-token is deprecated. When you run it, it says to use oc create token instead. We should also include that change as part of the docs change.

Also, by hard-coding metricsDirectory in the job config, we are reverting some functionality to generate the local dir with the uuid in the file name. We should preserve that functionality so we are not overwriting the same dir on repeated runs.

      metricsDirectory: reporting-metrics

Thanks for all the inputs regarding docs @afcollins. Updated them accordingly.
Regarding metrics directory, I idea of this change is to leave it up to the user to provide a list of non-colliding metric directory names for their runs in local. Let me know if you have any concerns around this idea.

cc: @rsevilla87

[rsevilla87]

Thanks for doing this!
I believe with these changes, the documentation is incorrect.
While we are touching that section, the command oc sa new-token is deprecated. When you run it, it says to use oc create token instead. We should also include that change as part of the docs change.
Also, by hard-coding metricsDirectory in the job config, we are reverting some functionality to generate the local dir with the uuid in the file name. We should preserve that functionality so we are not overwriting the same dir on repeated runs.

      metricsDirectory: reporting-metrics

Thanks for all the inputs regarding docs @afcollins. Updated them accordingly. Regarding metrics directory, I idea of this change is to leave it up to the user to provide a list of non-colliding metric directory names for their runs in local. Let me know if you have any concerns around this idea.

cc: @rsevilla87

correct, that's the idea, but it doesn't work well though, all metrics get indexed to reporting-metrics, but that's due to a bug in the go-commons library...

Regarding the issue mentioned by @afcollins, we could conifgure metricsDirectory with something like the below to fix it.

      metricsDirectory: reporting-metrics-{{.UUID}}

[vishnuchalla]

Thanks for doing this!
I believe with these changes, the documentation is incorrect.
While we are touching that section, the command oc sa new-token is deprecated. When you run it, it says to use oc create token instead. We should also include that change as part of the docs change.
Also, by hard-coding metricsDirectory in the job config, we are reverting some functionality to generate the local dir with the uuid in the file name. We should preserve that functionality so we are not overwriting the same dir on repeated runs.

      metricsDirectory: reporting-metrics

Thanks for all the inputs regarding docs @afcollins. Updated them accordingly. Regarding metrics directory, I idea of this change is to leave it up to the user to provide a list of non-colliding metric directory names for their runs in local. Let me know if you have any concerns around this idea.
cc: @rsevilla87

correct, that's the idea, but it doesn't work well though, all metrics get indexed to reporting-metrics, but that's due to a bug in the go-commons library...

Regarding the issue mentioned by @afcollins, we could conifgure metricsDirectory with something like the below to fix it.

      metricsDirectory: reporting-metrics-{{.UUID}}

Appending UUID at the end looks good to me, if we do not want any manual intervention at all.

[afcollins]

Thanks for all the updates!

I think the split local dir doesn't work as expected.

Unless we have some requirement for it, I would ask for it to be removed instead of looking into fixing it. Personally, I am OK writing all metrics for a run to a single dir, and I think it simplifies the changes in this PR.

[rsevilla87]

Hi, I created a PR in go-commons to fix/improve the indexers code to allow creating multiple indexers of the same kind cloud-bulldozer/go-commons#45

[rsevilla87]

lgtm!

[afcollins]

Looks good to me!

Thank you for all the fixes for local indexing, Vishnu. :D