profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/anhdat/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Dat Truong anhdat Picnic.nl Amsterdam, Netherlands http://anhd.at

anhdat/ADTiledMapSlicer 2

Image slicer in different levels for ARTiledImageView or NAMapKit

anhdat/advent-of-code 1

Advent of Code https://adventofcode.com/

anhdat/amazon-eks-ami 0

Packer configuration for building a custom EKS AMI

anhdat/argo-events 0

Event-based dependency manager for Kubernetes.

anhdat/aws-alb-ingress-controller 0

AWS ALB Ingress Controller for Kubernetes

anhdat/blackbox_exporter 0

Blackbox prober exporter

anhdat/charts 0

Curated applications for Kubernetes

anhdat/client_golang 0

Prometheus instrumentation library for Go applications

startedAkihiroSuda/lima

started time in 5 hours

pull request commenthashicorp/hcat

Allow for conditional notifications with new Notify API

Thanks @eikenb! And thank you for explaining and the additional context. That's a good point about >1 KV in the template! Definitely sounds like Option 1 or 2 would be best (rather than 0). I'll have to also do some rethinking on Option 2 🤔

eikenb

comment created time in 9 hours

pull request commenthashicorp/hcat

Allow for conditional notifications with new Notify API

Thanks for the feedback @lornasong, please take your time and review it on your schedule. I have plenty to do.

The main thought that crossed my mind while working on the KV/notifier example was how you could only do it for 1 KV field. With KvValue as a typed string you can only use the string value returned in the Notify logic as there is no way for you to know which key if there was >1 in the template.

That is why I included idea of the more complex type and for option 1.

I thought about option 2 then as I'm not sure if KV is the only field where this might come up or that the Key field is the only one that'd prove to be relevant (eg. like Namespace). Option 2 simply elides out this issue by passing along everything it has. So if there was additional fields that could matter, they'd be there.

Hope the additional context helps. Thanks for looking and, again, please take your time.

eikenb

comment created time in 9 hours

pull request commenthashicorp/hcat

Allow for conditional notifications with new Notify API

Excited about this change! I found the KvValue type and example usage really, really helpful. From looking over, the changes make sense to me. I'd like to spend some time playing around and making sure I really understand everything before resume reviewing if that's ok. Planning to do this later on today and maybe into Monday. Let me know if I start blocking you!

Regarding feedback on KvValue, I appreciate the analysis you provided! 🤔 I currently lean towards your PR's implementation of KvValue as a string type (I'll call it option 0) or option 1.

Thinking about option 2, it looks like the Read Key API response provides a lot of additional fields that I think hcat users are unlikely to need e.g. CreateIndex, Session, Flags etc. In the Read Key API, the fields (in addition to 'value') that I think might be useful are key and namespace; however I think it's likely that a user will already have this info if they care about them. e.g. a user will definitely already have the key; if they care about namespace, they'll have the namespace to query Read Key API. So I currently lean towards returning only what was requested (option 0) or only adding new fields that seem useful in a custom type (option 1). To be fair, I'm not sure if this can be abstracted to all APIs and might be thinking about this too narrowly since I don't have a good understanding of use cases!

eikenb

comment created time in 12 hours

pull request commenthashicorp/hcat

Allow for conditional notifications with new Notify API

One thing I'd like feedback on is the KvValue field. I thought having something other than just the bare string type for type asserting would be useful and so added only that as simply as I could. But I was also considering making it a bit more detailed and have it return either a locally defined KvPair with at least the key and value stored or we could use the original, underlying Consul KVPair struct that has a lot more fields on it.

If we extend the type to have more information, I'd also welcome feedback on the either/or pairing above, the local vs original options, as this would guide my designs for the rest of these types.

  1. wrap the original data in custom types
    • gives us more control
    • only need to add new fields as this is what is currently in place
  2. use the original data from the server's API (from Consul, Vault, etc.)
    • would always be up to date with new fields added by the API
    • but would make our data be completely reliant on the API library
    • could link out to original docs
eikenb

comment created time in a day

push eventhashicorp/hcat

John Eikenberry

commit sha 04aa21afd9c56368820b5d7208d1cca4fbd456a8

Notifier (testable) example

view details

push time in a day

pull request commenthashicorp/hcat

Allow for conditional notifications with new Notify API

Broken up into 4 commits. First one contains the main changes. Last couple add a doc_test example w/ a KV filtered notifier. Remaining commit is just all the testing tweaks to work with API changes.

eikenb

comment created time in a day

PR closed hashicorp/hcat

Notifier interface gets new Notify() signature

Updates the Notifier interface, and the implementations, with the new version of the Notify() method signature. The new version takes the newly updated data as the argument and returns a boolean that determines if Wait() returns or continues to wait. This, along with how it calls the existing template or otherwise manages notification updates, gives the Notify() implementor control over whether that update triggers a action (like template rendering) in the applications.

The old method signature was mostly a placeholder, so this is the first complete version of the interface.

+147 -36

2 comments

3 changed files

eikenb

pr closed time in a day

pull request commenthashicorp/hcat

Notifier interface gets new Notify() signature

Closing in favor of https://github.com/hashicorp/hcat/pull/53

eikenb

comment created time in a day

PR opened hashicorp/hcat

Allow for conditional notifications with new Notify API

Updates the Notifier interface, and the implementations, with the new version of the Notify() method signature. The new version takes the newly updated data as the argument and returns a boolean that determines if Wait() returns or continues to wait. This, along with how it calls the existing template or otherwise manages notification updates, gives the Notify() implementer control over whether that update triggers an action (like template rendering) in the applications.

+288 -100

0 comment

22 changed files

pr created time in a day

push eventhashicorp/hcat

John Eikenberry

commit sha 061213bcb1e63ce505dba0416ac563ea095746fe

Notifier interface gets new Notify() signature Updates the Notifier interface, and the implementations, with the new version of the Notify() method signature. The new version takes the newly updated data as the argument and returns a boolean that determines if Wait() returns or continues to wait. This, along with how it calls the existing template or otherwise manages notification updates, gives the Notify() implementer control over whether that update triggers an action (like template rendering) in the applications. The old method signature was mostly a placeholder, so this is the first complete version of the interface.

view details

John Eikenberry

commit sha 6eee5ea944aa0096ac79c5f6781a2d676664e61b

update tests with new Execute API

view details

John Eikenberry

commit sha bf791babad63b0c951909cff2a41d315e9852eb5

add KvValue, exported dependency type for KV gets Example of how we will need to export custom types for all the dependencies to enable type asserting for differenctiating between the dependencies used. Used in the doc_test example.

view details

John Eikenberry

commit sha 5ab551f591da8e7ac74f294e78528e73ef59c0f8

Notifier (testable) example

view details

push time in a day

create barnchhashicorp/hcat

branch : conditional-notification-v2

created branch time in a day

startedbmkessler/fastdiv

started time in 2 days

startedpositive-security/send-my

started time in 2 days

created repositorykubernetes-sigs/cosi-driver-sample

Sample Driver that provides reference implementation for Container Object Storage Interface (COSI) API

created time in 2 days

push eventhashicorp/hcat

John Eikenberry

commit sha 846ae703234eb33ba8c497e9bd5c962bab54f34c

remove unused watcher.Remove and supporting code Remove() and related code is not used anywhere, nuke it and it's tests.

view details

John Eikenberry

commit sha beef0f648a646dc63ad9636f95d4a01df7602425

clear cache entry during sweep step When removing the Remove() code I realized the Sweep() code wasn't clearning out the swept entry from cache. Add the cache delete call and test it.

view details

John Eikenberry

commit sha a87d3e7341a7bed3683ff2514e6414a833039dd4

refine parameter type requirements, Notifier->IDer Lots of passing around `Notifier` instances when only the ID() method is needed. Add `IDer` interface for use in these cases (and embed in Notifier).

view details

John Eikenberry

commit sha af825d413cf7b17a6bcde9ac37128935b8485ca7

Merge pull request #52 from hashicorp/watcher-updates Watcher updates

view details

John Eikenberry

commit sha 6a25d0c787da8594cfbd4a9399db878b282638a0

Notifier interface gets new Notify() signature Updates the Notifier interface, and the implementations, with the new version of the Notify() method signature. The new version takes the newly updated data as the argument and returns a boolean that determines if Wait() returns or continues to wait. This, along with how it calls the existing template or otherwise manages notification updates, gives the Notify() implementor control over whether that update triggers a action (like template rendering) in the applications. The old method signature was mostly a placeholder, so this is the first complete version of the interface.

view details

push time in 2 days

push eventhashicorp/hcat

John Eikenberry

commit sha 846ae703234eb33ba8c497e9bd5c962bab54f34c

remove unused watcher.Remove and supporting code Remove() and related code is not used anywhere, nuke it and it's tests.

view details

John Eikenberry

commit sha beef0f648a646dc63ad9636f95d4a01df7602425

clear cache entry during sweep step When removing the Remove() code I realized the Sweep() code wasn't clearning out the swept entry from cache. Add the cache delete call and test it.

view details

John Eikenberry

commit sha a87d3e7341a7bed3683ff2514e6414a833039dd4

refine parameter type requirements, Notifier->IDer Lots of passing around `Notifier` instances when only the ID() method is needed. Add `IDer` interface for use in these cases (and embed in Notifier).

view details

John Eikenberry

commit sha af825d413cf7b17a6bcde9ac37128935b8485ca7

Merge pull request #52 from hashicorp/watcher-updates Watcher updates

view details

push time in 2 days

PR merged hashicorp/hcat

Watcher updates

3 tweaks not tied to a feature but wanted to get cleaned up. Each of the 3 things has it's own commit to make them easier to digest.

Remove unused watcher.Remove and supporting code. Clear cache entry during sweep step. refine parameter type requirements, Notifier->IDer

+37 -83

0 comment

2 changed files

eikenb

pr closed time in 2 days

Pull request review commenthashicorp/hcat

Watcher updates

 func (tp trackedPair) markCacheAccessed() trackedPair { 	return tp } +// IDer an interface that supports and ID+type IDer interface {+	ID() string+}

I've been trying to be stricter with my inputs by defining more specific Interface types as needed. I feel there is probably a better point of balance that is more specific/detailed than I've done in the past.

And while I've just accepted the "-er" naming... it comes at a cost (eg. Watcherer, Renderer... :grimacing:)

eikenb

comment created time in 2 days

Pull request review commenthashicorp/hcat

Watcher updates

 func (tp trackedPair) markCacheAccessed() trackedPair { 	return tp } +// IDer an interface that supports and ID+type IDer interface {+	ID() string+}

The interface "-er" suffix has always been amusing to me

eikenb

comment created time in 3 days

Pull request review commenthashicorp/hcat

Watcher updates

 func (tp trackedPair) markCacheAccessed() trackedPair { 	return tp } +// IDer an interface that supports and ID+type IDer interface {+	ID() string+}

Interesting pattern! Noting this down to use some day in the future!

eikenb

comment created time in 3 days

startedNotionX/react-notion-x

started time in 3 days

PR opened hashicorp/hcat

Watcher updates

3 tweaks not tied to a feature but wanted to get cleaned up. Each of the 3 things has it's own commit to make them easier to digest.

Remove unused watcher.Remove and supporting code. Clear cache entry during sweep step. refine parameter type requirements, Notifier->IDer

+37 -83

0 comment

2 changed files

pr created time in 3 days

create barnchhashicorp/hcat

branch : watcher-updates

created branch time in 3 days

startedline/rules_apple_line

started time in 3 days

startedmmcloughlin/profile

started time in 3 days

pull request commenthashicorp/hcat

Notifier interface gets new Notify() signature

Let me note that I'm working on a doc_test.go example of this in use to provide some basic documentation.

eikenb

comment created time in 3 days

PR opened hashicorp/hcat

Notifier interface gets new Notify() signature

Updates the Notifier interface, and the implementations, with the new version of the Notify() method signature. The new version takes the newly updated data as the argument and returns a boolean that determines if Wait() returns or continues to wait. This, along with how it calls the existing template or otherwise manages notification updates, gives the Notify() implementor control over whether that update triggers a action (like template rendering) in the applications.

The old method signature was mostly a placeholder, so this is the first complete version of the interface.

+147 -36

0 comment

3 changed files

pr created time in 3 days

create barnchhashicorp/hcat

branch : conditional-notification

created branch time in 3 days

startedzachwaugh/pilcrow

started time in 4 days