[jira] [Created] (CLOUDSTACK-7160) API: Updating a network ACL rule fails if the protocol is switched from TCP/UDP to anything else and vice versa
Patrick D. created CLOUDSTACK-7160: -- Summary: API: Updating a network ACL rule fails if the protocol is switched from TCP/UDP to anything else and vice versa Key: CLOUDSTACK-7160 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7160 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Patrick D. Priority: Minor Steps to reproduce: - Create a VPC - Create a network ACL rule with TCP as protocol - Click "Update" icon - Change from TCP to ICMP - Press "OK" -> Will fail with message : "Can't specify start/end port when protocol is ICMP" This will also happen, if changing to "ALL" -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7161) API: The response of an "updateNetworkACLItem" command returns a "createnetworkaclresponse"
Patrick D. created CLOUDSTACK-7161: -- Summary: API: The response of an "updateNetworkACLItem" command returns a "createnetworkaclresponse" Key: CLOUDSTACK-7161 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7161 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Patrick D. Priority: Trivial -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7418) Deleting a load balancer rule that has an SSL cert assigned to it does not delete the mapping in the load_balancer_cert_map table
Patrick D. created CLOUDSTACK-7418: -- Summary: Deleting a load balancer rule that has an SSL cert assigned to it does not delete the mapping in the load_balancer_cert_map table Key: CLOUDSTACK-7418 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7418 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Patrick D. This causes a Null Pointer Exception when listing the SSL certificates because it tries to get the ID of a lbr that does not exist anymore. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7420) Creating a stickiness policy for a load balancer rule that has protocol SSL will fail.
Patrick D. created CLOUDSTACK-7420: -- Summary: Creating a stickiness policy for a load balancer rule that has protocol SSL will fail. Key: CLOUDSTACK-7420 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7420 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Patrick D. 2014-08-25 11:36:05,562 ERROR [c.c.n.ExternalLoadBalancerDeviceManagerImpl] (API-Job-Executor-67:ctx-a8f58eed job-674 ctx-47688fe7) Unable to apply load balancer rules to the external load balancer appliance in zone dev3_zone1 due to: Exception: com.cloud.utils.exception.ExecutionException Message: Failed to create new virtual server:Cloud-VirtualServer due to Can not update virtual server:Cloud-VirtualServer as current protocol:SSL of virtual server is different from the intended protocol:HTTP Stack: com.cloud.utils.exception.ExecutionException: Failed to create new virtual server:Cloud-VirtualServer due to Can not update virtual server:Cloud-VirtualServer as current protocol:SSL of virtual server is different from the intended protocol:HTTP at com.cloud.network.resource.NetscalerResource.addLBVirtualServer(NetscalerResource.java:2802) at com.cloud.network.resource.NetscalerResource.execute(NetscalerResource.java:589) at com.cloud.network.resource.NetscalerResource.executeRequest(NetscalerResource.java:427) at com.cloud.network.resource.NetscalerResource.retry(NetscalerResource.java:3656) at com.cloud.network.resource.NetscalerResource.execute(NetscalerResource.java:885) at com.cloud.network.resource.NetscalerResource.executeRequest(NetscalerResource.java:427) at com.cloud.network.resource.NetscalerResource.retry(NetscalerResource.java:3656) at com.cloud.network.resource.NetscalerResource.execute(NetscalerResource.java:885) at com.cloud.network.resource.NetscalerResource.executeRequest(NetscalerResource.java:427) at com.cloud.network.resource.NetscalerResource.executeRequest(NetscalerResource.java:416) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7420) Creating a stickiness policy for a load balancer rule that has protocol SSL will fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick D. updated CLOUDSTACK-7420: --- Summary: Creating a stickiness policy for a load balancer rule that has protocol SSL will fail (was: Creating a stickiness policy for a load balancer rule that has protocol SSL will fail.) > Creating a stickiness policy for a load balancer rule that has protocol SSL > will fail > - > > Key: CLOUDSTACK-7420 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7420 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.0 >Reporter: Patrick D. > > 2014-08-25 11:36:05,562 ERROR [c.c.n.ExternalLoadBalancerDeviceManagerImpl] > (API-Job-Executor-67:ctx-a8f58eed job-674 ctx-47688fe7) Unable to apply load > balancer rules to the external load balancer appliance in zone dev3_zone1 due > to: Exception: com.cloud.utils.exception.ExecutionException > Message: Failed to create new virtual server:Cloud-VirtualServer due to Can > not update virtual server:Cloud-VirtualServer as current protocol:SSL of > virtual server is different from the intended protocol:HTTP > Stack: com.cloud.utils.exception.ExecutionException: Failed to create new > virtual server:Cloud-VirtualServer due to Can not update virtual > server:Cloud-VirtualServer as current protocol:SSL of virtual server is > different from the intended protocol:HTTP > at > com.cloud.network.resource.NetscalerResource.addLBVirtualServer(NetscalerResource.java:2802) > at > com.cloud.network.resource.NetscalerResource.execute(NetscalerResource.java:589) > at > com.cloud.network.resource.NetscalerResource.executeRequest(NetscalerResource.java:427) > at > com.cloud.network.resource.NetscalerResource.retry(NetscalerResource.java:3656) > at > com.cloud.network.resource.NetscalerResource.execute(NetscalerResource.java:885) > at > com.cloud.network.resource.NetscalerResource.executeRequest(NetscalerResource.java:427) > at > com.cloud.network.resource.NetscalerResource.retry(NetscalerResource.java:3656) > at > com.cloud.network.resource.NetscalerResource.execute(NetscalerResource.java:885) > at > com.cloud.network.resource.NetscalerResource.executeRequest(NetscalerResource.java:427) > at > com.cloud.network.resource.NetscalerResource.executeRequest(NetscalerResource.java:416) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7420) Creating a stickiness policy for a load balancer rule that has protocol SSL will fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14110828#comment-14110828 ] Patrick D. commented on CLOUDSTACK-7420: Create an LB rule: algorithm=roundrobin&command=createLoadBalancerRule&name=lbrule&networkId=c3601690-3ea3-4987-b9e4-c55728a40384&privatePort=12&projectId=777cd2f4-8d38-4510-bce6-7d94eede0557&protocol=ssl&publicIpId=feffe971-5f58-4763-80eb-a5bfd72330c9&publicPort=12&response=json Assign instances to it: command=assignToLoadBalancerRule&id=46844e60-a168-4278-bd20-4f2efe21d4f5&projectId=777cd2f4-8d38-4510-bce6-7d94eede0557&response=json&virtualmachineids=0f09d6c8-d4de-4f38-a179-6b552839002b Assign an SSL cert to it: certId=3ed76011-c135-41d4-b180-237433b763d1&command=assignCertToLoadBalancer&lbRuleId=46844e60-a168-4278-bd20-4f2efe21d4f5&response=json Create an LB stickiness policy for LB rule: command=createLBStickinessPolicy&lbruleid=46844e60-a168-4278-bd20-4f2efe21d4f5&methodname=LbCookie&name=ckie¶m[0].name=holdtime¶m[0].value=10&projectid=777cd2f4-8d38-4510-bce6-7d94eede0557&response=json It will then fail with the same exception. However, if you create a rule, create a stickiness policy, assign the cert and then assign instances, it will not fail > Creating a stickiness policy for a load balancer rule that has protocol SSL > will fail > - > > Key: CLOUDSTACK-7420 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7420 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.0 >Reporter: Patrick D. > > 2014-08-25 11:36:05,562 ERROR [c.c.n.ExternalLoadBalancerDeviceManagerImpl] > (API-Job-Executor-67:ctx-a8f58eed job-674 ctx-47688fe7) Unable to apply load > balancer rules to the external load balancer appliance in zone dev3_zone1 due > to: Exception: com.cloud.utils.exception.ExecutionException > Message: Failed to create new virtual server:Cloud-VirtualServer due to Can > not update virtual server:Cloud-VirtualServer as current protocol:SSL of > virtual server is different from the intended protocol:HTTP > Stack: com.cloud.utils.exception.ExecutionException: Failed to create new > virtual server:Cloud-VirtualServer due to Can not update virtual > server:Cloud-VirtualServer as current protocol:SSL of virtual server is > different from the intended protocol:HTTP > at > com.cloud.network.resource.NetscalerResource.addLBVirtualServer(NetscalerResource.java:2802) > at > com.cloud.network.resource.NetscalerResource.execute(NetscalerResource.java:589) > at > com.cloud.network.resource.NetscalerResource.executeRequest(NetscalerResource.java:427) > at > com.cloud.network.resource.NetscalerResource.retry(NetscalerResource.java:3656) > at > com.cloud.network.resource.NetscalerResource.execute(NetscalerResource.java:885) > at > com.cloud.network.resource.NetscalerResource.executeRequest(NetscalerResource.java:427) > at > com.cloud.network.resource.NetscalerResource.retry(NetscalerResource.java:3656) > at > com.cloud.network.resource.NetscalerResource.execute(NetscalerResource.java:885) > at > com.cloud.network.resource.NetscalerResource.executeRequest(NetscalerResource.java:427) > at > com.cloud.network.resource.NetscalerResource.executeRequest(NetscalerResource.java:416) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassi
[jira] [Created] (CLOUDSTACK-7488) Releasing an IP address that has a LBR with a SSL certificate does not remove the LBR-SSL mapping (which breaks SSL Cert listing)
Patrick D. created CLOUDSTACK-7488: -- Summary: Releasing an IP address that has a LBR with a SSL certificate does not remove the LBR-SSL mapping (which breaks SSL Cert listing) Key: CLOUDSTACK-7488 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7488 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Patrick D. In relation to CLOUDSTACK-7418 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8890) Can no longer create VPC or other basic resources on projects because of CLOUDSTACK-7908
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick D. updated CLOUDSTACK-8890: --- Description: Steps to reproduce: - Create project - Try to create VPC in project - Fails This does not work for any resource owned by a project. The implemented code gets the first user of the owner account, but in the case of a project (an account), there are no users, which cause and IndexOutOfBoundsException -> (https://issues.apache.org/jira/browse/CLOUDSTACK-7908) was: Steps to reproduce: - Create project - Try to create VPC in project - Fails This does not work for any resource owned by a project. The implemented code gets the first user of the owner account, but in the case of a project (an account), there are no users, which cause and IndexOutOfBoundsException > Can no longer create VPC or other basic resources on projects because of > CLOUDSTACK-7908 > > > Key: CLOUDSTACK-8890 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8890 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Patrick D. >Priority: Blocker > > Steps to reproduce: > - Create project > - Try to create VPC in project > - Fails > This does not work for any resource owned by a project. The implemented code > gets the first user of the owner account, but in the case of a project (an > account), there are no users, which cause and IndexOutOfBoundsException -> > (https://issues.apache.org/jira/browse/CLOUDSTACK-7908) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8898) Devcloud4 deployments are broken
Patrick D. created CLOUDSTACK-8898: -- Summary: Devcloud4 deployments are broken Key: CLOUDSTACK-8898 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8898 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Patrick D. Chef vagrant box was moved to bento organization -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8890) Can no longer create VPC or other basic resources on projects because of CLOUDSTACK-7908
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14904514#comment-14904514 ] Patrick D. commented on CLOUDSTACK-8890: Hey [~bo...@pcextreme.nl], I can take a look. Thanks! (I also commented on the PR) > Can no longer create VPC or other basic resources on projects because of > CLOUDSTACK-7908 > > > Key: CLOUDSTACK-8890 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8890 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Patrick D. >Priority: Blocker > > Steps to reproduce: > - Create project > - Try to create VPC in project > - Fails > This does not work for any resource owned by a project. The implemented code > gets the first user of the owner account, but in the case of a project (an > account), there are no users, which cause and IndexOutOfBoundsException -> > (https://issues.apache.org/jira/browse/CLOUDSTACK-7908) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-8793) Project Site-2-Site VPN Connection Fails to Register Correctly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick D. reassigned CLOUDSTACK-8793: -- Assignee: Patrick D. > Project Site-2-Site VPN Connection Fails to Register Correctly > -- > > Key: CLOUDSTACK-8793 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8793 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Projects >Affects Versions: 4.5.2 > Environment: Clean install of ACS 4.5.2 on CentOS 6.6 >Reporter: Geoff Higgibottom >Assignee: Patrick D. > Labels: project, vpc, vpn > > When trying to create a new Site-2-Site VPN Connection for a Project using > the UI the following error message is presented. > "VPN connection can only be esitablished between same account's VPN gateway > and customer gateway!" > Apart from the spelling mistake in the error message, the main issue is that > the VPN Connection fails to create as the VPN Customer Gateway is linked to > the Logged in user account, and not the Project. > The VPN Gateway is correctly linked to the Project, as this was fixed in > CLOUDSTACK-5409. > Manually updating the ‘domain_id’ and ‘account_id’ values in the > ‘s2s_vpn_connection’ table in the DB will result in the successful creation > of the VPN Connection, but this connection will not display in the UI or when > querying via the API. > The same error exists when using only the API so it is not a UI issue. > This prevents the use of Site-2Site VPNs for VPCs belonging to Projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8916) Add a cross zones boolean to the RegisterTemplateCmd and render the zoneId optional
Patrick D. created CLOUDSTACK-8916: -- Summary: Add a cross zones boolean to the RegisterTemplateCmd and render the zoneId optional Key: CLOUDSTACK-8916 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8916 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Reporter: Patrick D. Assignee: Patrick D. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8955) Allow enabling/disabling of disk and service offerings
Patrick D. created CLOUDSTACK-8955: -- Summary: Allow enabling/disabling of disk and service offerings Key: CLOUDSTACK-8955 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8955 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Reporter: Patrick D. Assignee: Patrick D. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6276) Affinity Groups within projects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15011265#comment-15011265 ] Patrick D. commented on CLOUDSTACK-6276: Hey guys, I commented on the GitHub PR. I was looking to help with this issue. Is anyone still working on it? Thanks, pdube > Affinity Groups within projects > --- > > Key: CLOUDSTACK-6276 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6276 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Ingo Jochim > > Hello, > I like to have the features "Affinity Group" and "Project" combined. > As far as I know I cannot use Affinity Groups within Projects. > Thanks and regards, > Ingo -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (CLOUDSTACK-6276) Affinity Groups within projects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick D. updated CLOUDSTACK-6276: --- Comment: was deleted (was: Hey guys, I commented on the GitHub PR. I was looking to help with this issue. Is anyone still working on it? Thanks, pdube) > Affinity Groups within projects > --- > > Key: CLOUDSTACK-6276 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6276 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Ingo Jochim > > Hello, > I like to have the features "Affinity Group" and "Project" combined. > As far as I know I cannot use Affinity Groups within Projects. > Thanks and regards, > Ingo -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8793) Project Site-2-Site VPN Connection Fails to Register Correctly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick D. resolved CLOUDSTACK-8793. Resolution: Fixed Fix Version/s: 4.6.0 > Project Site-2-Site VPN Connection Fails to Register Correctly > -- > > Key: CLOUDSTACK-8793 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8793 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Projects >Affects Versions: 4.5.2 > Environment: Clean install of ACS 4.5.2 on CentOS 6.6 >Reporter: Geoff Higgibottom >Assignee: Patrick D. > Labels: project, vpc, vpn > Fix For: 4.6.0 > > > When trying to create a new Site-2-Site VPN Connection for a Project using > the UI the following error message is presented. > "VPN connection can only be esitablished between same account's VPN gateway > and customer gateway!" > Apart from the spelling mistake in the error message, the main issue is that > the VPN Connection fails to create as the VPN Customer Gateway is linked to > the Logged in user account, and not the Project. > The VPN Gateway is correctly linked to the Project, as this was fixed in > CLOUDSTACK-5409. > Manually updating the ‘domain_id’ and ‘account_id’ values in the > ‘s2s_vpn_connection’ table in the DB will result in the successful creation > of the VPN Connection, but this connection will not display in the UI or when > querying via the API. > The same error exists when using only the API so it is not a UI issue. > This prevents the use of Site-2Site VPNs for VPCs belonging to Projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-6276) Affinity Groups within projects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick D. reassigned CLOUDSTACK-6276: -- Assignee: Patrick D. > Affinity Groups within projects > --- > > Key: CLOUDSTACK-6276 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6276 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Ingo Jochim >Assignee: Patrick D. > Fix For: 4.7.0 > > > Hello, > I like to have the features "Affinity Group" and "Project" combined. > As far as I know I cannot use Affinity Groups within Projects. > Thanks and regards, > Ingo -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-6276) Affinity Groups within projects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick D. resolved CLOUDSTACK-6276. Resolution: Fixed Fix Version/s: 4.7.0 > Affinity Groups within projects > --- > > Key: CLOUDSTACK-6276 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6276 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Ingo Jochim >Assignee: Patrick D. > Fix For: 4.7.0 > > > Hello, > I like to have the features "Affinity Group" and "Project" combined. > As far as I know I cannot use Affinity Groups within Projects. > Thanks and regards, > Ingo -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9404) Network ACL rules in VPCs are applied in an inverted order
Patrick D. created CLOUDSTACK-9404: -- Summary: Network ACL rules in VPCs are applied in an inverted order Key: CLOUDSTACK-9404 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9404 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.8.0, 4.7.2, 4.9.0 Reporter: Patrick D. Assignee: Patrick D. Found the issue in the agent code. The comparator is inverted -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-9404) Network ACL rules in VPCs are applied in an inverted order
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick D. resolved CLOUDSTACK-9404. Resolution: Fixed > Network ACL rules in VPCs are applied in an inverted order > -- > > Key: CLOUDSTACK-9404 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9404 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.2, 4.8.0, 4.9.0 >Reporter: Patrick D. >Assignee: Patrick D. > > Found the issue in the agent code. The comparator is inverted -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9430) Adding a network ACL rule adds it in the wrong order for VPCs
Patrick D. created CLOUDSTACK-9430: -- Summary: Adding a network ACL rule adds it in the wrong order for VPCs Key: CLOUDSTACK-9430 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9430 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Patrick D. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9430) Adding a network ACL rule adds it in the wrong order for VPCs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick D. updated CLOUDSTACK-9430: --- Affects Version/s: 4.9.0 4.7.1 4.8.0 > Adding a network ACL rule adds it in the wrong order for VPCs > - > > Key: CLOUDSTACK-9430 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9430 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.1, 4.8.0, 4.9.0 >Reporter: Patrick D. > > Editing a rule number as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9430) Adding a network ACL rule adds it in the wrong order for VPCs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick D. updated CLOUDSTACK-9430: --- Description: Editing a rule number as well. > Adding a network ACL rule adds it in the wrong order for VPCs > - > > Key: CLOUDSTACK-9430 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9430 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.1, 4.8.0, 4.9.0 >Reporter: Patrick D. > > Editing a rule number as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-9431) Network usage stats from VR in VPC are wrong after upgrading to ACS 4.7
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick D. reassigned CLOUDSTACK-9431:
--
Assignee: Patrick D.
> Network usage stats from VR in VPC are wrong after upgrading to ACS 4.7
> ---
>
> Key: CLOUDSTACK-9431
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9431
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Usage, Virtual Router
>Affects Versions: 4.7.1
>Reporter: Simon Godard
>Assignee: Patrick D.
>
> After upgrading to ACS 4.7.1 and our Virtual routers to 4.6.0, we noticed
> that the Network usage (bytes sent and received) were not good anymore. Bytes
> sent are now 0 and bytes received appear to be what used to be bytes sent
> before the update.
> We are using Advanced networking with VPC on Xen Server 6.5.
> I have checked the CloudStack Java code that is handling retrieving the
> network stats and nothing changed for a long time. What changed is the way
> the Virtual router is configured (now using Python scripts). After comparing
> the previous _iptables_ rules, I noticed something weird with the
> NETWORK_STATS_eth1 chain:
> {noformat}
> iptables -L NETWORK_STATS_eth1 -n -v -x
> Chain NETWORK_STATS_eth1 (1 references)
> pkts bytestarget prot opt in out source
> destination
>00all-- * eth10.0.0.0/0
> 10.188.216.0/24
>47170 7755561all-- * eth110.188.216.0/24
> 0.0.0.0/0
>00all-- * eth10.0.0.0/0
> 10.188.218.0/24
>71957 689541123 all-- * eth110.188.218.0/24
> 0.0.0.0/0
> {noformat}
> The rules are out of order and the _in_ and _out_ too. Now, if we compare
> those rules against the previous ones (version 4.4.4 of the VR):
> {noformat}
> iptables -L NETWORK_STATS_eth1 -n -v -x
> Chain NETWORK_STATS_eth1 (1 references)
> pkts bytes target prot opt in out source
> destination
> 35167 2673Kall -- anyeth110.158.216.0/22 anywhere
>
> 33036 2511Kall -- eth1 any anywhere
> 10.158.216.0/22
> {noformat}
> Once I noticed the differences, I tried to find the root cause in CsAddress.py
> The following lines appear to be problematic.
> {noformat}
> self.fw.append(["", "front", "-A NETWORK_STATS_%s -o %s -s %s" %
> ("eth1", "eth1", self.address['network'])])
> self.fw.append(["", "front", "-A NETWORK_STATS_%s -o %s -d %s" %
> ("eth1", "eth1", self.address['network'])])
> {noformat}
> After updating them to be the following (note the -i instead of -o on the
> second line), the network stats are back to normal:
> {noformat}
> self.fw.append(["", "front", "-A NETWORK_STATS_%s -o %s -s %s" %
> ("eth1", "eth1", self.address['network'])])
> self.fw.append(["", "front", "-A NETWORK_STATS_%s -i %s -d %s" %
> ("eth1", "eth1", self.address['network'])])
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-9430) Adding a network ACL rule adds it in the wrong order for VPCs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick D. reassigned CLOUDSTACK-9430: -- Assignee: Patrick D. > Adding a network ACL rule adds it in the wrong order for VPCs > - > > Key: CLOUDSTACK-9430 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9430 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.1, 4.8.0, 4.9.0 >Reporter: Patrick D. >Assignee: Patrick D. > > Editing a rule number as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9423) Object storage should get the correct size for compressed templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15387705#comment-15387705 ] Patrick D. commented on CLOUDSTACK-9423: [~sahmed] Is the issue resolved? If so, could you update this ticket please? > Object storage should get the correct size for compressed templates > --- > > Key: CLOUDSTACK-9423 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9423 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: syed ahmed > Labels: secondary_storage, swift, template > > When uploading templates to an object store like Swift, if the template is > compressed, we get an invalid size (negative). This fix tries to see if the > template is compressed, if so, gets the correct size by partially > decompressing the VHD header. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9435) If User Data is encoded as a URL safe string using the apache commons library, it cannot be decoded by the python scripts
Patrick D. created CLOUDSTACK-9435: -- Summary: If User Data is encoded as a URL safe string using the apache commons library, it cannot be decoded by the python scripts Key: CLOUDSTACK-9435 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9435 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Patrick D. Assignee: Patrick D. This prevents all actions on the VR -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-9440) Missing and duplicate VR rules for VPC router on reboot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick D. reassigned CLOUDSTACK-9440: -- Assignee: Patrick D. > Missing and duplicate VR rules for VPC router on reboot > --- > > Key: CLOUDSTACK-9440 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9440 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Patrick D. >Assignee: Patrick D. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9440) Missing and duplicate VR rules for VPC router on reboot
Patrick D. created CLOUDSTACK-9440: -- Summary: Missing and duplicate VR rules for VPC router on reboot Key: CLOUDSTACK-9440 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9440 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Patrick D. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9441) Adding an EGRESS accept rule in VPC network ACL does not add the drop all rule as well
Patrick D. created CLOUDSTACK-9441: -- Summary: Adding an EGRESS accept rule in VPC network ACL does not add the drop all rule as well Key: CLOUDSTACK-9441 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9441 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Patrick D. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9341) Cannot upload volume when using Swift as secondary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230827#comment-15230827 ] Patrick D. commented on CLOUDSTACK-9341: [~williamstev...@gmail.com] No this is for volume upload > Cannot upload volume when using Swift as secondary storage > -- > > Key: CLOUDSTACK-9341 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9341 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Secondary Storage >Affects Versions: Future, 4.4.4, 4.7.0 >Reporter: Pierre-Luc Dion >Assignee: Patrick D. >Priority: Minor > > tested on 4.4.4 and 4.7.1: > Uploading a volume fails when using swift as secondary storage. > The error returned is: org.apache.cloudstack.storage.to.VolumeObjectTO cannot > be cast to org.apache.cloudstack.storage.to.TemplateObjectTO > The code related to this issue: > https://github.com/apache/cloudstack/blob/master/plugins/storage/image/swift/src/org/apache/cloudstack/storage/datastore/driver/SwiftImageStoreDriverImpl.java#L105 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7908) Addition of userid field to vm_instance table to identify user that created the VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14803175#comment-14803175 ] Patrick D. commented on CLOUDSTACK-7908: This change actually breaks anything related to projects. A project (basically an account) does not have any users. This causes IndexOutOfBoundsExceptions everywhere this was implemented. > Addition of userid field to vm_instance table to identify user that created > the VM > -- > > Key: CLOUDSTACK-7908 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7908 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 > Environment: 4.3.0 >Reporter: David Williams >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.6.0 > > > It would be handy/helpful if the userid of the user that created a VM was > recorded in the database in the vm_instance table. Currently, the only way I > know of to find the user that deployed a VM is by checking the logs. There's > an owner field in the vm_instance table but this seems to be the account ID > of the account the user belongs to. > By being able to find the user that deployed a VM, it makes VM cleanups much > easier since you know who to contact for each VM to check if it can be > deleted. A similar thing in the other tables for the other resources would be > useful too when trying to cleanup networks and volumes, etc. Also, if this > change went ahead, then the API and GUI could be changed also to show the > user details for the VM when listing the VM's details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8890) Can no longer create VPC or other basic resources on projects because of CLOUDSTACK-7908
Patrick D. created CLOUDSTACK-8890: -- Summary: Can no longer create VPC or other basic resources on projects because of CLOUDSTACK-7908 Key: CLOUDSTACK-8890 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8890 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.6.0 Reporter: Patrick D. Priority: Blocker This does not work for any resource owned by a project. The implemented code gets the first user of the owner account, but in the case of a project (an account), there are no users, which cause and IndexOutOfBoundsException -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8890) Can no longer create VPC or other basic resources on projects because of CLOUDSTACK-7908
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick D. updated CLOUDSTACK-8890: --- Description: This does not work for any resource owned by a project. The implemented code gets the first user of the owner account, but in the case of a project (an account), there are no users, which cause and IndexOutOfBoundsException Steps to reproduce: - Create project - Try to create VPC in project - Fails was:This does not work for any resource owned by a project. The implemented code gets the first user of the owner account, but in the case of a project (an account), there are no users, which cause and IndexOutOfBoundsException > Can no longer create VPC or other basic resources on projects because of > CLOUDSTACK-7908 > > > Key: CLOUDSTACK-8890 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8890 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Patrick D. >Priority: Blocker > > This does not work for any resource owned by a project. The implemented code > gets the first user of the owner account, but in the case of a project (an > account), there are no users, which cause and IndexOutOfBoundsException > Steps to reproduce: > - Create project > - Try to create VPC in project > - Fails -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8890) Can no longer create VPC or other basic resources on projects because of CLOUDSTACK-7908
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick D. updated CLOUDSTACK-8890: --- Description: Steps to reproduce: - Create project - Try to create VPC in project - Fails This does not work for any resource owned by a project. The implemented code gets the first user of the owner account, but in the case of a project (an account), there are no users, which cause and IndexOutOfBoundsException was: This does not work for any resource owned by a project. The implemented code gets the first user of the owner account, but in the case of a project (an account), there are no users, which cause and IndexOutOfBoundsException > Can no longer create VPC or other basic resources on projects because of > CLOUDSTACK-7908 > > > Key: CLOUDSTACK-8890 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8890 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Patrick D. >Priority: Blocker > > Steps to reproduce: > - Create project > - Try to create VPC in project > - Fails > This does not work for any resource owned by a project. The implemented code > gets the first user of the owner account, but in the case of a project (an > account), there are no users, which cause and IndexOutOfBoundsException -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8890) Can no longer create VPC or other basic resources on projects because of CLOUDSTACK-7908
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick D. updated CLOUDSTACK-8890: --- Description: This does not work for any resource owned by a project. The implemented code gets the first user of the owner account, but in the case of a project (an account), there are no users, which cause and IndexOutOfBoundsException was: This does not work for any resource owned by a project. The implemented code gets the first user of the owner account, but in the case of a project (an account), there are no users, which cause and IndexOutOfBoundsException Steps to reproduce: - Create project - Try to create VPC in project - Fails > Can no longer create VPC or other basic resources on projects because of > CLOUDSTACK-7908 > > > Key: CLOUDSTACK-8890 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8890 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Patrick D. >Priority: Blocker > > This does not work for any resource owned by a project. The implemented code > gets the first user of the owner account, but in the case of a project (an > account), there are no users, which cause and IndexOutOfBoundsException -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9656) Usage does not gather if you have a project with usage
Patrick D. created CLOUDSTACK-9656: -- Summary: Usage does not gather if you have a project with usage Key: CLOUDSTACK-9656 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9656 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Patrick D. It hits a NPE in the Usage Job and cannot continue -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-9656) Usage does not gather if you have a project with usage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick D. reassigned CLOUDSTACK-9656: -- Assignee: Patrick D. > Usage does not gather if you have a project with usage > -- > > Key: CLOUDSTACK-9656 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9656 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Patrick D. >Assignee: Patrick D. > > It hits a NPE in the Usage Job and cannot continue -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9656) Usage does not gather if you have a project with usage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick D. updated CLOUDSTACK-9656: --- Priority: Blocker (was: Major) > Usage does not gather if you have a project with usage > -- > > Key: CLOUDSTACK-9656 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9656 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Patrick D. >Assignee: Patrick D. >Priority: Blocker > > It hits a NPE in the Usage Job and cannot continue -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9677) Swift Storage Policy support for Secondary Storage
Patrick D. created CLOUDSTACK-9677: -- Summary: Swift Storage Policy support for Secondary Storage Key: CLOUDSTACK-9677 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9677 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Reporter: Patrick D. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-9677) Swift Storage Policy support for Secondary Storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick D. reassigned CLOUDSTACK-9677: -- Assignee: Patrick D. > Swift Storage Policy support for Secondary Storage > -- > > Key: CLOUDSTACK-9677 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9677 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Patrick D. >Assignee: Patrick D. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
