| 2022-09-21 09:30:29 |
Tom Haddon |
bug |
|
|
added bug |
| 2022-09-21 09:30:39 |
Tom Haddon |
tags |
|
canonical-is |
|
| 2022-09-21 09:31:06 |
Tom Haddon |
attachment added |
|
engine report from machine 0 in controller model https://bugs.launchpad.net/juju/+bug/1990369/+attachment/5617657/+files/engine-report.unit0.log |
|
| 2022-09-21 09:31:26 |
Tom Haddon |
attachment added |
|
engine report from machine 1 in controller model https://bugs.launchpad.net/juju/+bug/1990369/+attachment/5617658/+files/engine-report.unit1.log |
|
| 2022-09-21 09:31:45 |
Tom Haddon |
attachment added |
|
engine report from machine 2 in controller model https://bugs.launchpad.net/juju/+bug/1990369/+attachment/5617659/+files/engine-report.unit2.log |
|
| 2022-09-21 09:33:42 |
Tom Haddon |
description |
We have a juju k8s model (2.9.32) attached to an openstack HA controller in which we had a number of applications deployed, including two versions of https://charmhub.io/redis-k8s - named in this model as `redis-cache` and `redis-broker`.
The initial deployment was using pod-spec charms, and we wanted to switch to sidecar charms. In local testing, we found that we couldn't just run a charm upgrade, but needed to remove the application and then redeploy.
However, when we came to do this on our staging instance, we found ourselves unable to redeploy the applications. The units are stuck in "installing agent" status and there are no pods deployed in kubernetes.
We have done some live debugging with Joe Phillips (thx!) and I'll attach some engine reports from the controllers for reference.
We're not able to reproduce this yet in another model, but are happy to provide any information or access to the model via a screenshare as needed to help debug. |
We have a juju k8s model (2.9.32) attached to an openstack HA controller in which we had a number of applications deployed, including two versions of https://charmhub.io/redis-k8s - named in this model as `redis-cache` and `redis-broker`.
The initial deployment was using pod-spec charms, and we wanted to switch to sidecar charms. In local testing, we found that we couldn't just run a charm upgrade, but needed to remove the application and then redeploy.
However, when we came to do this on our staging instance, we found ourselves unable to redeploy the applications. The units are stuck in "installing agent" status and there are no pods deployed in kubernetes.
We have the same issue for both versions of the redis-k8s applications that we've deployed (redis-cache and redis-broker). We can deploy them fine if we use a different application name (e.g. redis-cache2 or redis-broker2).
We have done some live debugging with Joe Phillips (thx!) and I'll attach some engine reports from the controllers for reference.
We're not able to reproduce this yet in another model, but are happy to provide any information or access to the model via a screenshare as needed to help debug. |
|
| 2022-09-21 09:35:48 |
Tom Haddon |
description |
We have a juju k8s model (2.9.32) attached to an openstack HA controller in which we had a number of applications deployed, including two versions of https://charmhub.io/redis-k8s - named in this model as `redis-cache` and `redis-broker`.
The initial deployment was using pod-spec charms, and we wanted to switch to sidecar charms. In local testing, we found that we couldn't just run a charm upgrade, but needed to remove the application and then redeploy.
However, when we came to do this on our staging instance, we found ourselves unable to redeploy the applications. The units are stuck in "installing agent" status and there are no pods deployed in kubernetes.
We have the same issue for both versions of the redis-k8s applications that we've deployed (redis-cache and redis-broker). We can deploy them fine if we use a different application name (e.g. redis-cache2 or redis-broker2).
We have done some live debugging with Joe Phillips (thx!) and I'll attach some engine reports from the controllers for reference.
We're not able to reproduce this yet in another model, but are happy to provide any information or access to the model via a screenshare as needed to help debug. |
We have a juju k8s model (2.9.32) attached to an openstack HA controller in which we had a number of applications deployed, including two versions of https://charmhub.io/redis-k8s - named in this model as `redis-cache` and `redis-broker`.
The initial deployment was using pod-spec charms, and we wanted to switch to sidecar charms (which are published in the edge channel of this charm). In local testing, we found that we couldn't just run a charm upgrade, but needed to remove the application and then redeploy.
However, when we came to do this on our staging instance, we found ourselves unable to redeploy the applications. The units are stuck in "installing agent" status and there are no pods deployed in kubernetes.
We have the same issue for both versions of the redis-k8s applications that we've deployed (redis-cache and redis-broker). We can deploy them fine if we use a different application name (e.g. redis-cache2 or redis-broker2).
We have done some live debugging with Joe Phillips (thx!) and I'll attach some engine reports from the controllers for reference.
We're not able to reproduce this yet in another model, but are happy to provide any information or access to the model via a screenshare as needed to help debug. |
|
| 2022-09-21 09:38:59 |
Arturo Enrique Seijas Fernández |
bug |
|
|
added subscriber Arturo Enrique Seijas Fernández |
| 2022-09-22 11:33:19 |
Vitaly Antonenko |
juju: status |
New |
Triaged |
|
| 2022-09-22 11:33:23 |
Vitaly Antonenko |
juju: importance |
Undecided |
High |
|
| 2022-09-22 11:33:55 |
Vitaly Antonenko |
juju: assignee |
|
Joseph Phillips (manadart) |
|
| 2022-09-22 14:53:49 |
John A Meinel |
juju: milestone |
|
2.9-next |
|
| 2022-09-22 14:53:49 |
John A Meinel |
juju: assignee |
Joseph Phillips (manadart) |
|
|
| 2023-04-25 14:37:38 |
Ian Booth |
juju: milestone |
2.9-next |
|
|
