[jira] [Commented] (CLOUDSTACK-6170) Support managed storage for root disks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13936027#comment-13936027 ] ASF subversion and git services commented on CLOUDSTACK-6170: - Commit 709d2a096dda5b05d575e53a316c6aabb785f6cd in cloudstack's branch refs/heads/resize-root from [~mike-tutkowski] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=709d2a0 ] CLOUDSTACK-6170 Support managed storage for root disks -- Key: CLOUDSTACK-6170 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6170 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Environment: I expect to support managed storage for root disks on XenServer and ESX (KVM is targeted for 4.5). Reporter: Mike Tutkowski Assignee: Mike Tutkowski Fix For: 4.4.0 Cloud environments have a need for guaranteed storage performance. By this I mean having the ability to specify a minimum and maximum number of IOPS on a volume-by-volume basis. I added support for this for XenServer and ESX in 4.2 for data disks. I added support for this for KVM in 4.3 for data disks. It is my intent to add support for this for XenServer and ESX in 4.4 for root disks (with subsequent support for root disks on KVM expected in 4.5). The main changes are expected to occur in CloudStack logic that controls hypervisors and additions to the way root-volume orchestration happens. This will also require minor changes in the SolidFire (storage) plug-in. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6181) Root resize
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Sorensen resolved CLOUDSTACK-6181. - Resolution: Implemented Root resize --- Key: CLOUDSTACK-6181 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6181 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Storage Controller, UI Affects Versions: 4.4.0 Environment: KVM/libvirt/CentOS, Xenserver Reporter: Nux Labels: disk, resize, template Fix For: 4.4.0 Rationale: Currently the root size of an instance is locked to that of the template. This creates unnecessary template duplicates, prevents the creation of a market place, wastes time and disk space and generally makes work more complicated. Real life example - a small VPS provider might want to offer the following sizes (in GB): 10,20,40,80,160,240,320,480,620 That's 9 offerings. The template selection could look like this, including real disk space used: Windows 2008 ~10GB Windows 2008+Plesk ~15GB Windows 2008+MSSQL ~15GB Windows 2012 ~10GB Windows 2012+Plesk ~15GB Windows 2012+MSSQL ~15GB CentOS ~1GB CentOS+CPanel ~3GB CentOS+Virtualmin ~3GB CentOS+Zimbra ~3GB CentOS+Docker ~2GB Debian ~1GB Ubuntu LTS ~1GB In this case the total disk space used by templates will be 828 GB, that's almost 1 TB. If your storage is expensive and limited SSD this can get painful! If the root resize feature is enabled we can reduce this to under 100 GB. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6181) Root resize
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13936034#comment-13936034 ] ASF subversion and git services commented on CLOUDSTACK-6181: - Commit e9e2ee3ac5d396b32fa5e6ee82f4bf4410f5754e in cloudstack's branch refs/heads/4.4 from [~mlsorensen] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e9e2ee3 ] CLOUDSTACK-6181: Merge of resize root feature (resize-root branch) Root resize --- Key: CLOUDSTACK-6181 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6181 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Storage Controller, UI Affects Versions: 4.4.0 Environment: KVM/libvirt/CentOS, Xenserver Reporter: Nux Labels: disk, resize, template Fix For: 4.4.0 Rationale: Currently the root size of an instance is locked to that of the template. This creates unnecessary template duplicates, prevents the creation of a market place, wastes time and disk space and generally makes work more complicated. Real life example - a small VPS provider might want to offer the following sizes (in GB): 10,20,40,80,160,240,320,480,620 That's 9 offerings. The template selection could look like this, including real disk space used: Windows 2008 ~10GB Windows 2008+Plesk ~15GB Windows 2008+MSSQL ~15GB Windows 2012 ~10GB Windows 2012+Plesk ~15GB Windows 2012+MSSQL ~15GB CentOS ~1GB CentOS+CPanel ~3GB CentOS+Virtualmin ~3GB CentOS+Zimbra ~3GB CentOS+Docker ~2GB Debian ~1GB Ubuntu LTS ~1GB In this case the total disk space used by templates will be 828 GB, that's almost 1 TB. If your storage is expensive and limited SSD this can get painful! If the root resize feature is enabled we can reduce this to under 100 GB. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6242) Potential bugs and improvements for exception handlers
Ding Yuan created CLOUDSTACK-6242:
-
Summary: Potential bugs and improvements for exception handlers
Key: CLOUDSTACK-6242
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6242
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Projects, Storage Controller
Affects Versions: 4.2.0
Reporter: Ding Yuan
Hi Cloudstack developers,
I'm reporting a few cases where the exception handling logic could be improved.
In particular, there are a few cases where the caught exception is too general
(over-catch), and/or missing log messages. Attaching a patch for review.
There are a few cases where it looks suspicious but I do not know how to fix
right now (all filenames and line numbers are based on version 4.2.1):
=
Case 1:
Line: 375, File: com/cloud/network/ovs/OvsTunnelManagerImpl.java
{noformat}
326: try {
327: String myIp = getGreEndpointIP(dest.getHost(), nw);
.. .. ..
373:} catch (Exception e) {
374:// I really thing we should do a better handling of these
exceptions
375:s_logger.warn(Ovs Tunnel network created tunnel failed, e);
376:}
{noformat}
Comment seems to suggest for a better handling.
=
=
Case 2:
Line: 2295, File: com/cloud/resource/ResourceManagerImpl.java
{noformat}
2284: try {
2285: /*
2286: * FIXME: this is a buggy logic, check with alex.
Shouldn't
2287: * return if propagation return non null
2288: */
2289: Boolean result =
_clusterMgr.propagateResourceEvent(h.getId(),
ResourceState.Event.UpdatePassword);
2290: if (result != null) {
2291: return result;
2292: }
2293:
2294: doUpdateHostPassword(h.getId());
2295: } catch (AgentUnavailableException e) {
2296: }
{noformat}
Seem from the comment the logic should be fixed.
A similar code snipeet is at:
Line: 2276, File: com/cloud/resource/ResourceManagerImpl.java
=
=
Case 3:
Line: 184, File:
org/apache/cloudstack/api/command/user/autoscale/CreateAutoScaleVmGroupCmd.java
{noformat}
174: try
175: {
176: success = _autoScaleService.configureAutoScaleVmGroup(this);
177: if (success) {
178: vmGroup = _entityMgr.findById(AutoScaleVmGroup.class,
getEntityId());
179: AutoScaleVmGroupResponse responseObject =
_responseGenerator.createAutoScaleVmGroupResponse(vmGroup);
180: setResponseObject(responseObject);
181: responseObject.setResponseName(getCommandName());
182: }
183: } catch (Exception ex) {
184: // TODO what will happen if Resource Layer fails in a step
inbetween
185: s_logger.warn(Failed to create autoscale vm group, ex);
186: }
{noformat}
The comment, TODO, seems to suggest for better handling.
=
=
Case 4:
Line: 222, File: com/cloud/api/ApiDispatcher.java
This snippet is moved to ParamProcessWorker.java in the trunk.
{noformat}
203: try {
204: setFieldValue(field, cmd, paramObj, parameterAnnotation);
.. ..
220: } catch (CloudRuntimeException cloudEx) {
221:s_logger.error(CloudRuntimeException, cloudEx);
222: // FIXME: Better error message? This only happens if the
API command is not executable, which typically
223: //means
224: // there was
225: // and IllegalAccessException setting one of the
parameters.
226: throw new ServerApiException(ApiErrorCode.INTERNAL_ERROR,
Internal error executing API command + cmd.getCommandName().substring(0,
cmd.getCommandName().length() - 8));
227: }
{noformat}
The FIXME comment seems to suggest for getter error message.
=
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6242) Potential bugs and improvements for exception handlers
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ding Yuan updated CLOUDSTACK-6242:
--
Attachment: CLOUDSTACK-6242.patch
Patch against trunk.
Potential bugs and improvements for exception handlers
--
Key: CLOUDSTACK-6242
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6242
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Projects, Storage Controller
Affects Versions: 4.2.0
Reporter: Ding Yuan
Attachments: CLOUDSTACK-6242.patch
Hi Cloudstack developers,
I'm reporting a few cases where the exception handling logic could be
improved. In particular, there are a few cases where the caught exception is
too general (over-catch), and/or missing log messages. Attaching a patch for
review.
There are a few cases where it looks suspicious but I do not know how to fix
right now (all filenames and line numbers are based on version 4.2.1):
=
Case 1:
Line: 375, File: com/cloud/network/ovs/OvsTunnelManagerImpl.java
{noformat}
326: try {
327: String myIp = getGreEndpointIP(dest.getHost(), nw);
.. .. ..
373:} catch (Exception e) {
374:// I really thing we should do a better handling of these
exceptions
375:s_logger.warn(Ovs Tunnel network created tunnel failed, e);
376:}
{noformat}
Comment seems to suggest for a better handling.
=
=
Case 2:
Line: 2295, File: com/cloud/resource/ResourceManagerImpl.java
{noformat}
2284: try {
2285: /*
2286: * FIXME: this is a buggy logic, check with alex.
Shouldn't
2287: * return if propagation return non null
2288: */
2289: Boolean result =
_clusterMgr.propagateResourceEvent(h.getId(),
ResourceState.Event.UpdatePassword);
2290: if (result != null) {
2291: return result;
2292: }
2293:
2294: doUpdateHostPassword(h.getId());
2295: } catch (AgentUnavailableException e) {
2296: }
{noformat}
Seem from the comment the logic should be fixed.
A similar code snipeet is at:
Line: 2276, File: com/cloud/resource/ResourceManagerImpl.java
=
=
Case 3:
Line: 184, File:
org/apache/cloudstack/api/command/user/autoscale/CreateAutoScaleVmGroupCmd.java
{noformat}
174: try
175: {
176: success = _autoScaleService.configureAutoScaleVmGroup(this);
177: if (success) {
178: vmGroup = _entityMgr.findById(AutoScaleVmGroup.class,
getEntityId());
179: AutoScaleVmGroupResponse responseObject =
_responseGenerator.createAutoScaleVmGroupResponse(vmGroup);
180: setResponseObject(responseObject);
181: responseObject.setResponseName(getCommandName());
182: }
183: } catch (Exception ex) {
184: // TODO what will happen if Resource Layer fails in a step
inbetween
185: s_logger.warn(Failed to create autoscale vm group, ex);
186: }
{noformat}
The comment, TODO, seems to suggest for better handling.
=
=
Case 4:
Line: 222, File: com/cloud/api/ApiDispatcher.java
This snippet is moved to ParamProcessWorker.java in the trunk.
{noformat}
203: try {
204: setFieldValue(field, cmd, paramObj, parameterAnnotation);
.. ..
220: } catch (CloudRuntimeException cloudEx) {
221:s_logger.error(CloudRuntimeException, cloudEx);
222: // FIXME: Better error message? This only happens if the
API command is not executable, which typically
223: //means
224: // there was
225: // and IllegalAccessException setting one of the
parameters.
226: throw new
ServerApiException(ApiErrorCode.INTERNAL_ERROR, Internal error executing API
command + cmd.getCommandName().substring(0, cmd.getCommandName().length() -
8));
227: }
{noformat}
The FIXME comment seems to suggest for getter error message.
=
--
This message was sent by Atlassian JIRA
(v6.2#6252)
