[DISCUSSION] module naming convention

[choieastsea]

Summary

This proposal suggests transitioning from OpenStack-specific component names (Nova, Glance, Keystone, etc.) to generic, service-oriented naming conventions (compute, image, identity, etc.) in our codebase to improve maintainability, readability, and alignment with industry standards.

Motivation

Current State

• Our current codebase uses OpenStack-specific component names like nova, glance, keystone, neutron, cinder, etc.
• These names require domain-specific knowledge of OpenStack ecosystem
• New team members need to learn the mapping between service names and their actual functions

Industry Standards

• The OpenStack SDK and OpenStack APIs already use generic service names (compute, image, identity, network, volume)
• Other cloud providers (AWS, Azure, GCP) use functional naming conventions
• Generic names are more intuitive and self-documenting

Benefits of Generic Naming

1. Improved Readability: Code becomes self-documenting when service names clearly indicate their purpose
2. Easier Onboarding: New developers can understand functionality without OpenStack-specific knowledge
3. Better Abstraction: Generic names allow for potential future migration to other cloud platforms
4. Consistency: Aligns with OpenStack's own API naming conventions
5. Maintainability: Reduces cognitive load when reading and maintaining code

Proposal

Naming Mapping

Rename existing OpenStack component references according to OpenStack API service types:

Current (OpenStack Component)	Proposed (Generic Service)	Description
nova	compute	Virtual machine and instance management
glance	image	Virtual machine image storage and management
keystone	identity	Authentication and authorization services
neutron	network	Software-defined networking
cinder	volume	Block storage services
swift	object-store	Object storage services
heat	orchestration	Infrastructure orchestration and templates
horizon	dashboard	Web-based user interface

Implementation Strategy

Phase 1: Module and Package Renaming

• Rename module directories and package names
• Update import statements across the codebase
• Maintain backward compatibility through alias imports during transition period

Phase 2: Function and Class Renaming

• Rename classes, functions, and variables to use generic terminology
• Update documentation and comments
• Refactor configuration files and environment variables

Phase 3: API and Interface Updates

• Update public APIs to use generic naming
• Modify configuration schemas
• Update deployment scripts and infrastructure code

[halucinor]

This issue is resolved