-
Notifications
You must be signed in to change notification settings - Fork 27
Renaming all the Components
We want to make sure that component names are:
- Descriptive and intuitive
- Internally consistent
- Consistent with the names used by similar applications which users might be familiar with
Here are some suggestions:
An XML document describing how to build an image.
- Component Outline
- Image Template (keep current name)
A collection of Deployables. (I thought it was the reverse i.e. a deployable is a collection of assemblies - dmac)
- Component Blueprint
- It’s not particularly clear how a Component Outline is different from a Component Blueprint. ~~~~matty_dubs
A collection of Images that should be deployable together.
- Application Blueprint
- Deployment Template
A Deployable which has been launched~~~~ a collection of instances that function together.
- Application
- This is already an overloaded term, and I think an “application” is Apache, not a collection of machines. —matty_dubs
- Deployment (keep current name)
- Instance Cluster
- Instance Group
A grouping of deployables (?) for (?).
- Cloud
- This term is already absurdly overloaded, and this is just confusing. I strongly oppose this one. —matty_dubs
- Environment (keep current name)
A grouping of deployables (?)
- Cloud Resource Zone
- Zone
- Pool (keep current name)
A mapping of particular back-end realms (AWS Availability Zones / RHEV data centers) or specific providers.
- Cloud Resource Cluster
- Realm (keep current name; consistent with Deltacloud)
A particular cloud provider, such as “ec2-us-east-1” or a particular RHEV cluster (?)
- Cloud Resource Provider
- Cloud Provider (more direct and clearer)
Minimum values for CPU, memory, disk, and architecture used to map to back-end hardware profiles in Deltacloud.
- Cloud Resource Profile
- Hardware Profile (keep current name)
- Instance Type (follows EC2’s naming)