{"action":"created","issue":{"url":"https://api.github.com/repos/kubernetes/kubernetes/issues/25283","repository_url":"https://api.github.com/repos/kubernetes/kubernetes","labels_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/25283/labels{/name}","comments_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/25283/comments","events_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/25283/events","html_url":"https://github.com/kubernetes/kubernetes/issues/25283","id":153541750,"number":25283,"title":"Consider a kind of Service that ignores readiness","user":{"login":"bprashanth","id":10927820,"avatar_url":"https://avatars.githubusercontent.com/u/10927820?v=3","gravatar_id":"","url":"https://api.github.com/users/bprashanth","html_url":"https://github.com/bprashanth","followers_url":"https://api.github.com/users/bprashanth/followers","following_url":"https://api.github.com/users/bprashanth/following{/other_user}","gists_url":"https://api.github.com/users/bprashanth/gists{/gist_id}","starred_url":"https://api.github.com/users/bprashanth/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bprashanth/subscriptions","organizations_url":"https://api.github.com/users/bprashanth/orgs","repos_url":"https://api.github.com/users/bprashanth/repos","events_url":"https://api.github.com/users/bprashanth/events{/privacy}","received_events_url":"https://api.github.com/users/bprashanth/received_events","type":"User","site_admin":false},"labels":[{"id":173493827,"url":"https://api.github.com/repos/kubernetes/kubernetes/labels/team/cluster","name":"team/cluster","color":"d2b48c","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":13,"created_at":"2016-05-06T21:27:58Z","updated_at":"2016-12-01T02:43:32Z","closed_at":null,"body":"This is mostly motivated by petset. Currently we create a governing service that is responsible for the network identity of each pet. The requirements of this governing service differ from a normal service in the following ways:\n1. Pets have internal protocols to notice peer health, and a list of different checks (eg: http://www.cloudera.com/documentation/enterprise/5-4-x/topics/cm_ht_zookeeper_server.html). In kube, peers use DNS to communicate. So we don't want a readiness check failure to remove the pet from DNS and abruptly cut it off from the set. \n2. The \"governing service\" is headless so kube-proxy doesn't need to NAT the service ip.\n3. Clients will not be using this Service, so it doesn't matter that unready pets show up in DNS under the svcName sub domain.\n\nIn addition to these, there's one important reason some pets need to have DNS before readiness. To provide the guarantees required to safely bootstrap a pet, we need:    \n1. Pet0 starts before pet1..\n2. Don't start pet1 till pet0 is running/ready\n3. When pet1 starts, it sees pet0 in DNS\n\nThe easiest way to guarantee 3 today is to do one of:    \n- poll in the entrypoint of pet0, till it sees itself\n- poll in the init container of pet0, till it sees itself \n- poll in the init containers of pet {1..N-1} till it sees all previous pets\n\nThird option is not a great idea because we don't know who else is supposed to exist, and for the first 2 to work with a readiness probe, we need a DNS record before the Service is ready. \n"},"comment":{"url":"https://api.github.com/repos/kubernetes/kubernetes/issues/comments/264063434","html_url":"https://github.com/kubernetes/kubernetes/issues/25283#issuecomment-264063434","issue_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/25283","id":264063434,"user":{"login":"smarterclayton","id":1163175,"avatar_url":"https://avatars.githubusercontent.com/u/1163175?v=3","gravatar_id":"","url":"https://api.github.com/users/smarterclayton","html_url":"https://github.com/smarterclayton","followers_url":"https://api.github.com/users/smarterclayton/followers","following_url":"https://api.github.com/users/smarterclayton/following{/other_user}","gists_url":"https://api.github.com/users/smarterclayton/gists{/gist_id}","starred_url":"https://api.github.com/users/smarterclayton/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/smarterclayton/subscriptions","organizations_url":"https://api.github.com/users/smarterclayton/orgs","repos_url":"https://api.github.com/users/smarterclayton/repos","events_url":"https://api.github.com/users/smarterclayton/events{/privacy}","received_events_url":"https://api.github.com/users/smarterclayton/received_events","type":"User","site_admin":false},"created_at":"2016-12-01T02:43:32Z","updated_at":"2016-12-01T02:43:32Z","body":"JBoss EAP uses it to form initial quorum for jgroups, which isn't a strong\nconsensus system.  So they use deployments and a minimum set to form an\ninitial quorum and deal with split brain like jgroups normally does\n(infinispan has multiple consistent modes, some of which might prefer loose\npools).  Arguably smaller sets and some infinispan quorums might prefer\nstatefulsets, but those use cases are also more tolerant of partitions in\ngeneral.\n\nOn Wed, Nov 30, 2016 at 9:23 PM, Prashanth B <notifications@github.com>\nwrote:\n\n> We have people who want unready endpoints for deployments to form gossip\n> pools\n>\n> That's exactly the kind of use case I was looking for, something that\n> doesn't require pet names. I get the feeling there will be other apps but I\n> couldn't produce an example.\n>\n> —\n> You are receiving this because you commented.\n> Reply to this email directly, view it on GitHub\n> <https://github.com/kubernetes/kubernetes/issues/25283#issuecomment-264060670>,\n> or mute the thread\n> <https://github.com/notifications/unsubscribe-auth/ABG_p87dwBZ8Wc1HxWQJVodG2t8vgxnKks5rDi-9gaJpZM4IZOsq>\n> .\n>\n"}}
{"actor":{"display_login":"smarterclayton"}}