+1 for the feature, Did you consider systemvms? Or the default vm-template? Or are those marked as undeletable or even hardcoded in case the table gets editted outside of ACS?
The delete feature is vital. You marked it as open for discussion but I don't agree. The admin should delete when he makes a mistake! Or when an os has a structural vulnerability! How and when is memory mapping done? Someone is busy instantiating a template based on an os which in the meanwhile is being deleted. What happens? regards, On Mon, Mar 3, 2014 at 9:44 PM, Amogh Vasekar <amogh.vase...@citrix.com> wrote: > Hi, > > CloudStack currently does not allow an easy way to add new guest OS types, > for example, a standard way to add say, CentOS 6.5 even though a > hypervisor may support it. > Part of the reason is since the OS to hypervisor-specific platform > mappings are currently hard-coded into the code-base [1][2] > To support such new OS addition, the current way is to manipulate the DB > using upgrade scripts and make the necessary code changes. > This proposal aims to partially mitigate this issue by allowing the > CloudStack admin the ability to add new OS in the list, and update the > mapping to hypervisor-specific platform names, via APIs / UI. For now, the > admin will be responsible for providing the mapping to hypervisor-specific > platform names based on his knowledge, which may be enhanced in future. > For example, based on [1], an admin should be able to add a mapping like : > CentOS 6.5 (64 bit) -> CentsOS 6.5 . > > The functional spec can be found at : > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Proposal+-+Ability+t > o+add+new+guest+OS+mappings > > Comments / suggestions welcome. > > Thanks, > Amogh > > > [1] > https://github.com/apache/cloudstack/blob/master/plugins/hypervisors/kvm/sr > c/com/cloud/hypervisor/kvm/resource/KVMGuestOsMapper.java > [2] > https://github.com/apache/cloudstack/blob/master/plugins/hypervisors/xen/sr > c/com/cloud/hypervisor/xen/resource/CitrixHelper.java > -- Daan
