-
Notifications
You must be signed in to change notification settings - Fork 489
Add lookup for additional metadata from JS plugins #2099
Add lookup for additional metadata from JS plugins #2099
Conversation
56df03a
to
d6ad3d2
Compare
@@ -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 { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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```
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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>
d6ad3d2
to
9491df7
Compare
There was a problem hiding this 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) |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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.
203f450
to
ec7b3a5
Compare
I'm syncing with @chinigo and @dimitrybesson to address some of the concerns. |
ec7b3a5
to
5ac6684
Compare
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>
5ac6684
to
f460354
Compare
There was a problem hiding this 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.
- Improve check for missing argument - restrict metadata values to string - Make tests more descriptive Signed-off-by: Vikram Yadav <yvikram@vmware.com>
545e780
to
064abf7
Compare
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. |
There was a problem hiding this 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.
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. |
6e8e170
to
88cee0f
Compare
Signed-off-by: Vikram Yadav <yvikram@vmware.com>
88cee0f
to
0a36383
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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