Activity log for bug #2003540

Date Who What changed Old value New value Message
2023-01-20 13:15:32 Andre Ruiz bug added bug
2023-01-20 13:16:10 Andre Ruiz description I'm running charm cinder-three-par, channel yoga/stable, release 13. It's related to cinder-volume charm channel yoga/stable release 582. Cinder-volume is running separate from main cinder services so that it can be run on compute-nodes that have FC HBAs (controllers do not have them). The charm configuration is as follows: ==================================8<-------------------------------------- applications: # extra cinder volumes on compute nodes because of 3par FC access cinder-volume: bindings: '': oam-space admin: public-space amqp: internal-space certificates: internal-space identity-service: internal-space internal: internal-space public: public-space shared-db: internal-space channel: yoga/stable charm: cinder constraints: spaces=ceph-access-space options: block-device: None glance-api-version: 2 openstack-origin: *openstack-origin region: *openstack-region use-internal-endpoints: true enabled-services: "volume" num_units: 6 to: # trying to spread over racks - 2001 - 2010 - 2020 - 2030 - 2040 - 2050 cinder-three-par-backend03: channel: yoga/stable charm: cinder-three-par options: driver-type: fc san-ip: 10.x.x.x san-login: redacted san-password: redacted hpe3par-api-url: https://10.x.x.x:8080/api/v1 hpe3par-username: redacted hpe3par-password: redacted hpe3par-cpg: Xxxx_CPG03 use-multipath-for-image-xfer: True enforce-multipath-for-image-xfer: True volume-backend-name: 3PAR_Backend03 relations: - ['cinder-volume:storage-backend', 'cinder-three-par-backend03:storage-backend'] ==================================8<-------------------------------------- The configuration does work, the driver connects to the storage and reports status "up" to cinder services. But the charm status stays like "Charm configuration in progress" even after everything is already ok. The order of events is as follows: - Charms cinder-volume and cinder-three-par finish installing - Both execute for some time - Cinder-three-par *does* pass configuration to cinder-volume, which can be seen in main cinder.conf file - Cinder-volume blocks with "services not running that should be: cinder-volume" because of a different bug (LP#1987009) - I restart the cinder-volumes services as the suggested workaround in that bug report, services do start normally and charm status become active - At some point, not sure if before or after that, status for charm cinder-three-par also becomes active - at this point, everything is working, cinder-volume is running, 3par driver is configured, backend status in "openstack volume services list" appears "up" - a few minutes pass by, I think one cycle of update-status (~about 5 minutes), status of charm cinder-three-par becomes "waiting" with message "Charm configuration in progress" and stays like that forever cinder-three-par-backend03/0* waiting idle 10.1.12.56 Charm configuration in progress cinder-three-par-backend03/3 waiting idle 10.1.12.64 Charm configuration in progress cinder-three-par-backend03/2 waiting idle 10.1.12.76 Charm configuration in progress cinder-three-par-backend03/1 waiting idle 10.1.12.86 Charm configuration in progress cinder-three-par-backend03/4 waiting idle 10.1.12.92 Charm configuration in progress cinder-three-par-backend03/5 waiting idle 10.1.12.106 Charm configuration in progress So, everything seems fine until that last moment where the charm decides again it's not configured yet. I'm running charm cinder-three-par, channel yoga/stable, release 13. It's related to cinder-volume charm channel yoga/stable release 582. Cinder-volume is running separate from main cinder services so that it can be run on compute-nodes that have FC HBAs (controllers do not have them). It's yoga on focal. The charm configuration is as follows: ==================================8<-------------------------------------- applications:   # extra cinder volumes on compute nodes because of 3par FC access   cinder-volume:     bindings:       '': oam-space       admin: public-space       amqp: internal-space       certificates: internal-space       identity-service: internal-space       internal: internal-space       public: public-space       shared-db: internal-space     channel: yoga/stable     charm: cinder     constraints: spaces=ceph-access-space     options:       block-device: None       glance-api-version: 2       openstack-origin: *openstack-origin       region: *openstack-region       use-internal-endpoints: true       enabled-services: "volume"     num_units: 6     to: # trying to spread over racks     - 2001     - 2010     - 2020     - 2030     - 2040     - 2050   cinder-three-par-backend03:     channel: yoga/stable     charm: cinder-three-par     options:       driver-type: fc       san-ip: 10.x.x.x       san-login: redacted       san-password: redacted       hpe3par-api-url: https://10.x.x.x:8080/api/v1       hpe3par-username: redacted       hpe3par-password: redacted       hpe3par-cpg: Xxxx_CPG03       use-multipath-for-image-xfer: True       enforce-multipath-for-image-xfer: True       volume-backend-name: 3PAR_Backend03 relations:   - ['cinder-volume:storage-backend', 'cinder-three-par-backend03:storage-backend'] ==================================8<-------------------------------------- The configuration does work, the driver connects to the storage and reports status "up" to cinder services. But the charm status stays like "Charm configuration in progress" even after everything is already ok. The order of events is as follows: - Charms cinder-volume and cinder-three-par finish installing - Both execute for some time - Cinder-three-par *does* pass configuration to cinder-volume, which can be seen in main cinder.conf file - Cinder-volume blocks with "services not running that should be: cinder-volume" because of a different bug (LP#1987009) - I restart the cinder-volumes services as the suggested workaround in that bug report, services do start normally and charm status become active - At some point, not sure if before or after that, status for charm cinder-three-par also becomes active - at this point, everything is working, cinder-volume is running, 3par driver is configured, backend status in "openstack volume services list" appears "up" - a few minutes pass by, I think one cycle of update-status (~about 5 minutes), status of charm cinder-three-par becomes "waiting" with message "Charm configuration in progress" and stays like that forever   cinder-three-par-backend03/0* waiting idle 10.1.12.56 Charm configuration in progress   cinder-three-par-backend03/3 waiting idle 10.1.12.64 Charm configuration in progress   cinder-three-par-backend03/2 waiting idle 10.1.12.76 Charm configuration in progress   cinder-three-par-backend03/1 waiting idle 10.1.12.86 Charm configuration in progress   cinder-three-par-backend03/4 waiting idle 10.1.12.92 Charm configuration in progress   cinder-three-par-backend03/5 waiting idle 10.1.12.106 Charm configuration in progress So, everything seems fine until that last moment where the charm decides again it's not configured yet.
2023-01-20 13:18:34 Andre Ruiz description I'm running charm cinder-three-par, channel yoga/stable, release 13. It's related to cinder-volume charm channel yoga/stable release 582. Cinder-volume is running separate from main cinder services so that it can be run on compute-nodes that have FC HBAs (controllers do not have them). It's yoga on focal. The charm configuration is as follows: ==================================8<-------------------------------------- applications:   # extra cinder volumes on compute nodes because of 3par FC access   cinder-volume:     bindings:       '': oam-space       admin: public-space       amqp: internal-space       certificates: internal-space       identity-service: internal-space       internal: internal-space       public: public-space       shared-db: internal-space     channel: yoga/stable     charm: cinder     constraints: spaces=ceph-access-space     options:       block-device: None       glance-api-version: 2       openstack-origin: *openstack-origin       region: *openstack-region       use-internal-endpoints: true       enabled-services: "volume"     num_units: 6     to: # trying to spread over racks     - 2001     - 2010     - 2020     - 2030     - 2040     - 2050   cinder-three-par-backend03:     channel: yoga/stable     charm: cinder-three-par     options:       driver-type: fc       san-ip: 10.x.x.x       san-login: redacted       san-password: redacted       hpe3par-api-url: https://10.x.x.x:8080/api/v1       hpe3par-username: redacted       hpe3par-password: redacted       hpe3par-cpg: Xxxx_CPG03       use-multipath-for-image-xfer: True       enforce-multipath-for-image-xfer: True       volume-backend-name: 3PAR_Backend03 relations:   - ['cinder-volume:storage-backend', 'cinder-three-par-backend03:storage-backend'] ==================================8<-------------------------------------- The configuration does work, the driver connects to the storage and reports status "up" to cinder services. But the charm status stays like "Charm configuration in progress" even after everything is already ok. The order of events is as follows: - Charms cinder-volume and cinder-three-par finish installing - Both execute for some time - Cinder-three-par *does* pass configuration to cinder-volume, which can be seen in main cinder.conf file - Cinder-volume blocks with "services not running that should be: cinder-volume" because of a different bug (LP#1987009) - I restart the cinder-volumes services as the suggested workaround in that bug report, services do start normally and charm status become active - At some point, not sure if before or after that, status for charm cinder-three-par also becomes active - at this point, everything is working, cinder-volume is running, 3par driver is configured, backend status in "openstack volume services list" appears "up" - a few minutes pass by, I think one cycle of update-status (~about 5 minutes), status of charm cinder-three-par becomes "waiting" with message "Charm configuration in progress" and stays like that forever   cinder-three-par-backend03/0* waiting idle 10.1.12.56 Charm configuration in progress   cinder-three-par-backend03/3 waiting idle 10.1.12.64 Charm configuration in progress   cinder-three-par-backend03/2 waiting idle 10.1.12.76 Charm configuration in progress   cinder-three-par-backend03/1 waiting idle 10.1.12.86 Charm configuration in progress   cinder-three-par-backend03/4 waiting idle 10.1.12.92 Charm configuration in progress   cinder-three-par-backend03/5 waiting idle 10.1.12.106 Charm configuration in progress So, everything seems fine until that last moment where the charm decides again it's not configured yet. I'm running charm cinder-three-par, channel yoga/stable, release 13. It's related to cinder-volume charm channel yoga/stable release 582. Cinder-volume is running separate from main cinder services so that it can be run on compute-nodes that have FC HBAs (controllers do not have them). It's yoga on focal. The charm configuration is as follows: ==================================8<-------------------------------------- applications:   # extra cinder volumes on compute nodes because of 3par FC access   cinder-volume:     bindings:       '': oam-space       admin: public-space       amqp: internal-space       certificates: internal-space       identity-service: internal-space       internal: internal-space       public: public-space       shared-db: internal-space     channel: yoga/stable     charm: cinder     constraints: spaces=ceph-access-space     options:       block-device: None       glance-api-version: 2       openstack-origin: *openstack-origin       region: *openstack-region       use-internal-endpoints: true       enabled-services: "volume"     num_units: 6     to: # trying to spread over racks     - 2001     - 2010     - 2020     - 2030     - 2040     - 2050   cinder-three-par-backend03:     channel: yoga/stable     charm: cinder-three-par     options:       driver-type: fc       san-ip: 10.x.x.x       san-login: redacted       san-password: redacted       hpe3par-api-url: https://10.x.x.x:8080/api/v1       hpe3par-username: redacted       hpe3par-password: redacted       hpe3par-cpg: Xxxx_CPG03       use-multipath-for-image-xfer: True       enforce-multipath-for-image-xfer: True       volume-backend-name: 3PAR_Backend03 relations:   - ['cinder-volume:storage-backend', 'cinder-three-par-backend03:storage-backend'] ==================================8<-------------------------------------- The configuration does work, the driver connects to the storage and reports status "up" to cinder services. But the charm status stays like "Charm configuration in progress" even after everything is already ok. The order of events is as follows: - Charms cinder-volume and cinder-three-par finish installing - Both execute for some time - Cinder-three-par *does* pass configuration to cinder-volume, which can be seen in main cinder.conf file - Cinder-volume blocks with "services not running that should be: cinder-volume" because of a different bug (LP#1987009) - I restart the cinder-volumes services as the suggested workaround in that bug report, services do start normally and charm status become active - At some point, not sure if before or after that, status for charm cinder-three-par also becomes active - at this point, everything is working, cinder-volume is running, 3par driver is configured, backend status in "openstack volume services list" appears "up" - a few minutes pass by, I think one cycle of update-status (~about 5 minutes), status of charm cinder-three-par becomes "waiting" with message "Charm configuration in progress" and stays like that forever   cinder-three-par-backend03/0* waiting idle 10.1.12.56 Charm configuration in progress   cinder-three-par-backend03/3 waiting idle 10.1.12.64 Charm configuration in progress   cinder-three-par-backend03/2 waiting idle 10.1.12.76 Charm configuration in progress   cinder-three-par-backend03/1 waiting idle 10.1.12.86 Charm configuration in progress   cinder-three-par-backend03/4 waiting idle 10.1.12.92 Charm configuration in progress   cinder-three-par-backend03/5 waiting idle 10.1.12.106 Charm configuration in progress So, everything seems fine until that last moment where the charm decides again it's not configured yet. To be clear: driver continues to work, the only issue is charm status.