From 04620af37ee7a0ea9e141dfa70846f8e7be8e5c4 Mon Sep 17 00:00:00 2001 From: Jared Vititoe Date: Sat, 3 Oct 2026 00:16:58 -0400 Subject: [PATCH] Add MIT license; stop tracking local AI notes; use public Gitea URLs --- .gitignore | 6 +- Claude.md | 209 -------------------------------------------------- LICENSE | 21 +++++ README.md | 5 +- driveAtlas.sh | 2 +- 5 files changed, 29 insertions(+), 214 deletions(-) delete mode 100644 Claude.md create mode 100644 LICENSE diff --git a/.gitignore b/.gitignore index 072c47b..aea3a1e 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,5 @@ -todo.txt \ No newline at end of file +todo.txt +# AI assistant notes (kept locally, not published) +Claude.md +CLAUDE.md +.claude/ diff --git a/Claude.md b/Claude.md deleted file mode 100644 index d36dcfe..0000000 --- a/Claude.md +++ /dev/null @@ -1,209 +0,0 @@ -# AI-Assisted Development Notes - -This document chronicles the development of Drive Atlas with assistance from Claude (Anthropic's AI assistant). - -## Project Overview - -Drive Atlas started as a simple bash script with hardcoded drive mappings and evolved into a comprehensive storage infrastructure management tool through iterative development and user feedback. - -## Development Session - -**Date:** January 6, 2026 -**AI Model:** Claude Sonnet 4.5 -**Developer:** LotusGuild -**Session Duration:** ~2 hours - -## Initial State - -The project began with: -- Basic ASCII art layouts for different server chassis -- Hardcoded drive mappings for "medium2" server -- Simple SMART data display -- Broken PCI path mappings (referenced non-existent hardware) -- Windows line endings causing script execution failures - -## Evolution Through Collaboration - -### Phase 1: Architecture Refactoring -**Problem:** Chassis layouts were tied to hostnames, making it hard to reuse templates. - -**Solution:** -- Separated chassis types from server hostnames -- Created reusable layout generator functions -- Introduced `CHASSIS_TYPES` and `SERVER_MAPPINGS` arrays -- Renamed "medium2" → "compute-storage-01" for clarity - -### Phase 2: Hardware Discovery -**Problem:** Script referenced PCI controller `0c:00.0` which didn't exist. - -**Approach:** -1. Created diagnostic script to probe actual hardware -2. Discovered real configuration: - - LSI SAS3008 HBA at `01:00.0` (bays 5-10) - - AMD SATA controller at `0d:00.0` (bays 1-4) - - NVMe at `0e:00.0` (M.2 slot) -3. User provided physical bay labels and visible serial numbers -4. Iteratively refined PCI PHY to bay mappings - -**Key Insight:** User confirmed bay 1 contained the SSD boot drive, which helped establish the correct mapping starting point. - -### Phase 3: Physical Verification -**Problem:** Needed to verify drive-to-bay mappings without powering down production server. - -**Solution:** -1. Added serial number display to script output -2. User physically inspected visible serial numbers on drive bays -3. Cross-referenced SMART serials with visible labels -4. Corrected HBA PHY mappings: - - Bay 5: phy6 (not phy2) - - Bay 6: phy7 (not phy3) - - Bay 7: phy5 (not phy4) - - Bay 8: phy2 (not phy5) - - Bay 9: phy4 (not phy6) - - Bay 10: phy3 (not phy7) - -### Phase 4: User Experience Improvements - -**ASCII Art Rendering:** -- Initial version had variable-width boxes that broke alignment -- Fixed by using consistent 10-character wide bay boxes -- Multiple iterations to perfect right border alignment - -**Drive Table Enhancements:** -- Original: Alphabetical by device name -- Improved: Sorted by physical bay position (1-10) -- Added BAY column to show physical location -- Wider columns to prevent text wrapping - -### Phase 5: Ceph Integration -**User Request:** "Can we show ceph in/up out/down status in the table?" - -**Implementation:** -1. Added CEPH OSD column using `ceph-volume lvm list` -2. Added STATUS column parsing `ceph osd tree` -3. Initial bug: Parsed wrong columns (5 & 6 instead of correct ones) -4. Fixed by understanding `ceph osd tree` format: - - Column 5: STATUS (up/down) - - Column 6: REWEIGHT (1.0 = in, 0 = out) - -**User Request:** "Show which is the boot drive somehow?" - -**Solution:** -- Added USAGE column -- Checks mount points -- Shows "BOOT" for root filesystem -- Shows mount point for other mounts -- Shows "-" for Ceph OSDs (using LVM) - -## Technical Challenges Solved - -### 1. Line Ending Issues -- **Problem:** `diagnose-drives.sh` had CRLF endings → script failures -- **Solution:** `sed -i 's/\r$//'` to convert to LF - -### 2. PCI Path Pattern Matching -- **Problem:** Bash regex escaping for grep patterns -- **Solution:** `grep -E "^\s*${osd_num}\s+"` for reliable matching - -### 3. Floating Point Comparison in Bash -- **Problem:** Bash doesn't natively support decimal comparisons -- **Solution:** Used `bc -l` with error handling: `$(echo "$reweight > 0" | bc -l 2>/dev/null || echo 0)` - -### 4. Associative Array Sorting -- **Problem:** Bash associative arrays don't maintain insertion order -- **Solution:** Extract keys, filter numeric ones, pipe to `sort -n` - -## Key Learning Moments - -1. **Hardware Reality vs. Assumptions:** The original script assumed controller addresses that didn't exist. Always probe actual hardware. - -2. **Physical Verification is Essential:** Serial numbers visible on drive trays were crucial for verifying correct mappings. - -3. **Iterative Refinement:** The script went through 15+ commits, each improving a specific aspect based on user testing and feedback. - -4. **User-Driven Feature Evolution:** Features like Ceph integration and boot drive detection emerged organically from user needs. - -## Commits Timeline - -1. Initial refactoring and architecture improvements -2. Fixed PCI path mappings based on discovered hardware -3. Added serial numbers for physical verification -4. Fixed ASCII art rendering issues -5. Corrected bay mappings based on user verification -6. Added bay-sorted output -7. Implemented Ceph OSD tracking -8. Added Ceph up/in status -9. Added boot drive detection -10. Fixed Ceph status parsing -11. Documentation updates - -## Collaborative Techniques Used - -### Information Gathering -- Asked clarifying questions about hardware configuration -- Requested diagnostic command output -- Had user physically verify drive locations - -### Iterative Development -- Made small, testable changes -- User tested after each significant change -- Incorporated feedback immediately - -### Problem-Solving Approach -1. Understand current state -2. Identify specific issues -3. Propose solution -4. Implement incrementally -5. Test and verify -6. Refine based on feedback - -## Metrics - -- **Lines of Code:** ~1178 (main script) -- **Supported Chassis Types:** 3 (10bay, large1, micro) -- **Mapped Servers:** 1 fully (compute-storage-01), 3 partially (storage-01, large1, compute-storage-gpu-01), 2 stubs (micro1, monitor-02) -- **Features Added:** 10+ -- **Bugs Fixed:** 6 major, multiple minor -- **Documentation:** Comprehensive README + this file - -## Future Enhancements - -Potential improvements identified during development: - -1. **Auto-detection:** Attempt to auto-map bays by testing with `hdparm` LED control -2. **Color Output:** Use terminal colors for health status (green/red) -3. **Historical Tracking:** Log temperature trends over time -4. **Alert Integration:** Notify when drive health deteriorates -5. **Web Interface:** Display chassis map in a web dashboard -6. **Multi-server View:** Show all servers in one consolidated view - -## Lessons for Future AI-Assisted Development - -### What Worked Well -- Breaking complex problems into small, testable pieces -- Using diagnostic scripts to understand actual vs. assumed state -- Physical verification before trusting software output -- Comprehensive documentation alongside code -- Git commits with detailed messages for traceability - -### What Could Be Improved -- Earlier physical verification would have saved iteration -- More upfront hardware documentation would help -- Automated testing for bay mappings (if possible) - -## Conclusion - -This project demonstrates effective human-AI collaboration where: -- The AI provided technical implementation and problem-solving -- The human provided domain knowledge, testing, and verification -- Iterative feedback loops led to a polished, production-ready tool - -The result is a robust infrastructure management tool that provides instant visibility into complex storage configurations across multiple servers. - ---- - -**Development Credits:** -- **Human Developer:** LotusGuild -- **AI Assistant:** Claude Sonnet 4.5 (Anthropic) -- **Development Date:** January 6, 2026 -- **Project:** Drive Atlas v1.1.0 diff --git a/LICENSE b/LICENSE new file mode 100644 index 0000000..6693f89 --- /dev/null +++ b/LICENSE @@ -0,0 +1,21 @@ +MIT License + +Copyright (c) 2024-2026 Jared Vititoe + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in all +copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE +SOFTWARE. diff --git a/README.md b/README.md index a3228d0..03252f1 100644 --- a/README.md +++ b/README.md @@ -20,12 +20,12 @@ A powerful server drive mapping tool that generates visual ASCII representations Execute remotely using curl: ```bash -bash <(curl -s http://10.10.10.63:3000/LotusGuild/driveAtlas/raw/branch/main/driveAtlas.sh) +bash <(curl -s https://code.lotusguild.org/LotusGuild/driveAtlas/raw/branch/main/driveAtlas.sh) ``` Or using wget: ```bash -bash <(wget -qO- http://10.10.10.63:3000/LotusGuild/driveAtlas/raw/branch/main/driveAtlas.sh) +bash <(wget -qO- https://code.lotusguild.org/LotusGuild/driveAtlas/raw/branch/main/driveAtlas.sh) ``` ## Requirements @@ -239,7 +239,6 @@ DEBUG=1 bash driveAtlas.sh - [driveAtlas.sh](driveAtlas.sh) - Main script (includes `--diagnose` mode for PCI path discovery) - [README.md](README.md) - This file -- [CLAUDE.md](CLAUDE.md) - AI-assisted development notes ## Contributing diff --git a/driveAtlas.sh b/driveAtlas.sh index 6865e99..ea309c1 100644 --- a/driveAtlas.sh +++ b/driveAtlas.sh @@ -323,7 +323,7 @@ REQUIRED_DEPS=(lsblk lspci readlink hostname) # Optional dependencies (enhanced functionality) OPTIONAL_DEPS=(smartctl ceph ceph-volume bc nvme) -FRESH_START_URL="http://10.10.10.63:3000/LotusGuild/freshStartScript/raw/branch/main/freshStart.sh" +FRESH_START_URL="https://code.lotusguild.org/LotusGuild/freshStartScript/raw/branch/main/freshStart.sh" #------------------------------------------------------------------------------ # check_dependencies