-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add ability to deploy an observable nats without stan stack #185
Conversation
…cated nats; next: authenticated stan
…source allocation)
…n nats-surveyor (bad creds location)
… mds(agency,event-processor)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few comments, once resolved and I've had a chance to test the changes on my machine I'll approve
@avatarneil @invertigo @ysingh-lacuna what say you? |
|
Also looks like the istio-system container is being created during bootstrap but not populated, I need to run a subsequent |
Also noticing that the redis and postgresql pods get tagged pretty strangely... |
Besides those things, NATS seems to be working E2E, so good besides that. Will approve once the previous comment are addressed. |
@avatarneil thx for the comments ... will go through them shortly. ball is in my court(tm) |
this is to support service-management via helm-release-names vs pod/namespace existence |
q: did you happen to capture the error? was it a timeout? |
this has been in mdsctl:bootstrap() for awhile now to support the js smoke-tests |
objective
deploy a contemporary nats+surveyor stack
see: https://docs.google.com/document/d/1Um5bgu6CY1MapEb-VOy5OAECDkrr9RsgijjGiqCQTTQ/edit
not included in this patch are the following:
multi-tenancy
further going with this approach we will want to deploy the stans pods outside the central nats namespace, optimally collocated within the mds pod.
alternatively we can consider centralizing the stan cluster, leaving the [tenant-id] message prefix in place but this feels suboptimal to me (unnecessarily co-mingling tenant infrastructure).
profiles / tunables
when running locally it is encouraged to specify one of the non-default
local
profiles in that they are tuned to tighten the streaming message durability policies tuned for resource constrained environments.on this note, the message default message retention policy for non-local environments is:
note: best guessing these values which we can/will adjust as we gain more operational context
additionally included in this patch is nats-authentication which should work by default storing nats-credentials-information in the ~/.nkeys and ~/.nsc directories by default. this is overridable such that we can leverage shared operational credentials, namely from the
cloud-ops
repository, with an mds override, eg:observability
nats provides surveyor which is the expected prometheus+grafana stack. as such we will gain more operational insight into nats.
deploy local
deploy remote
verify
cleanup