cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Meier (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-9433) Change of VM compute offering with additional storage tags not allowed
Date Mon, 25 Jul 2016 08:25:20 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391526#comment-15391526
] 

Christian Meier commented on CLOUDSTACK-9433:
---------------------------------------------

I am not 100 % if understood you correctly,
therefore I would like to rethink this though once more.

Assuming that you are an administrator for a small to medium sized private cloud. His company
has aqcuired one storage array for this cluster. Later on, you get another storage which has
improved IOPS or an SSD cache lets say some nice but precious features. This SAN should be
reserved for special purposes. Therefore he has to create two tags: one "Cache" and one "NoCache".
The administrator now tags creates new version of the current offerings or maybe later, when
buying new machines with higher CPU or memory values creates new offerings all with the new
storage tagging scheme. To keep the overview for the users he disables the older offerings.
Now by a requirement some of the old VMs should get a larger CPU allocation. No VM with the
old (untagged) service offerings can now migrate to any new offering. They are now complete
out of the upgrade path.

Well, if I understand you correctly, instead of giving the users (including the application
administrators) a clean API and/or GUI for this to do, you suggest the root administrator
bypassing the business layer, reversing the database schema on their own and modifying the
database directly not knowing whether there are unknown dependencies hidden in the data and
therefore maybe destroying your installation? There is a good reason why many companies tell
their customers that they will loose their support if they directly modify the database.

Regarding "The difference is - the update of service offering - is a structured approach -
where you can decide who moves to what storage tag and where... Changing tag on existing service
offering that has many vms associated - is helping incompetent admin - shoot himself in the
foot.": If I understood your definitions "Update of the service offering" vs. "Changing tag
on existing service offering" correctly, I assume that this is exactly what I propose, namely
not changing the definition of an existing offering but instead creating a new one and update
the offering associations of the VMs. Unfortunately this my preferred structured approach
is not possible because the change towards the new offering is not possible :(



> Change of VM compute offering with additional storage tags not allowed
> ----------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-9433
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9433
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>    Affects Versions: 4.8.0
>            Reporter: Christian Meier
>
> It is not possible to upgrade service offerings of a with no storage tags to a offering
with a storage tag.
> The UI does not show a newly created Service Offering which has defined a Storage Tag.
If tried through cloudmonkey, the error reports :
> "Unable to upgrade virtual machine; the new service offering should have tags as subset
of current service offering tags. Current service offering tags: []; new service offering
tags: [RootLun]"
> While I understood the error message in the first place, it seems to me an artificially
introduced restriction which does not reflect real circumstances.
> Usually users start without using a sophisticated tagging scheme. Later on while already
having instantiated VMs, and maybe getting additional primary storage they want to refine
their usage scheme. They start to create offerings with storage tags. All existing machines
cannot migrate to these new service offerings but must be completely reinstalled.
> (An automatic storage migration might be an additional option, but I think still the
ROOT admin can manually migrate the existing volumes if necessary.) More importantly, I think
the artificial restriction must be removed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message