Uploaded image for project: 'Cost Management'
  1. Cost Management
  2. COST-3753

Implement a enable tag limit

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Done
    • Icon: Undefined Undefined
    • 2023Q3
    • None
    • Data Pipeline

      With the settings page moving under cost we are enhancing the way we enable tags. We will set an account level limit of 200, this limit should be an environment variable so that it can be easily changed in the future. 

      As we move forward we will adopt a grandfathered in approach, where accounts that are currently over the limit can keep the amount of enable tags that they have. However, they will not be able to add new enabled tags until they remove enough tags to get under our limit. 

      This will be a soft limit, where anytime a customer goes over they will not be able to configure new enabled tags until they get below the threshold. 

      we currently scrap all new keys when we convert the csv file to parquet and bulk insert them into the individual tag tables during file processing. For AWS, Azure, and OCI the enabled field in their models defaults to True. (We can hand wave over the part of the redesign that combined these 5 provider tables to one unified table for now). The issue with keeping the `enable=True` in combination of setting a max enabled limit for each provider is that we would have to start enforcing the limit during the csv to parquet conversion process.  

      we will take a less strict approach here meaning let's say the customer is at 197 enabled tags and we are processing a cloud cost report that has 5 new tags, I'm not oppose to allowing the 5 new tags to be added and the customer would get into the same case as the customers who are currently over the max. Now the next time you are processing a cloud cost report and you are at 202 enable tags you wouldn't automatically enable any new cloud tags, the customer would be forced to remove unused once or consolidate their tagging or prioritize what tags they really need cost breakdowns on.

      Not sure if this is still needed: 
      We should consider updating these tables to include the enabled/disabled flag + the total enabled count per source:

      • reporting_awstags_summary
      • reporting_azuretags_summary
      • reporting_gcptags_summary
      • reporting_ocitags_summary
      • reporting_ocptags_summary

            myersco Cody Myers
            rhn-support-lcouzens Luke Couzens
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: