[
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)
