On 24/09/2015 18:45, Avery Payne wrote:
> This is probably the only real problem in the arrangement I'm using
> then. The entire premise is "the support scripts live where the
> definitions live and are called with relative pathing, allowing the
> definitions to be located anywhere".
My point of view is that service directories have their place on a
RAM filesystem, so they should not include heavy data. Stuff like
support scripts is read-only: it doesn't have to be in RAM.
You can have local data with relative pathing... in your own
service directory. As soon as you exit your service directory,
it's global data.
> This was done precisely to
> avoid the mess of "you MUST have your scripts/support scripts live at
> this exact path", which was originally inspired by a message exchange
> we had months ago about separating policy from mechanism. For my
> definitions to work, those four dot-directories have to live where
> the run-time definitions live. In this case, your compiled directory
> is the equivalent of a run-time directory.
>
> I am certainly not adverse to changing their names or locations - the
> entire purpose is to have a set of definitions that work out of the
> box, and I need to make it do whatever is required to achieve that -
> but I cringe at the concept that I would need to use an absolute
> path, because I'll end up making everything brittle as a result. I'm
> open to suggestions on how to fix this.
I'd suggest something like a BASEDIR environment variable, defaulting
to "." or "../svcdef" or whatever the relative path for your support
scripts normally is. All your calls to the support scripts would then
start with ${BASEDIR}. Is it envisionable?
> The only magic needed is that the support directories have to be
> located in the same runtime location, so that the relative path links
> will align and everything will be found. The compiled definitions
> are the equivalent of a runtime location, therefore, they must live
> there.
Nope, it doesn't work that way. s6-rc relocates the service directories
at run time, and it only knows how to handle service directories. If
you have extra data, put it either in a service directory or completely
outside s6-rc's reach.
> (a) stay a symlink pointing to a directory in /data, in this case the
> directory is named /data/1.0.0 or (b) dereference /env entirely,
> turning /env into a real directory filled with the contents of the
> files in data/1.0.0 so that the files are retained. Either solution
> works.
Currently, (a) happens. I don't guarantee it will stay the same, but
it should, and if it ever changes, it will change to (b). So that will
not be a problem.
> It doesn't matter if they have a wrapper, as long as the terminus of
> that chain ends up calling ../.run/run at some point.
Honestly, if you're interested in converting your supervision-scripts
to the s6-rc format, I think it will be easier to work on an automatic
offline converter that takes your scripts and rearranges them in a
format that plays nice with s6-rc-compile than to try and port your
whole directory structure. It's not like you're going to need all the
compatibility layers if you know your target is s6-rc, hence s6.
> One of the stated goals of the project is that there will be
> no such thing as a separate /run file in each definition
Can you clarify what benefit you're getting from that approach?
--
Laurent
Received on Thu Sep 24 2015 - 19:29:01 UTC