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

Sidecar: Ask if collectors should be restarted after a configuration change #5081

Open
lennartkoopmann opened this Issue Sep 7, 2018 · 5 comments

Comments

Projects
None yet
5 participants
@lennartkoopmann
Member

lennartkoopmann commented Sep 7, 2018

I changed the configuration of my osquery instances and wasn't sure if I had to manually restart the collectors next. Worse, all my osqueryd instances failed because the configuration file handle was invalid after the configuration change and I definitely had to restart the processes.

Can we ask the user if the underlying processes should be restarted if a configuration was changed?

@lennartkoopmann lennartkoopmann added this to the 3.0.0 milestone Sep 7, 2018

@lennartkoopmann

This comment has been minimized.

Show comment
Hide comment
@lennartkoopmann

lennartkoopmann Sep 7, 2018

Member

A possible caveat: We'd have to wait until the new config was applied, or send the restart request together with the config change.

Member

lennartkoopmann commented Sep 7, 2018

A possible caveat: We'd have to wait until the new config was applied, or send the restart request together with the config change.

@lennartkoopmann

This comment has been minimized.

Show comment
Hide comment
@lennartkoopmann

lennartkoopmann Sep 7, 2018

Member

User error. The restart is happening automatically already.

Should we still ask?

Member

lennartkoopmann commented Sep 7, 2018

User error. The restart is happening automatically already.

Should we still ask?

@mariussturm

This comment has been minimized.

Show comment
Hide comment
@mariussturm

mariussturm Sep 7, 2018

Member

Right, the current behavior is that a configuration change is detected automatically and because of that the Sidecar restarts the process. An option would be to interfere into this procedure and mark a collector with a no-auto-restart flag. The only problem is that the user would need a feedback in the UI if a restart is needed or not. In that way we could roll out configurations and let them validate but the actual restart is up to the user.

Member

mariussturm commented Sep 7, 2018

Right, the current behavior is that a configuration change is detected automatically and because of that the Sidecar restarts the process. An option would be to interfere into this procedure and mark a collector with a no-auto-restart flag. The only problem is that the user would need a feedback in the UI if a restart is needed or not. In that way we could roll out configurations and let them validate but the actual restart is up to the user.

@mariussturm

This comment has been minimized.

Show comment
Hide comment
@mariussturm

mariussturm Sep 7, 2018

Member

Thinking this a little bit further, the big boys use-case is in a scenario with lots and lots of collectors. An admin would be afraid to do a configuration change because he doesn't know if all instances will fail or not. The current way of doing it is to create a second collector configuration -> apply it to one or two hosts only, test a configuration change. Afterwards put the changes in the production configuration.

We could support this process by providing a new view, e.g. Collector Workspace where all of this is automated. With one click a configuration and the corresponding collector is copied -> fiddle around -> assign it to one or two hosts -> Promote it to production.

We will try to mock something up to see if that would e feasible way. Probably nothing for 3.0.

Member

mariussturm commented Sep 7, 2018

Thinking this a little bit further, the big boys use-case is in a scenario with lots and lots of collectors. An admin would be afraid to do a configuration change because he doesn't know if all instances will fail or not. The current way of doing it is to create a second collector configuration -> apply it to one or two hosts only, test a configuration change. Afterwards put the changes in the production configuration.

We could support this process by providing a new view, e.g. Collector Workspace where all of this is automated. With one click a configuration and the corresponding collector is copied -> fiddle around -> assign it to one or two hosts -> Promote it to production.

We will try to mock something up to see if that would e feasible way. Probably nothing for 3.0.

@bernd

This comment has been minimized.

Show comment
Hide comment
@bernd

bernd Sep 7, 2018

Member

I agree, before we think about how we would solve the "ask for restart" we should think about use cases and why someone might want to not restart a collector automatically after a config change. 👍

Member

bernd commented Sep 7, 2018

I agree, before we think about how we would solve the "ask for restart" we should think about use cases and why someone might want to not restart a collector automatically after a config change. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment