On Jan 17, 2011, at 1:51 PM, Richard Crowley wrote:
>> I recently ran into a need for this working on a Pip provider for the
>> package resource, but I'd like to autorequire python packages so that
>> the pip provider is guaranteed to be available. There may be other
>> issues with this as well (the command won't exist until runtime so
>> maybe Puppet will think the host is not capable?)
> I don't think the means by which a provider becomes available on a server
> should be up to Puppet. Given that, it feels like a daunting task to
> enumerate the ways a provider may become available for the purpose of
> autorequiring those resources.
>
> Consider just the pip provider on Ubuntu: Python could come from the
> python2.6 or python3 package or a custom build in an exec resource. Pip
> could come from the python-pip package, via the python-setuptools package and
> `easy_install pip`, or `python setup.py install` in an exec resource.
>
> A similar situation exists for the gem provider, though that's not a
> practical concern when Puppet is installed as a gem.
>
> I think the best solution to this particular problem is to let the user
> specify using a run stage or a collection how they choose to install pip:
>
> Exec["easy_install pip"] -> Package <| provider == pip |>
>
> If autorequire were to come to providers, it should be reserved for things
> that are known by the provider (for example, the apt provider autorequiring
> /etc/apt/sources.list) rather than trying to enumerate how the provider comes
> to be.
I completely agree.
> Postponing resources until a particular program is available in PATH seems
> interesting but it introduces a new type of nondeterminism that the master
> will never be able to resolve.
Note that this isn't necessarily true - you could have this work well within
limits. This is along the lines of the graph frontier work we're planning for
other areas -- resources that might reasonably be available for execution but
you'd prefer not to, because of performance optimization or something. We're
initially planning on using this for combining package installs, but we've also
talked about using it for cross-host dependencies (delaying resources until
their remote dependencies become available or a timeout is reached), and it
could be used here. You still have the possibility of a failure, but the
failure is only when you know there's no possibility of success.
I know that's a bit gibberish, but hopefully it'll be a bit clearer once we
start to actually develop it. :)
--
It's very hard to predict things . . . Especially the future.
-- Prof. Charles Kelemen, Swarthmore CS Dept.
---------------------------------------------------------------------
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.
