Soliciting opinions here. IYESHO, what should happen in this situation?
service “foo” do
supports :restart => false
end
file “blah” do
notifies :restart, "service[foo]"
end
Right now, it depends upon the provider. The init provider will
translate the restart action into a sequence of stop, start actions.
The upstart provider will ignore the “supports” declaration and call
restart anyway.
The current behavior is defensible; the “supports” declaration is
clearly a lie for any Upstart service. I’m just trying to work around
an issue (http://tickets.opscode.com/browse/CHEF-1971) wherein
"restart" doesn’t work the way Chef expects it to for Upstart
services.
I wonder if it would make more sense to handle ‘supports’ at a higher
level and reject any attempt to send an action that is declared as
unsupported. Or at least have the service resource itself, rather
than the individual providers, handle things like translating restart
into stop/start.
Thoughts?
–
Mark J. Reed markjreed@gmail.com
To me, it definitely makes sense to at the very least warn when an unsupported operation is given. Mysterious no-ops are probably the most frustrating part of my current beginner experience with Chef, and tracking them down is often painful (I'm currently tracking down a mysterious no-op on "supports" with a User block and :manage_home => true, and another mysterious no-op on a cookbook_file block).
Turning typos or requests for unsupported operations into mysterious no-ops does beginners no favors.
--- On Tue, 1/11/11, Mark J. Reed markjreed@gmail.com wrote:
From: Mark J. Reed markjreed@gmail.com
Subject: [chef] Notifies with an unsupported action
To: chef@lists.opscode.com
Date: Tuesday, January 11, 2011, 12:13 PM
Soliciting opinions here.
IYESHO, what should happen in this situation?
service "foo" do
supports :restart => false
end
file "blah" do
notifies :restart, "service[foo]"
end
Right now, it depends upon the provider. The init
provider will
translate the restart action into a sequence of stop, start
actions.
The upstart provider will ignore the "supports" declaration
and call
restart anyway.
The current behavior is defensible; the "supports"
declaration is
clearly a lie for any Upstart service. I'm just
trying to work around
an issue (http://tickets.opscode.com/browse/CHEF-1971) wherein
"restart" doesn't work the way Chef expects it to for
Upstart
services.
I wonder if it would make more sense to handle 'supports'
at a higher
level and reject any attempt to send an action that is
declared as
unsupported. Or at least have the service resource
itself, rather
than the individual providers, handle things like
translating restart
into stop/start.
Thoughts?
--
Mark J. Reed markjreed@gmail.com
I agree. In lieu of any official unit testing framework, I'd rather
have a idempotent fast-fail than a no-op on errors. I'm actually
wishing there were support for custom logging inside those blocks to
make debugging much easier.
On Tue, Jan 11, 2011 at 3:16 PM, Noah Gibbs noah_gibbs@yahoo.com wrote:
To me, it definitely makes sense to at the very least warn when an unsupported operation is given. Mysterious no-ops are probably the most frustrating part of my current beginner experience with Chef, and tracking them down is often painful (I'm currently tracking down a mysterious no-op on "supports" with a User block and :manage_home => true, and another mysterious no-op on a cookbook_file block).
Turning typos or requests for unsupported operations into mysterious no-ops does beginners no favors.
--- On Tue, 1/11/11, Mark J. Reed markjreed@gmail.com wrote:
From: Mark J. Reed markjreed@gmail.com
Subject: [chef] Notifies with an unsupported action
To: chef@lists.opscode.com
Date: Tuesday, January 11, 2011, 12:13 PM
Soliciting opinions here.
IYESHO, what should happen in this situation?
service "foo" do
supports :restart => false
end
file "blah" do
notifies :restart, "service[foo]"
end
Right now, it depends upon the provider. The init
provider will
translate the restart action into a sequence of stop, start
actions.
The upstart provider will ignore the "supports" declaration
and call
restart anyway.
The current behavior is defensible; the "supports"
declaration is
clearly a lie for any Upstart service. I'm just
trying to work around
an issue (http://tickets.opscode.com/browse/CHEF-1971) wherein
"restart" doesn't work the way Chef expects it to for
Upstart
services.
I wonder if it would make more sense to handle 'supports'
at a higher
level and reject any attempt to send an action that is
declared as
unsupported. Or at least have the service resource
itself, rather
than the individual providers, handle things like
translating restart
into stop/start.
Thoughts?
--
Mark J. Reed markjreed@gmail.com
On Tue, Jan 11, 2011 at 12:22 PM, John E. Vincent (lusis)
lusis.org+chef-list@gmail.com wrote:
I agree. In lieu of any official unit testing framework, I'd rather
have a idempotent fast-fail than a no-op on errors. I'm actually
wishing there were support for custom logging inside those blocks to
make debugging much easier.
On Tue, Jan 11, 2011 at 3:16 PM, Noah Gibbs noah_gibbs@yahoo.com wrote:
To me, it definitely makes sense to at the very least warn when an unsupported operation is given. Mysterious no-ops are probably the most frustrating part of my current beginner experience with Chef, and tracking them down is often painful (I'm currently tracking down a mysterious no-op on "supports" with a User block and :manage_home => true, and another mysterious no-op on a cookbook_file block).
(Sorry for being so late to this party)
I think that, at minimum, Chef should check that a resource actually
defines the action you're sending via notifies. This can be done
pretty easily for the new notification syntax/internals we added in
0.9.10. Has anyone created a ticket yet?
Dan DeLeo
On Tue, Jan 11, 2011 at 12:13 PM, Mark J. Reed markjreed@gmail.com wrote:
The current behavior is defensible; the "supports" declaration is
clearly a lie for any Upstart service. I'm just trying to work around
an issue (http://tickets.opscode.com/browse/CHEF-1971) wherein
"restart" doesn't work the way Chef expects it to for Upstart
services.
For starters, we should fix CHEF-1971 so that restart using upstart
does fail so much.
Have you tried using restart_command to workaround?
service "foo" do
restart_command "true"
end
'supports' started out as a way to describe what actions the init
script behind the provider supported as we couldn't easily detect
this. It's actually kind of stunning how many ways we've propped up
sysvinit over the years to do things it wasn't ever designed for. I'm
reluctant to modify 'supports' to specify what actions are allowed. Is
there a common use case for this, particularly outside of this
workaround?
I wonder if it would make more sense to handle 'supports' at a higher
level and reject any attempt to send an action that is declared as
unsupported. Or at least have the service resource itself, rather
than the individual providers, handle things like translating restart
into stop/start.
We shouldn't assume that restart is a matter of a successful stop
followed by a start because init systems are become more and more
complex and there may very well be actions performed by a restart that
are unique. I admit, this is likely rare, and in this case the user
could use restart_command to get what they wanted. However there is
the principle of least surprise. If I ask Chef to restart a service
using a particular provider, I would expect it to use restart, where
possible.
Otherwise, I agree with the rest of the thread; the service resource
should probably chatter a little more about what it is doing.
Bryan
On Tue, Jan 18, 2011 at 1:00 AM, Bryan McLellan btm@loftninjas.org wrote:
We shouldn't assume that restart is a matter of a successful stop
followed by a start because init systems are become more and more
Agreed. On the other hand, Upstart has some oddities (
http://tickets.opscode.com/browse/CHEF-1424 )
- restart will not re-read the service.conf file
- restart will not start the service if stopped
I've been bitten by both of these. At the very least, we should
document this (right in the "Service resource" documentation). It
would be nice to paper over it with Chef, but I don't have any bright
ideas.
-=Dan=-
On Tue, Jan 18, 2011 at 8:35 AM, Dan DeMaggio dan@animoto.com wrote:
- restart will not start the service if stopped
That's the subject of the ticket I opened (CHEF-1971). Upstart is
very state-sensitive: you can't start a running service or start or
restart a stopped one. Of course it's presumably going to be
replaced by systemd in the not-too-distant future.
It would be nice to paper over it with Chef, but I don't have any bright
ideas.
It's up to the provider to provide the semantics of the resource. If
the recipe calls for stopping a service and the service is already
stopped, then instead of trying to run the "stop service" command, the
provider should do nothing. That's currently true, but the analogous
check is not in place for restart.
--
Mark J. Reed markjreed@gmail.com