* add dynamic timeouts to plugin worker vacuum gRPC calls All vacuum gRPC calls used context.Background() with no deadline, so the plugin scheduler's execution timeout could kill a job while a large volume compact was still in progress. Use volume-size-scaled timeouts matching the topology vacuum approach: 3 min/GB for compact, 1 min/GB for check, commit, and cleanup. Fixes #8591 * scale scheduler execution timeout by volume size The scheduler's per-job execution timeout (default 240s) would kill vacuum jobs on large volumes before they finish. Three changes: 1. Vacuum detection now includes estimated_runtime_seconds in job proposals, computed as 5 min/GB of volume size. 2. The scheduler checks for estimated_runtime_seconds in job parameters and uses it as the execution timeout when larger than the default — a generic mechanism any handler can use. 3. Vacuum task gRPC calls now use the passed-in ctx as parent instead of context.Background(), so scheduler cancellation propagates to in-flight RPCs. * extend job type runtime when proposals need more time The JobTypeMaxRuntime (default 30 min) wraps both detection and execution. Its context is the parent of all per-job execution contexts, so even with per-job estimated_runtime_seconds, jobCtx would cancel everything when it expires. After detection, scan proposals for the maximum estimated_runtime_seconds. If any proposal needs more time than the remaining JobTypeMaxRuntime, create a new execution context with enough headroom. This lets large vacuum jobs complete without being killed by the job type deadline while still respecting the configured limit for normal-sized jobs. * log missing volume size metric, remove dead minimum runtime guard Add a debug log in vacuumTimeout when t.volumeSize is 0 so operators can investigate why metrics are missing for a volume. Remove the unreachable estimatedRuntimeSeconds < 180 check in buildVacuumProposal — volumeSizeGB always >= 1 (due to +1 floor), so estimatedRuntimeSeconds is always >= 300. * cap estimated runtime and fix status check context - Cap maxEstimatedRuntime and per-job timeout overrides to 8 hours to prevent unbounded timeouts from bad metrics. - Check execCtx.Err() instead of jobCtx.Err() for status reporting, since dispatch runs under execCtx which may have a longer deadline. A successful dispatch under execCtx was misreported as "timeout" when jobCtx had expired.
SeaweedFS Admin Component
A modern web-based administration interface for SeaweedFS clusters built with Go, Gin, Templ, and Bootstrap.
Features
- Dashboard: Real-time cluster status and metrics
- Master Management: Monitor master nodes and leadership status
- Volume Server Management: View volume servers, capacity, and health
- Object Store Bucket Management: Create, delete, and manage Object Store buckets with web interface
- S3 Tables Management: Manage table buckets, namespaces, tables, tags, and policies via the admin UI
- System Health: Overall cluster health monitoring
- Responsive Design: Bootstrap-based UI that works on all devices
- Authentication: Optional user authentication with sessions
- TLS Support: HTTPS support for production deployments
Building
Using the Admin Makefile
The admin component has its own Makefile for development and building:
# Navigate to admin directory
cd weed/admin
# View all available targets
make help
# Generate templates and build
make build
# Development mode with template watching
make dev
# Run the admin server
make run
# Clean build artifacts
make clean
Using the Root Makefile
The root SeaweedFS Makefile automatically integrates the admin component:
# From the root directory
make install # Builds weed with admin component
make full_install # Full build with all tags
make test # Runs tests including admin component
# Admin-specific targets from root
make admin-generate # Generate admin templates
make admin-build # Build admin component
make admin-run # Run admin server
make admin-dev # Development mode
make admin-clean # Clean admin artifacts
Manual Building
If you prefer to build manually:
# Install templ compiler
go install github.com/a-h/templ/cmd/templ@latest
# Generate templates
templ generate
# Build the main weed binary
cd ../../../
go build -o weed ./weed
Development
Template Development
The admin interface uses Templ for type-safe HTML templates:
# Watch for template changes and auto-regenerate
make watch
# Or manually generate templates
make generate
# Format templates
make fmt
File Structure
weed/admin/
├── Makefile # Admin-specific build tasks
├── README.md # This file
├── admin.go # Main application entry point
├── dash/ # Server and handler logic
│ ├── admin_server.go # HTTP server setup
│ ├── handler_admin.go # Admin dashboard handlers
│ ├── handler_auth.go # Authentication handlers
│ └── middleware.go # HTTP middleware
├── static/ # Static assets
│ ├── css/admin.css # Admin-specific styles
│ └── js/admin.js # Admin-specific JavaScript
└── view/ # Templates
├── app/ # Application templates
│ ├── admin.templ # Main dashboard template
│ ├── s3_buckets.templ # Object Store bucket management template
│ ├── s3tables_*.templ # S3 Tables management templates
│ └── *_templ.go # Generated Go code
└── layout/ # Layout templates
├── layout.templ # Base layout template
└── layout_templ.go # Generated Go code
Object Store Management
The admin interface includes Object Store and S3 Tables management capabilities:
- Create/delete Object Store buckets and adjust quotas or ownership.
- Manage S3 Tables buckets, namespaces, and tables.
- Update S3 Tables policies and tags via the UI and API endpoints.
Usage
Basic Usage
# Start admin interface on default port (23646)
weed admin
# Start with custom configuration
weed admin -port=8080 -masters="master1:9333,master2:9333"
# Start with authentication
weed admin -adminUser=admin -adminPassword=secret123
# Start with HTTPS
weed admin -port=443 -tlsCert=/path/to/cert.pem -tlsKey=/path/to/key.pem
Configuration Options
| Option | Default | Description |
|---|---|---|
-port |
23646 | Admin server port |
-masters |
localhost:9333 | Comma-separated master servers |
-adminUser |
admin | Admin username (if auth enabled) |
-adminPassword |
"" | Admin password (empty = no auth) |
-tlsCert |
"" | Path to TLS certificate |
-tlsKey |
"" | Path to TLS private key |
Docker Usage
# Build Docker image with admin component
make docker-build
# Run with Docker
docker run -p 23646:23646 seaweedfs/seaweedfs:latest admin -masters=host.docker.internal:9333
Development Workflow
Quick Start
# Clone and setup
git clone <seaweedfs-repo>
cd seaweedfs/weed/admin
# Install dependencies and build
make install-deps
make build
# Start development server
make dev
Making Changes
-
Template Changes: Edit
.templfiles inview/- Templates auto-regenerate in development mode
- Use
make generateto manually regenerate
-
Go Code Changes: Edit
.gofiles- Restart the server to see changes
- Use
make buildto rebuild
-
Static Assets: Edit files in
static/- Changes are served immediately
Testing
# Run admin component tests
make test
# Run from root directory
make admin-test
# Lint code
make lint
# Format code
make fmt
Production Deployment
Security Considerations
- Authentication: Always set
adminPasswordin production - HTTPS: Use TLS certificates for encrypted connections
- Firewall: Restrict admin interface access to authorized networks
Example Production Setup
# Production deployment with security
weed admin \
-port=443 \
-masters="master1:9333,master2:9333,master3:9333" \
-adminUser=admin \
-adminPassword=your-secure-password \
-tlsCert=/etc/ssl/certs/admin.crt \
-tlsKey=/etc/ssl/private/admin.key
Monitoring
The admin interface provides endpoints for monitoring:
GET /health- Health check endpointGET /metrics- Prometheus metrics (if enabled)GET /api/status- JSON status information
Troubleshooting
Common Issues
- Templates not found: Run
make generateto create template files - Build errors: Ensure
templis installed withmake install-templ - Static files not loading: Check that
static/directory exists and has proper files - Connection errors: Verify master and filer addresses are correct
Debug Mode
# Enable debug logging
weed -v=2 admin
# Check generated templates
ls -la view/app/*_templ.go view/layout/*_templ.go
Contributing
- Fork the repository
- Create a feature branch
- Make your changes
- Run tests:
make test - Format code:
make fmt - Submit a pull request
Architecture
The admin component follows a clean architecture:
- Presentation Layer: Templ templates + Bootstrap CSS
- HTTP Layer: Gin router with middleware
- Business Logic: Handler functions in
dash/package - Data Layer: Communicates with SeaweedFS masters and filers
This separation makes the code maintainable and testable.