Bug 1303924

Summary: [RFE] Calamari should emit events when PG state changes.
Product: [Red Hat Storage] Red Hat Ceph Storage Reporter: Darshan <dnarayan>
Component: CalamariAssignee: Christina Meno <gmeno>
Calamari sub component: Back-end QA Contact: ceph-qe-bugs <ceph-qe-bugs>
Status: CLOSED WONTFIX Docs Contact:
Severity: medium    
Priority: unspecified CC: ceph-eng-bugs, dnarayan, flucifre, japplewh, nthomas
Version: 1.3.1   
Target Milestone: rc   
Target Release: 2.3   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-03-28 20:17:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1291304    

Description Darshan 2016-02-02 12:25:15 UTC 
Description of problem:
Calamari should emit events whenever there is a change in PG state, it should give information like old-state, new-state, PG id and other relevant info.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 4 Christina Meno 2016-04-27 19:25:51 UTC 
This is the kind of data I have access to Darshan.
I can send events for pg state changes that effect particular pools, particular OSDs and global state. I am a little concerned that if you just blindly pass through each change the meaning will get lost in too many notifications. What are your thoughts?

{
    "all": {
        "active+clean": 192
    },
    "by_osd": {
        "0": {
            "active+clean": 192
        }
    },
    "by_pool": {
        "0": {
            "active+clean": 64
        },
        "1": {
            "active+clean": 64
        },
        "2": {
            "active+clean": 64
        }
    }
}
Comment 5 Darshan 2016-04-28 07:23:23 UTC 
(In reply to Gregory Meno from comment #4)
> This is the kind of data I have access to Darshan.
> I can send events for pg state changes that effect particular pools,
> particular OSDs and global state. I am a little concerned that if you just
> blindly pass through each change the meaning will get lost in too many
> notifications. What are your thoughts?
> 
> {
>     "all": {
>         "active+clean": 192
>     },
>     "by_osd": {
>         "0": {
>             "active+clean": 192
>         }
>     },
>     "by_pool": {
>         "0": {
>             "active+clean": 64
>         },
>         "1": {
>             "active+clean": 64
>         },
>         "2": {
>             "active+clean": 64
>         }
>     }
> }

I agree with your concern, it doesn't make sense to notify for each state change. I had a discussion with monitoring guys, and they periodically(10min) sync the PG state detail. skyring can rely on this to get the updated PG state information. So, its okay to not have this feature.
Comment 6 Christina Meno 2016-05-02 23:04:41 UTC 
Nishanth, I moved this 2.1 on guidance from Darshan. I wanted to confirm that you saw it and agree with the action.
Comment 7 Christina Meno 2016-05-02 23:07:08 UTC 
same statement as comment 6 to you Jeff
Comment 8 Nishanth Thomas 2016-05-04 15:43:55 UTC 
Ack. I am fine with this and go ahead with this plan if Jeff in agreement
Comment 9 Jeff Applewhite 2016-05-10 21:02:43 UTC 
(In reply to Nishanth Thomas from comment #8)
> Ack. I am fine with this and go ahead with this plan if Jeff in agreement

I am fine with this. PG state change notifications will be too chatty if we don't limit them.
The only question I have is: Gregory/Nishanth are there any exceptions to this rule, i.e. where something is so bad we need to immediately notify a state change?
Comment 10 Christina Meno 2017-03-28 20:17:50 UTC 
No plans to provide this functionality