Smarter update diff simpler #184
Conversation
| Kennel.out.puts "#{LINE_UP}Deleted #{message}" | ||
| end | ||
|
|
||
| Update.new(update_log: update_log) |
There was a problem hiding this comment.
Note that update_log exposes quite a bit of data (and all undocumented). For the purposes of the corresponding zendesk kennel PR we could have made it expose just the tracking ids.
There was a problem hiding this comment.
how is the update-log different from a Plan ? ... it has the ids resolved ?
can we use the Plan internally and then resolve the ids in the plan to have the same data structure at the end ?
There was a problem hiding this comment.
Well.... at the moment, perhaps not much. My longer term view however is this:
The way that plan works at the moment – and therefore what the plan actually is – is very simplistic. I prefer to think of it not so much of a plan, but more of a diff; a comparison. If we compare A to B, then this is added, this is changed, this is removed.
If the job then is resolve those differences (assuming it's a non-empty set), then we need to do something. What, exactly? Well, that's the plan. Or, once performed, the results.
Our methodology is already showing its shortcomings. If we for example create a monitor M with tracking id K and type T, and then we update kennel so that the type now needs to be T', then (IIRC) Kennel currently can't handle that, because Datadog does not allow a monitor's type to be changed. However, it is solvable: instead of updating the monitor, delete monitor M then create monitor M' type T' (and with the same tracking ID K). In this case, the diff would be "Monitor K change T => T'", but the plan would be "delete M and create M'".
Another example: circular references. The reason that I haven't yet merged #160 is that it would allow for / increase the likelihood of circular references. Monitor M, whose message text includes a link to troubleshooting dashboard D. But dashboard D contains a view of monitor M. So if M => D and D => M, and neither exist, so the diff is "both D and M are new", what's the plan? Possible answer: create M (but with the message text only containing the kennel tracking text); create D, referring to M; update M to set its message text correctly, linking to D.
To return to your question, "what's the difference between the plan and the update log?". What we currently call plan is a diff. What I'm calling update_log is closer to a plan – but retrospective.
lib/kennel/syncer.rb
Outdated
| noop?: noop?, | ||
| already_ok: @already_ok, |
There was a problem hiding this comment.
these seem a bit redundant, maybe a plan class could hold the attrs and have a noop? method ?
There was a problem hiding this comment.
Maybe. In a later refactor, I would suggest.
There was a problem hiding this comment.
You're not suggesting changing the interface, just the implementation.
lib/kennel/tasks.rb
Outdated
| @environment ||= begin | ||
| require "kennel" |
There was a problem hiding this comment.
maybe cleaner ?
| @environment ||= begin | |
| require "kennel" | |
| return if @environment_loaded | |
| @environment_loaded = true | |
| require "kennel" |
|
need a release or more coming ? |
|
In terms of the "smarter diff" feature, that's all that's needed. Smaller releases are better than big anyway :-) |
|
1.118.0
…On Wed, Sep 14, 2022 at 10:24 PM Rachel Evans ***@***.***> wrote:
In terms of the "smarter diff" feature, that's all that's needed. Smaller
releases are better than big anyway :-)
—
Reply to this email directly, view it on GitHub
<#184 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAACYZ4USN6YQIJE2FCPHNTV6KXKDANCNFSM6AAAAAAQD3BIXM>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
Have
.planand.updatereturn useful data structures.Unrelated, though useful for testing: allow the
Managed by kennelmarker to be overridden.