Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add plugin backend reload capability #3112

Merged
merged 16 commits into from
Aug 8, 2017
Merged

Add plugin backend reload capability #3112

merged 16 commits into from
Aug 8, 2017

Conversation

calvn
Copy link
Contributor

@calvn calvn commented Aug 4, 2017

No description provided.

@calvn calvn requested review from jefferai and briankassouf August 4, 2017 19:16
c.mountsLock.Lock()
defer c.mountsLock.Unlock()

for _, mount := range mounts {
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 can partially reload some backends before failing. I wonder if this should be an all-or-nothing operation, where reload executed only after a check on all mounts successful.

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe it should use multierror to return which mounts were unable to be reloaded. That way it gets through as many as it can

@calvn calvn added this to the 0.8.0 milestone Aug 4, 2017
@calvn calvn changed the title Add plugin backend restart capability Add plugin backend reload capability Aug 4, 2017
defer c.mountsLock.Unlock()

// Filter mount entries that only matches the plugin name
for _, entry := range c.mounts.Entries {
Copy link
Member

Choose a reason for hiding this comment

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

This function likely needs to iterate through c.auth.Entries too, in case the plugin name they give is an auth plugin.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed in f127fa6.

}
if resp != nil {
t.Fatalf("bad: %v", resp)
}
Copy link
Member

Choose a reason for hiding this comment

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

I realize this is making sure there's no error, but is there a way to verify that a reload actually happened other than no error?

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 am not sure how this can be done, since the backend has no access/knowledge of the underlying plugin process.

}

// Call initialize; this takes care of init tasks that must be run after
// the ignore paths are collected.
Copy link
Member

Choose a reason for hiding this comment

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

Yes, but keep in mind that on the ent side there needs to be logic here to handle the ignore paths in case they've changed (so likely, remove the ones that are there at the beginning, then add them now).

Copy link
Member

@jefferai jefferai left a comment

Choose a reason for hiding this comment

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

Just a few minor things!

}

func (c *Core) reloadPluginCommon(entry *MountEntry) error {
if entry.Type == "plugin" {
Copy link
Contributor

Choose a reason for hiding this comment

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

This is a small nit, but it probably would be cleaner to verify the entry type is a plugin outside of this function and only call reloadPluginCommon if it is indeed a plugin.

@@ -821,6 +821,27 @@ func NewSystemBackend(core *Core) *SystemBackend {
HelpSynopsis: strings.TrimSpace(sysHelp["plugin-catalog"][0]),
HelpDescription: strings.TrimSpace(sysHelp["plugin-catalog"][1]),
},
&framework.Path{
Pattern: "plugin/backend/reload$",
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this be plugins/ to match the existing endpoint? Also since it operates on multiple plugins

@briankassouf
Copy link
Contributor

We should also add the ability to automatically reload a plugin process in the event of a plugin crash, the plugin backend could just watch for rpc.ErrShutdown coming from the RPC calls and restart the plugin.

@calvn calvn merged commit 01d1c20 into master Aug 8, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants