Note: this re-post is due to an error I made earlier today. I've gutted
out a bunch of stuff as well. My apologies for the duplication.
On 4/28/2015 11:34 AM, Laurent Bercot wrote:
I'm also interested in Avery's experience with dependency handling.
Hm. Today isn't the best day to write th
Dang it. Hit the send button.
It will be a bit, I'll follow up with the completed email. Sorry for
the half-baked posting.
On 4/28/2015 11:34 AM, Laurent Bercot wrote:
I'm also interested in Avery's experience with dependency handling.
Hm. Today isn't the best day to write this (having been up since 4am)
but I'll try to digest all the little bits and pieces into something.
Here we go...
First, I will quali
On 28/04/2015 20:49, Avery Payne wrote:
Good point, I'm going to stop discussion here and go "over there", where the
discussion belongs.
That's not what I meant :)
Keep your thread here, it interests people who are not subscribed
to skaware, and it will be simpler. But please come "over ther
On 4/28/2015 11:34 AM, Laurent Bercot wrote:
If a lot of people would like to participate but don't want to
subscribe to the skaware mailing-list, I'll move the thread here.
Good point, I'm going to stop discussion here and go "over there", where
the discussion belongs.
On 4/28/2015 10:50 AM, bougyman wrote:
Well at least we're talking the same language now, though reversing
"parent/child" is disconcerting to my OCD.
Sorry if the terminology is "reversed".
Here's the current version of run.sh, with dependency support baked
in:
https://bitbucket.org/avery_
On 28/04/2015 19:31, Steve Litt wrote:
You know it's a shame that neither daemontools, nor as far as I know
runit, allows you to declare the order services cycle in.
Dependency management is not the job of a supervision suite. It is
the job of a service manager that runs on top of a supervisio
On 4/28/2015 10:31 AM, Steve Litt wrote:
Good! I was about to ask the definitions of parent and child, but the
preceding makes it clear.
I'm taking it from the viewpoint that says "the service that the user
wishes to start is the parent of all other service dependencies that
must start".
On Tue, Apr 28, 2015 at 12:31 PM, Steve Litt wrote:
> Good! I was about to ask the definitions of parent and child, but the
> preceding makes it clear.
Well at least we're talking the same language now, though reversing
"parent/child" is
disconcerting to my OCD.
>>
>> Here's the current version
On Tue, 28 Apr 2015 07:57:31 -0700
Avery Payne wrote:
> On 4/28/2015 7:18 AM, bougyman wrote:
> > On Tue, Apr 28, 2015 at 8:38 AM, Avery Payne
> > wrote:
> >
> > I guess I don't know what this means, in practice. My child services
> > generally know about the
> > parent in their ./run script and
On 4/28/2015 7:18 AM, bougyman wrote:
On Tue, Apr 28, 2015 at 8:38 AM, Avery Payne wrote:
I guess I don't know what this means, in practice. My child services
generally know about the
parent in their ./run script and the parent (sometimes) has to know
about the children in his
./finish script.
On Tue, Apr 28, 2015 at 8:38 AM, Avery Payne wrote:
> The steps described are explicit and hard-coded into a service's ./run
> script. This design works "just OK" and ensures complicated start-up
> sequences can be carried out, but it does not allow easy replacement of
> child services. The cat
On 4/22/2015 5:56 AM, bougyman wrote:
What more is needed and what would making this "first class" add or
improve upon? Tj
This question has been in the back of my mind for several days now,
giving it some off-and-on consideration.
The steps described are explicit and hard-coded into a serv
13 matches
Mail list logo
