On Jan 29, 2011, at 9:05 AM, Brice Figureau wrote:
> Hi,
>
> I had the opportunity to work again on this patch to add the so-called
> puppet device app and cisco facts.
>
> It's not yet ready, so I won't send the new patches to the list (they
> should be available in my github branch of course) today.
After looking through your code just briefly, this looks like it could actually
just be a Puppet module, rather than being added to core.
Not that I'm specifically opposed to it being in core; I've just been thinking
a lot about the ability to have big functionality like this in modules. E.g.,
I'm moving my data_app stuff into a module, and I think it'll work well there,
and it should work for most anyone running 2.6 without upgrading.
> On 18/01/11 21:19, Luke Kanies wrote:
>> On Jan 18, 2011, at 4:15 AM, Brice Figureau wrote:
>>> [...]
>>> I'm mentioning "type" here, but this could also be stored in the
>>> manifests by using explicitely a provider.
>>
>> Would it be reasonable to have this data in an external node
>> classifier, with some kind of search interface? Then the device
>> process just iterates over all devices, or something similar?
>
> To start simple, I stucked with the /etc/puppet/device.conf file I
> mentioned earlier in the thread.
> I'll do another pass when the puppet device will be more mature to add
> an ENC system, a daemon mode, etc...
> I want to have the base system running first :)
Makes sense.
>>> 2) Puppet device is responsible for parsing this file, and for
>>> each device: * use the device certname as our current $certname *
>>> switch $vardir (and other essential state directory settings) to
>>> $vardir/devices/$certname, creating those if they don't exist at
>>> the same time. * it should set the facts terminus to :device which
>>> would route the configurer fact request to the correct terminus for
>>> the given device type/model. * call the configurer to fetch a
>>> catalog and apply it to the remote device. Since $vardir is
>>> overriden, all the state goes to a different directory. * clean-up
>>> the mess we did with overriding $vardir * wash, rinse, repeat for
>>> the next device.
>>>
>>> This should partially isolate the current host from the device
>>> system (at least the puppet internal stuff).
>>
>> Yep, this seems like a good fit.
>
> This part is implemented.
>
>>> Now, I don't really see how we can achieve a perfect isolation.
>>> Nothing can prevent someone to add a destructive file{} resource to
>>> the device catalog, which unfortunately will be applied as is. Or
>>> maybe we can use some kind of catalog filtering and allow only the
>>> network device types...
>>
>> I can see a couple of ways.
>>
>> The "simplest" is that you have a post-compile hook that just makes
>> sure only device-specific resources are in the catalog. It's simple,
>> but not terribly supportable in the long term. This would probably
>> be easiest by validating the provider, rather than the type itself,
>> since that's what's modifying the system.
>
> But this process happens on the master, correct?
> The problem is that the master doesn't know it talks to a puppet device.
Doesn't it know that from the facts? Or something similar?
>> The better solution in the long term, IMO, is to have a
>> constraint-based system for resource types and/or providers, so you
>> could reasonably restrict a catalog to only having types that
>> function on, say, devices, rather than POSIX OSes. I don't really
>> know how this would work, but at the least, it would involve every
>> provider list its constraints and/or features, and then a given
>> catalog could be restricted based on them.
>
> Yes, that's appealing. We could leverage the confine system we have on
> the providers to do that.
>
>> I don't think it'd be quite as simple as trusting existing provider
>> constraints, because you'd actually want some way to guarantee that
>> the host machine isn't being modified, but it might be.
>
> That's correct.
>
>>> This (even partial) isolation has the benefits of bringin proper
>>> device facts, and reports/catalogs will be correctly fetched/pushed
>>> for the given device certname.
>>>
>>> In my view puppet device would not be a daemon, but that should be
>>> something that can be added. I don't exactly remember how the agent
>>> is used, I'll have to check that, though.
>>>
>>> Does it match what you were thinking?
>>
>> Yes, exactly.
>>
>>> There is still something that I find clumsy or not following the
>>> "puppet way". Until now every type was able to autodiscover the
>>> correct provider (or can be forced to a given provider). We'll
>>> currently lose this model, if we specify the device type in the
>>> config file.
>>
>> Yeah. I think we will need to specify enough information that we can
>> figure out how to discover the facts about the host we're
>> configuring, but the rest should be autodiscovered as much as
>> possible based on those facts. Given that we do have to connect from
>> an external host, we're fundamentally limited in some ways.
>
> One thing that will be difficult is to auto-detect the kind of device
> we're connecting to (especially because almost every device has a
> different authentication prompt when using telnet).
> For the moment I took the easy way and let the user specify the device
> type in the config file, but ulitmately that'd be great to auto-discover
> the correct model we're connecting to...
Yeah, that might be intractable. I guess nmap or snmp might do something, but
in general you'll probably have to do some kind of declaration.
--
It is odd, but on the infrequent occasions when I have been called upon
in a formal place to play the bongo drums, the introducer never seems
to find it necessary to mention that I also do theoretical physics.
-- Richard Feynman
---------------------------------------------------------------------
Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
