#6973 Greenwave in stage has no rules
Closed: Fixed 5 years ago Opened 5 years ago by pingou.

  • Describe what you need us to do:
    Greenwave in stg has no rules just like in prod, it's fine in prod but in stg it means we can't test things there.

I'm currently working on a script to waive an entire bodhi update (given an update id, query greenwave, send all the appropriate waivers and check that greenwave is adjusted), but since there are no missing requirements in stg I can't test it there.

Could we have one or two rules for pushing to testing and/or stable in stg greenwave?

  • When do you need this? (YYYY/MM/DD)
    ASAP but not sky-falling urgent

  • If we cannot complete your request, what is the impact?
    Can't really test things in stg.

\cc @ralph @dcallagh


Metadata Update from @kevin:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: factory2

5 years ago

I'm pretty sure that stage and prod already share the same policy right now -- assuming I am reading the Ansible role correctly.

(Actually there is one difference which is that the "remote policy" support is turned on in stage but not prod -- but I guess that is not the issue you are seeing here.)

Indeed the stage policies seem to be complete if I compare:

https://greenwave-web-greenwave.app.os.fedoraproject.org/api/v1.0/policies
https://greenwave-web-greenwave.app.os.stg.fedoraproject.org/api/v1.0/policies

Maybe the problem is actually missing test results in stg Resultsdb or something like that?

Can you give an example of a request you are making against stg Greenwave that does not give the answer you expect?

pretty sure that stage and prod already share the same policy right now

This is what I'm asking to change, could we change the stg instance of greenwave to enforce some test, so we can still test gating in stg.
Currently, greenwave will not enforce anything both in prod and in stg, which means, nothing will be gated. This makes it hard to test gating/waiving in stg :)

@pingou - I'm fine if you want to pick some rules and set them in the playbook/role.

We could use Ansible templating to bring back the exact policies that were removed to staging. The config lives here:

https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/openshift-apps/greenwave/templates/configmap.yml

These are the policies that were removed:

https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/roles/openshift-apps/greenwave/templates/configmap.yml?id=a4bae0fdb982eca04261adc900c00d26008b479a

So we can just bring those back and wrap them in {% if env == "staging" %}'s.

I was looking at this file when I realized that @ralph has already adjusted it: https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=d6ce1dc842a2eab276f90bbcd5d70ae665ff6559

Thanks @ralph !

While at it, could we consider this change as well:

--- a/roles/openshift-apps/greenwave/templates/configmap.yml   
+++ b/roles/openshift-apps/greenwave/templates/configmap.yml   
@@ -19,7 +19,7 @@ data:
     SECRET_KEY = '{{stg_greenwave_secret_key}}'
     WAIVERDB_API_URL = 'https://waiverdb-web-waiverdb.app.os.stg.fedoraproject.org/api/v1.0'
     RESULTSDB_API_URL = 'https://taskotron.stg.fedoraproject.org/resultsdb_api/api/v2.0'
-    CORS_URL = 'https://bodhi.stg.fedoraproject.org'
+    CORS_URL = '*'
 {% else %}
     SECRET_KEY = '{{prod_greenwave_secret_key}}'
     WAIVERDB_API_URL = 'https://waiverdb-web-waiverdb.app.os.fedoraproject.org/api/v1.0'

(Note: the change only applies to stg as well).

It would make testing bodhi/greenwave integration way easier since it would allow to query greenwave from our dev machine.

Thoughts?

Accepting CORS requests from any origin should be fine for Greenwave. It has no authentication and it's stateless so there is really not much that a "malicious" requester could ever do by forging a Greenwave request.

I'm going to apply this to stage and kick a run of the playbook then, thanks @dcallagh :)

I think this is all set now, let's close :)

Thanks everyone!

Metadata Update from @pingou:
- Issue close_status updated to: Fixed

5 years ago

Login to comment on this ticket.

Metadata