Yeah, I do see that argument. You already have this problem with gradual
upgrades though, so I don't think it's particularly bad.

I mostly don't like having multiple pieces lying around that do lower-level
plumbing/waiting. With everything in one place, it makes it much easier to
eg write policies as to how various internal processes work (wait for this
event, wait for that event), which I think would be the real way to
simplify upgrades.

On Tuesday, May 27, 2014, Andreas Fuchs <notifications@github.com> wrote:

> In lib/einhorn/command.rb:
>
> > @@ -225,12 +225,25 @@ def self.reload
> >        ENV.clear
> >        ENV.update(Einhorn::TransientState.environ)
> >
> > +      upgrade_sentinel = fork do
>
> Gonna extract this into its own method.
>
> I considered integrating the sentinel into Einhorn's mourning process, but
> besides it complicating the entire upgrade process (which started out as
> fairly obscure already!), I don't see much of a benefit. /:
>
> I think that with upgrade and reload being blocking operations to
> einhornsh (which is great!), it would be pretty unexpected if commands
> issued between issuing the upgrade command and finishing the upgrade
> would be served: e.g., what would incrementing the worker count pre-upgrade
> do?
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/stripe/einhorn/pull/37/files#r13088715>
> .
>


-- 
Sent from mobile