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

Don't (re)install an extension if it's already running #205

Closed
stefannica opened this issue Sep 1, 2021 · 3 comments · Fixed by #281
Closed

Don't (re)install an extension if it's already running #205

stefannica opened this issue Sep 1, 2021 · 3 comments · Fixed by #281
Assignees
Labels
area/extension FuseML extensions for 3rd party tool integration area/installer Installation related requests enhancement New feature or request

Comments

@stefannica
Copy link
Member

When installing an extension through the fuseml-installer, there are some use cases concerning existing installations of that extension and its dependencies that need to be addressed:

  1. what happens if the extension or one of its dependencies is already running in the cluster, installed by means other than FuseML
  2. what happens if the extension of one of its dependencies has already been previously installed through the FuseML installer

Addressing this using a general strategy is preferable, but not easy to define. First, we need a general mechanism that we can use to "detect" existing installations, both those that are managed by FuseML and those that are not. Here are some suggestions:

  • extend the installer extension DSL to allow specifying some mechanism that can be used to "detect" if/where an extension is running:
    • in the case of helm charts, this can probably be done automatically, by listing the chart installments
    • a generic k8s resource selector (e.g. namespace, service or deployment) could be configured
  • alternatively, we could assume that FuseML is the sole means of installing extensions in the cluster(s) that it's managing, and ignore existing installations that are not managed by FuseML, in which case the installer only needs to "detect" FuseML managed extensions, which can be achieved by implementing a FuseML specific convention, like labeling the namespace(s) where that extension is running

What to do when an extension or dependency is "detected":

  • decide on a default behavior, e.g. skip the installation altogether
  • allow the user to override that behavior (e.g. by supplying a --force-reinstall) flag
@stefannica stefannica added enhancement New feature or request area/installer Installation related requests area/extension FuseML extensions for 3rd party tool integration labels Sep 1, 2021
@stefannica stefannica added this to Backlog in FuseML Project Board via automation Sep 1, 2021
@stefannica stefannica moved this from Backlog to V2 in FuseML Project Board Sep 1, 2021
@jsuchome
Copy link
Member

jsuchome commented Sep 1, 2021

in the case of helm charts, this can probably be done automatically, by listing the chart installments

This is actually already implemented

@jsuchome jsuchome self-assigned this Oct 19, 2021
@jsuchome jsuchome moved this from V3 to In progress in FuseML Project Board Oct 19, 2021
@jsuchome
Copy link
Member

jsuchome commented Oct 19, 2021

#274 solves at least some of the issues mentioned:

  • what happens if the extension or one of its dependencies is already running in the cluster, installed by means other than FuseML

So, this should be solved; if such kind of dependency is already there, FuseML skips its installation, assuming the requirements are met.
The check is done by checking the namespace only, so it may be kind of weak for now, but we will see how it goes.

  • what happens if the extension of one of its dependencies has already been previously installed through the FuseML installer

OK, so in this case, FuseML tries to reinstall the extension (unless it's a helm chart!). We need to think if it is good/bad/good enough...

I think it does not necessary mean it is bad: what could possibly go wrong here? If the same manifest is applied again, Kubernetes itself is able to recognize if some object needs to be (re)created or not.

The possibly good part of it is that this might be a way to "fix" broken installations of an extension...

@jsuchome
Copy link
Member

So, --force-reinstall is currently the default option for the extensions that were already installed by FuseML before.

We can add an option to turn it off and behave just like with 3rd party extensions: whenever an existing namespace is detected, skip the installation.

Now, the question is, what should be the default: "force reinstallation" or "keep detected"?

jsuchome added a commit to jsuchome/fuseml that referenced this issue Oct 20, 2021
Until now, reinstalation was the default option for non-helm based
exensions. This PR;

- changes the default behavior: if fuseml finds existing extension,
it will not touch it
- add new command line argument ("--force-reinstall") that allows
user to reinstall extensions that were previously installed by FuseML.

The extensions installed by third party won't be touched in either case.

Closes fuseml#205
jsuchome added a commit to jsuchome/fuseml that referenced this issue Oct 20, 2021
Until now, reinstalation was the default option for non-helm based
exensions. This PR;

- changes the default behavior: if fuseml finds existing extension,
it will not touch it
- add new command line argument ("--force-reinstall") that allows
user to reinstall extensions that were previously installed by FuseML.

The extensions installed by third party won't be touched in either case.

Closes fuseml#205
jsuchome added a commit to jsuchome/fuseml that referenced this issue Oct 22, 2021
Until now, reinstalation was the default option for non-helm based
exensions. This PR;

- changes the default behavior: if fuseml finds existing extension,
it will not touch it
- add new command line argument ("--force-reinstall") that allows
user to reinstall extensions that were previously installed by FuseML.

The extensions installed by third party won't be touched in either case.

Closes fuseml#205
FuseML Project Board automation moved this from In progress to Done Oct 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/extension FuseML extensions for 3rd party tool integration area/installer Installation related requests enhancement New feature or request
Projects
Development

Successfully merging a pull request may close this issue.

2 participants