Change:
// It doesn't update, probe or get the pod. type defaultPetHealthChecker struct{} <del> // isHealthy returns true if the pod is running and has the // "pod.alpha.kubernetes.io/initialized" set to "true". </del> <ins> // isHealthy returns true if the pod is ready & running. If the pod has the // "pod.alpha.kubernetes.io/initialized" annotation set to "false", pod state is ignored. </ins> func (d *defaultPetHealthChecker) isHealthy(pod *api.Pod) bool { if pod == nil || pod.Status.Phase != api.PodRunning { return false } <ins> podReady := api.IsPodReady(pod) // User may have specified a pod readiness override through a debug annotation. </ins> initialized, ok := pod.Annotations[StatefulSetInitAnnotation] <del> if !ok { glog.Infof("StatefulSet pod %v in %v, waiting on annotation %v", api.PodRunning, pod.Name, StatefulSetInitAnnotation) return false } b, err := strconv.ParseBool(initialized) if err != nil { return false </del> <ins> if ok { if initAnnotation, err := strconv.ParseBool(initialized); err != nil { glog.Infof("Failed to parse %v annotation on pod %v: %v", StatefulSetInitAnnotation, pod.Name, err) } else if !initAnnotation { glog.Infof("StatefulSet pod %v waiting on annotation %v", pod.Name, StatefulSetInitAnnotation) podReady = initAnnotation } </ins> } <del> return b && api.IsPodReady(pod) </del> <ins> return podReady </ins> } // isDying returns true if the pod has a non-nil deletion timestamp. Since the

Discussion:
PetSets currently support an annotation in their PodTemplateSpec field. From the user documentation: Debugging: If one want to bring up the pets in my petset one after the other, while pausing after each step, confirming that the state is as expected, one may use this functionality. For example, a petset where each pet is a replica of a distributed database; we set the to in the petset template initially. This leads to the following progression: PetSetController creates pet-0 Manually intervene and check that it has initialized as expected. Set annotation to true (equivalent to marking that pet as healthy) PetSetController creates pet-1 Manually intervene and check that it has initialized as expected. ... Blocking the PetSet controller: We may want to ensure that the petset controller is not performing scale operations when a different user-initiated action is in progress (for example, where pets are leaving due to a kubectl drain). This may be used as a mechanism to orphan a pod from a petset controller (for a closer look), while ensuring that a replacement is not created. The use case 1 above can be realized using and is probably easier to do that way rather than use the annotation. I don't see a reason to have that case supported when we can have users scale up a PetSet gradually and manually in an identical manner. It may have been of more importance before v1.4 when the scaler & reaper were not implemented. Due to the second use-case, if it would make sense to continue to have this ability, I propose that we move it from the PodTemplateSpec to the PetSetSpec, where it will eventually reside. This seems to me, like the logical place for such a debug hook to reside. In order to run/pause the scaling operations of the PetSet controller, we could have annotations along the lines of with the annotation defaulting to when absent. /cc
Should we just support Pause on PetSet (for part of these cases)?
Do users have to catch the roll out at the right time in order for this to work? For example if I want to pause between nodes 2 and 3 coming up, do I need to be precise in my timing when editing the resource? How does this look from the users perspective?
Note that Pause allows scaling in Deployments, it just blocks upgrades.

That being said, I think Pause will be useful for PetSets in general. Not sure though if we can use it somehow for this specific issue.
I like the debugging hook for PetSets. If it's optional I don't see any reason to get rid of it.
pauses petset controller if necessary and inspects the state of the system_ With the previous flow, the petset controller was paused after each pet's creation automatically, and here it would be an extra step to pause the controller it if necessary. I don't know how important it is though, but to me it seems easier to understand than a per-pod annotation.
and I had several discussions with the lifecycle of what would be useful. There are a bunch of use cases that overlap: not a primary concern for most users but helpful (prevent changes) - very important if you are triaging failures. Technically scaling is itself a user action, so if you don't want your pet set autoscaled while triaging failures you need to take action on the HPA like deployments. Since PetSets and ReplicaSets are nothing alike w.r.t. scaling I'm not terribly concerned that pause means slightly different things if for end users it Does The Right Thing control by a third party controller - this is the babysitter controller wanting to reuse the petset controller for core stuff but still have the hook angle. Not thought through enough to design around.
Note that Pause does not prevent scaling in Deployments, only upgrades , Clayton Coleman wrote:
Just to summarize: The current behavior with the annotation It is set on a per-pet basis. Setting it to false on any single pod blocks all operations on the petset; scaling, creation of new pets, etc. All pets must contain the annotation, and have its value set to true in order to make progress. By default, it is set to false and makes the petset controller pause after creating one pet. The smallest change we can make for beta: Rename it to (or some better name) Make it optional (with the absence of the annotation meaning that the petset can scale) Surface the reason better when we block on scaling because of the annotation. I still think there is value in moving it to be an annotation on the PetSet resource, rather than having it be in each pod, which is confusing to users. wdyt?
Putting it on the pod template is clever, but surprising.

How many examples are dependent on it? , Anirudh Ramanathan < :
Last I checked, all the examples had set to true. We should just get rid of it from all examples in my opinion. If we make the default (or the absence of any such annotation) to mean that the petset controller can make progress, we can safely do that. was going to do a pass over the examples after the PetSet renaming. This could be an additional step. Does that sound ok?
If it's not found, we assume you want to pause. You're proposing that if it's not found, we default to "forge ahead". SG. It should only be used in debugging/testing today. Basically if you don't know how to write your , you'd create a petset with it set, kubectl exec and write it out, scale the petset by 1, kubectl exec ..., and when you have a working cluster, put what you did in an init container and create the petset without it. This is the absolute min. You're also proposing that we move it to the petset. This makes sense overall, but I initially didn't do that because I didn't know how we would end up doing pause.
We could leave it there as "alpha" and then remove it in 1.6 once we have more time to talk about how upgrades and debugging and pause should work? , Prashanth B wrote:
Yeah the minimum work is to flip the behavior of the controller when the annotation is not found:
Agree on flipping behavior. , Prashanth B wrote:
Flipping SGTM. are you suggesting we leave the annotation-name as it is, and don't change it to ? If we are changing it, we should probably change the name from as well, since it doesn't make as much sense anymore. Probably ?
or healthy rather.
Flipping default behavior (when not present). Or did I misunderstand beeps proposal? On Oct 27, 2016, at 7:11 PM, Anirudh Ramanathan wrote: Flipping SGTM. are you suggesting we leave the annotation-name as it is, and don't change it to ? If we are changing it, we should probably change the name from initialized as well, since it doesn't make as much sense anymore. Probably unhealthy?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .
Renaming it to beta is effectively moving it to beta, so I think given that we're still confused about how this ties in to the big picture, that might be premature. If it's either move to beta or drop, I'd probably vote for drop, it's a debug hook after all. Renaming it to something else but keeping in beta makes sense.
sorry, keeping in alpha
whats going on with this tag? it's used in the docs here should i use it going forward?
It's alpha and may be removed at any time. On Nov 2, 2016, at 3:11 PM, Zachary Adam Kaplan wrote: whats going on with this tag? it's used in the docs here should i use it going forward? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .