| 2021-08-19 14:41:13 |
Steven Parker |
bug |
|
|
added bug |
| 2021-08-20 13:06:36 |
Steven Parker |
bug |
|
|
added subscriber alive-shad (BootStack) |
| 2021-08-20 13:09:27 |
Andy Boje |
bug |
|
|
added subscriber Andy Boje |
| 2021-08-25 14:42:10 |
Steven Parker |
bug task added |
|
charm-kubernetes-worker |
|
| 2021-08-25 14:42:39 |
Steven Parker |
bug task added |
|
charm-kubernetes-master |
|
| 2021-08-25 14:52:28 |
Steven Parker |
bug |
|
|
added subscriber Canonical IS BootStack |
| 2021-08-25 17:43:15 |
Cory Johns |
bug task added |
|
charm-easyrsa |
|
| 2021-08-25 18:22:39 |
Cory Johns |
bug task deleted |
charm-kubernetes-master |
|
|
| 2021-08-25 18:22:44 |
Cory Johns |
bug task deleted |
charm-kubernetes-worker |
|
|
| 2021-08-27 13:28:08 |
Aurelien Lourot |
vault-charm: status |
New |
Triaged |
|
| 2021-08-27 13:28:11 |
Aurelien Lourot |
vault-charm: importance |
Undecided |
Medium |
|
| 2021-12-14 21:53:34 |
James Troup |
bug |
|
|
added subscriber Canonical Field High |
| 2021-12-14 21:56:10 |
Corey Bryant |
vault-charm: importance |
Medium |
High |
|
| 2021-12-14 22:02:14 |
Corey Bryant |
description |
While attempting to refresh certificates for a k8s installation no units other then the client leaders updated.
Steps to replicate:
Deploy k8s stack and vault with replication count 3 (HA).
Delete vault unit which is leader and add another
execute refresh certificates action
confirm k8s client.crt is actually updated or fail to update
juju ssh kubernetes-worker/0 sudo openssl x509 -in /root/cdk/client.crt -text
Repeat a few times
At issue is that there are multiple instances of relation data from those units being shared with other applications vs one source of truth (the leader).
We have one vault leader which provides the correct data when we re-issue certificates.
However, older vault units that may have been leader at some time still retain stale certificate data shared with all the clients.
That stale data is conflicting with the newly provided certificates and the clients think nothing has changed (the stale data has the original certs)
and thus the clients do not drop the client certificates to disk.
We cleared data from the non leaders to solve the issue:
For example here is vault/0 which is a non-leader (vault/1 is the current leader)
juju run -u vault/0 "relation-set -r certificates:61
kubernetes-master_0.server.key='' kubernetes-master_0.server.cert='' kubernetes-master_0.processed_client_requests=''
kubernetes-master_1.server.key='' kubernetes-master_1.server.cert='' kubernetes-master_1.processed_client_requests=''
kubernetes-master_2.server.key='' kubernetes-master_2.server.cert='' kubernetes-master_2.processed_client_requests=''
kubernetes-master_5.server.key='' kubernetes-master_5.server.cert='' kubernetes-master_5.processed_client_requests=''
"
Once the stale data was cleared the clients saw the new certificates and updated correctly. |
While attempting to refresh certificates for a k8s installation no units other then the client leaders updated.
Steps to replicate:
Deploy k8s stack and vault with replication count 3 (HA).
Delete vault unit which is leader and add another
execute refresh certificates action
confirm k8s client.crt is actually updated or fail to update
juju ssh kubernetes-worker/0 sudo openssl x509 -in /root/cdk/client.crt -text
Repeat a few times
At issue is that there are multiple instances of relation data from those units being shared with other applications vs one source of truth (the leader).
We have one vault leader which provides the correct data when we re-issue certificates.
However, older vault units that may have been leader at some time still retain stale certificate data shared with all the clients.
That stale data is conflicting with the newly provided certificates and the clients think nothing has changed (the stale data has the original certs)
and thus the clients do not drop the client certificates to disk.
== work-around ==
We cleared data from the non leaders to solve the issue:
For example here is vault/0 which is a non-leader (vault/1 is the current leader)
juju run -u vault/0 "relation-set -r certificates:61
kubernetes-master_0.server.key='' kubernetes-master_0.server.cert='' kubernetes-master_0.processed_client_requests=''
kubernetes-master_1.server.key='' kubernetes-master_1.server.cert='' kubernetes-master_1.processed_client_requests=''
kubernetes-master_2.server.key='' kubernetes-master_2.server.cert='' kubernetes-master_2.processed_client_requests=''
kubernetes-master_5.server.key='' kubernetes-master_5.server.cert='' kubernetes-master_5.processed_client_requests=''
"
Once the stale data was cleared the clients saw the new certificates and updated correctly. |
|
| 2021-12-14 22:02:28 |
Corey Bryant |
description |
While attempting to refresh certificates for a k8s installation no units other then the client leaders updated.
Steps to replicate:
Deploy k8s stack and vault with replication count 3 (HA).
Delete vault unit which is leader and add another
execute refresh certificates action
confirm k8s client.crt is actually updated or fail to update
juju ssh kubernetes-worker/0 sudo openssl x509 -in /root/cdk/client.crt -text
Repeat a few times
At issue is that there are multiple instances of relation data from those units being shared with other applications vs one source of truth (the leader).
We have one vault leader which provides the correct data when we re-issue certificates.
However, older vault units that may have been leader at some time still retain stale certificate data shared with all the clients.
That stale data is conflicting with the newly provided certificates and the clients think nothing has changed (the stale data has the original certs)
and thus the clients do not drop the client certificates to disk.
== work-around ==
We cleared data from the non leaders to solve the issue:
For example here is vault/0 which is a non-leader (vault/1 is the current leader)
juju run -u vault/0 "relation-set -r certificates:61
kubernetes-master_0.server.key='' kubernetes-master_0.server.cert='' kubernetes-master_0.processed_client_requests=''
kubernetes-master_1.server.key='' kubernetes-master_1.server.cert='' kubernetes-master_1.processed_client_requests=''
kubernetes-master_2.server.key='' kubernetes-master_2.server.cert='' kubernetes-master_2.processed_client_requests=''
kubernetes-master_5.server.key='' kubernetes-master_5.server.cert='' kubernetes-master_5.processed_client_requests=''
"
Once the stale data was cleared the clients saw the new certificates and updated correctly. |
While attempting to refresh certificates for a k8s installation no units other then the client leaders updated.
Steps to replicate:
Deploy k8s stack and vault with replication count 3 (HA).
Delete vault unit which is leader and add another
execute refresh certificates action
confirm k8s client.crt is actually updated or fail to update
juju ssh kubernetes-worker/0 sudo openssl x509 -in /root/cdk/client.crt -text
Repeat a few times
At issue is that there are multiple instances of relation data from those units being shared with other applications vs one source of truth (the leader).
We have one vault leader which provides the correct data when we re-issue certificates.
However, older vault units that may have been leader at some time still retain stale certificate data shared with all the clients.
That stale data is conflicting with the newly provided certificates and the clients think nothing has changed (the stale data has the original certs)
and thus the clients do not drop the client certificates to disk.
== work-around below ==
We cleared data from the non leaders to solve the issue:
For example here is vault/0 which is a non-leader (vault/1 is the current leader)
juju run -u vault/0 "relation-set -r certificates:61
kubernetes-master_0.server.key='' kubernetes-master_0.server.cert='' kubernetes-master_0.processed_client_requests=''
kubernetes-master_1.server.key='' kubernetes-master_1.server.cert='' kubernetes-master_1.processed_client_requests=''
kubernetes-master_2.server.key='' kubernetes-master_2.server.cert='' kubernetes-master_2.processed_client_requests=''
kubernetes-master_5.server.key='' kubernetes-master_5.server.cert='' kubernetes-master_5.processed_client_requests=''
"
Once the stale data was cleared the clients saw the new certificates and updated correctly. |
|
| 2021-12-14 22:03:12 |
Corey Bryant |
vault-charm: importance |
High |
Medium |
|
| 2021-12-14 22:03:20 |
Corey Bryant |
vault-charm: importance |
Medium |
High |
|
| 2021-12-14 22:03:34 |
Corey Bryant |
bug task added |
|
charm-ovn-chassis |
|
| 2021-12-14 22:03:46 |
Corey Bryant |
bug task added |
|
charm-ovn-central |
|
| 2021-12-15 00:30:07 |
Andrea Ieri |
bug task added |
|
charm-neutron-api-plugin-ovn |
|
| 2022-01-24 18:07:49 |
Corey Bryant |
charm-ovn-chassis: status |
New |
Triaged |
|
| 2022-01-24 18:07:52 |
Corey Bryant |
charm-ovn-chassis: importance |
Undecided |
High |
|
| 2022-01-24 18:07:56 |
Corey Bryant |
charm-ovn-central: status |
New |
Triaged |
|
| 2022-01-24 18:08:00 |
Corey Bryant |
charm-ovn-central: importance |
Undecided |
High |
|
| 2022-01-24 18:08:03 |
Corey Bryant |
charm-neutron-api-plugin-ovn: status |
New |
Triaged |
|
| 2022-01-24 18:08:05 |
Corey Bryant |
charm-neutron-api-plugin-ovn: importance |
Undecided |
High |
|
| 2022-01-27 09:53:12 |
Martin Kalcok |
vault-charm: assignee |
|
Martin Kalcok (martin-kalcok) |
|
| 2022-01-27 09:53:16 |
Martin Kalcok |
vault-charm: status |
Triaged |
In Progress |
|
| 2022-02-11 15:40:30 |
Martin Kalcok |
tags |
|
review-needed |
|
| 2022-02-28 16:07:59 |
Martin Kalcok |
tags |
review-needed |
|
|
| 2022-03-17 19:48:07 |
Corey Bryant |
attachment added |
|
bundle.yaml https://bugs.launchpad.net/vault-charm/+bug/1940549/+attachment/5570187/+files/bundle.yaml |
|
| 2022-05-23 18:32:45 |
Corey Bryant |
vault-charm: status |
In Progress |
Fix Committed |
|
| 2022-05-23 18:34:46 |
Corey Bryant |
charm-ovn-chassis: status |
Triaged |
Fix Committed |
|
| 2022-05-23 18:34:49 |
Corey Bryant |
charm-ovn-central: status |
Triaged |
Fix Committed |
|
| 2022-05-23 18:34:52 |
Corey Bryant |
charm-neutron-api-plugin-ovn: status |
Triaged |
Fix Committed |
|
| 2022-05-23 18:34:55 |
Corey Bryant |
charm-easyrsa: status |
New |
Fix Committed |
|
| 2022-05-23 18:48:56 |
George Kraft |
bug task deleted |
charm-easyrsa |
|
|
| 2022-06-23 23:54:12 |
Brett Milford |
bug |
|
|
added subscriber Brett Milford |
| 2022-07-20 22:15:22 |
Navdeep |
vault-charm: status |
Fix Committed |
Fix Released |
|
| 2022-08-10 08:00:43 |
Eric Chen |
tags |
|
bseng-344 |
|
| 2022-10-28 14:32:00 |
Felipe Reyes |
vault-charm: status |
Fix Released |
Fix Committed |
|
| 2022-10-28 14:35:19 |
Felipe Reyes |
vault-charm: status |
Fix Committed |
New |
|
| 2022-10-30 14:40:21 |
Eric Chen |
vault-charm: assignee |
Martin Kalcok (martin-kalcok) |
|
|
| 2023-01-16 08:12:44 |
Jorge Rodríguez |
bug |
|
|
added subscriber Jorge Rodríguez |
| 2023-03-22 00:25:01 |
Andrea Ieri |
tags |
bseng-344 |
bseng-1021 bseng-344 |
|
| 2023-03-30 13:47:34 |
Junien F |
bug |
|
|
added subscriber The Canonical Sysadmins |
| 2023-03-30 13:49:39 |
Camille Rodriguez |
bug |
|
|
added subscriber Camille Rodriguez |
| 2023-04-06 05:15:49 |
Billy Olsen |
nominated for series |
|
vault-charm/1.6 |
|
| 2023-04-06 05:15:49 |
Billy Olsen |
bug task added |
|
vault-charm/1.6 |
|
| 2023-04-06 05:15:49 |
Billy Olsen |
nominated for series |
|
vault-charm/1.8 |
|
| 2023-04-06 05:15:49 |
Billy Olsen |
bug task added |
|
vault-charm/1.8 |
|
| 2023-04-06 05:15:49 |
Billy Olsen |
nominated for series |
|
vault-charm/1.5 |
|
| 2023-04-06 05:15:49 |
Billy Olsen |
bug task added |
|
vault-charm/1.5 |
|
| 2023-04-06 05:15:49 |
Billy Olsen |
nominated for series |
|
vault-charm/1.7 |
|
| 2023-04-06 05:15:49 |
Billy Olsen |
bug task added |
|
vault-charm/1.7 |
|
| 2023-04-06 05:17:31 |
Billy Olsen |
vault-charm/1.8: status |
New |
Fix Released |
|
| 2023-04-06 05:17:35 |
Billy Olsen |
vault-charm/1.7: status |
New |
Fix Released |
|
| 2023-04-06 05:17:40 |
Billy Olsen |
vault-charm/1.6: status |
New |
Fix Released |
|
| 2023-04-11 12:17:49 |
Rodrigo Barbieri |
vault-charm/1.5: status |
New |
Fix Released |
|
| 2023-05-02 08:32:49 |
Mustafa Kemal Gilor |
bug |
|
|
added subscriber Mustafa Kemal Gilor |
| 2023-06-12 11:09:53 |
Alex Kavanagh |
vault-charm/1.5: status |
Fix Released |
Triaged |
|
| 2023-06-12 11:09:56 |
Alex Kavanagh |
vault-charm: status |
New |
Triaged |
|
| 2023-06-12 11:10:00 |
Alex Kavanagh |
vault-charm/1.6: status |
Fix Released |
Triaged |
|
| 2023-06-12 11:10:03 |
Alex Kavanagh |
vault-charm/1.7: status |
Fix Released |
Triaged |
|
| 2023-06-12 11:10:05 |
Alex Kavanagh |
vault-charm/1.8: status |
Fix Released |
Triaged |
|
| 2023-10-16 14:46:11 |
Alex Kavanagh |
vault-charm: status |
Triaged |
Fix Released |
|
| 2023-10-16 14:46:47 |
Alex Kavanagh |
charm-neutron-api-plugin-ovn: status |
Fix Committed |
Fix Released |
|
| 2023-10-16 14:46:49 |
Alex Kavanagh |
charm-ovn-central: status |
Fix Committed |
Fix Released |
|
| 2023-10-16 14:46:54 |
Alex Kavanagh |
charm-ovn-central: status |
Fix Released |
Fix Committed |
|
| 2023-10-16 14:46:57 |
Alex Kavanagh |
charm-neutron-api-plugin-ovn: status |
Fix Released |
Fix Committed |
|
| 2023-12-05 15:17:25 |
Chris Valean |
bug |
|
|
added subscriber Chris Valean |
| 2024-03-03 12:30:28 |
Alex Kavanagh |
vault-charm/1.8: status |
Triaged |
Fix Released |
|
| 2024-03-03 12:30:33 |
Alex Kavanagh |
vault-charm/1.7: status |
Triaged |
Fix Released |
|
| 2024-03-03 12:30:41 |
Alex Kavanagh |
vault-charm/1.6: status |
Triaged |
In Progress |
|
| 2024-03-03 12:30:51 |
Alex Kavanagh |
vault-charm/1.6: status |
In Progress |
Triaged |
|
