Question: Future direction of this project

[clockworksoul]

Currently, this project supports three means of configuring its behavior, none of which are as fleshed out as they could/should be:

1. Using the Golang API proper
2. Environment variables
3. The CLI (which ostensibly exists as a proof-of-concept for the API)

I've been throwing around the idea developing a distinct Smudge server that can provide -- perhaps by running sidecar next to a larger service -- all Smudge capabilities, without the service needing to implement the Go API. The server could then communicate with the Smudge sidecar via some language-agnostic means

This leads me to a couple of questions:

First, is this worth even doing? Is there any use for this?

Second, I don't think it makes sense to support both CLI and environment variables for specifying variables, so I'm leaning towards dropping environment variable support entirely. Does anybody have any opinions about this?

Third, I think this would be best served by creating a separate server project that uses the API. Does anybody have any thoughts about this?

Thanks for your thoughts!

[eelcocramer]

I think it is valuable to have smudge as a library as it is, so it can be embedded in whatever kind of software folks think of.

I also think it can be valuable to create some program using the smudge library to build a generic tool like serf or etcd. Serf uses a similar wire protocol as smudge implements (also SWIM) but needs TCP to incidentally sync / bootstrap.

I've created a program, using smudge, that has a similar (but simpler) function as Serf. It has a (g)RPC interface for interacting with a agent running the program and a CLI to interact with the network (join, leave, status, broadcast, etc).

I will check (next week) if I'm allowed to donate the code of this program but there is nothing fancy to it to be honest.

This program allows both CLI and environment variables. I think environment variables are useful when containerising the program.

I hope this helps.

[clockworksoul]

Thanks, @eelcocramer!

It does help. Quite a lot.

No matter what, the API will be open and available. I think that's critical. If I write a sidecar service it would be in addition to, not instead of, the API for sure.

It's interesting that you mention that you've created a function similar to serf, using gRPC to interact with an agent. The thing I was considering creating is actually very similar to that agent you mentioned, and intended to make use of gRPC. I'd be very interested to see what you've come up with.

If I do build this yet-to-be-named thing, though, I'd probably end up tearing the environment variable logic out and moving it to the service proper. Basically, I'm not convinced that the API shouldn't have just the one means of setting its behavior: via API calls.

Thoughts?

[eelcocramer]

I agree with you that there is not much use for the environment variables within the library. 👍

[clockworksoul]

Okay so that's what I'll do:

• Create a new service in a distinct repo
• The service will be designed to run as a sidecar process for member/status updates
• It will support gRPC and RESTful APIs
• Behavior can be affected by CLI and environment variables (the former takes precedence); environment variable support will be removed from Smudge
• It might be nice to include a /metrics endpoint for scraping by Prometheus
• Perhaps the broadcast system can be used to implement some additional functionality at a later date

Now, what to call it?

[eelcocramer]

Smear? :-)

[clockworksoul]

Smear? :-)

Heh. Nice. I was thinking of keeping with an art theme. Maybe "Scribble"? /shrug

I was also thinking that since it's a higher order entity that I'd name it after some higher order art structure, particularly something to do with lines connecting one another. Maybe Triquetra or something like that?

Irrelevant aside: at one point I was thinking about making a Chord-based distributed data store and naming it Ensō. 😄 I'd still like to do that eventually, but no rush there.

I'm drawing a blank (see what I did there?) for the moment, but I'm open to suggestions.

[clockworksoul]

Enso is just too good of a name... I'm cannibalizing it for this project.

Created the repo here.

[eelcocramer]

I can contribute my code. I've named my project tamtam but I'm fine changing the name. I will need some time to add licenses etc. but now you know it is coming.

[clockworksoul]

That would be very welcome! I'm looking forward to seeing what you've done. :)

[eelcocramer]

I've published my code here: https://github.com/servicelab/tamtam

For now I did not rename it as you intend to be Enso a distributed data store and TamTam is more or less a serf clone.

I'll be happy to discuss moving/renaming TamTam into the same namespace as smudge if this would seem more appropriate.

Feedback & discussion would be greatly appreciated.

update moved the code into another namespace...