Skip to content
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

Wait for ES deployment to be ready and then deploy jaeger #216

Closed
pavolloffay opened this issue Feb 21, 2019 · 5 comments
Closed

Wait for ES deployment to be ready and then deploy jaeger #216

pavolloffay opened this issue Feb 21, 2019 · 5 comments

Comments

@pavolloffay
Copy link
Member

Now operator creates ES CR and jaeger objects (deployments) at the same time. This is causing jaeger pods to fail multiple times until Elasticsearch is up.

@pavolloffay
Copy link
Member Author

I think this one of the most important features for ES deployment.

Thinking about how to tackle it. Maybe the best would be to use k8s client and wait until ES deployment is up - readiness probe responds positively.

@jpkrohling
Copy link
Contributor

I'd say that the cleanest would be to create a Job that blocks until it can make a connection to ES. This Job can be added to the list of Dependencies, similar to how the CassandraCreateSchema works.

func Dependencies(jaeger *v1alpha1.Jaeger) []batchv1.Job {
if strings.EqualFold(jaeger.Spec.Storage.Type, "cassandra") {
return cassandraDeps(jaeger)
}
return nil
}

func cassandraDeps(jaeger *v1alpha1.Jaeger) []batchv1.Job {

@pavolloffay
Copy link
Member Author

I was thinking about this but - it seems more complicated and harder to maintain.

With job we need a separate docker image with code which calls ES - this will require mounting secrets etc.

I would rather use operator to do this using the similar way how it looks for dependencies jobs to be finished.

@pavolloffay
Copy link
Member Author

Dependencies for C* makes sense - it initializes schema. Whereas in this case we just wait until deployment is ready.

For rollover support using dependencies makes sense - as we need to initialize mappings and create indices. The rollover image would fail if the ES is not up.

@jpkrohling
Copy link
Contributor

Then probably something like:

for _, d := range depInventory.Create {
if err := r.waitForStability(d); err != nil {
return err
}
}
for _, d := range depInventory.Update {
if err := r.waitForStability(d); err != nil {
return err
}
}

and

func (r *ReconcileJaeger) waitForStability(dep appsv1.Deployment) error {
// TODO: decide what's a good timeout... the first cold run might take a while to download
// the images, subsequent runs should take only a few seconds
return wait.PollImmediate(time.Second, 5*time.Minute, func() (done bool, err error) {
d := &appsv1.Deployment{}
if err := r.client.Get(context.Background(), types.NamespacedName{Name: dep.Name, Namespace: dep.Namespace}, d); err != nil {
return false, err
}
if d.Status.ReadyReplicas != d.Status.Replicas {
log.WithFields(log.Fields{
"namespace": dep.Namespace,
"name": dep.Name,
"ready": d.Status.ReadyReplicas,
"desired": d.Status.Replicas,
}).Debug("Waiting for deployment to estabilize")
return false, nil
}
return true, nil
})
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants