Skip to content
This repository has been archived by the owner on Jan 19, 2023. It is now read-only.

Add lookup for additional metadata from JS plugins #2099

Merged
merged 4 commits into from
Mar 11, 2021

Conversation

xtreme-vikram-yadav
Copy link
Contributor

What this PR does / why we need it:
It allows octant to extract out additional contextual data sent by the JS plugins.

Which issue(s) this PR fixes

Special notes for your reviewer: There will be a separate PR to add similar support for Go plugins.

Related PR: vmware-archive/plugin-library-for-octant#8

@@ -44,6 +44,16 @@ func (d *DashboardDelete) Call(ctx context.Context, vm *goja.Runtime) func(c goj
// This will never error since &key is a pointer to a type.
_ = vm.ExportTo(obj, &key)

if len(c.Arguments) > 1 {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is needed to keep the metadata argument optional. I don't have strong opinions about this so let me know if anybody prefers this to always be passed with calls to the data store.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Javascript doesn't care one way or the other, so either way seems fine to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking of a scenario where octant users decide to use the older plugins with new octant release. This will not introduce any breaking change in that case


_ = vm.ExportTo(metadataObj, &metadata)
for key, val := range metadata {
ctx = context.WithValue(ctx, key, val)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like the context passed in here has a long life and adding context here keep increasing the memory imprint of the context. While it doesn't impact the correctness of the functionality, its growth with every execution of this code is concerning to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Example when i logged the context(I am passing datetime utc string from JS plugin in this example):

It started off with:
context : context.Background.WithCancel.WithValue(type log.key, val <not Stringer>).WithValue(type context.OctantContextKey, val <not Stringer>).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT)

After a while the context grew:

context : context.Background.WithCancel.WithValue(type log.key, val <not Stringer>).WithValue(type context.OctantContextKey, val <not Stringer>).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT).WithValue(type string, val Wed, 03 Mar 2021 02:02:39 GMT)^C2021-03-02T21:03:19.268-0500```

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this because we're iterating over all the keys of the metadata, but only deleting the last key?

It was my impression that context.WithValue creates a copy rather than mutating the existing instance, so because, here, the copied ctx object goes out of scope at the end of this method, I would not have thought a memory leak was possible.

If it is a long-lived object, how does it behave when multiple calls specify different values for a given key?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should be using a different variable name than key here to avoid confusion

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's because i'm reusing the variable for the new context. I'm experimenting with a new variable for each function call to avoid this.

[vmware-archive#2042]

Signed-off-by: Vikram Yadav <yvikram@vmware.com>
Copy link
Contributor

@chinigo chinigo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A handful of questions but no objections.


_ = vm.ExportTo(metadataObj, &metadata)
for key, val := range metadata {
ctx = context.WithValue(ctx, key, val)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this because we're iterating over all the keys of the metadata, but only deleting the last key?

It was my impression that context.WithValue creates a copy rather than mutating the existing instance, so because, here, the copied ctx object goes out of scope at the end of this method, I would not have thought a memory leak was possible.

If it is a long-lived object, how does it behave when multiple calls specify different values for a given key?

@@ -44,6 +44,16 @@ func (d *DashboardDelete) Call(ctx context.Context, vm *goja.Runtime) func(c goj
// This will never error since &key is a pointer to a type.
_ = vm.ExportTo(obj, &key)

if len(c.Arguments) > 1 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Javascript doesn't care one way or the other, so either way seems fine to me.

@xtreme-vikram-yadav
Copy link
Contributor Author

I'm syncing with @chinigo and @dimitrybesson to address some of the concerns.

Improve test coverage
[vmware-archive#2042]

Signed-off-by: Vikram Yadav <yvikram@vmware.com>
Co-authored-by: Michael Chinigo <mchinigo@vmware.com>
Co-authored-by: Dimitry Besson <dbesson@vmware.com>
Copy link
Contributor

@wwitzel3 wwitzel3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking great, I'd like to see a couple minor updates and then I think this is ready.

pkg/plugin/javascript/dashboard_delete.go Outdated Show resolved Hide resolved
pkg/plugin/javascript/dashboard_client.go Outdated Show resolved Hide resolved
pkg/plugin/javascript/dashboard_list.go Outdated Show resolved Hide resolved
- Improve check for missing argument
- restrict metadata values to string
- Make tests more descriptive

Signed-off-by: Vikram Yadav <yvikram@vmware.com>
@wwitzel3
Copy link
Contributor

wwitzel3 commented Mar 9, 2021

This is an interesting example of a similar idea, https://github.com/grpc/grpc-go/blob/v1.36.0/metadata/metadata.go#L154 .. I think I would like to see the Key/Value extraction and copying done as a function that we can unit test.

Copy link
Contributor

@wwitzel3 wwitzel3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry @xtreme-vikram-yadav I changed my mind, I would like to see the Key/Value extraction and copy process as a stand-alone function.

I don't think we need to use the go-grpc implementation, but I don't like that pattern of creating a unit testable single purpose function, instead of copying and pasting this in to each client method.

@xtreme-vikram-yadav
Copy link
Contributor Author

I have moved the common extraction logic out. I have kept the unit tests as is though because they are public and should be tested for the function they provide.

Signed-off-by: Vikram Yadav <yvikram@vmware.com>
Copy link
Contributor

@wwitzel3 wwitzel3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@wwitzel3 wwitzel3 merged commit ec84d18 into vmware-archive:master Mar 11, 2021
@xtreme-vikram-yadav xtreme-vikram-yadav mentioned this pull request Apr 21, 2021
6 tasks
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Plugins can enrich calls to custom object stores with arbitrary metadata
3 participants