Uploaded image for project: 'Red Hat 3scale API Management'
  1. Red Hat 3scale API Management
  2. THREESCALE-4871

Proxy configuration is not saved

XMLWordPrintable

    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Hide

      From the browser dev tools:

      $('.PromoteButton').removeAttr('disabled').removeClass('disabled-button')
      
      Show
      From the browser dev tools: $( '.PromoteButton' ).removeAttr( 'disabled' ).removeClass( 'disabled-button' )
    • Hide

      Unable to reproduce the issue.

      Show
      Unable to reproduce the issue.

      A customer did the upgrade from 2.5 to 2.6 and then from 2.6 to 2.7. After the upgrade the customer explains that when performing a change in the admin portal, the "Promote vX to Staging" button is greyed out. After some tests we have seen that the button behaves correctly according to the values that are stored in the DB, it is the data that is not correctly updated in the database:

      Based on the logic in the promote_to_staging_button_options method and pending_affecting_changes we checked the values of the updated_at fields in the proxy_configs and proxy_config_affecting_changes tables.

      We have asked to perform 2 tests;

      TEST 1: the "Promote v.X to Staging" button was greyed out when the customer did the query to mysql. Steps of the test:
      1) Go to the terminal of system-mysql pod, from the OpenShif UI or rsh the pod.
      2) Login to mysql:

       MYSQL_PWD="$MYSQL_PASSWORD" mysql -h 127.0.0.1 -u $MYSQL_USER -D $MYSQL_DATABASE
      

      2) Then run the following commands:

      SELECT proxy_id, created_at FROM proxy_configs ORDER BY id DESC LIMIT 1;
      SELECT updated_at FROM proxy_config_affecting_changes WHERE proxy_id = xxxx;
      

      3) Resutls:

      mysql> SELECT proxy_id, created_at FROM proxy_configs ORDER BY id DESC LIMIT 1;
      +----------+---------------------+
      | proxy_id | created_at          |
      +----------+---------------------+
      |       11 | 2020-04-02 13:10:40 |
      +----------+---------------------+
      1 row in set (0.01 sec)
      
      mysql> SELECT updated_at FROM proxy_config_affecting_changes WHERE proxy_id =11;
      +---------------------+
      | updated_at          |
      +---------------------+
      | 2020-03-27 14:50:32 |
      +---------------------+
      1 row in set (0.00 sec)
      -------------------------------------
      

      TEST 2: the customer created a new mapping rule: the button was still greyed out. After manually enabling the `Promote vX to Staging` button via the browser's dev console, the customer promoted the changes to Staging. Afterwards the customer did the query to mysql. Steps of the test:

      4) Go to a service of your choice and create a new mapping rule.
      5) Check the status of the "Promote v.X to Staging" button whether is blue or greyed out. If it is blue, click it.
      6) Run again the 2 commands:

      SELECT proxy_id, created_at FROM proxy_configs ORDER BY id DESC LIMIT 1;
      SELECT updated_at FROM proxy_config_affecting_changes WHERE proxy_id = xxxx;
      

      7) Resutls:

      mysql> SELECT proxy_id, created_at FROM proxy_configs ORDER BY id DESC LIMIT 1;
      +----------+---------------------+
      | proxy_id | created_at          |
      +----------+---------------------+
      |       11 | 2020-04-02 15:21:54 |
      +----------+---------------------+
      1 row in set (0.00 sec)
      
      mysql> SELECT updated_at FROM proxy_config_affecting_changes WHERE proxy_id =11;
      +---------------------+
      | updated_at          |
      +---------------------+
      | 2020-03-27 14:50:32 |
      +---------------------+
      1 row in set (0.00 sec)
      

      So it seems that after adding a mapping rule, or even after promoting the change to staging, the updated_at field of the proxy_config_affecting_changes table doesn't change, it's still in 2020-03-27 14:50:32.

      The same issue happens when creating a metric or updating the settings in:

      • /apiconfig/services/xx/metrics
      • /apiconfig/services/XX/settings
        The information is not saved in the database and there is no workaround for that actions.

      Please provide any guidance on how to proceed to fix the issue.

            Unassigned Unassigned
            rhn-support-avilatus Anna Vila Tusell
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: