Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

FaultDomain, conventions for additional hierarchy. #294

Merged
merged 1 commit into from
Feb 16, 2019
Merged

FaultDomain, conventions for additional hierarchy. #294

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
12 changes: 12 additions & 0 deletions include/mesos/mesos.proto
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -827,6 +827,18 @@ message ExecutorInfo {
* in the same zone, in different zones in the same region, or in
* different regions. Note that all masters in a given Mesos cluster
* must be in the same region.
*
* Complex deployments may have additional levels of hierarchy: for example,
* multiple racks might be grouped together into "halls" and multiple DCs in
* the same geographical vicinity might be grouped together. As a convention,
* the recommended way to represent additional levels of hierarchy is via dot-
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need to recommend "dot" right? It could be any delimiter that they choose to have? As far as Mesos is concerned, it doesn't matter.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realize that Mesos doesn't care. The goal of having a convention was to promote compatibility across frameworks and clusters that can handle additional levels of hierarchy. Consistency suffers w/o convention. This was the justification for adding the same commentary to the design doc, and it's just as relevant (and much easier to find) here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vinodkone did you have any other thoughts on this matter?

* separated labels in the existing zone and region fields. For example, the
* fact that racks "abc" and "def" are in the same hall might be represented
* using the zone names "rack-abc.hall-1" and "rack-def.hall-1", for example.
* Software that is not aware of this additional structure will compare the
* zone names for equality- hence, the two zones will be treated as different
* (unrelated) zones. Software that is "hall-aware" can inspect the zone names
* and make use of the additional hierarchy.
*/
message DomainInfo {
message FaultDomain {
Expand Down
12 changes: 12 additions & 0 deletions include/mesos/v1/mesos.proto
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -825,6 +825,18 @@ message ExecutorInfo {
* in the same zone, in different zones in the same region, or in
* different regions. Note that all masters in a given Mesos cluster
* must be in the same region.
*
* Complex deployments may have additional levels of hierarchy: for example,
* multiple racks might be grouped together into "halls" and multiple DCs in
* the same geographical vicinity might be grouped together. As a convention,
* the recommended way to represent additional levels of hierarchy is via dot-
* separated labels in the existing zone and region fields. For example, the
* fact that racks "abc" and "def" are in the same hall might be represented
* using the zone names "rack-abc.hall-1" and "rack-def.hall-1", for example.
* Software that is not aware of this additional structure will compare the
* zone names for equality- hence, the two zones will be treated as different
* (unrelated) zones. Software that is "hall-aware" can inspect the zone names
* and make use of the additional hierarchy.
*/
message DomainInfo {
message FaultDomain {
Expand Down