On Feb 4, 2011, at 1:14 AM, Brice Figureau wrote:
> On Thu, 2011-02-03 at 21:42 -0800, Luke Kanies wrote:
>> 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.
>
> Hmm, I thought module were limited to types/providers/functions.
> Did it change lately?
They've never been limited to those, exactly - there are some limitations to
downloading files other than those and using them in the running services, but
anything can be distributed.
> Of course I'd prefer this code to be in core for at least one reason:
> I'm not sure I can have the bandwidth to maintain this code (ie making
> sure the code still works with newer puppet versions, etc...). So
> ultimately this will rot in its repository :)
> Being part of the core assures me that someone (beside me) will care
> when the tests will fail :)
> Being part of the core also assures me that I can leverage your
> infrastructure (ie redmine, CI, etc...).
Makes sense. I'd like it in core, too, but I've been wondering whether it
makes more sense to keep this kind of work in a module until it gets merged,
rather than keeping it in a branch.
So, I'm not exactly recommending a module, but I'm at least wondering if it
makes sense.
>> 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.
>
> Well, if it's possible to have a bunch of app, type/provider, and tons
> of puppet/util classes in a module, then it should be doable.
> I'm just completely unsure how you package, distribute and use such
> monster module (any pointers?) :)
Me too. :)
That's one of the reasons I want this - to be a forcing function to either
figure out what this looks like or make it work.
>>> 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?
>
> Yes that's one way of doing it.
> So how do you implement such post-compile hook?
> Is there anything in place in puppet to do that, or should I just try to
> implement this?
> And the subsequent question is: will that work in a puppet module?
Realistically, there are two ways to do it right now: Have the validation be
in the executable that pulls the catalog from the server, or (and this is
probably stupid) make a new catalog terminus on the server to replace the
compiler terminus that does this validation.
>>>> 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.
>
> I'll continue to focus on the basic functionnality first :)
--
Ours is the age that is proud of machines that think and suspicious of
men who try to. -- H. Mumford Jones
---------------------------------------------------------------------
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.
