chef / chef/chef

The way that unified_mode immediate notifications work should be a first-class citizen

Open
#11,729 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Status: Untriaged
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.