-
Notifications
You must be signed in to change notification settings - Fork 97
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
Unpackerr #343
Comments
Problem # 1: edit:solved This means, when installing the Unpackerr RockOn, the user should NOT create a separate share. Instead, the user should use an existing share, which will be almost always used by another RockOn at the same time. Long question short... what does the following mean, and what are our options here? Problem # 2: edit: a proposal |
@kanecko Hello there.
This is to guide folks into having a seperation of concerns. I.e. having dedicated shares means no form one Rock-on can accidentally contaminate another. But there are for sure instances where one may want to access say the output of one Rock-on via the input/output of another. This should be doable but the warning is to help folks avoid things like two Rock-ons using say a configuration share and they end up re-configuring each other by way of competing/overlapping configuration files. That's it basically. There is also now, in our testing channel and Stable RC releases , the following front-end filter: Hope that helps. |
Am putting this on hold until #2094 #2280 #2012 are implemented. |
Clarification, with links, on rockstor-core dependencies (previously indicated).
|
Hello all,
I will be adding the Unpackerr to the repo at some point :)
It will be based on the official multi-arch docker image https://hub.docker.com/r/golift/unpackerr
As far as I know, "--host" will not be needed.
The text was updated successfully, but these errors were encountered: