On Jan 24, 2011, at 10:02 AM, Peter Meier wrote:
> Hi
>
> so I was currently reworking the floating around Zenoss provider to work
> properly with Zenoss 3. However, I encountered the following problem:
>
> The Webservice-Call (whether it is XMLRPC or REST) to add a device will
> in Zenoss 3 now create a task on the Zenoss Server, which will add a
> device. So the return code of the call represents the successful or
> failed creation of the task. But there is no way to figure out whether
> adding the device was actually successfull unless we lookup the device
> itself how we would do it in the exists? method. However, this only
> succeeds if the task have already run.
>
> So actually we would have to wait for the task engine to process the
> created task and then we would know wether adding was successful or not.
> We could do this by waiting a certain amount of time (current celsius
> degree times PI ...) or if there is a way to query the task engine:
> Query it unless the task is processed and then check if the device shows
> up or not.
> However, both ways would block puppet for a (un)certain amount of time.
>
> So my current solution was to fire and forget. Which runs the provider
> without any blocking calls, however if there are for example any wrong
> parameters and only the task itself will do the parameter checking, I
> won't be able to detect that adding the device failed (and especially:
> Why it failed!) and furthermore, puppet will try to add the device again
> in the next run.
>
> I think this is a general problem with puppet providers that will call
> services that will finish the task asynchronously. So I'm asking myself
> if there are any best practices to deal with such interfaces? Should
> puppet actually be able to deal with this kind of calls? Or is the fire
> and forget solution the appropriate one.
The short answer is, that's the only solution at this point.
We've got plans to add the ability for the transaction to be able to consider
some resources as 'not ready' and move on to other resources, but really, I had
never considered this for providers. That would be more complicated because
you would need to begin a resource, get part-way through, pause it, and then
keep checking back.
I was thinking more simplistic cases like having an external dependency that
must be ready before a resource can be checked.
--
What's the good of having mastery over cosmic balance and knowing the
secrets of fate if you can't blow something up?
-- Terry Pratchett, "Reaper Man"
---------------------------------------------------------------------
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.
