Uploaded image for project: 'Red Hat OpenStack Services on OpenShift'
  1. Red Hat OpenStack Services on OpenShift
  2. OSPRH-10833

Tenancy support for RHOSO prometheus metrics

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • None
    • telemetry-operator
    • None
    • Tenancy based metrics
    • 4
    • False
    • Hide

      None

      Show
      None
    • False
    • OBSDA-810Generate Billing Reports for RHOSO Usage
    • Not Selected
    • Proposed
    • Proposed
    • To Do
    • OBSDA-810 - Generate Billing Reports for RHOSO Usage
    • Proposed
    • Proposed
    • 0% To Do, 0% In Progress, 100% Done

      Description still WIP

      Epic Overview

      All RHOSO's resources are split into tenants. With metrics, we have the information about the user and project from which they come. We should have a mechanism, which would allow a user to view only the metrics they're supposed to see (so only their metric, or metrics from the current project). Current behavior is that every user has access to all metrics. This is partially implemented in the python-observabilityclient, but this is there just for conveniency and it can be easily disabled (which is on purpose), so this doesn't add anything to security

      Goals

      All customers. The security of metrics will be increased.

      Requirements

      A list of specific needs or objectives that a Epic must deliver to satisfy the Feature.. Some requirements will be flagged as MVP. If an MVP gets shifted, the epic shifts.  If a non MVP requirement slips, it does not shift the epic.

      requirement Notes is Mvp?
      A user can see only the metrics they should see.   yes
      Dashboards should work. They should show only data related to the chosen user / project   yes
           

      Out of Scope

      < What is not in a scope? >

      Background, and strategic fit

      < What does the person writing code, testing, documenting need to know? >

      Assumptions

      < Are there assumptions being made regarding prerequisites and dependencies?>

      < Are there assumptions about hardware, software or people resources?>

      Customer Considerations

      < Are there specific customer environments that need to be considered (such as working with existing h/w and software)?>

      < Are there upgrade considerations that customers need to account for or that the feature should address on behalf of the customer?>

      Documentation Considerations

      < What educational or reference material (docs) is required to support this epic? For users/admins? Other functions (security officers, etc)? >

      < What does success look like?>

      < Does this epic have doc impact?  Possible values are: New Content, Updates to existing content,  Release Note, or No Doc Impact>

      < If unsure and no Technical Writer is available, please contact Content Strategy. If yes, complete the following.>

      • <What concepts do customers need to understand to be successful in [action]?>
      • <How do we expect customers will use the epic? For what purpose(s)?>
      • <What reference material might a customer want/need to complete [action]?>
      • <Is there source material that can be used as reference for the Technical Writer in writing the content? If yes, please link if available. >
      • <What is the doc impact (New Content, Updates to existing content, or Release Note)?>

      Interoperability Considerations

      < Which other products and versions in our portfolio does this feature impact?>

      < What interoperability test scenarios should be factored by the layered product(s)?>

      Questions

      Question Outcome
       Does observatorium tenancy model fit openstack?  
      Can openstack users be mapped to openshift users?  
      Can we have a reverse-proxy in front of Prometheus, which would add multi-tenancy by authorizing requests with keystone and modifying Prometheus queries accordingly?  

              rh-ee-jwysogla Jaromir Wysoglad
              rh-ee-jwysogla Jaromir Wysoglad
              rhos-dfg-cloudops
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: