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] [Updated] (CLOUDSTACK-9433) Change of VM compute offering with additional storage tags not allowed
Date Thu, 21 Jul 2016 08:09:20 GMT

     [ https://issues.apache.org/jira/browse/CLOUDSTACK-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Christian Meier updated CLOUDSTACK-9433:
----------------------------------------
    Description: 
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.

  was:
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 neccessary.) More importantly, I think the
artificial restriction must be removed.


> 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