#mcollective

[mcollective-package-agent] richardc pushed 1 new commit to master: https://git.io/vzMGN

mcollective-package-agent/master 8520f75 Richard Clamp: (maint) Stop pointing at the wiki for the installation guide

^^^ ++ :)

what’s the right way to specify a structured fact to the mco facts agent?

os.family and os:family fail the validation

correction, os.family just doesn’t return anything

os returns a hash structure with {}

hmm… if I open up the fact_data.ddl, I can see that structured facts are supposed to be supported with the . syntax…

grilled-cheese: "specify to the agent..." ?? are you writing a facts plugin, or trying to retrieve a fact ?

just trying to retrieve a fact

for use in filter?

and I was incorrect, os.family does return it’s just empty

just for demo purposes

`mco facts os` returns the hash object, `mco facts os.family` returns empty

this is the most useful way to identify the fact names: mco inventory nodename | awk '/Facts:/','/^$/'

how are you populating the facts.yaml file? This is likely the cause of the problem.

with your cron job

although you’re about to get a PR on it

waiting 10 minutes to see if it works

ok, done

jorhett: the facts.yaml file is a valid yaml dump from facter

it also works on basic unstructured facts like ssldir

for some reason structured facts are special though

I think the question is whether it's outputting strings or structured facts into the file. I had to write some code to handle both situations early last year...

that looks right...

added a snip of facts.yaml

jorhett: hence my confusion

yeah... reading the code right now :(

so this works: mco find -S 'fact("os.family").value=RedHat'

but it appears that "mco facts" not so much

in puppet 3 that wasn’t as huge an issue, but with 4 structured facts are the way forward

Looks like I know what PR I'm working on this weekend :(

unfortunately I'm using Chef at $dayjob and facts-ohai supports structured facts just fine

yeah… sorry

I’ve created a bunch of work for you with the mco PR and the merge with voxpupuli

so how much is the PR you sent me hurting you? If it's seriously getting in your way, I could prioritize it. If you're just playing around, I might prefer that you test the new merged version

It’s not phasing me at the moment, but I’m trying to tidy up my PoC, get security officer signoff, and expand into production all before leaving my current job next month

at the moment, I’m using my cronjob PR branch in my environment with R10k

finding this facts bug was an accident of trying to validate mco was setup properly before moving on to authorization and wiring it up to my puppet deployment scripts

I’m glad it isn’t just me though

I’ve chased it a while today trying to figure out what I’d done wrong

yeah, the output of inventory pipe awk facts is the hint

I knew I was using them, but I had to go lookup how

That’s a workaround, but it puts more load on the middleware and client where it should be a simple distributed server load