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

Enable the deletion of tenants

XMLWordPrintable

    • Icon: Task Task
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • SaaS
    • System
    • None
    • 2
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Engineering
    • 3scale 2020-02-17, 3scale 2020-03-09, 3scale 2020-03-23

      We did THREESCALE-971 and THREESCALE-1836, however, the Tue, 26 Mar 2019 we started destroying old inactive tenants from our DB and it was a big disaster, so as an emergency we disabled the deletion of tenants (only for SaaS).

      After we fix the efficiency of deleting tenants, we can enable this task again. For that we must remove this line.

      Also we should execute deletes in smaller batches, but that is to be decided when the moment arrives (THREESCALE-11768).

      TESTING: this is an internal change with no user facing changes. So I don't think it is feasible to be tested by end-to-end test suite. But I leave it to QE to decide. The basic idea is that now you can remove huge tenants and services without overloading your 3scale cluster but there is no easy reproducer for triggering the issue in the past vs non-triggering. In the past, if you had a big service or a tenant that you wanted to remove and your 3scale instance was under load, then it often happened that there would be an unending cycle of sidekiq jobs being rescheduled until uncontained they may end up crashing sidekiq. Not to say performance degradation during this.

              Unassigned Unassigned
              mnoyabon Marta Noya (Inactive)
              Aleksandar Kostadinov Aleksandar Kostadinov
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: