Facts not populating for specific host type

Support
#1

Hi All

I've upgraded to Foreman v1.1, and have noticed that facts for my NetApp
filers aren't being populated in Foreman…

Have used the Foreman installer module to setup and configure Foreman with
Puppet under Passenger.
Node.rb is set to ":facts => true", and I'm getting successful fact storage
for other nodes…

However any fact reports from my NetApp filers get rejected with a HTTP 400
code:
192.168.150.123 - - [05/Apr/2013:09:30:04 +0100] "POST /fact_values/create
HTTP/1.1" 400 919 "-" "-"

I've had a look at the base Facts.yaml files, and cant notice anything
syntactically different between a netapp report that isnt work and one that
is working…
Couple of examples:
$ cat /var/lib/puppet/yaml/facts/actint-star-nactl01.yaml
— !ruby/object:Puppet::Node::Facts
values:
memorysize: "1151"
clientcert: actint-star-nactl01
hostname: actint-star-nactl01
system_revision: ""
system_machine_type: SIMBOX
hardwaremodel: SIMBOX
partner_system_id: ""
number_of_processors: "2"
operatingsystem: "NetApp Release 8.0.4RC1 7-Mode: Wed Sep 5 10:55:52
PDT 2012"
partner_serial_number: ""
system_id: "4061490550"
clientversion: "3.1.0"
!ruby/sym "_timestamp": 2013-04-05 09:32:55.682040 +01:00
system_serial_number: "4061490-55-0"
processor: ""
expiration: 2013-04-05 11:32:55.620438 +01:00
name: actint-star-nactl01

$ cat /var/lib/puppet/yaml/facts/actint-star-f501.card.co.uk.yaml
— !ruby/object:Puppet::Node::Facts
values:
system_name: Linux
pva_version: ""
hardware_name: cpus
annunciator_board_serial: ""
fqdn: actint-star-f501.card.co.uk
macaddress: "00:50:56:8F:00:24"
partition: Common
disk_size_shared: "20158 MB"
uptime_seconds: "1275125"
clientcert: actint-star-f501.card.co.uk
os_release: "2.6.32-71.18.2.el6.f5.x86_64"
hardware_cpus: cpus
hostname: actint-star-f501
version: BIG-IP_v11.1.0
hardware_slot: "0"
switch_board_serial: ""
annunciator_board_part_revision: ""
hardwaremodel: x86_64
os_version: "#1 SMP Wed Feb 20 01:30:12 PST 2013"
host_board_part_revision: ""
group_id: DefaultGroup
disk_size_var: "3023 MB"
disk_free_config: "2796 MB"
disk_size_varlibmysql: "12095 MB"
chassis_serial: "420f6693-8d63-a1e9-bbe03a83193a"
uptime_hours: "354"
disk_size_usr: "1685 MB"
disk_free_usr: "531 MB"
uptime_days: "14"
platform: Z100
hardware_model: "Six-Core AMD Opteron™ Processor 2435"
disk_free_shared: "17528 MB"
system_id: F52941D5-1974-EED0-D29B-75ED436856F0
hardware_cpus_slot: "0"
disk_size_varlog: "7055 MB"
clientversion: "3.1.0"
domain: card.co.uk
!ruby/sym "timestamp": 2013-04-05 09:12:22.660220 +01:00
disk_free: "46 MB"
hardware_cpu_mhz: "2600.169"
disk_size_: "247 MB"
host_board_serial: ""
marketing_name: "BIG-IP Virtual Edition"
disk_free_varlibmysql: "10741 MB"
switch_board_part_revision: ""
uptime: "14 days"
timezone: BST
product_category: "Virtual Edition"
disk_free_var: "2609 MB"
disk_size_config: "3023 MB"
hardware_cores: "2"
hardware_cpus_model: "Six-Core AMD Opteron™ Processor 2435"
hardware_versions:
"#<SOAP::Mapping::Object:0x7fc25367cd08>#<SOAP::Mapping::Object:0x7fc25367b278>#<SOAP::Mapping::Object:0x7fc253679a90>"
disk_free_varlog: "6409 MB"
hardware_cache_size: "512 KB"
expiration: 2013-04-05 11:12:22.406777 +01:00
name: actint-star-f501.card.co.uk

I'm pretty sure these facts used to work pre v1.1, so not sure what has
changed to make them not work now… My fact code hasn't changed in a
while, and closely mirrors the Puppetlabs-F5 fact code…

Any ideas???

Cheers
Gavin

#2

I assume that's from your Apache logs? What's in Foreman's logs for the
same request?

Greg

··· On 5 April 2013 09:45, Gavin Williams wrote:

Hi All

I’ve upgraded to Foreman v1.1, and have noticed that facts for my NetApp
filers aren’t being populated in Foreman…

Have used the Foreman installer module to setup and configure Foreman with
Puppet under Passenger.
Node.rb is set to “:facts => true”, and I’m getting successful fact
storage for other nodes…

However any fact reports from my NetApp filers get rejected with a HTTP
400 code:
192.168.150.123 - - [05/Apr/2013:09:30:04 +0100] “POST /fact_values/create
HTTP/1.1” 400 919 “-” “-”

#3

Ahh, that gives me a bit more information…

··· --- ==> /var/log/foreman/production.log <==

Started POST “/fact_values/create” for 192.168.150.123 at Fri Apr 05
11:35:56 +0100 2013
Processing by FactValuesController#create as
Parameters: {“facts”=>"[FILTERED]"}
Failed to import facts: Mysql::Error: Column ‘name’ cannot be null: INSERT
INTO hosts (created_at, environment_id, model_id,
organization_id, ptable_id, installed_at, comment, enabled, ip,
last_freshcheck, root_pass, owner_id, mac, puppet_proxy_id,
last_compile, image_id, puppet_status, environment, serial,
build, last_report, image_file, managed, use_image, owner_type,
location_id, subnet_id, updated_at, medium_id, domain_id,
compute_resource_id, source_file_id, uuid, hostgroup_id,
puppet_ca_proxy_id, name, certname, operatingsystem_id, disk,
architecture_id) VALUES (‘2013-04-05 10:35:56’, NULL, NULL, NULL, NULL,
NULL, NULL, 1, NULL, NULL, NULL, NULL, ‘’, NULL, NULL, NULL, 0, NULL, NULL,
0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, ‘2013-04-05 10:35:56’, NULL,
NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL)
Rendered text template (0.0ms)
Completed 400 Bad Request in 17ms (Views: 1.0ms | ActiveRecord: 1.5ms)

==> /var/log/httpd/access_log <==
192.168.150.123 - - [05/Apr/2013:11:35:56 +0100] “POST /fact_values/create
HTTP/1.1” 400 919 “-” “-”

Not sure why it’s all NULL’s though :s

Thoughts?

Gav

On 5 April 2013 11:16, Greg Sutcliffe greg.sutcliffe@gmail.com wrote:

On 5 April 2013 09:45, Gavin Williams fatmcgav@gmail.com wrote:

Hi All

I’ve upgraded to Foreman v1.1, and have noticed that facts for my NetApp
filers aren’t being populated in Foreman…

Have used the Foreman installer module to setup and configure Foreman
with Puppet under Passenger.
Node.rb is set to “:facts => true”, and I’m getting successful fact
storage for other nodes…

However any fact reports from my NetApp filers get rejected with a HTTP
400 code:
192.168.150.123 - - [05/Apr/2013:09:30:04 +0100] “POST
/fact_values/create HTTP/1.1” 400 919 “-” “-”

I assume that’s from your Apache logs? What’s in Foreman’s logs for the
same request?

Greg

–
You received this message because you are subscribed to a topic in the
Google Groups “Foreman users” group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/foreman-users/x-eVGDbWcf0/unsubscribe?hl=en
.
To unsubscribe from this group and all its topics, send an email to
foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

#4

Greg

Could this be due to the fact that this node hasn't got a fqdn?

Was looking through foreman/app/models/host.rb, and importHostAndFacts is
working with the certname and fqdn…
Certname is specificed, however fqdn isnt…

Of course I could be barking up the wrong tree… :wink:

Cheers
Gavin

··· On Friday, 5 April 2013 11:38:35 UTC+1, Gavin Williams wrote: > > Ahh, that gives me a bit more information... > > --- > ==> /var/log/foreman/production.log <== > > > Started POST "/fact_values/create" for 192.168.150.123 at Fri Apr 05 > 11:35:56 +0100 2013 > Processing by FactValuesController#create as > Parameters: {"facts"=>"[FILTERED]"} > Failed to import facts: Mysql::Error: Column 'name' cannot be null: INSERT > INTO `hosts` (`created_at`, `environment_id`, `model_id`, > `organization_id`, `ptable_id`, `installed_at`, `comment`, `enabled`, `ip`, > `last_freshcheck`, `root_pass`, `owner_id`, `mac`, `puppet_proxy_id`, > `last_compile`, `image_id`, `puppet_status`, `environment`, `serial`, > `build`, `last_report`, `image_file`, `managed`, `use_image`, `owner_type`, > `location_id`, `subnet_id`, `updated_at`, `medium_id`, `domain_id`, > `compute_resource_id`, `source_file_id`, `uuid`, `hostgroup_id`, > `puppet_ca_proxy_id`, `name`, `certname`, `operatingsystem_id`, `disk`, > `architecture_id`) VALUES ('2013-04-05 10:35:56', NULL, NULL, NULL, NULL, > NULL, NULL, 1, NULL, NULL, NULL, NULL, '', NULL, NULL, NULL, 0, NULL, NULL, > 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, '2013-04-05 10:35:56', NULL, > NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL) > Rendered text template (0.0ms) > Completed 400 Bad Request in 17ms (Views: 1.0ms | ActiveRecord: 1.5ms) > > ==> /var/log/httpd/access_log <== > 192.168.150.123 - - [05/Apr/2013:11:35:56 +0100] "POST /fact_values/create > HTTP/1.1" 400 919 "-" "-" > --- > > > Not sure why it's all NULL's though :s > > Thoughts? > > Gav > > > On 5 April 2013 11:16, Greg Sutcliffe wrote: > >> On 5 April 2013 09:45, Gavin Williams wrote: >> >>> Hi All >>> >>> I've upgraded to Foreman v1.1, and have noticed that facts for my NetApp >>> filers aren't being populated in Foreman... >>> >>> Have used the Foreman installer module to setup and configure Foreman >>> with Puppet under Passenger. >>> Node.rb is set to ":facts => true", and I'm getting successful fact >>> storage for other nodes... >>> >>> However any fact reports from my NetApp filers get rejected with a HTTP >>> 400 code: >>> 192.168.150.123 - - [05/Apr/2013:09:30:04 +0100] "POST >>> /fact_values/create HTTP/1.1" 400 919 "-" "-" >>> >> >> I assume that's from your Apache logs? What's in Foreman's logs for the >> same request? >> >> Greg >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Foreman users" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/foreman-users/x-eVGDbWcf0/unsubscribe?hl=en >> . >> To unsubscribe from this group and all its topics, send an email to >> foreman-users+unsubscribe@googlegroups.com. >> To post to this group, send email to foreman-users@googlegroups.com. >> Visit this group at http://groups.google.com/group/foreman-users?hl=en. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > >
#5

It's possible. Try changing it (either on the node or in the source code)
and see if it's happy :wink:

··· On 5 April 2013 12:41, Gavin Williams wrote:

Greg

Could this be due to the fact that this node hasn’t got a fqdn?

Was looking through foreman/app/models/host.rb, and importHostAndFacts is
working with the certname and fqdn…
Certname is specificed, however fqdn isnt…

#6

Ahh, looks like that's the culprit…

Added a hacked together fqdn fact for my NetApp filer, and it went straight
in…

However it has now created a new host entry in Foreman :frowning:

So feels like it needs a code change to handle, however unfortunately I'm
not familiar enough with Foreman to be able to suggest what…

Cheers
Gavin

··· On 5 April 2013 13:04, Greg Sutcliffe wrote:

On 5 April 2013 12:41, Gavin Williams fatmcgav@gmail.com wrote:

Greg

Could this be due to the fact that this node hasn’t got a fqdn?

Was looking through foreman/app/models/host.rb, and importHostAndFacts is
working with the certname and fqdn…
Certname is specificed, however fqdn isnt…

It’s possible. Try changing it (either on the node or in the source code)
and see if it’s happy :wink:

–
You received this message because you are subscribed to a topic in the
Google Groups “Foreman users” group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/foreman-users/x-eVGDbWcf0/unsubscribe?hl=en
.
To unsubscribe from this group and all its topics, send an email to
foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

#7

Is there a reason why your machines don't have fully qualified names? :slight_smile:

··· On 5 April 2013 13:55, fatmcgav wrote:

Ahh, looks like that’s the culprit…

Added a hacked together fqdn fact for my NetApp filer, and it went
straight in…

#8

UH, soo far I've not found an easy way to pull it out of the NetApp device
API…
Will take another look though see if I can work up a repeatable fqdn
source…

FYI, I'm also the dev of the netapp device module I'm working with :slight_smile:

··· On 5 April 2013 15:07, Greg Sutcliffe wrote:

On 5 April 2013 13:55, fatmcgav fatmcgav@gmail.com wrote:

Ahh, looks like that’s the culprit…

Added a hacked together fqdn fact for my NetApp filer, and it went
straight in…

Is there a reason why your machines don’t have fully qualified names? :slight_smile:

–
You received this message because you are subscribed to a topic in the
Google Groups “Foreman users” group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/foreman-users/x-eVGDbWcf0/unsubscribe?hl=en
.
To unsubscribe from this group and all its topics, send an email to
foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

#9

Ah right. So I'm thinking that fixing the NetApp facts may be the best way
to go - I think accepting hosts without a domain might be dangerous in the
long run. If you can't fix that, perhaps we can revisit it, maybe add a
flag to the upload method to change the import behaviour. Or for a really
cool fix, use the new STI classes to create Host::Device with different
import rules :slight_smile:

··· On 5 April 2013 15:11, fatmcgav wrote:

UH, soo far I’ve not found an easy way to pull it out of the NetApp device
API…
Will take another look though see if I can work up a repeatable fqdn
source…

FYI, I’m also the dev of the netapp device module I’m working with :slight_smile:

#10

Greg

Yep, am taking a look at fixing the fact gathering now… Was adding more
facts anyways, which lead to me discovering aforementioned fact import
issue…

'… Or for a really cool fix, use the new STI classes to create
Host::Device with different import rules :)'
That sounds quite cool… From what I've read on Puppet Network devices soo
far, they only use a subset of the standard Factor facts… So might be a
good enhancement :slight_smile:

Cheers
Gav

··· On 5 April 2013 15:19, Greg Sutcliffe wrote:

On 5 April 2013 15:11, fatmcgav fatmcgav@gmail.com wrote:

UH, soo far I’ve not found an easy way to pull it out of the NetApp
device API…
Will take another look though see if I can work up a repeatable fqdn
source…

FYI, I’m also the dev of the netapp device module I’m working with :slight_smile:

Ah right. So I’m thinking that fixing the NetApp facts may be the best way
to go - I think accepting hosts without a domain might be dangerous in the
long run. If you can’t fix that, perhaps we can revisit it, maybe add a
flag to the upload method to change the import behaviour. Or for a really
cool fix, use the new STI classes to create Host::Device with different
import rules :slight_smile:

–
You received this message because you are subscribed to a topic in the
Google Groups “Foreman users” group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/foreman-users/x-eVGDbWcf0/unsubscribe?hl=en
.
To unsubscribe from this group and all its topics, send an email to
foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

#11

> Greg
>
> Yep, am taking a look at fixing the fact gathering now… Was adding more
> facts anyways, which lead to me discovering aforementioned fact import
> issue…
>

Cool.

> '… Or for a really cool fix, use the new STI classes to create
> Host::Device with different import rules :)'
> That sounds quite cool… From what I've read on Puppet Network devices
> soo far, they only use a subset of the standard Factor facts… So might be
> a good enhancement :slight_smile:
>

If you fancy having a go, take a look at the Metal-as-a-service plugin[1]
for how I'm adding a new type with different import rules (in this case; a
blank piece of hardware on the network that's waiting to be provisioned).
There's a lot of stuff in there you don't need, but the core
app/models/hosts/discovered.rb shows how I'm inheriting Host::Base. In your
case it might make more sense to inherit from Host::Managed (to keep all of
the current Host methods) but override importHostAndFacts.

Greg

[1] https://github.com/GregSutcliffe/foreman_discovery

··· On 5 April 2013 15:28, fatmcgav wrote:
#12

Cool, will take a look :slight_smile:

Have updated my device facts now so that it seems to be working a bit
better… Need to test with a device with a fqdn as hostname, but it's
working for my current test cases :slight_smile:

Facts hash now looks like:
{
"operatingsystem" => "NetApp",
"number_of_processors" => "2",
"system_revision" => nil,
"system_machine_type" => "SIMBOX",
"domain" => "card.co.uk",
"system_id" => "4061490550",
"system_serial_number" => "4061490-55-0",
"version" => "NetApp Release 8.0.4RC1 7-Mode: Wed Sep 5
10:55:52 PDT 2012",
"processor" => nil,
"fqdn" => "actint-star-nactl01.card.co.uk",
"operatingsystemrelease" => "8.0.4RC1",
"memorysize" => "1151",
"productname" => "SIMBOX",
"partner_system_id" => nil,
"partner_serial_number" => nil,
"hostname" => "actint-star-nactl01"
}

Cheers
Gavin

··· On 5 April 2013 15:33, Greg Sutcliffe wrote:

On 5 April 2013 15:28, fatmcgav fatmcgav@gmail.com wrote:

Greg

Yep, am taking a look at fixing the fact gathering now… Was adding more
facts anyways, which lead to me discovering aforementioned fact import
issue…

Cool.

'… Or for a really cool fix, use the new STI classes to create
Host::Device with different import rules :)'
That sounds quite cool… From what I’ve read on Puppet Network devices
soo far, they only use a subset of the standard Factor facts… So might be
a good enhancement :slight_smile:

If you fancy having a go, take a look at the Metal-as-a-service plugin[1]
for how I’m adding a new type with different import rules (in this case; a
blank piece of hardware on the network that’s waiting to be provisioned).
There’s a lot of stuff in there you don’t need, but the core
app/models/hosts/discovered.rb shows how I’m inheriting Host::Base. In your
case it might make more sense to inherit from Host::Managed (to keep all of
the current Host methods) but override importHostAndFacts.

Greg

[1] https://github.com/GregSutcliffe/foreman_discovery

–
You received this message because you are subscribed to a topic in the
Google Groups “Foreman users” group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/foreman-users/x-eVGDbWcf0/unsubscribe?hl=en
.
To unsubscribe from this group and all its topics, send an email to
foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.