Initialize plugins with current Octant state

[scothis]

Describe the problem/challenge you have

When loading a plugin, it doesn't actually know what Octant's state is for values like the current namespace or filters. A plugin has to guess what the current values are until it observes an action change the value.

Describe the solution you'd like

Either an additional argument should be passed to plugins as they are initialized containing the current state, or plugins should have a way to lookup the current state on demand.

Environment:

• Octant version (use octant version): 0.16.1

[wwitzel3]

I've been thinking about this recently, mainly for the JavaScript plugins, since I'm not sure how to do this in the Go plugins yet, having some lifecycle handlers here I think makes sense.

These would be called before the plugin was officially registered with Octant and started to receive requests:

• Setup can provide all of the current state like filters, namespace, context
• Start can be used as a handler to connect to external services, start watches (when we support that)

[wwitzel3]

And the API fetching of current state for these values also makes sense. Expect an API endpoint in the short-term and some better lifecycle management in the long-term.

[xtreme-vikram-yadav]

Forgot to mention but I picked it today.

[wwitzel3]

We had a chat about this issue, we are going solve it in two ways:

• Request object will contain the current context
• Request object will contain the current namespace
• Request object will contain the current list of filters
• A new action will be added to allow plugins to watch for context change
• A new action will be added to allow plugins to watch for filter changes
• Watching for a namespace change already exists

This allows plugin authors to always pull the current state from request objects directly, without the need to make an API call back to Octant to get that information. No need to setup an action handler if you only care about the current state.

This allows plugin authors to react to those changes on demand if needed, for example, to clear/update local caches.

[wwitzel3]

This doesn't solve the issue of the namespace being known during the "loading phase" .. @scothis do you have a problem with that given the described solution above? Or do you really want to have the current namespace before processing any requests?

[scothis]

The current namespace (et al) on each request would address my concern.

[wwitzel3]

fixed by #2244