bucket-models

The per-bucket configuration models. Each bucket carries multiple XML documents (lifecycle, replication, encryption, versioning, object lock, tagging) and each lives in its own subpackage under internal/bucket/.

Layout

internal/bucket/
├── bandwidth/                 # Per-bucket bandwidth tracking
├── encryption/                # PutBucketEncryption XML model
├── lifecycle/                 # PutBucketLifecycleConfiguration model + evaluator
├── object/
│   └── lock/                  # Object Lock retention model
├── replication/               # PutBucketReplication model
└── versioning/                # PutBucketVersioning model

What each one provides

Package	Highlights
internal/bucket/lifecycle	Lifecycle.Eval(...) — given an object, returns the right action (Expire / Transition / NoOp) per rule. Parses prefix/tag filters, age + date predicates, transition targets.
internal/bucket/replication	XML model + role/destination resolution. Compiled rules used by cmd/bucket-replication.go.
internal/bucket/encryption	Default-encryption XML and validation.
internal/bucket/versioning	The BucketVersioningConfig model — Enabled / Suspended states, plus excludedPrefixes for partial versioning.
internal/bucket/object/lock	Object Lock retention modes (Compliance, Governance), legal holds, defaults.
internal/bucket/bandwidth	Token-bucket per replication target so a runaway target can't starve everything else.

Why they live here

These packages are pure XML/data models with no dependency on cmd/. Keeping them in internal/ lets:

• The runtime in cmd/bucket-*.go import them.
• Site replication import them when transferring config across sites.
• Tests exercise them in isolation.

Integration points

• cmd/bucket-handlers.go, cmd/bucket-policy-handlers.go, cmd/bucket-lifecycle-handlers.go, cmd/bucket-replication-handlers.go, etc. each call into one of these packages.
• cmd/data-scanner.go is the largest consumer of internal/bucket/lifecycle.
• cmd/site-replication.go shuttles every model across sites.

Entry points for modification

• New rule type. Pick the right subpackage; extend the XML schema (mind backwards compat) and the evaluator. Add a unit test in the package.
• New per-bucket config. Create a new subpackage under internal/bucket/<name>/, parallel to the existing ones.

See Lifecycle and tiering and Replication for the runtime that drives these models.