{"action":"created","issue":{"url":"https://api.github.com/repos/openshift/cluster-version-operator/issues/31","repository_url":"https://api.github.com/repos/openshift/cluster-version-operator","labels_url":"https://api.github.com/repos/openshift/cluster-version-operator/issues/31/labels{/name}","comments_url":"https://api.github.com/repos/openshift/cluster-version-operator/issues/31/comments","events_url":"https://api.github.com/repos/openshift/cluster-version-operator/issues/31/events","html_url":"https://github.com/openshift/cluster-version-operator/pull/31","id":367326505,"node_id":"MDExOlB1bGxSZXF1ZXN0MjIwNzkxNjQx","number":31,"title":"[WIP] make operator status more kube-like","user":{"login":"deads2k","id":8225098,"node_id":"MDQ6VXNlcjgyMjUwOTg=","avatar_url":"https://avatars0.githubusercontent.com/u/8225098?v=4","gravatar_id":"","url":"https://api.github.com/users/deads2k","html_url":"https://github.com/deads2k","followers_url":"https://api.github.com/users/deads2k/followers","following_url":"https://api.github.com/users/deads2k/following{/other_user}","gists_url":"https://api.github.com/users/deads2k/gists{/gist_id}","starred_url":"https://api.github.com/users/deads2k/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/deads2k/subscriptions","organizations_url":"https://api.github.com/users/deads2k/orgs","repos_url":"https://api.github.com/users/deads2k/repos","events_url":"https://api.github.com/users/deads2k/events{/privacy}","received_events_url":"https://api.github.com/users/deads2k/received_events","type":"User","site_admin":false},"labels":[{"id":1005846184,"node_id":"MDU6TGFiZWwxMDA1ODQ2MTg0","url":"https://api.github.com/repos/openshift/cluster-version-operator/labels/do-not-merge/work-in-progress","name":"do-not-merge/work-in-progress","color":"e11d21","default":false},{"id":1005846013,"node_id":"MDU6TGFiZWwxMDA1ODQ2MDEz","url":"https://api.github.com/repos/openshift/cluster-version-operator/labels/size/XL","name":"size/XL","color":"ee5500","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":7,"created_at":"2018-10-05T18:47:26Z","updated_at":"2018-10-09T20:38:09Z","closed_at":null,"author_association":"NONE","pull_request":{"url":"https://api.github.com/repos/openshift/cluster-version-operator/pulls/31","html_url":"https://github.com/openshift/cluster-version-operator/pull/31","diff_url":"https://github.com/openshift/cluster-version-operator/pull/31.diff","patch_url":"https://github.com/openshift/cluster-version-operator/pull/31.patch"},"body":"@crawford @smarterclayton @abhinavdahiya @derekwaynecarr  @openshift/api-review \r\n\r\nLet's figure out the shape of the status reporting API.  This is WIP where we can work out fine details.  The story so far.....\r\n\r\nKube and OpenShift workload and core resources have a dedicate slice of conditions under `.status.conditions` that individually track `True`, `False`, `Unknown` states.  This avoids multiplying states in a state machine and various ecosystem features have built around them like `kubectl wait` and the CRD spec/status permissions split.  Along with the concept of status being a thing that is completely re-derivable from cluster state.\r\n\r\nSince the operatorstatus described here is closely related to the CVO (only consumer), this pull moves the `OperatorStatus` type into `clusterversion.openshift.io`.  Also, the spec/status split for customresources provides a kube-like experience, so I've renamed it to `Operator` with filled in `.status` and an empty `.spec`.  \r\n\r\nOne key question I had is why the `OperatorStatus` is namespace scoped.  It's fairly easy to keep it there, but in looking at the operators we manage by the CVO, it seems that they are largely cluster-scoped, not largely namespace scoped.\r\n\r\n1. kube-apiserver\r\n2. kube-controller-manager\r\n3. kube-scheduler\r\n4. openshift-apiserver\r\n5. openshift-controller-manager\r\n6. dns\r\n7. sdn\r\n8. image registry\r\n9. templates\r\n\r\nGiven that, naming at a cluster scope seems to make more sense since they do not scale with the number of namespaces available."},"comment":{"url":"https://api.github.com/repos/openshift/cluster-version-operator/issues/comments/428342673","html_url":"https://github.com/openshift/cluster-version-operator/pull/31#issuecomment-428342673","issue_url":"https://api.github.com/repos/openshift/cluster-version-operator/issues/31","id":428342673,"node_id":"MDEyOklzc3VlQ29tbWVudDQyODM0MjY3Mw==","user":{"login":"deads2k","id":8225098,"node_id":"MDQ6VXNlcjgyMjUwOTg=","avatar_url":"https://avatars0.githubusercontent.com/u/8225098?v=4","gravatar_id":"","url":"https://api.github.com/users/deads2k","html_url":"https://github.com/deads2k","followers_url":"https://api.github.com/users/deads2k/followers","following_url":"https://api.github.com/users/deads2k/following{/other_user}","gists_url":"https://api.github.com/users/deads2k/gists{/gist_id}","starred_url":"https://api.github.com/users/deads2k/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/deads2k/subscriptions","organizations_url":"https://api.github.com/users/deads2k/orgs","repos_url":"https://api.github.com/users/deads2k/repos","events_url":"https://api.github.com/users/deads2k/events{/privacy}","received_events_url":"https://api.github.com/users/deads2k/received_events","type":"User","site_admin":false},"created_at":"2018-10-09T20:38:09Z","updated_at":"2018-10-09T20:38:09Z","author_association":"NONE","body":"> > Since the operatorstatus described here is closely related to the CVO (only consumer), this pull moves the OperatorStatus type into clusterversion.openshift.io.\r\n> \r\n> The OperatorStatus is designed to be the common API between all of the operators. Right now, CVO is the only one who cares, but in the future, operators almost certainly will have dependencies between one another. I'd like to keep this in a separate API.\r\n\r\nI'm not aware of plans to try to have a secondary status object be a means to express and discover dependency relationships.  It seems like we'd want the dependencies to be directly \"owned\" by producer with consumers being responsible for conforming.\r\n\r\nYou can see an example of using a common status object not working is the relationship between etcd and all apiservers. Etcd takes care of creating and rotating client cert/keys pairs which are secrets.  They must be consumed by the apiserver operators to keep their etcd connections alive.  If you tried to include that here, you would create a confidential resource that you cannot grant read access to.  If you do not include them here, you have to create the alternative to depending on this resource.  I think we have to go with the latter."}}
{"actor":{"display_login":"deads2k"}}