Please consider changing the name of PetSet before General Availability #27430
25 participants
and others
Thanks for speaking up - we will definitely take this into the discussions in the community before this feature moves out of alpha.
Agree. We went with PetSet as a working name in part because we knew it could never be the "real" name, but we didn't have a good name for the concept yet. Names hold power, so we want to be careful to find something thta captures the problem well. Having a first impl of the solution will help refine the problem statement, too.
@thockin I kinda like it ... and it may be a bit too late. Lots of press about Pet Set already.
Yeah, I may have misunderstood what was meant by changing it before coming out of alpha. To some extent I think the damage is already done now.
Blame me
@thockin we have videos on YouTube, blog posts, tweet, LinkedIn stuff and presentations at conferences, and many many decks with that content. You want to do the rebranding??? It is a big problem to change at this point...
I'm 100% ok with renaming, and don't feel like there's any pain in doing so. However, CarSet does not feel like a fit.
For any who would like name change, please voice here. We'll bring this up at the community meeting next week, and I'd like to settle on a new name by August 1.
Re-quoting myself for emphasis:
Imagine how angry people would be if this feature were called "WifeSet" and the analogy were "wives vs. bar hook-ups."
If the name were something that was seen more universally as unacceptable, I don't think "people already started using the term in social media, oh well, let's keep it" would be an acceptable attitude. The fact that it's already out there doesn't mean there's no value in changing it. If having a reference to something out in the wild meant you couldn't change it in the future, we wouldn't have things like changelogs and semantic versioning.
CarSet does not have any relevance in tech, can we come up with something techy or ship like? I am sorta on the side of not changing it, but we need a good name. If we do change it we gotta change it quite quickly. People will have PetSet in production very quickly if not now. Changing code because a team chooses to change branding probably will not make people happy.
I'm not bound to CarSet (though PetSet doesn't have any "relevance in tech" either)—I was just offering a suggestion that used a similar metaphor, so as not to simply ask the team to do something without offering a possible way to do it. People who have worked on the feature or been involved in its design discussions will probably have better ideas, since they have the best understanding of the use cases for the feature.
Just stumbled on this thread...adding my $0.02.
- Naming IS HARD!!! I've named dozens of products, features and even companies and its never been a quick or simple process.
- Everyone has an opinion. 100% certain there will be someone that does't like a name.
- Getting everyone to agree on a name shouldn't be a requirement
- Very hard to re-name something once it has any kind of name recognition.
As for PetSets in particular, I think it's a pretty good name. Both informative and evocative (IMO in a good way), which are two of the most important aspects of a name.
That said, its really the name of one of several similar kind of features. And within this broader context it lacks the consistency you'd expect across similar things. Don't have any of the history, but I thought Replication Controllers were renamed to Replica Sets to introduce the idea of Sets which could then be applied to different kinds of sets (i.e. PetSets). But as a group, these two names seem random and they miss the opportunity to apply further consistency across Sets (i.e. one name is literal, the other analogous).
Also, will there be other kinds of Sets? If not, then random is probably OK. But if there will be more kinds of Sets, then the next one would also have to be random since you definitely shouldn't have two 'literal' names with another that is 'analogous'. That would just make PetSets seem too casual and not serious.
JetSet seems fitting (and one letter off). Besides relating the term "jet set", a JetSet is composed of Jets, which should be handled with care
The name PetSet is derived from the common metaphor in infrastructure of "pets vs. cattle."
The name petset is derived from the fact that I care about my pets, regardless of what anyone else thinks about their cattle. Cattle are sacred in some places, food in others, and I view that as a culture difference. I won't use pets vs cattle to explain this feature where I'm from, but pets vs servers works just as well :)
That's a fair point. Pets have value whether or not they are compared to something else. But the usage of the term in Kubernetes is not without context: Pets vs cattle is a metaphor very commonly used in writing about modern infrastructure. A quick Google search even brings up usage of the term in Kubernetes's own blog. It seems to sidestep the issue I'm trying to address to suggest that the term has no prior meaning in this area of our industry. There are an infinite number of things this feature could be called. Surely there is something that would work that doesn't use this metaphor.
We can publish options for discussion here. Instead of using metaphors, which can have unintended meaning, let's try a descriptive name. Should ideally be easy to understand for someone with a Linux background. Throwing out some options.
- PersistentSet
- StatefulSet or StateSet
- PermanentSet
- StickySet
- BindSet
- NamedSet
- SavedSet
- StoredSet
- SequentialSet
- OrderedSet
I think that's a good initial set of names (pun intended). I don't think we're too late to change it, as others have pointed out. Yes, there are videos and other materials out there, but it will only get worse with time. If the community agrees that this is a worthwhile thing to do, it should act quickly, otherwise we end up with fuzzy transitions like the one from Replication Controllers to Deployments and Replica Sets.
If we can come up with and agree on API method and parameter names we can certainly converge on object names like these. I find several of the ones proposed by @apsinha to be simple and self-explanatory. I personally think the first two work well: PersistentSet or StatefulSet, as opposed to EphemeralSet.
My $0.02 vote from Aparna's excellent list:
- NamedSet
- PersistentSet
On the crazy idea side:
- Snowflake Set
- Borg Set (like "I am 7 of 9")
I was never fond of PetSet - only for the reason that it is not obvious what it is on its face, and breaks with the obvious naming we have across the product. A "ReplicaSet" is, plainly, a set of replicas. A "Deployment" is ... well ... a deployment. Etc.
The word I'm looking for here is "what is the opposite of a bunch of exact replicas, each of which are unique in some way, but still have some similarity as a group." Maybe I'm coming around to Family/FamilialSet. Or ClusterSet?
Aparna's list is great. My favorite of the bunch is StatefulSet, since the term "stateful application" is used in the container world and should be pretty easily understood. In discussion of container orchestration systems, you'll often hear people ask, "Great, but how does it handle stateful apps?" In a similar way to how the other ThingSets are sets of Things, a StatefulSet is a set of stateful pods/apps. It could even be more explicit: StatefulPodSet.
It's hard to pick a name that doesn't extol any single feature of petset (such as state, persistence, ordering, ordinality, name, sequence). This is one feature we built in reverse, by prototyping a bunch of applications that didn't fit in any existing bucket and formalizing their requirements into an api.
This process is sometimes called domain modelling, and the number of things required by this domain is > 1 word. We faced a similar dilemma choosing its api-group. I think "is a recognizable term for describing the concept at play" might be a trap, and we just need to call it a word that makes people think of the domain.
Aparna's list is awesome!
My $0.02 vote is:
- PersistentSet
- NamedSet
- OrderedSet
We should consider primary use-cases of PetSet to choose name http://kubernetes.io/docs/user-guide/petset/#when-to-use-pet-set
Here are a few more options:
- DistinctSet
- UniqueSet
- SuiSet (stateful uniquely identifiable; also a play on sui generis)
- PetSet, redefined as an abbreviation/backronym of PersistentSet ("Pe't")
PetSet, redefined as an abbreviation/backronym of PersistentSet ("Pe't")
I like this @Lukenickerson
So the features of Pet Set are based on identity and don't have to include Data existence. I can have a stateless Pet Set of an application that required known identity for quorum. I would ask to stay away from names that include references to other components like Persistent Volumes when you don't need a PV for a Pet Set.
But back to @smarterclayton's point, should we focus on if we want to change the name to what the name should be on this issue? @smarterclayton you mentioned that we have a procedure for naming stuff?
From the latest blog post: A relevant analogy is that a Pet Set is composed of Pet dogs. If you have a white, brown or black dog and the brown dog runs away, you can replace it with another brown dog no one would notice. wat.
I think this is a pretty good example of how "pet" isn't the right name for this even technically since a pet has a number of extra implications.
NamedSet or IdentitySet seems to align closest with what's currently provided. They're not a PersistentSet unless you specifically add volumes to them or in other words, a PersistentSet to me is a NamedSet + (n * PersistentVolumeClaim).
Also relevant re: the blog post. This really needs to happen sooner rather than later or it's guaranteed to stick or at least be too complicated to change due to docs/issues/code that already references the current name.
For completeness, names that have been proposed in the past that I don't see above include NominalSet, ShardSet, and IndexedSet.
The distinguishing characteristics we want to convey were specified here:
#27430 (comment)
To expand on the storage point: The controller currently known as PetSet is unique among all the controllers in that it can instantiate and manage PVCs as well as pods, and, though it has other uses, the driving motivation for this controller is improved support for stateful workloads.
Another blog post has appeared which quite heavily uses the pets vs. cattle metaphor and makes it very clear that this is the derivation of the name of PetSet. Is there a way to communicate to the Kubernetes marketing team that a rename is being discussed? This kind of attention on the name PetSet is why I emphasized "before release" in the title of this issue.
Thanks to everyone participating in the discussion to help find a more fitting name.
Sets are unordered. Lists, Arrays and Sequence all imply order and having indexes. So, I don't get why it has to end in set. I don't even think it is good for it to end in set.
Which opens up:
- PodArray
- PodList
- PodSequence
- PetArray
-
uuh, no... wait, that last one doesn't work
😏
-
uuh, no... wait, that last one doesn't work
They aren't replicas, but they aren't totally different either. There is only one template. They all have to have the same PodSpec. So, "distinct" or snowflake overemphasize the differences.
It would be nice to capture that they are similar, and cooperate to fulfill a single purpose (what we would call a service if that name wasn't taken). But they have numbers.
Which leads me to the name "Team". They work together, but they have numbers on the back of their jerseys so that you can tell them apart.
Another thought:
While the dictionary definition of "Replica" is an identical copy. But that is not how we use it in computer systems. MySQL, which is a key motivating use case for PetSet, talks about the master and slave (yes, I know another offensive term), as both being replicas. In fact, zookeeper and cassandra talk about replication and replication factors -- which I understand refers to specific data being replicated rather than instances, but all these apps that we are talking about running with PetSet, there is replication involved.
So, what about:
- ReplicaList
- ReplicaVector
- ReplicaSequence
- ReplicaArray
I sort of like ReplicaArray best because array index is a thing, but list index, vector index, and sequence index are not so much things.
I also like that it suggests some similarity with ReplicaSet.
Also, the PetSet type has a replicas field in it, so, yeah.
Team, Lineup, Ensemble, Cohort or Variants. I agree with @erictune that the name needs to convey some degree of similarity rather than uniqueness.
Can someone change the name of this issue? Release has already occurred ;)
StatefulSet gets my vote.
Or on the radical side:
PetSet ... just keep the darn name.
erictune
changed the title from Please consider changing the name of PetSet before release to Please consider changing the name of PetSet before General Availability 
In my mind, the general use case that stands above the rest is that by contrast to all other pod deployment mechanisms this is the one that allows stateful pods. So my vote is for StateSet - it is after all a set of states (thanks @apsinha for a great list); it sounds the best to me and is grammatically akin to PetSet, ReplicaSet and DaemonSet; but I would side with StatefulSet as a next best option.
Terms that start with "Replica" will be confusing next to ReplicaSet. And names that make the indexing prominent don't describe why you would want to use pods that are indexed. Team is a good suggestion, but "Teamwork" could also describe what ReplicaSets do.
+1 for StatefulSet, @erictune when reading your comment i was already confused by this, thinking it was already changed to ReplicaSet. Please do not pick a name that is too similar as it would be very easy to confuse the two (ReplicationController vs ReplicaSet vs ReplicaSequence ??? Very confusing to a beginner).
+1 to ShardSet. A shard of a distributed database has a stable identity and associated persistent storage. Shards may added/removed from the system, but it is a non-trivial operation that requires careful planning and execution. This is the gist of a PetSet as I understand it.
Also the terms "shard" / "sharding" are already familiar the intended users of this feature, which is IMO an advantage over more abstract names like OrderedSet, ReplicaVector.
I think ShardSet is a little too narrow because sharding is a subset of what PetSets do. PetSets allow the stateful representation of shards. PetSets are also for the stateful management of unsharded data like SQL master/slave replicas or etcd clusters where data is replicated but not sharded. As best as I can tell the commonality is statefulness.
Agreed, but does "StatefulSet" make sense? Are the things in the set stateful, or the set itself? I think most people would assume the latter. ShardSet does not have this ambiguity.
"Replica" has already been established as the identical, interchangeable kind in Kubernetes lingo, so I think using a different word is warranted for the replicas that have distinguishable identity.
I would say - keep PetSet (it's good enough name) and focus on something more important. There are already Masters/Slaves and BlackLists/WhiteLists and we live with it :)
I suspect the naming problem is actually a symptom of a design/hierarchy/abstraction problem from trying to add mid-layer functionality without breaking reverse compatibility of the existing layers.
AFAIK, the distinguishing capability of PetSet is that it persists the IP and volumes of a container through resurrection/rescheduling of the container. This implies there may be a missing abstraction layer between replicator and container.
For example, ignoring existing nomenclature, you could describe Clans as sets of Households that contain People, where the Clan describes a quantity of Households, the Household describes a named set of People, and the People can be either parents or children (expressing a two-level hierarchy of containers like a pod, where the parent namespaces network/disk/volumes for the children to share). The names that the Household uses to describe the People could then be configurable to either survive reincarnation (like PetSets) or not. If reincarnation is enabled, a replacement Person would get the same name/network/volumes as its predecessor. These names are probably not ideal either, but they hopefully they express how ReplicaSet and PetSet could exist in the same object hierarchy.
The goals of an rc and petset are different. an rc is like a batallion of soldiers, they don't really know each other and as some die they're replaced asap. A petset is more like a family, they get names and startup/die in order. Obviously the soldiers can form a familiy, it would just be awkward, and the family can form an army, it would just be ineffective. The difference between an rc with reincarnation set to true and a petset is the latter provides an ordinal index, startup/teardown and a few other features designed to safeguard cluster membership.
The difference between an rc with reincarnation set to true and a petset is the latter provides an ordinal index, startup/teardown and a few other features designed to safeguard cluster membership.
Those could be accounted for with feature flags, rather than being implicit features of the abstraction layer. Ordinal index is similar enough to a persistent name. Startup/teardown is something that would be nice to have on all containers/pods.
I brought this up back when PetSet was just a proposal, but it didn't get much response. At the risk of being labeled or dismissed as an "SJW" or "preachy vegan," or of stirring up drama, please hear me out:
The name PetSet is derived from the common metaphor in infrastructure of "pets vs. cattle." The metaphor encourages infrastructure developers to think of cloud servers as anonymous and fungible resources rather than things to be manually managed by a person. The implication is that instead of treating a server like a pet, which you take care of and treat when it becomes sick, you simply destroy the server and replace it with a new one, as a cattle rancher would simply kill an animal that didn't serve its economic purpose to the rancher. The pet has a personal and emotional value to you, but the cattle is just a commodity.
The lesson in infrastructure here is quite a good one, and its value should be preserved, but using this particular metaphor is quite unfortunate, because it perpetuates the belief that the life and well being of an animal has value only in relation to its value to humans.
This may seem like making a mountain out of a molehill, but try to think about how our language perpetuates our culture and our beliefs. Try to think about it in the context of how future generations will see it. In the same way that homophobic or racist language was (and in some cases still is) commonplace and accepted in days past, in the modern world we generally recognize this language as unacceptable because it promotes a negative world view that we have progressed past. Imagine how angry people would be if this feature were called "WifeSet" and the analogy were "wives vs. bar hook-ups." We're in an era of increasing empathy, and that empathy is not bounded only to other humans. It affects any being that can feel pain, sadness, or loss, like we can.
While I don't claim to have a perfect substitute for this analogy that might replace PetSet, the one I have been using myself is to compare the role of owning a car vs using a taxi or ridesharing service. When you own a car, it is your personal possession. You take care of it. You keep it fueled, cleaned, and maintained in good shape. When it breaks, you get it fixed. In contrast, a taxi or ridesharing service is using a car as a fungible resource. You hail one only when you need the service it provides, and you use it only as long as you require that service. You don't care which car picks you up, or who is driving it, as long as it is fulfills the service. So my own suggestion for a replacement for PetSet is CarSet. If someone has a better idea that seems to "click" with people more, all the better. And of course, the feature could be named something more general—it doesn't have to use an analogy. (I recall that originally "NominalSet" was being considered.)
This issue is not about me or anyone else being "offended," or requesting that the name be changed to CarSet specifically—it's just asking specifically not to invoke the pets vs. cattle metaphor in the name of this feature.
Thank you very much for considering this.
For context, here is my previous comment from back in the proposal phase.