tahoe-lafs/trac-2024-07-25
2
0
Issues 1.1k Wiki

Create a specification for the servers of happiness behavior #911

New Issue
Closed
opened 2010-01-17 05:20:35 +00:00 by kevan · 11 comments
kevan commented 2010-01-17 05:20:35 +00:00
Owner
Copy Link

The discussion in #778 is a bit jumbled to be a canonical specification for the servers of happiness behavior. It would be nice to distill that discussion into a coherent specification, and then to put that specification at docs/specifications/servers-of-happiness.txt.

The discussion in #778 is a bit jumbled to be a canonical specification for the servers of happiness behavior. It would be nice to distill that discussion into a coherent specification, and then to put that specification at docs/specifications/servers-of-happiness.txt.
tahoe-lafs added the
documentation
major
task
1.5.0
 labels 2010-01-17 05:20:35 +00:00
tahoe-lafs added this to the undecided milestone 2010-01-17 05:20:35 +00:00
tahoe-lafs modified the milestone from undecided to 1.7.0 2010-02-01 19:56:23 +00:00
zooko commented 2010-05-08 19:19:14 +00:00
Copy Link

Kevan: your docs in your docs patch on #778 look sufficient to me. Shall we close this ticket as a dup of #778? If you agree then please go ahead and mark it as dup and close it.

Kevan: your docs in your docs patch on #778 look sufficient to me. Shall we close this ticket as a dup of #778? If you agree then please go ahead and mark it as dup and close it.
zooko commented 2010-05-08 19:20:04 +00:00
Copy Link

Oh, perhaps you mean to add doc of how Tahoe-LAFS calculates the servers-of-happiness for a given server-share mapping, or how it decides which servers to use or not use on upload. That is not currently done in your docs.txt over on #778.

Oh, perhaps you mean to add doc of *how* Tahoe-LAFS calculates the servers-of-happiness for a given server-share mapping, or how it decides which servers to use or not use on upload. That is *not* currently done in your docs.txt over on #778.
kevan commented 2010-05-08 19:44:36 +00:00
Author
Owner
Copy Link

Your second comment is correct -- the specification would cover what is in the docs for #778, as well as the reduction of the happiness behavior to a matching in a bipartite graph.

Your second comment is correct -- the specification would cover what is in the docs for #778, as well as the reduction of the happiness behavior to a matching in a bipartite graph.
zooko commented 2010-05-16 00:32:42 +00:00
Copy Link

Kevan: we've now added a bit more doc about servers-of-happiness in [architecture.txt]source:docs/architecture.txt@4309#L140, but I guess you want to actually write a complete specification of the matching algorithm and so on. Perhaps you should just add it as another paragraph in the "Server Select" part of architecture.txt? Anyway, it may be worth doing for 1.7.0 final.

Kevan: we've now added a bit more doc about servers-of-happiness in [architecture.txt]source:docs/architecture.txt@4309#L140, but I guess you want to actually write a complete specification of the matching algorithm and so on. Perhaps you should just add it as another paragraph in the "Server Select" part of architecture.txt? Anyway, it may be worth doing for 1.7.0 final.
kevan commented 2010-05-16 01:44:08 +00:00
Author
Owner
Copy Link

I'm planning on having whichever approach we want to go with done by 1.7.0 final.

I'm planning on having whichever approach we want to go with done by 1.7.0 final.
kevan commented 2010-05-19 00:59:03 +00:00
Author
Owner
Copy Link

I made docs/specifications/servers-of-happiness.txt -- I wanted to summarize a bit more of the discussion on #778 than I thought would fit well in the architecture document. I'm attaching a patch with that. However, the actual matching specification would very easily fit in architecture.txt. What do you think? Is the separate file overkill?

I made docs/specifications/servers-of-happiness.txt -- I wanted to summarize a bit more of the discussion on #778 than I thought would fit well in the architecture document. I'm attaching a patch with that. However, the actual matching specification would very easily fit in architecture.txt. What do you think? Is the separate file overkill?
kevan commented 2010-05-19 00:59:20 +00:00
Author
Owner
Copy Link

Attachment 911.darcspatch.txt (19061 bytes) added

**Attachment** 911.darcspatch.txt (19061 bytes) added
911.darcspatch.txt
19 KiB
kevan commented 2010-05-24 00:46:18 +00:00
Author
Owner
Copy Link

Attachment 911specv2.dpatch (19196 bytes) added

revised specification that mentions that servers of happiness only applies to immutable files for now

**Attachment** 911specv2.dpatch (19196 bytes) added revised specification that mentions that servers of happiness only applies to immutable files for now
911specv2.dpatch
19 KiB
zooko commented 2010-06-16 18:58:16 +00:00
Copy Link

Applied in changeset:7cadb49b88c03209. Thanks!

Applied in changeset:7cadb49b88c03209. Thanks!
zooko added the
fixed
 label 2010-06-16 18:58:16 +00:00
zooko closed this issue 2010-06-16 18:58:16 +00:00
tahoe-lafs removed the
fixed
 label 2010-06-19 00:49:46 +00:00
davidsarah reopened this issue 2010-06-19 00:49:46 +00:00
davidsarah commented 2010-06-19 00:52:37 +00:00
Author
Owner
Copy Link

Attachment servers-of-happiness-doc.dpatch (56519 bytes) added

configuration.txt and servers-of-happiness.txt: 1 <= happy <= N, not k <= happy <= N. Also minor wording changes.

**Attachment** servers-of-happiness-doc.dpatch (56519 bytes) added configuration.txt and servers-of-happiness.txt: 1 <= happy <= N, not k <= happy <= N. Also minor wording changes.
servers-of-happiness-doc.dpatch
55 KiB
davidsarah commented 2010-06-19 03:04:39 +00:00
Author
Owner
Copy Link

servers-of-happiness-doc.dpatch applied in changeset:a92a23fe343862f2.

servers-of-happiness-doc.dpatch applied in changeset:a92a23fe343862f2.
tahoe-lafs added the
fixed
 label 2010-06-19 03:04:39 +00:00
davidsarah closed this issue 2010-06-19 03:04:39 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
0.2.0

   
0.3.0

   
0.4.0

   
0.5.0

   
0.5.1

   
0.6.0

   
0.6.1

   
0.7.0

   
0.8.0

   
0.9.0

   
1.0.0

   
1.1.0

   
1.10.0

   
1.10.1

   
1.10.2

   
1.10a2

   
1.11.0

   
1.12.0

   
1.12.1

   
1.13.0

   
1.14.0

   
1.15.0

   
1.15.1

   
1.2.0

   
1.3.0

   
1.4.1

   
1.5.0

   
1.6.0

   
1.6.1

   
1.7.0

   
1.7.1

   
1.7β

   
1.8.0

   
1.8.1

   
1.8.2

   
1.8.3

   
1.8β

   
1.9.0

   
1.9.0-s3branch

   
1.9.0a1

   
1.9.0a2

   
1.9.0b1

   
1.9.1

   
1.9.2

   
1.9.2a1

   
LeastAuthority.com automation

   
blocker

   
cannot reproduce

   
cloud-branch

   
code

catch-all for anything that can be fixed by writing code but isn't classified better

  
code-dirnodes

anything involving tahoe directories

  
code-encoding

immutable-file encoding format/layout, cap format, encoding/decoding algorithms

  
code-frontend

general frontend things: new user-facing interfaces, FTP/SFTP servers, FUSE-like interfaces

  
code-frontend-cli

CLI tools

  
code-frontend-ftp-sftp

   
code-frontend-magic-folder

   
code-frontend-web

webapi interfaces, user-facing "WUI" interfaces

  
code-mutable

anything involving mutable files: encoding/decoding, share format

  
code-network

Introducer, locating storage servers, establishing/maintaining connections to them

  
code-nodeadmin

node startup/shutdown, tools to create nodes, logging tools, management/monitoring tools, manhole, disk-space-limiting tools

  
code-peerselection

server selection/sorting algorithm, rebalancing code, allocation policy, swarming-download

  
code-storage

storage-server implementation, share-storage directory layout, client-to-server share transfer protocol

  
contrib

problems with non-core things that live in the source:contrib/ directory

  
critical

   
defect

   
dev-infrastructure

things that help us build Tahoe: buildbot, automated speed/memory/code-coverage tests and results-displayers, IRC channels, mailing lists, this Trac instance

  
documentation

docs items. Also use 'docs' keyword on tickets in more specific components.

  
duplicate

   
enhancement

   
fixed

   
invalid

   
major

   
minor

   
n/a

   
normal

   
operational

things involved in running a tahoe grid, external tools to monitor/maintain a grid (like "nodeadmin" but larger-scale). Was also used for issues with the allmydata.com grid.

  
packaging

setup.py script, library dependencies, binary packages, licensing, installation instructions

  
somebody else's problem

   
supercritical

   
task

   
trivial

   
unknown

Uncategorized. All tickets default to this component until someone updates it.

  
was already fixed

   
website

things about the tahoe-lafs.org website (and sometimes this Trac instance, shared with 'dev-infrastructure')

  
wontfix

   
worksforme
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
Milestone
Clear milestone
No items
No Milestone
1.7.0
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: tahoe-lafs/trac-2024-07-25#911
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?