That is definitely helpful information. Thanks!
So about the repo notifications:
Could I assume that the true or false state of the def below in the
vcsrepo.rb resource type controls whether the notification is fired or not
for the related providers? Forgive me I'm rather new to the lower level
internals of resources and providers.
def insync?(is)
@should ||= []
case should
when :present
return true unless [:absent, :purged, :held].include?(is)
when :latest
if is == :latest
return true
else
return false
end
when :bare
return is == :bare
end
end
About the other resource type:
I can definitely see what your saying but it seems like if the
notifications on the repo update worked then all the other build state
resources should just work if notified provided they manage their state
effectively (which so far they do)? Admittedly, I have been using execs
for things like my make, make install, etc... It just seems like the repo
notification is the major obstacle even with a custom resource to manage
the state of the build.
Adrian
On Tuesday, October 9, 2012 3:47:29 PM UTC+1, jcbollinger wrote:
>
>
>
> On Tuesday, October 9, 2012 6:12:30 AM UTC-5, Adrian Webb wrote:
>>
>> Hello,
>>
>> I've been trying to implement a puppet definition that uses vcsrepo and
>> notifies the caller through an update_notify parameter when the repository
>> contents change on disk. I have however found this very hard to accomplish.
>>
>> Basically I am trying to pull down a git repo and when the head of the
>> repo changes on the disk of the agent, run a build command (such as make)
>> into a release directory. So the system automatically tracks a branch or
>> responds to changes in tags and the system automatically builds off of that
>> information. In order to allow for multiple types of build processes I am
>> trying to notify other resources through the exec notify property.
>>
>> My problem is this:
>>
>> The only way to trigger the notification in a conditional manner that I
>> have found is to use the onlyif or unless properties on the exec resource.
>> Notifications still happen on the exec command even if the command fails so
>> I can not use an inline command to notify or not (that I know of). But the
>> onlyif property which I have been trying seems to execute before any of the
>> actual commands so it always runs before the vcsrepo update, which voids
>> the intended purpose. I can not use functions with a conditional because
>> they are only run on puppet master and also suffer from the same issue
>> where they run before any commands, and I can not use a fact because I need
>> a directory parameter and it is also runs before any of the commands.
>>
>> So I need a way to conditionally trigger a notify during the course of a
>> execution run right after the vcsrepo gets done pulling down any updates.
>> Does anyone know how I might accomplish this task through puppet? So far
>> nothing I have tried works. I would think that this goal would not be that
>> isolated (building a repository after and only after repository updates).
>> In my case I normally build into release directories so absolutely can not
>> afford to rebuild on every puppet execution which runs every 5 minutes.
>>
>>
> In fact, your goal is not particularly well aligned with Puppet. That
> doesn't mean you can't accomplish it via Puppet, but it's not surprising
> that you're having trouble getting there. Puppet is focused on managing
> state, and the actual tasks performed for that purpose are intentionally
> de-emphasized, but your objective is characterized principally by
> performing specific tasks, as opposed to by the state achieved via doing so.
>
> With that said, finding a suitable way forward probably depends on
> understanding the model. The relevant parts work like this:
>
> - A resource employing 'notify' sends an event to the designated other
> resources each time it is non-trivially synchronized, meaning that Puppet
> changes a managed property from out of sync to in sync
> - Exec resources have no persistent state to examine. Whether they
> are initially considered in sync is judged by their 'onlyif', 'unless',
> and
> 'creates' properties. Execs for which none of those is set are considered
> out of sync on every Puppet run.
> - How out of sync Exec resources are synchronized depends on the
> values of their 'refreshonly' parameters. If an Exec's 'refreshonly' is
> false (the default) then it is synchronized by running its 'command';
> otherwise, it is synchronized by doing nothing, but refreshed (if it
> receives an event) by running the 'command'.
> - Resources that are initially in sync automatically succeed.
> Resources that need to be synchronized succeed if and only if they can are
> successfully synchronized. For an Exec to succeed, that means the
> 'command' exits with the status specified by the 'status' property, or
> with
> status 0 if an explicit status is not specified.
>
> You have at least two relevant resources in your system: one managing the
> local copy of your VCS repo, and one managing the build status of the code
> therein. To achieve your goal, the former must send an event to the latter
> if and only if it updates anything in the local copy, and the latter must
> do nothing unless it receives an event.
>
> Much depends, therefore, on the specific resource types you are using,
> especially the one for the local copy of your repo. You must use ones that
> support the needed signaling behavior. You may be able to create one in
> Exec form if you don't have a suitable one available otherwise. (Puppet
> does not have such a resource type built in, but there are add-in modules
> that might provide types that do what you want.)
>
>
> John
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/AZLJlX7AVkkJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
