Puppet facts uploading to PuppetDB

[Ken Barber]

Do many people use or care about the ability to upload facts out of
band to PuppetDB from a machine without the need for a full catalog
compilation? Its not a highly documented facility, ie. doesn't work
out of the box without configuration changes, but I know some people
have asked me this on IRC etc.

If you are using this facility, are you running masterless or with a
puppet master out of curiosity? Also - why are you using this
facility, what does it give you - what problems are you trying to
solve beyond just relying on the facts from a catalog compilation?

I'm just curious because some of this functionality is changing in a
future Puppet (basically it will stop working), trying to determine
whether its worth the time to port this functionality over to
something new. Or whether we should promote a new project outside of
the PL core items to do this (like a new module or plugin for
example).

ken.

[Chuck]

We are pushing facts into puppetdb for initial loads so that we can track system loads before puppet runs the first time.

[Jason Antman]

Hmm... I didn't even know this existed. Ironically, given your question, it sounds like something I'd want to use. But if it's going away, I guess I'll just totally forget that I heard it...

Use case: We still have a bunch of legacy systems that aren't puppetized and probably never will be (lots of "base" stuff that we do on "every" host that would break these snowflakes). For everything else, PuppetDB is our one and only inventory system. These legacy boxes exist only in a... spreadsheet. If I knew there was a way to get facts from them into PuppetDB without risking what would happen with a full puppet run, I probably would've done it by now...

-Jason

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/c94810dd-3e34-44db-bc63-bd6efa9d7df5%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Ken Barber]

> Hmm... I didn't even know this existed. Ironically, given your question, it
> sounds like something I'd want to use. But if it's going away, I guess I'll
> just totally forget that I heard it...

Oh to be clear Jason, the functionality is of course still staying for
PuppetDB :-). Its just the transmission via the master that has been
removed. There are a number of future architecture cases that might
allow this via an alternate path, that are being debated however - but
we don't want to rush into something like this, or make promises we
can't keep :-). Understanding the use-cases in the real world is
obviously important to these considerations.

> Use case: We still have a bunch of legacy systems that aren't puppetized and
> probably never will be (lots of "base" stuff that we do on "every" host that
> would break these snowflakes). For everything else, PuppetDB is our one and
> only inventory system. These legacy boxes exist only in a... spreadsheet. If
> I knew there was a way to get facts from them into PuppetDB without risking
> what would happen with a full puppet run, I probably would've done it by
> now...

So this sounds like you could just get away with something that
doesn't require the Puppet runtime, that can submit facts directly to
PuppetDB. At the moment this is completely possible with our commands
submission API, but afaik tooling is generally done by users only in a
bespoke way, at least I don't know anything that has been published.

Truth is its actually dead easy to do this, (*hint hint* for those who
have been looking for a personal project to work on, I'm sure we'd
love to see such a thing - and would happily promote it here:
https://docs.puppetlabs.com/puppetdb/2.2/community_add_ons.html). I
have something ~10 lines that already does this for example in Ruby
(using the Facter class from the facter gem/library), but since we're
moving to a cfacter world, might be good to consider doing it
different for future compatibility (not to mention a C++11 based
facter will provide more portability opportunities).

The main complication as ever, is the SSL authentication and the PKI
handling of keys/certs etc. Obviously with Puppet you get the key/cert
signing baked in - although one might consider yet another tool or
bespoke methodology to make this work as an alternate to the Puppet
client.

ken.

[Erik Dalén]

We do this, but could probably live without it. But we do it using the facts indirector and setting it up to cache to puppetdb.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAE4bNT%3DKfbj-4f4BUgX2PgrM%3DKbcNt6RXxhTKfHL%3D4xpyrpSxA%40mail.gmail.com.

[Ken Barber]

> We do this, but could probably live without it. But we do it using the facts
> indirector and setting it up to cache to puppetdb.

So in both cases you use 'puppet facts upload'?

ken.

[Corey Osman]

I am using this in a puppet post run command to upload the facts that changed after the puppet run.

I have run into this problem on many occasions where I like to build a custom UI around displaying custom facts.

Because facts only get uploaded to puppetdb before the puppet agent runs so there has always been a delay of one puppet run in realizing what the 

environment actually looks like.

So to fix this we used the puppet facts upload functionality.  There are many custom facts that interact with the software that puppet was deploying.

So in a way we are using facts outside of puppet but we are using puppetdb's REST API to retrieve those facts and display to our developers.

Basically we use facts as infrastructure metadata that we can display to our developers and devops team to make informed decisions about what's deployed where 

and who broke the environment by showing latest git revisions of the deployed code.  

If you would like to talk further about this please reach out to me via email.

Corey