Re: Re: Re: Re: Re: Re: RE: RE: knife winrm roles

Chef Infra (archive)
1

I can confirm that the FQDNs are not set. How do I do that?

Hi,

They both get three hits but winrm returns saying no nodes returned from search. Why doesn’t winrm think there are nodes when chef-expander is returning three hits?

Can you confirm that these nodes have the fqdn attribute set (using knife node show)?

Cheers,

Steve

2

Hi,

On Mon, Apr 2, 2012 at 8:51 AM, Soula, William wsoula@mobicorp.com wrote:

I can confirm that the FQDNs are not set. How do I do that?

That explains why knife winrm is reporting no results. (see
http://tickets.opscode.com/browse/CHEF-2847) Typically the fqdn
should be set by Ohai during the Chef client run.

Hi,

They both get three hits but winrm returns saying no nodes returned from
search. Why doesn't winrm think there are nodes when chef-expander is
returning three hits?

Can you confirm that these nodes have the fqdn attribute set (using knife
node show)?

Cheers,

Steve

3

Hi all,

Using chef 0.10.4 (slightly out of date i know)

I would expect the following to start service mongodb as soon as the package is installed… but instead it wilfully ignored the notified directive, while installing the package

Anybody have any ideas?

case node[‘platform’]
when “debian”, “ubuntu”

package “mongodb” do
package_name "mongodb-10gen"
notifies :start, “service[mongodb]”, :immediately
end

end

service “mongodb” do
supports :restart => true, :status => true
action :nothing
end

4

The notification from the package resource will only be sent if the package
is being installed or upgraded. So if you already have the latest version
of your package then the notification won't be executed.

I am also a little confused by your logic. In most cookbooks I have seen
the service resource will start itself using the ':start' action and the
package would if necessary send a ':restart' notification. It seems strange
to rely on the package to start the service.

On Mon, May 7, 2012 at 1:10 PM, Geoff Meakin <
geoffmeakin@aciddevelopments.co.uk> wrote:

Hi all,

Using chef 0.10.4 (slightly out of date i know)

I would expect the following to start service mongodb as soon as the
package is installed… but instead it wilfully ignored the notified
directive, while installing the package

Anybody have any ideas?

case node['platform']
when "debian", "ubuntu"

package "mongodb" do
package_name "mongodb-10gen"
notifies :start, "service[mongodb]", :immediately
end

end

service "mongodb" do
supports :restart => true, :status => true
action :nothing
end

--
-Bryan

5

Hi Bryan,

The notification from the package resource will only be sent if the package is being installed or upgraded. So if you already have the latest version of your package then the notification won't be executed.

Thanks for answering my email! This is what currently happens:

[Tue, 08 May 2012 03:31:02 +0100] INFO: Processing package[mongodb] action install (mongodb::10gen_repo line 23)
[Tue, 08 May 2012 03:31:11 +0100] INFO: package[mongodb] installed version 2.0.4
[Tue, 08 May 2012 03:31:11 +0100] INFO: Processing bash[add mongodb superuser] action run (mongodb::10gen_repo line 33)

(add mongodb superuser is my next task, and is wrong as service[mongodb] should have been notified immediately).

I am also a little confused by your logic. In most cookbooks I have seen the service resource will start itself using the ':start' action and the package would if necessary send a ':restart' notification. It seems strange to rely on the package to start the service.

I guess what I was trying to achieve is the following:

  1. On a chef run, dont assume that the database should always be started. There might have been good reasons it was taken down by a sysadmin
  2. When first installing mongodb package, the service needs starting so some setup items can take place (create users etc.)

I welcome any comments… or maybe Ive found a bug?

Cheers
Geoff

I would expect the following to start service mongodb as soon as the package is installed… but instead it wilfully ignored the notified directive, while installing the package

Anybody have any ideas?

case node['platform']
when "debian", "ubuntu"

package "mongodb" do
package_name "mongodb-10gen"
notifies :start, "service[mongodb]", :immediately
end

end

service "mongodb" do
supports :restart => true, :status => true
action :nothing
end

6

On 05/07/2012 07:35 PM, Geoff Meakin wrote:

I guess what I was trying to achieve is the following:

  1. On a chef run, dont assume that the database should always be started.
    There might have been good reasons it was taken down by a sysadmin
  2. When first installing mongodb package, the service needs starting so some
    setup items can take place (create users etc.)

I welcome any comments… or maybe Ive found a bug?

Just specifying the service should be started will cause chef to check the
status of the service, and start it if it's not started. No need to key that
off of the package. Set the action for the service to [:start, :enable], and
chef will ensure it's always started and enabled. Then, as suggested
elsewhere, if you upgrade the package, it probably makes sense to restart the
service.

--
Phil Dibowitz phil@ipom.com
Open Source software and tech docs Insanity Palace of Metallica
http://www.phildev.net/ http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't matter
and those who matter don't mind."

  • Dr. Seuss
7

Hi Phil,

I think you misunderstood (1)

  1. On a chef run, dont assume that the database should always be started.
    There might have been good reasons it was taken down by a sysadmin

I'm trying to NOT ensure the database is always started.
For example as a sysadmin i may have taken my database down for very good reasons whilst I sort some stuff out. I dont want chef restarting it automatically

Cheers

8

On May 8, 2012, at 2:07 PM, Geoff Meakin wrote:

Hi Phil,

I think you misunderstood (1)

  1. On a chef run, dont assume that the database should always be started.
    There might have been good reasons it was taken down by a sysadmin

I'm trying to NOT ensure the database is always started.
For example as a sysadmin i may have taken my database down for very good reasons whilst I sort some stuff out. I dont want chef restarting it automatically

I think you are missing then the main feature of Chef configuration management - to ensure system is always in a correct state.

A better way for solving your problem will be to use "not_if/only_if" for "service" resource. For example, do no start the service if there is a specific file present on the system. When you need to have your database down, just create that file, and chef will not do anything. Removing the file will mean for chef to do all required things.

Cheers

--
Vladimir Girnet
Infrastructure Engineer
Tacit Knowledge

9

On 05/08/2012 04:29 AM, Vladimir Girnet wrote:

On May 8, 2012, at 2:07 PM, Geoff Meakin wrote:

Hi Phil,

I think you misunderstood (1)

  1. On a chef run, dont assume that the database should always be started.
    There might have been good reasons it was taken down by a sysadmin

I'm trying to NOT ensure the database is always started.
For example as a sysadmin i may have taken my database down for very good
reasons whilst I sort some stuff out. I dont want chef restarting it
automatically

I think you are missing then the main feature of Chef configuration management

  • to ensure system is always in a correct state.

A better way for solving your problem will be to use "not_if/only_if" for
"service" resource. For example, do no start the service if there is a
specific file present on the system. When you need to have your database down,
just create that file, and chef will not do anything. Removing the file will
mean for chef to do all required things.

Right. For example, make it dependent on /tmp/no_start_mongo and touch that
file when you're doing mongo maintenance.

--
Phil Dibowitz phil@ipom.com
Open Source software and tech docs Insanity Palace of Metallica
http://www.phildev.net/ http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't matter
and those who matter don't mind."

  • Dr. Seuss
10

On Tue, May 8, 2012 at 4:54 PM, Phil Dibowitz phil@ipom.com wrote:

On 05/08/2012 04:29 AM, Vladimir Girnet wrote:

On May 8, 2012, at 2:07 PM, Geoff Meakin wrote:

Hi Phil,

I think you misunderstood (1)

  1. On a chef run, dont assume that the database should always be started.
    There might have been good reasons it was taken down by a sysadmin

I'm trying to NOT ensure the database is always started.
For example as a sysadmin i may have taken my database down for very good
reasons whilst I sort some stuff out. I dont want chef restarting it
automatically

I think you are missing then the main feature of Chef configuration management

  • to ensure system is always in a correct state.

A better way for solving your problem will be to use "not_if/only_if" for
"service" resource. For example, do no start the service if there is a
specific file present on the system. When you need to have your database down,
just create that file, and chef will not do anything. Removing the file will
mean for chef to do all required things.

Right. For example, make it dependent on /tmp/no_start_mongo and touch that
file when you're doing mongo maintenance.

That's good advice, and possibly an acceptable solution, but I'm also
interested in an explanation for the behaviour that Geoff reported.

I'd have expected a package resource to fire its notifications on
install, not just update (surely both are changes).
The wiki documentation doesn't list any caveats about notifications
for the Package resource.

Are we missing something, or is this a bug?

Zac

11

On Tue, May 8, 2012 at 12:16 PM, Zac Stevens zts@cryptocracy.com wrote:

Are we missing something, or is this a bug?

Could you run 'chef-client -l debug' and provide the relevant output?
This will show more of what Chef is doing and why its making the
choices it does may be obvious in there.

Bryan