The way that unified_mode immediate notifications work should be a first-class citizen
Nobody has claimed this yet.
- Dominant language
- Ruby
- Stars
- 8.2k
- Forks
- 2.5k
- Avg merge
- 4d 5h
- Merged PRs (30d)
- 23
Description
I should have invented a new notification for unified_mode rather than hacking up :immediately to do what I wanted and then just mapped :immediately onto that when running in unified_mode.
It can be used in non-unified_mode in recipe context to delay a notification until the resource is declared, which is very useful compared to our all-or-nothing do-it-right-now or do-it-way-at-the-end.
So if you decouple user creation from later recipes that consume events that the users were created or not, you want to loop over a huge pile of user resources. then only fire off one ohai reload, then later you've got some recipe where you want to be able to say "if user alice was added sometime in this run, then i want to update and run now". You don't want to fire immediately off the user resources, because you don't want 100 ohai reloads firing. You also probably don't want to promote the later recipe to running immediately as soon as the user resource to add alice fires.
You want to manage all the users first. If any of them were update you want to reload ohai once. Then when you get to the recipe that matters you want to fire resources there only if alice was added this run.
list_of_all_my_users.each do |username|
user username do
notifies :reload, "ohai[reload]", :parsetime
end
end
ohai "reload" do
action :nothing
end
[... much later ...]
execute "do something if alice was created" do
subscribes :run, "user[alice]", :parsetime
end
This is basically what I built with unified_mode and putting that code into a unified_mode sub-resource nearly works, except the notifications to the ohai resource aren't properly de-duped (which I'd argue is a bug and they should be).
This would also clarify some of the magic in the unified_mode behavior by giving it a name. It may need a better name than :parsetime.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing how unified_mode handles notifications and how :immediately currently maps to that behavior, then compare it with the proposed :parsetime semantics. Done means a first-class notification behavior supports deferred resource notifications, deduplicates repeated notifications, and preserves the described recipe-context behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ruby
- Domain
- devops
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100