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. On 27 Sep 2014 15:28, "Ken Barber" <k...@puppetlabs.com> wrote:
> > 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. > > -- > 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+unsubscr...@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 > . > For more options, visit https://groups.google.com/d/optout. > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAAAzDLdjwJT2DAFpzWUGZ9LeytunwthyGEuWHiO_8ZHm-tU3hw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
