rockstor/rockon-registry

Unpackerr

Opened this issue · 3 comments

kanecko commented

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.

kanecko commented

Problem # 1: edit:solved
Unpackerr needs to use an existing share (e.g. from Transmission), because it watches for archives.

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?
"If a Config or Data Share is assigned to more than one Rock-on, it could cause strange behavior."

Problem # 2: edit: a proposal
All of the following env vars are optional...
image

phillxnet commented

@kanecko Hello there.
Re:

"If a Config or Data Share is assigned to more than one Rock-on, it could cause strange behavior."

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:
rockstor/rockstor-core#2481

Hope that helps.
@Hooverdan96 and @FroggyFlox are more up on these matters than myself so if they comment further here then I'd go with what they say :) .

  • 👍2
kanecko commented

Am putting this on hold until #2094 #2280 #2012 are implemented.
Thus, I am implementing them next.

  • 👍3