Client-side tech stack

[Kylo Ginsberg]

[I am forking from the thread announcing Puppet Server 0.2.0, for which this was OT.]

Sorry for the delayed response on this - hard to keep up with email at times :)

On Fri, Oct 10, 2014 at 4:55 PM, Felix Frank <Felix...@alumni.tu-berlin.de> wrote:

On 10/03/2014 03:50 PM, jcbollinger wrote:

I feel compelled to point out that if the "faster language" happens to be C++, then you will need a plug-in interface in some different language (presumably Ruby, but straight C would be more typical).  C++ APIs are sensitive to compiler and compile options used, and they provide essentially no compile-time encapsulation of API classes' private members, so it would not be wise to suppose that you will ever be able to directly support unwrapped, third-party, C++ plugins.  Especially with the current fast pace of Puppet development.

Absolutely correct. C++11 is an *implementation* choice, but not an *interface* choice, for the reasons you've given.

For cfacter (at least initially) the tldr on plugin support is two-fold:

* for custom facts, we dynamically load the ruby library (if not already loaded) and implement the facter API used by custom facts

* implement external facts

The non-tldr version is at https://github.com/puppetlabs/cfacter/blob/master/Extensibility.md and also discusses some future ideas for getting external facts on a par with custom facts (e.g. providing built-in facts as a json blob on stdin).

We definitely could implement a C interface for adding facts as well. There were one or two questions about that at PuppetConf. I'd be curious to know how much demand there is for that approach.

Thinking about the extension points for the agent, notably providers, we may be able to follow a similar-ish model there of:

* dynamically load ruby and implement the provider api (tricky b/c the api needs improved definition/hardening)

* introduce a concept of external providers

* maybe add a C API here as well?

Feedback or ideas in this space would be great!

 

I somehow just realized yesterday that CFacter is a thing already. So I guess we're already somewhere down this road.

Just cloned the repo - doesn't seem to build on Debian sid with Ruby 2.1.0. Will likely take some fiddling.

Of the debians, I haven't tried sid, though we are building it on wheezy (packages coming in the next week or two, so stay tuned).

FYI the build doesn't depend on ruby-devel packages (the MRI embedding relies on the relevant bits of the Ruby C API being stable, which it generally has been).

If you have build issues on sid (or anywhere for that matter), just ping on irc/email/etc; I'm sure people can sort it out. And these are early days for this tech stack, so it would be nice to surface oddities or friction points early.

Best,

Kylo

-- 

Kylo Ginsberg | ky...@puppetlabs.com | irc: kylo | twitter: @kylog

[Felix Frank]

On 10/15/2014 09:44 PM, Kylo Ginsberg wrote:
>
> We definitely could implement a C interface for adding facts as well.
> There were one or two questions about that at PuppetConf. I'd be curious
> to know how much demand there is for that approach.

Come to think of it, there was this other recent thread about building a
library of facts concerning CVEs. I could see people caring to deploy
binary facts to their agents to gather a large number of facts of this
magnitude as efficiently as possible.

Of course, this will complicate the
develop->forgeupload->download->deploy chain considerably.

> Thinking about the extension points for the agent, notably providers, we
> may be able to follow a similar-ish model there of:
> * dynamically load ruby and implement the provider api (tricky b/c the
> api needs improved definition/hardening)
> * introduce a concept of external providers
> * maybe add a C API here as well?

Same as above - binary providers may be preferable to many users with
homogenous serverscapes.

> Just cloned the repo - doesn't seem to build on Debian sid with Ruby
> 2.1.0. Will likely take some fiddling.
>
>
> Of the debians, I haven't tried sid, though we are building it on wheezy
> (packages coming in the next week or two, so stay tuned).
>
> FYI the build doesn't depend on ruby-devel packages (the MRI embedding
> relies on the relevant bits of the Ruby C API being stable, which it
> generally has been).

Thanks for the notes.

> If you have build issues on sid (or anywhere for that matter), just ping
> on irc/email/etc; I'm sure people can sort it out. And these are early
> days for this tech stack, so it would be nice to surface oddities or
> friction points early.

Will do next chance I get. Thanks for the reply.

Cheers,
Felix