fix(docs): Update getting-started script pre-26.3.0#123
Conversation
There was a problem hiding this comment.
This hangs when using the helm install (stackablectl works fine):
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
...
MountVolume.SetUp failed for volume "pvc-f096ca69-82f2-43c4-8a6f-9e02c103f8bf" : rpc error: code = Unavailable desc = listener has no addresses yet
Warning FailedMount 41s (x9 over 4m50s) kubelet MountVolume.SetUp failed for volume "pvc-9de1bb0c-f73a-40b3-9671-ea9d83f68923" : rpc error: code = FailedPrecondition desc = failed to parse pod details: PodListeners.v1alpha1.listeners.stackable.tech/pod-7d2401dc-ca8a-45fa-a5a5-a34881a68726.default has no addresses for listener discovery-service-listener yet
I'll try again
adwk67
moved this from Development: Waiting for Review
to Development: In Review
in Stackable Engineering
OK, I need to FixEither change
by appending or change |
|
In my opinion, the second approach is the better one. What do you think @adwk67? |
Yes, I agree - that's cleaner and less invasive. |
When running the getting started script against a local kind cluster, stackablectl will automatically choose the stable-nodes preset, which works out of the box with both external-stable and external-unstable. However, when using helm, the default preset (ephemeral-nodes) is used and causes OpenSearch cluster pods to not start up, because kind doesn't support LoadBalancers. This is the reason why we chose to do the less invasive change, and change the ListenerClass to external-unstable.
|
Personally I would have gone with the preset, and made sure there's a note in the getting started docs to help the reader make the right choice for themselves (a comment in the yaml could do the same too). |
NickLarsenNZ
left a comment
NickLarsenNZ
left a comment
There was a problem hiding this comment.
LGTM (see my earlier comment).
NickLarsenNZ
moved this from Development: In Review
to Development: Done
in Stackable Engineering
3 participants
Check and Update Getting Started Script
Part of stackabletech/issues#826
This getting-started script was technically fine as is (it ran through without any issues), but I still opted to include both waiting conditions, because it generally a good thing to do going forward.