[Bug 2012073] [NEW] [SRU] SwiftSignalHandle fails due to python2-3 decode error

[Rodrigo Barbieri]

Public bug reported:

Storyboard link: https://storyboard.openstack.org/#!/story/2010485

============
SRU TEMPLATE
============

[Impact]

The issue impact stack creation workflows where swift signals are used.
There is no workaround for the issue other than not using swift signals.
The fix is a conditional one-liner that performs a type-check before
running the code change.

[TestCase]

1. Setting up env
1a. Deploy an environment with ceph-rgw and heat
1b. Make sure rgw-swift-versioning-enabled=true

2. Reproducing the bug

2a. Create a stack using the following template:

---
heat_template_version: 2021-04-16

resources:
  signal:
    type: OS::Heat::SwiftSignal
    properties:
      handle: {get_resource: signal_handle}
      timeout: 300

  signal_handle:
    type: OS::Heat::SwiftSignalHandle

  instance_port:
    type: OS::Neutron::Port
    properties:
      network: private
      fixed_ips:
        - subnet_id: private_subnet

  the_server:
    type: OS::Nova::Server
    properties:
      name: test
      image: cirros2
      flavor: m1.cirros
      networks:
        - port: { get_resource: instance_port }
      user_data_format: RAW
      user_data:
        str_replace:
          template: |
            #!/bin/sh

            # Simple success signal
            wc_notify --data-binary '{"status": "SUCCESS"}'
          params:
            wc_notify: { get_attr: [signal_handle, curl_cli] }

2b. Use command "openstack stack create test -t template.yaml

2c. Wait for stack creation to fail using command "openstack stack list"

2d. Once failed, display the details using command "openstack stack show
test"

2e. Confirm error with the message:

| stack_status_reason   | Resource CREATE failed: Error:
resources.signal: Failed to parse JSON data: b'in progress'

3. Cleanup not really needed

4. Install package that contains the fixed code

5. Confirming fix: Repeat steps 2a-2e and confirm stack creation is
either successful or fails with a different message for another reason

[Regression Potential]

Since there is a type-check included in the fix, the regression
potential is minimal, as if the condition is not fulfilled, then the
original code is run.

** Affects: cloud-archive
     Importance: Undecided
         Status: New

** Affects: cloud-archive/yoga
     Importance: Undecided
         Status: New

** Affects: cloud-archive/zed
     Importance: Undecided
         Status: New

** Affects: heat (Ubuntu)
     Importance: Undecided
         Status: New

** Affects: heat (Ubuntu Jammy)
     Importance: Undecided
         Status: New

** Affects: heat (Ubuntu Kinetic)
     Importance: Undecided
         Status: New


** Tags: sts sts-sru-needed

** Description changed:

- Storyboard link
+ Storyboard link: https://storyboard.openstack.org/#!/story/2010485
  
  ============
  SRU TEMPLATE
  ============
  
  [Impact]
  
  The issue impact stack creation workflows where swift signals are used.
  There is no workaround for the issue other than not using swift signals.
  The fix is a conditional one-liner that performs a type-check before
  running the code change.
  
  [TestCase]
  
  1. Setting up env
  1a. Deploy an environment with ceph-rgw and heat
  1b. Make sure rgw-swift-versioning-enabled=true
  
  2. Reproducing the bug
  
  2a. Create a stack using the following template:
  
  ---
  heat_template_version: 2021-04-16
  
  resources:
-   signal:
-     type: OS::Heat::SwiftSignal
-     properties:
-       handle: {get_resource: signal_handle}
-       timeout: 300
+   signal:
+     type: OS::Heat::SwiftSignal
+     properties:
+       handle: {get_resource: signal_handle}
+       timeout: 300
  
-   signal_handle:
-     type: OS::Heat::SwiftSignalHandle
+   signal_handle:
+     type: OS::Heat::SwiftSignalHandle
  
-   instance_port:
-     type: OS::Neutron::Port
-     properties:
-       network: private
-       fixed_ips:
-         - subnet_id: private_subnet
+   instance_port:
+     type: OS::Neutron::Port
+     properties:
+       network: private
+       fixed_ips:
+         - subnet_id: private_subnet
  
-   the_server:
-     type: OS::Nova::Server
-     properties:
-       name: test
-       image: cirros2
-       flavor: m1.cirros
-       networks:
-         - port: { get_resource: instance_port }
-       user_data_format: RAW
-       user_data:
-         str_replace:
-           template: |
-             #!/bin/sh
+   the_server:
+     type: OS::Nova::Server
+     properties:
+       name: test
+       image: cirros2
+       flavor: m1.cirros
+       networks:
+         - port: { get_resource: instance_port }
+       user_data_format: RAW
+       user_data:
+         str_replace:
+           template: |
+             #!/bin/sh
  
-             # Simple success signal
-             wc_notify --data-binary '{"status": "SUCCESS"}'
-           params:
-             wc_notify: { get_attr: [signal_handle, curl_cli] }
+             # Simple success signal
+             wc_notify --data-binary '{"status": "SUCCESS"}'
+           params:
+             wc_notify: { get_attr: [signal_handle, curl_cli] }
  
- 
- 2b. Use command "openstack stack create test -t template.yaml 
+ 2b. Use command "openstack stack create test -t template.yaml
  
  2c. Wait for stack creation to fail using command "openstack stack list"
  
  2d. Once failed, display the details using command "openstack stack show
  test"
  
  2e. Confirm error with the message:
  
  | stack_status_reason   | Resource CREATE failed: Error:
  resources.signal: Failed to parse JSON data: b'in progress'
  
  3. Cleanup not really needed
  
  4. Install package that contains the fixed code
  
  5. Confirming fix: Repeat steps 2a-2e and confirm stack creation is
  either successful or fails with a different message for another reason
  
- 
  [Regression Potential]
  
  Since there is a type-check included in the fix, the regression
  potential is minimal, as if the condition is not fulfilled, then the
  original code is run.

** Tags added: sts sts-sru-needed

** Also affects: heat (Ubuntu Kinetic)
   Importance: Undecided
       Status: New

** Also affects: heat (Ubuntu Jammy)
   Importance: Undecided
       Status: New

** Also affects: cloud-archive
   Importance: Undecided
       Status: New

** Also affects: cloud-archive/yoga
   Importance: Undecided
       Status: New

** Also affects: cloud-archive/zed
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to heat in Ubuntu.
https://bugs.launchpad.net/bugs/2012073

Title:
  [SRU] SwiftSignalHandle fails due to python2-3 decode error

Status in Ubuntu Cloud Archive:
  New
Status in Ubuntu Cloud Archive yoga series:
  New
Status in Ubuntu Cloud Archive zed series:
  New
Status in heat package in Ubuntu:
  New
Status in heat source package in Jammy:
  New
Status in heat source package in Kinetic:
  New

Bug description:
  Storyboard link: https://storyboard.openstack.org/#!/story/2010485

  ============
  SRU TEMPLATE
  ============

  [Impact]

  The issue impact stack creation workflows where swift signals are
  used. There is no workaround for the issue other than not using swift
  signals. The fix is a conditional one-liner that performs a type-check
  before running the code change.

  [TestCase]

  1. Setting up env
  1a. Deploy an environment with ceph-rgw and heat
  1b. Make sure rgw-swift-versioning-enabled=true

  2. Reproducing the bug

  2a. Create a stack using the following template:

  ---
  heat_template_version: 2021-04-16

  resources:
    signal:
      type: OS::Heat::SwiftSignal
      properties:
        handle: {get_resource: signal_handle}
        timeout: 300

    signal_handle:
      type: OS::Heat::SwiftSignalHandle

    instance_port:
      type: OS::Neutron::Port
      properties:
        network: private
        fixed_ips:
          - subnet_id: private_subnet

    the_server:
      type: OS::Nova::Server
      properties:
        name: test
        image: cirros2
        flavor: m1.cirros
        networks:
          - port: { get_resource: instance_port }
        user_data_format: RAW
        user_data:
          str_replace:
            template: |
              #!/bin/sh

              # Simple success signal
              wc_notify --data-binary '{"status": "SUCCESS"}'
            params:
              wc_notify: { get_attr: [signal_handle, curl_cli] }

  2b. Use command "openstack stack create test -t template.yaml

  2c. Wait for stack creation to fail using command "openstack stack
  list"

  2d. Once failed, display the details using command "openstack stack
  show test"

  2e. Confirm error with the message:

  | stack_status_reason   | Resource CREATE failed: Error:
  resources.signal: Failed to parse JSON data: b'in progress'

  3. Cleanup not really needed

  4. Install package that contains the fixed code

  5. Confirming fix: Repeat steps 2a-2e and confirm stack creation is
  either successful or fails with a different message for another reason

  [Regression Potential]

  Since there is a type-check included in the fix, the regression
  potential is minimal, as if the condition is not fulfilled, then the
  original code is run.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/2012073/+subscriptions