[jira] [Created] (CLOUDSTACK-9772) Perform HEAD request to retrieve header information
Marc-Aurèle Brothier created CLOUDSTACK-9772: Summary: Perform HEAD request to retrieve header information Key: CLOUDSTACK-9772 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9772 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Template Affects Versions: 4.5.2.2, 4.9.0.1, 4.8.1.1, 4.9.0, 4.8.0, 4.7.1, 4.7.0, 4.6.2, 4.6.1, 4.6.0, 4.5.2, 4.4.4, 4.5.1, 4.3.2, 4.4.3, 4.4.2, 4.4.1, 4.3.1, 4.5.0, 4.4.0, 4.3.0, 4.2.1, 4.2.0 Reporter: Marc-Aurèle Brothier Assignee: Marc-Aurèle Brothier The function in UriUtils which perform a check for the template file size of an arbitrary URL is sending a `GET` request to only retrieve the response header. A `HEAD` is the correct way of retrieving such information from the response header. This was affecting the restart of a management server since all templates were retrieved when receiving the startup command from the secondary storage sysvm. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CLOUDSTACK-9773) Don't break API output with non-printable characters
Marc-Aurèle Brothier created CLOUDSTACK-9773: Summary: Don't break API output with non-printable characters Key: CLOUDSTACK-9773 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9773 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Reporter: Marc-Aurèle Brothier Assignee: Marc-Aurèle Brothier When sending non printable characters, the response returns them as they were sent, thus potentially breaking the JSON/XML parser on the other side. Best would be to not include such invalid character in the response. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-947) QA - Ability to manage advanced and baic zones in single instance of CS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-947. - Resolution: Fixed This has already been fixed from what I understand. > QA - Ability to manage advanced and baic zones in single instance of CS > > > Key: CLOUDSTACK-947 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-947 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.0 >Reporter: Sudha Ponnaganti >Priority: Minor > Fix For: Future > > > core tasks that need to be done: > - review requirements/FS > - upload test plan/test cases > - get test cases reviewed > - add automation > - upload test results > - review documentation -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-1259) NPE at service shutdown
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-1259. -- Resolution: Invalid Issue closed for the lack of information regarding its necessity and implementation. > NPE at service shutdown > --- > > Key: CLOUDSTACK-1259 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1259 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.0, 4.2.0 >Reporter: Prasanna Santhanam >Priority: Minor > > During shutdown of mgmt service the following NPE is observed: > 2013-02-13 15:53:33,128 ERROR [async.dao.SyncQueueItemDaoImpl] > (AsyncJobMgr-Heartbeat-1:null) Unexpected excetpion, > java.lang.NullPointerException > at > org.apache.log4j.helpers.PatternConverter.spacePad(PatternConverter.java:107) > at > org.apache.log4j.helpers.PatternConverter.format(PatternConverter.java:80) > at org.apache.log4j.PatternLayout.format(PatternLayout.java:506) > at org.apache.log4j.net.SyslogAppender.append(SyslogAppender.java:320) > at > org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251) > at > org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66) > at org.apache.log4j.Category.callAppenders(Category.java:206) > at org.apache.log4j.Category.forcedLog(Category.java:391) > at org.apache.log4j.Category.warn(Category.java:1043) > at com.cloud.utils.db.Transaction.getConnection(Transaction.java:552) > at > com.cloud.utils.db.Transaction.prepareStatement(Transaction.java:461) > at > com.cloud.utils.db.Transaction.prepareAutoCloseStatement(Transaction.java:454) > at > com.cloud.async.dao.SyncQueueItemDaoImpl.getNextQueueItems(SyncQueueItemDaoImpl.java:95) > at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204) > at > org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:689) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:80) > at > com.cloud.utils.db.TransactionContextBuilder.AroundAnyMethod(TransactionContextBuilder.java:37) > at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621) > at > org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610) > at > org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:65) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:622) > at > com.cloud.async.SyncQueueManagerImpl.dequeueFromAny(SyncQueueManagerImpl.java:141) > at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204) > at > com.cloud.async.SyncQueueManagerImpl.dequeueFromAny(SyncQueueManagerImpl.java:141) > at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204) > at > org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:689) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:80) > at > com.cloud.utils.db.TransactionContextBuilder.AroundAnyMethod(TransactionContextBuilder.java:37) > at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(Del
[jira] [Closed] (CLOUDSTACK-1441) Document ApiDiscoverService
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-1441. -- Resolution: Fixed It has already been documented > Document ApiDiscoverService > --- > > Key: CLOUDSTACK-1441 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1441 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Reporter: Jessica Tomechak >Priority: Minor > Labels: api > Fix For: Future > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-2705) [meta-data] Fetching meta-data using the URL http://10.1.1.1/latest/meta-data/<> doesn't work
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Weingärtner closed CLOUDSTACK-2705.
--
Resolution: Cannot Reproduce
Issue closed for the lack of information regarding its necessity and
implementation.
> [meta-data] Fetching meta-data using the URL
> http://10.1.1.1/latest/meta-data/<> doesn't work
> -
>
> Key: CLOUDSTACK-2705
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2705
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Environment: commit # 80a3c0535e0a8ad3edba3713a61d063a176191d8
>Reporter: venkata swamybabu budumuru
>Priority: Minor
>
> Steps to reproduce :
> - As per the 4.0.2 admin guide
> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Admin_Guide/user-data-and-meta-data.html,
> User should be able access meta-data using the link
> http://10.1.1.1/latest/meta-data/ but, it didnt work. The only link
> that works here is : http://10.1.1.1/latest/{metadata type}
> Either we need update our docs or we need to make the above link accessible
> to fetch the meta-data.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-1576) Viewing of the primary storage failed on MS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-1576. -- Resolution: Invalid Issue closed for the lack of information regarding its necessity and implementation. > Viewing of the primary storage failed on MS > > > Key: CLOUDSTACK-1576 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1576 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Fang Wang >Priority: Minor > > with Master branch, on MS UI, there is primary storage deployed. When > clicking to view details, failure window popped up and nothing shows. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-5793) [Automation]: Moving all Services Classes in existing tests to config
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-5793. -- Resolution: Fixed Seems to have already been done > [Automation]: Moving all Services Classes in existing tests to config > - > > Key: CLOUDSTACK-5793 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5793 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, marvin >Reporter: Santhosh Kumar Edukulla >Assignee: Girish Shilamkar >Priority: Minor > > Logging this bug to track moving Service\data class from existing tests to > config. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-6735) Clicking on instances when viewing an instance should not return you to the dashboard
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-6735. -- Resolution: Fixed > Clicking on instances when viewing an instance should not return you to the > dashboard > - > > Key: CLOUDSTACK-6735 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6735 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Website >Affects Versions: 4.3.0 > Environment: OS: Mac OS X > Browser: Chrome 34.0.x >Reporter: Bret Mette >Priority: Trivial > Labels: html > Attachments: 2014-05-20_2332.png > > > Clicking on "instances" in the bread crumbs when viewing an instance returns > you do the dashboard. > Current behavior: Dashboard is displayed. > Expected behavior: Instances list is displayed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-2532) remove bogus self assign to parent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-2532. -- Resolution: Fixed Solved > remove bogus self assign to parent > -- > > Key: CLOUDSTACK-2532 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2532 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.0.2 >Reporter: Dave Brosius >Assignee: Dave Brosius >Priority: Trivial > Attachments: 2532.txt > > > code assigns > this.parent = parent; > even tho there isn't any non-field parent in the constructor... > removed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-2225) Automation - Add Automation for QuickView and Table widgent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-2225. -- Resolution: Unresolved Issue closed for the lack of information regarding its necessity and implementation. > Automation - Add Automation for QuickView and Table widgent > --- > > Key: CLOUDSTACK-2225 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2225 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Sudha Ponnaganti >Priority: Trivial > Fix For: Future > > > Add automation for this feature -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (CLOUDSTACK-2532) remove bogus self assign to parent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner reopened CLOUDSTACK-2532: Assignee: (was: Dave Brosius) > remove bogus self assign to parent > -- > > Key: CLOUDSTACK-2532 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2532 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.0.2 >Reporter: Dave Brosius >Priority: Trivial > Attachments: 2532.txt > > > code assigns > this.parent = parent; > even tho there isn't any non-field parent in the constructor... > removed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (CLOUDSTACK-6735) Clicking on instances when viewing an instance should not return you to the dashboard
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner reopened CLOUDSTACK-6735: > Clicking on instances when viewing an instance should not return you to the > dashboard > - > > Key: CLOUDSTACK-6735 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6735 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Website >Affects Versions: 4.3.0 > Environment: OS: Mac OS X > Browser: Chrome 34.0.x >Reporter: Bret Mette >Priority: Trivial > Labels: html > Attachments: 2014-05-20_2332.png > > > Clicking on "instances" in the bread crumbs when viewing an instance returns > you do the dashboard. > Current behavior: Dashboard is displayed. > Expected behavior: Instances list is displayed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-6735) Clicking on instances when viewing an instance should not return you to the dashboard
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-6735. Resolution: Fixed > Clicking on instances when viewing an instance should not return you to the > dashboard > - > > Key: CLOUDSTACK-6735 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6735 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Website >Affects Versions: 4.3.0 > Environment: OS: Mac OS X > Browser: Chrome 34.0.x >Reporter: Bret Mette >Priority: Trivial > Labels: html > Attachments: 2014-05-20_2332.png > > > Clicking on "instances" in the bread crumbs when viewing an instance returns > you do the dashboard. > Current behavior: Dashboard is displayed. > Expected behavior: Instances list is displayed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-7161) API: The response of an "updateNetworkACLItem" command returns a "createnetworkaclresponse"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-7161. Resolution: Fixed > 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.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-9065) Packaging RPM: Add option for package release version, cleanup and lint
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-9065. Resolution: Fixed > Packaging RPM: Add option for package release version, cleanup and lint > --- > > Key: CLOUDSTACK-9065 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9065 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.6.0 >Reporter: David Amorim Faria >Assignee: David Amorim Faria >Priority: Trivial > > In RPM Packaging, add option for package release version. > Also, code cleanup and some linting. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-2532) remove bogus self assign to parent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-2532. Resolution: Fixed > remove bogus self assign to parent > -- > > Key: CLOUDSTACK-2532 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2532 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.0.2 >Reporter: Dave Brosius >Priority: Trivial > Attachments: 2532.txt > > > code assigns > this.parent = parent; > even tho there isn't any non-field parent in the constructor... > removed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-8781) Superfluous field during VPC creation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-8781. Resolution: Fixed > Superfluous field during VPC creation > - > > Key: CLOUDSTACK-8781 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8781 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.6.0 >Reporter: Nick Livens >Assignee: Nick Livens >Priority: Trivial > Fix For: Future > > Attachments: addVpc.png > > > When creating a VPC, there is a superfluous field "Public Load Balancer > Provider" which is being ignored since the LB Provider is specified in the > VPC offering. This might confuse the users whether they can use a different > LB provider than the one specified in the VPC offering. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-8202) Templates /IOS items order list is not persistent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-8202. Resolution: Fixed > Templates /IOS items order list is not persistent > -- > > Key: CLOUDSTACK-8202 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8202 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, Template >Affects Versions: 4.4.2 > Environment: CS 4.4.2 on CentOS release 6.6 (Final) >Reporter: Adam Kamali >Priority: Trivial > Labels: Template > > When trying to list the templates or ISO images in certain order (let us say > alphabetical or based on OS type) the item list will not be retained after > log off. > Service offering on the other hand (order list works fine) so it's only > Templates / ISO view that is affected. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-1069) Document workaround for: CS and LDAP user validation can't happen simultaneously
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-1069. Resolution: Fixed > Document workaround for: CS and LDAP user validation can't happen > simultaneously > > > Key: CLOUDSTACK-1069 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1069 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.0.0 >Reporter: Jessica Tomechak >Assignee: Hugo Trippaers >Priority: Minor > > Add the following to the section on LDAP Authentication in the Admin Guide: > LDAP User Authentication > Limitation > CloudStack and LDAP user authentication can't happen simultaneously because > the CloudStack user password is MD5 hashed and the LDAP server expects the > password in plain text. To workaround: > 1. Disable password hashing: > a. Open the sharedFunctions.js file located at > /usr/share/cloud/management/webapps/client/ > scripts. > b. Set the following variables to false: > var md5HashedLogin = false; > 2. Open /etc/cloud/management/components.xml file. > 3. Change the following: > > to > > 4. Restart the Cloud Management service. > service cloud-management restart > Now, the users can successfully log in by using either the LDAP credentials > or the CloudStack credentials. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-8817) listFirewallRules response JSON startport/endport not an int
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Weingärtner resolved CLOUDSTACK-8817.
Resolution: Fixed
> listFirewallRules response JSON startport/endport not an int
>
>
> Key: CLOUDSTACK-8817
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8817
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.6.0
>Reporter: René Moser
>Priority: Trivial
>
> h2. Summary
> listFirewallRules returns endpoint and startpoint values as String.
> h2. Excpected results
> {code}
> {
> "count": 1
> "firewallrule": [
> {
> "cidrlist": "0.0.0.0/0",
> "endport": 22,
> "fordisplay": true,
> "id": "126dccd4-ed9a-42a5-bd25-204aab8c8f03",
> "ipaddress": "10.101.0.21",
> "ipaddressid": "c70e7a84-4fa2-40a0-a70d-f64101663f21",
> "networkid": "b0c50de4-015e-4b28-a12a-8955698ebc2a",
> "protocol": "tcp",
> "startport": 22,
> "state": "Active",
> "tags": []
> }
> ]
> }
> {code}
> h2. Actuall results
> {code}
> {
> "count": 1
> "firewallrule": [
> {
> "cidrlist": "0.0.0.0/0",
> "endport": "22",
> "fordisplay": true,
> "id": "126dccd4-ed9a-42a5-bd25-204aab8c8f03",
> "ipaddress": "10.101.0.21",
> "ipaddressid": "c70e7a84-4fa2-40a0-a70d-f64101663f21",
> "networkid": "b0c50de4-015e-4b28-a12a-8955698ebc2a",
> "protocol": "tcp",
> "startport": "22",
> "state": "Active",
> "tags": []
> }
> ]
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-1460) UI : List Storage table has unused column name Actions
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-1460. Resolution: Fixed > UI : List Storage table has unused column name Actions > -- > > Key: CLOUDSTACK-1460 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1460 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.1.0, 4.2.0 > Environment: RHEL 6.3 >Reporter: Parth Jagirdar >Priority: Minor > Attachments: storage column.jpg > > > Either Actions column should be removed from the table Or should actually be > populated by some actions. > A Blank column shouldn't exists. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-2075) List capacity error causes UI to display status overlay
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-2075. Resolution: Fixed > List capacity error causes UI to display status overlay > --- > > Key: CLOUDSTACK-2075 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2075 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.0.0 > Environment: CentOS 6.3 > XenServer >Reporter: Diogo Monteiro >Priority: Minor > > Every time an action is performed on the UI a overlay pops up with the title > "Status" and nothing else. > Looking at the network activity this call seems to be causing the issue: > api?command=listCapacity&response=json > Here is a ss of the bug: > http://diogogmt.files.wordpress.com/2013/04/cloudstack-ui-status-error.png -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-917) QA - review Document vSphere / ESXi patch installation procedure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-917. - Resolution: Fixed This seems to be already fixed. In any case we can reopen it. > QA - review Document vSphere / ESXi patch installation procedure > > > Key: CLOUDSTACK-917 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-917 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Test >Affects Versions: 4.1.0 >Reporter: Sudha Ponnaganti >Priority: Minor > Fix For: Future > > > - review docs for this procedure > - Need to perform the procedure as well -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-4847) UI Error "Failed to delete storage pool on host"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-4847. Resolution: Fixed > UI Error "Failed to delete storage pool on host" > > > Key: CLOUDSTACK-4847 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4847 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 > Environment: [root@csman2-1 ~]# rpm -qa|grep cloudstack > cloudstack-management-4.2.0-1.el6.x86_64 > cloudstack-common-4.2.0-1.el6.x86_64 > cloudstack-awsapi-4.2.0-1.el6.x86_64 > cloudstack-cli-4.2.0-1.el6.x86_64 > cloudstack-usage-4.2.0-1.el6.x86_64 > [root@csman2-1 ~]# > [root@csman2-1 ~]# lsb > lsblklsb_release > [root@csman2-1 ~]# lsb_release -a > LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch > Distributor ID: CentOS > Description: CentOS release 6.4 (Final) > Release: 6.4 > Codename: Final >Reporter: Shanker Balan >Priority: Minor > > Hi, > In CloudStack 4.2, If adding a primary storage fails from the 'Infrastructure > -> Primary Storage -> Add Primary Storage' tab, the UI reports as "Failed to > delete storage pool on host". > The error message should be "Failed to add storage pool on host". > See screenshots: > http://imgur.com/s1g7FBW (Add Primary Storage Screen) > http://imgur.com/MYH1IyB (Error on addition) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-5219) Cannot create a template from an existing Snapshot (Simulator)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-5219. Resolution: Fixed > Cannot create a template from an existing Snapshot (Simulator) > -- > > Key: CLOUDSTACK-5219 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5219 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: David Grizzanti >Assignee: Meghna Kale >Priority: Minor > Attachments: VmSnapshot.jpg, volumeSnapshotSuccess.jpg, > volumeTemplatesFromSnapshot.jpg > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-6009) cloudstack presenting wrong used memory values
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-6009. Resolution: Fixed > cloudstack presenting wrong used memory values > -- > > Key: CLOUDSTACK-6009 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6009 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0, 4.2.0 >Reporter: Rafael Weingärtner >Priority: Minor > > Hi folks, I have sent an e-mail about this issue. And I was hoping to discuss > it before I opened a jira ticket. However, no one seemed to care about it. > So, here is the problem: > There is a wrong value being presented on infrastructure > Hosts. > The data used to present on statistics tab is got from "listHosts" API method: > http://cloudstack.apache.org/docs/api/apidocs-4.2/root_admin/listHosts.html > “listHosts” is the method which returns those values about the host (mem, cpu > and etc). > It returns these values about the host’s memory: > memoryallocated the amount of the host's memory currently allocated > memorytotal the memory total of the host > memoryusedthe amount of the host's memory currently used > The API Doc does not say the metric used on those values. But, I took a look > at the CS source code. And it turned out that the first two values are given > in bytes, while the third one is given in KB and that is why that value looks > so small when presented on statistics tab. It is not being converted in a > proper way on the UI. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-8873) listLoadBalancerRules response JSON publicport/privateport not an int, zonename missing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Weingärtner resolved CLOUDSTACK-8873.
Resolution: Fixed
> listLoadBalancerRules response JSON publicport/privateport not an int,
> zonename missing
> ---
>
> Key: CLOUDSTACK-8873
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8873
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: René Moser
>Priority: Trivial
> Fix For: Future
>
>
> h2. actual
> {code:none}
> {
> "count": 1,
> "loadbalancerrule": [
> {
> "account": "foo",
> "algorithm": "source",
> "cidrlist": "",
> "domain": "STXT",
> "domainid": "3a291b29-b184-4ddc-bdcc-8298c237942e",
> "id": "22bf1066-8bc3-425d-a213-a49431f7b865",
> "name": "foo",
> "networkid": "48df88b1-c2e2-432d-811a-681a2be74dde",
> "privateport": "80",
> "publicip": "1.2.4.5",
> "publicipid": "5d94a86d-0ee9-429a-9a5b-f57da4ee60cb",
> "publicport": "80",
> "state": "Add",
> "tags": [],
> "zoneid": "9e683e49-f4db-4b44-82ad-708689e9c4c8"
> }
> ]
> }
> {code}
> h2. expected
> {code:none}
> {
> "count": 1,
> "loadbalancerrule": [
> {
> "account": "foo",
> "algorithm": "source",
> "cidrlist": "",
> "domain": "STXT",
> "domainid": "3a291b29-b184-4ddc-bdcc-8298c237942e",
> "id": "22bf1066-8bc3-425d-a213-a49431f7b865",
> "name": "foo",
> "networkid": "48df88b1-c2e2-432d-811a-681a2be74dde",
> "privateport": 80,
> "publicip": "1.2.4.5",
> "publicipid": "5d94a86d-0ee9-429a-9a5b-f57da4ee60cb",
> "publicport": 80,
> "state": "Add",
> "tags": [],
> "zoneid": "9e683e49-f4db-4b44-82ad-708689e9c4c8"
> "zonename": "myzone"
> }
> ]
> }
> {code}
> *Note: also check the response for createLoadBalancerRule when fixing this!*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (CLOUDSTACK-8873) listLoadBalancerRules response JSON publicport/privateport not an int, zonename missing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Weingärtner reopened CLOUDSTACK-8873:
> listLoadBalancerRules response JSON publicport/privateport not an int,
> zonename missing
> ---
>
> Key: CLOUDSTACK-8873
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8873
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: René Moser
>Priority: Trivial
> Fix For: Future
>
>
> h2. actual
> {code:none}
> {
> "count": 1,
> "loadbalancerrule": [
> {
> "account": "foo",
> "algorithm": "source",
> "cidrlist": "",
> "domain": "STXT",
> "domainid": "3a291b29-b184-4ddc-bdcc-8298c237942e",
> "id": "22bf1066-8bc3-425d-a213-a49431f7b865",
> "name": "foo",
> "networkid": "48df88b1-c2e2-432d-811a-681a2be74dde",
> "privateport": "80",
> "publicip": "1.2.4.5",
> "publicipid": "5d94a86d-0ee9-429a-9a5b-f57da4ee60cb",
> "publicport": "80",
> "state": "Add",
> "tags": [],
> "zoneid": "9e683e49-f4db-4b44-82ad-708689e9c4c8"
> }
> ]
> }
> {code}
> h2. expected
> {code:none}
> {
> "count": 1,
> "loadbalancerrule": [
> {
> "account": "foo",
> "algorithm": "source",
> "cidrlist": "",
> "domain": "STXT",
> "domainid": "3a291b29-b184-4ddc-bdcc-8298c237942e",
> "id": "22bf1066-8bc3-425d-a213-a49431f7b865",
> "name": "foo",
> "networkid": "48df88b1-c2e2-432d-811a-681a2be74dde",
> "privateport": 80,
> "publicip": "1.2.4.5",
> "publicipid": "5d94a86d-0ee9-429a-9a5b-f57da4ee60cb",
> "publicport": 80,
> "state": "Add",
> "tags": [],
> "zoneid": "9e683e49-f4db-4b44-82ad-708689e9c4c8"
> "zonename": "myzone"
> }
> ]
> }
> {code}
> *Note: also check the response for createLoadBalancerRule when fixing this!*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-8918) [Install] Db Error after install - Unknown column 'iso_id1' in 'field list'
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-8918. -- Resolution: Fixed > [Install] Db Error after install - Unknown column 'iso_id1' in 'field list' > --- > > Key: CLOUDSTACK-8918 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8918 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.6.0 >Reporter: Raja Pullela >Assignee: Daan Hoogland >Priority: Trivial > Fix For: Future > > > Following error is seen in the MS logs > 2015-09-28 07:52:52,756 ERROR [c.c.u.d.Upgrade410to420] (main:null) > migrateDatafromIsoIdInVolumesTable:Exception:Unknown column 'iso_id1' in > 'field list' > com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Unknown column > 'iso_id1' in 'field list' > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:525) > at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) > at com.mysql.jdbc.Util.getInstance(Util.java:386) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052) > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3597) > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3529) > at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1990) > at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2151) > at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2625) > at > com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2119) > at > com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2283) > at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > at > com.cloud.upgrade.dao.Upgrade410to420.migrateDatafromIsoIdInVolumesTable(Upgrade410to420.java:2378) > at > com.cloud.upgrade.dao.Upgrade410to420.performDataMigration(Upgrade410to420.java:110) > at > com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:345) > at > com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:468) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.checkIntegrity(CloudStackExtendedLifeCycle.java:65) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:55) > at > org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:167) > at > org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51) > at > org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:339) > at > org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:143) > at > org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:108) > at > org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:947) > at > org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:482) > at > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContext(DefaultModuleDefinitionSet.java:145) > at > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$2.with(DefaultModuleDefinitionSet.java:122) > at > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:245) > at > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250) > at > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModu
[jira] [Resolved] (CLOUDSTACK-6837) Template order changes are not permanent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-6837. Resolution: Fixed > Template order changes are not permanent > > > Key: CLOUDSTACK-6837 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6837 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.1.1, 4.2.1 > Environment: KVM Environment running CS 4.2.1.1 >Reporter: Nick Sindlinger >Priority: Trivial > Fix For: Future > > > When using the Template Order buttons in the UI the changes can be seen > immediately. However upon leaving the template menu and returning to it you > will find that they have returned to the default order and that your changes > have not take effect. > I can see the API calls taking place in the management logs to reorder all > the templates however the changes are not permanent. > 2014-06-03 10:44:54,981 DEBUG [cloud.api.ApiServlet] (TP-Processor11:null) > ===START=== 69.170.148.179 -- GET > command=updateTemplate&response=json&sessionkey=zuM01Ft9Okr5oCJmcs4%2FVQMKXgo%3D&id=a7668b03-d998-46d2-9044-d9c9f54dd03e&sortKey=14&_=1401810294947 > 2014-06-03 10:44:55,001 DEBUG [cloud.api.ApiServlet] (TP-Processor5:null) > ===END=== 69.170.148.179 -- GET > command=updateTemplate&response=json&sessionkey=zuM01Ft9Okr5oCJmcs4%2FVQMKXgo%3D&id=fd635fc6-599c-41a3-ae88-b4fb9d4d9f0d&sortKey=19&_=1401810294940 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-1025) If an ISO is deleted there is no check if the ISO is actually attached to a guest or not.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-1025. -- Resolution: Fixed > If an ISO is deleted there is no check if the ISO is actually attached to a > guest or not. > - > > Key: CLOUDSTACK-1025 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1025 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO >Affects Versions: 4.0.0 >Reporter: Funs Kessen >Priority: Minor > > It's possible to remove ISO images that are still attached to VMs, this > results in the hypervisor having stale NFS handles and IO errors on the non > existing attached ISO. > for example: > Jan 21 13:33:07 XX tapdisk[6360]: > /var/run/sr-mount/f1c9b60b-516f-9f9d-9c1c-2021505f2c51/238-7-2e48e390-9f0d-31bb-92b2-71ca50d0e349.iso: > __tapdisk_vbd_complete_td_request: 185 messages suppressed > Jan 21 13:33:07 XX tapdisk[6360]: ERROR: errno -116 at > __tapdisk_vbd_complete_td_request: req tap-1.0: read 0x0008 secs @ 0x > - Stale NFS file handle > Jan 21 13:33:07 XX last message repeated 14 times > Jan 21 13:33:07 XX tapdisk[6360]: ERROR: errno -116 at > __tapdisk_vbd_complete_td_request: req tap-1.0: read 0x0008 secs @ 0x0010 > - Stale NFS file handle > Jan 21 13:33:07 XX tapdisk[6360]: > /var/run/sr-mount/f1c9b60b-516f-9f9d-9c1c-2021505f2c51/238-7-2e48e390-9f0d-31bb-92b2-71ca50d0e349.iso: > __tapdisk_vbd_complete_td_request: too many errors, dropped. > Jan 21 13:33:07 XX kernel: end_request: I/O error, dev tdb, sector 0 > Jan 21 13:33:07 XX last message repeated 14 times -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-1177) CloudStack always reports 'invalid username or password' when using IE10
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-1177. -- Resolution: Fixed > CloudStack always reports 'invalid username or password' when using IE10 > > > Key: CLOUDSTACK-1177 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1177 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.0.0 > Environment: Windows 8 (Enterprise) running IE10 >Reporter: Paul Angus >Priority: Minor > > When using IE10 on Windows 8; CloudStack always reports 'invalid username or > password'. Work-a-rounds are - use a different browser Firefox/Chrome etc or > change IE browser mode to IE9, IE8 or IE7. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-1285) UI -Tooltip - Lengthy and inconsistent description among toolips
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-1285. -- Resolution: Fixed > UI -Tooltip - Lengthy and inconsistent description among toolips > > > Key: CLOUDSTACK-1285 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1285 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.1.0, 4.2.0 > Environment: RHEL 6.3 Build#15 >Reporter: Parth Jagirdar >Priority: Minor > Attachments: 3.jpg, 4.jpg > > > "A unique name for the template. This will be visible to users, so choose > something descriptive" ; I think 94 Characters are too much for a ToolTip > representing name. (Screen 4) > And is also inconsistent with other tooltips for names which are more concise > and simple such as "A name for the Zone". (Refer to Screen 4 and compare it > to Screen 3) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-1225) Storage System vm id keeps on increasing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-1225. -- Resolution: Fixed > Storage System vm id keeps on increasing > - > > Key: CLOUDSTACK-1225 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1225 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.0.1 > Environment: Cloud Stack Mgmnt server 4.0.1 :XCP Virtual Machine > running with CentOS release 6.2 (Final)/ 2.6.32-220.el6.x86_64 > Mysql:5.1.67,Host: XCP Host 1.4.90-53341c,Storage: both primary and secondary > is on management server (/export/primary and /export/secondary),ip address: > Every machine is having public ip in the same CIDR. >Reporter: kevin parker >Priority: Minor > Labels: 4.0.1_Candidate > > Its been 3 weeks since i am working on Cloud Stack 4.0.1 > (http://jenkins.cloudstack.org/view/4.0.1/job/build-4.0.1-nonoss-rhel63/) > but couldn't even start system vms..In UI its showing "Creating system VMs > (this may take a while)" but nothing is happening and i also noticed that > select * from cloud.vm_instance\G; is increasing every minute. every > minute-two new id is getting generated with state Expunging. > But In UI it is still trying to create system VM but is actually failing but > there is no way to alert user about this.Will this ever stop? > sample error: > Exception while trying to start secondary storage vm > com.cloud.exception.InsufficientServerCapacityException: Unable to create a > deployment for VM[SecondaryStorageVm|s-91-VM]Scope=interface > com.cloud.dc.DataCenter; id=1 > 2013-02-11 08:15:59,375 WARN [cloud.api.ApiDispatcher] > (Job-Executor-8:job-8) class com.cloud.api.ServerApiException : Fail to start > system vm > this is the log:http://pastebin.com/fE5uUgZt -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-1287) The list table is malformed when scrolling down in the global setting page
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-1287. -- Resolution: Fixed > The list table is malformed when scrolling down in the global setting page > -- > > Key: CLOUDSTACK-1287 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1287 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI > Environment: Master branch >Reporter: Isaac Chiang >Priority: Minor > Labels: ui > Attachments: screenshot-1.jpg > > > When scrolling down the list table in global setting page, the width of the > columns are changed after each "listConfiguration" request -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-1283) UI - Tooltip - Need a clean way to differentiate between Alt Tag's and Tooltips.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-1283. -- Resolution: Fixed > UI - Tooltip - Need a clean way to differentiate between Alt Tag's and > Tooltips. > > > Key: CLOUDSTACK-1283 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1283 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.1.0, 4.2.0 > Environment: RHEL 6.3 Build 15 >Reporter: Parth Jagirdar >Priority: Minor > Attachments: 4 (2).jpg, 4 (3).jpg > > > Please refer to Comments in > https://issues.apache.org/jira/browse/CLOUDSTACK-176 > It may be that these are not Tooltips. (Refer to both screens attached) > But it is definitely within the feature scope; due to fact that a new feature > should not disrupt an existing one. Assuming ALT TAG's were pre existent. > Either we should make them both work in harmony and with clear distinction. > Or should disable 1 features as other is doing the exact same job. > Tagging as Minor. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-2436) Message "You do not have any affinity groups. Please continue to the next step." is shown multiple time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-2436. -- Resolution: Fixed > Message "You do not have any affinity groups. Please continue to the next > step." is shown multiple time > --- > > Key: CLOUDSTACK-2436 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2436 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra >Priority: Minor > Fix For: Future > > Attachments: screenshot-1.jpg > > > please check screenshot for better understanding. > Steps to reproduce > --- > 1-Create two Adv zones > 2-click add instance action button > 3-Select 1st zone , proceed till step 5(till affinity) > 4-By clicking on action button "previous" come back to zone selection page > (step one) > 5-Select second zone and repeat step 2,3,4 > 6-select alternatively zone1/Zone2 and Repeat step 2-4 > Expected > -- > Message "You do not have any affinity groups. Please continue to the next > step." should be displayed only single time > Actual > --- > Message is getting displayed multiple times -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-4778) cloudstack-sysvmadm gives an error on Ubuntu
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-4778. Resolution: Fixed > cloudstack-sysvmadm gives an error on Ubuntu > > > Key: CLOUDSTACK-4778 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4778 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Upgrade >Affects Versions: 4.2.0 >Reporter: Kirk Kosinski >Priority: Minor > Labels: ubuntu, upgrade > > When running the cloudstack-sysvmadm on a Ubuntu management server, the > following error is seen: > /usr/bin/cloudstack-sysvmadm: line 21: /etc/rc.d/init.d/functions: No such > file or directory > The script is trying to source a file (/etc/rc.d/init.d/functions) that does > not exist on Ubuntu 12.04. The script should be updated to work properly on a > Ubuntu management server. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-1442) Document BigSwitch plugin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-1442. -- Resolution: Fixed > Document BigSwitch plugin > - > > Key: CLOUDSTACK-1442 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1442 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Reporter: Jessica Tomechak >Assignee: Kanzhe Jiang >Priority: Minor > Fix For: Future > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-2215) SSVM does not use allocated storage ip range
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-2215. -- Resolution: Fixed > SSVM does not use allocated storage ip range > > > Key: CLOUDSTACK-2215 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2215 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller, Storage Controller >Affects Versions: 4.0.1, 4.0.2, 4.1.0, 4.2.0 > Environment: ACS4.1 as of 04/15/13 - i know its 10 days old, but i've > not seen fixes for this yet. > VMWare vSphere 5.0 with Advanced Network >Reporter: ilya musayev >Assignee: ilya musayev >Priority: Minor > Labels: Network, SSVM > > Create Advanced Network Zone, assign a range of IPs to storage network, also > predefine public range. > The Secondary Storage VM gets the IPs of Public Networks and not whats its > been given. In my example, i've defined two public networks - with very small > ip range (4 on each). I noticed that SSVM took 2 IPs from Public Network A, > and 1 IP from Public Network B. > If you have stringent setup and you need to allocate IPs as designed and > setup firewall rules, one would expect to setup firewall rules on storage ip > range, thinking that SSVM is going to use the IP from that range, however, > instead - it uses public ip range. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-1659) Create Press page for the Apache CMS site
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-1659. -- Resolution: Fixed > Create Press page for the Apache CMS site > - > > Key: CLOUDSTACK-1659 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1659 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Website >Affects Versions: Future >Reporter: Joe Brockmeier >Assignee: Joe Brockmeier >Priority: Minor > Fix For: Future > > > Create a press page with information needed to write about Apache > CloudStack, find contacts, etc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-5225) vmware os type error for redhat 6.x
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-5225. -- Resolution: Fixed > vmware os type error for redhat 6.x > --- > > Key: CLOUDSTACK-5225 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5225 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0 >Reporter: Jijun >Priority: Minor > Labels: vmware > > upload a redhat 6.x iso or template , start a vm using it. check the os type > in vsphere client, the vm os type is other 64 linux. the vmware-tools can not > be installed due to the issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-2439) "Domain" field under login page should be mandatory for the non root accounts.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-2439. Resolution: Fixed > "Domain" field under login page should be mandatory for the non root accounts. > -- > > Key: CLOUDSTACK-2439 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2439 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 >Reporter: manasaveloori >Priority: Minor > Fix For: Future > > > Steps: > Log in as admin > create a domain under root domain.(Eg:/root/test) > Create an account with new domain. > Log out of admin account and log in with new account user without specifying > any domain. > Expected: > For non root accounts having domain_id other than 1 ,the domain field should > be made Mandatory as username and password fields. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-1478) [DOC] Document baremetal kickstart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-1478. -- Resolution: Fixed > [DOC] Document baremetal kickstart > -- > > Key: CLOUDSTACK-1478 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1478 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.3.2 >Reporter: Jessica Tomechak >Priority: Minor > Fix For: Future > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-4440) CloudStack should handle native VMware HA for virtual routers
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-4440. -- Resolution: Fixed > CloudStack should handle native VMware HA for virtual routers > - > > Key: CLOUDSTACK-4440 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4440 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc, Management Server >Affects Versions: 4.5.0 >Reporter: Kirk Kosinski >Assignee: Sateesh Chodapuneedi >Priority: Minor > Labels: ha, networking, virtualrouter, vmware, vsphere > > Currently when a virtual router is rebooted by native VMware HA in vSphere, > it will lose its network and iptables configuration and cause connectivity > problems for VMs. Resolving this requires manual intervention by the > CloudStack administrator; the router must be rebooted, or the network > restarted. > This behavior is not ideal and will prolong downtime caused by an HA event, > and there is no point for the non-functional virtual router to even be > running. CloudStack should handle this situation gracefully by reconfiguring > a virtual router that is successfully rebooted by VMware HA. > In the meantime this limitation should be documented. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-4883) Installing New Memory in XenServer is not Detected
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-4883. -- Resolution: Fixed > Installing New Memory in XenServer is not Detected > -- > > Key: CLOUDSTACK-4883 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4883 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Affects Versions: 4.2.0 > Environment: XenServer 6.2 >Reporter: Soheil Eizadi >Assignee: Abhinandan Prateek >Priority: Minor > > I had a use case where my XenServer ran out of memory and I could not > create any more instances on CloudStack. > I shutdown the XenServer and increased the memory on XenServer and > brought up the Management Server again, but the Management Server still > sees the old values, however the Stats from the Host view show the correct > memory. > -Soheil > > From: Nitin Mehta [nitin.me...@citrix.com] > Sent: Wednesday, October 16, 2013 12:15 PM > To: d...@cloudstack.apache.org > Subject: Re: XenServer Memory Increase Problem > Soheil - I guess this is a bug that addition of new memory isn't detected. > File it if not already done. > I would suggest you to change the DB as of now. Right tables are host and > op_host_capacity (capacity_type=0). > You might have to keep in mind the over provisioning factors you have > kept. See if changing it works. > On 16/10/13 11:56 AM, "Soheil Eizadi" wrote: > >I am running on CloudStack Master 4.3. > > > >I had a use case where my XenServer ran out of memory and I could not > >create any more instances on CloudStack. > >I shutdown the XenServer and increased the memory on XenServer and > >brought up the Management Server again, but the Management Server still > >sees the old values. How is this suppose to work? > > > >As a workaround I assume I could find the database entry for the old RAM > >value and update with the new Memory Total. > > > >Here is some more detailed logs: > > > >The stats for the XenServer from CloudStack: > > > >Total CPU 2 x 2.67 GHz > >CPU Utilized0.08% > >CPU Allocated for VMs 0% > >Memory Total7.03 GB > >Memory Allocated2.50 GB > >Memory Used 3.60 MB > >Network Read558.23 MB > >Network Write 23.20 MB > > > > > >The log of memory problem: > >WARN [o.a.c.alerts] (Job-Executor-5:ctx-3b5b1c95) alertType:: 8 // > >dataCenterId:: 1 // podId:: null // clusterId:: null // message:: Failed > >to deploy Vm with Id: 27, on Host wi > >th Id: null > >INFO [o.a.c.a.c.u.v.DeployVMCmd] (Job-Executor-5:ctx-3b5b1c95) > >com.cloud.exception.InsufficientServerCapacityException: Unable to create > >a deployment for VM[User|test-2]Scope=in > >terface com.cloud.dc.DataCenter; id=1 > >INFO [o.a.c.a.c.u.v.DeployVMCmd] (Job-Executor-5:ctx-3b5b1c95) Unable to > >create a deployment for VM[User|test-2] > >com.cloud.exception.InsufficientServerCapacityException: Unable to create > >a deployment for VM[User|test-2]Scope=interface com.cloud.dc.DataCenter; > >id=1 > >at > >org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.reserveV > >irtualMachine(VMEntityManagerImpl.java:210) > >at > >org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.res > >erve(VirtualMachineEntityImpl.java:198) > >at > >com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java: > >3372) > >at > >com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java: > >2954) > >at > >com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java: > >2940) > >at > >com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorD > >ispatcher.intercept(ComponentInstantiationPostProcessor.java:125) > >at > >org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd. > >java:421) > >at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) > >at > >com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:97) > >at > >org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$1.run(AsyncJ > >obManagerImpl
[jira] [Closed] (CLOUDSTACK-3784) build_asf.sh script need to check if gpg-agent is running
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-3784. -- Resolution: Fixed > build_asf.sh script need to check if gpg-agent is running > - > > Key: CLOUDSTACK-3784 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3784 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.1.0, 4.1.1, 4.2.0 > Environment: rhel 6.4 with ACS 4.1.1 >Reporter: ilya musayev >Assignee: ilya musayev >Priority: Minor > > build_asf.sh will go into continuous loop if gpg-agent is not running. > add a logic to check if gpg-agent is running with --daemon > --use-standard-socket, make this step optional. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-7819) Cannot add tags to project
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-7819. -- Resolution: Invalid > Cannot add tags to project > -- > > Key: CLOUDSTACK-7819 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7819 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.4.1 >Reporter: Bartek Sierakowski >Priority: Trivial > Attachments: man_server.log > > > User(project admin) can not add tag to the project via GUI or API. > GUI error: ! Status Acct [UUID username] does not have permission to operate > within domain id=1 > I management server logs in attached file. > To reproduce: logon as non privileged user, create a project, try to add tag -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-2616) com.mysql.jdbc.exceptions.jdbc4.CommunicationsException error is displayed in management server log after long time of inactive mysql connection
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-2616. -- Resolution: Fixed > com.mysql.jdbc.exceptions.jdbc4.CommunicationsException error is displayed in > management server log after long time of inactive mysql connection > > > Key: CLOUDSTACK-2616 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2616 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0, 4.2.0 > Environment: Build from 4.1 >Reporter: Tetsuya Arita >Priority: Minor > Attachments: db.properties, jdbc-error.txt > > > after a long time of inactivity, the following / attached error message is > displayed in management server. > Then I cannot login to GUI for several times. > after some trials, I can login to GUI. > I attached management server log and db.properties. > this error was duplicated to > https://issues.apache.org/jira/browse/CLOUDSTACK-1805 . > CLOUDSTACK-1805 was not resolved but closed. so I would like to open this > ticket to track. > 2013-05-22 00:56:58,807 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null) > ===START=== 103.2.128.24 -- POST null > 2013-05-22 00:56:58,810 ERROR [cloud.api.ApiServlet] (catalina-exec-1:null) > unknown exception writing api response > com.cloud.utils.exception.CloudRuntimeException: DB Exception on: > com.mysql.jdbc.JDBC4PreparedStatement@65f65296: SELECT domain.id, > domain.parent, domain.name, domain.owner, domain.path, domain.level, > domain.removed, domain.child_count, domain.next_child_seq, domain.state, > domain.network_domain, domain.uuid FROM domain WHERE domain.path = _binary'/' > AND domain.removed IS NULL ORDER BY RAND() LIMIT 1 > at > com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:415) > at > com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:350) > at > com.cloud.utils.db.GenericDaoBase.findOneIncludingRemovedBy(GenericDaoBase.java:860) > at > com.cloud.utils.db.GenericDaoBase.findOneBy(GenericDaoBase.java:871) > at > com.cloud.domain.dao.DomainDaoImpl.findDomainByPath(DomainDaoImpl.java:200) > at sun.reflect.GeneratedMethodAccessor351.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:319) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:80) > at > com.cloud.utils.db.TransactionContextBuilder.AroundAnyMethod(TransactionContextBuilder.java:39) > at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621) > at > org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610) > at > org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:65) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202) > at sun.proxy.$Proxy45.findDomainByPath(Unknown Source) > at > com.cloud.user.DomainManagerImpl.findDomainByPath(DomainManagerImpl.java:175) > at > com.
[jira] [Closed] (CLOUDSTACK-4018) LDAP:able to configure ldap with invalid queryfilter and search base values
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Weingärtner closed CLOUDSTACK-4018.
--
Resolution: Fixed
> LDAP:able to configure ldap with invalid queryfilter and search base values
> ---
>
> Key: CLOUDSTACK-4018
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4018
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.2.0
>Reporter: sadhu suresh
>Priority: Minor
>
> try to provide invalid values for ldap query filter and search base
> after (&(email=%e)) write any string it will accpet like "
> (&(email=%e))sadhu"
> also for searchbase if we enter invalid values its accepting and registering
> successfully
> http://10.147.59.126:8080/client/api?command=ldapConfig&binddn=CN%3Dtest%2CCN%3DUsers%2CDC%3Dhyd-qa%2CDC%3Dcom&bindpass=_&hostname=10.147.38.163&searchbase=CN%3DUsers%2CDC%3Dhyd-qa%2CDC%3Dcom&queryfilter=(%26amp%3B(mail%3D%25e)sadhu&port=389&ssl=false&response=json&sessionkey=gNp53otI4v395R8Blh5OI7j59wE%3D
> { "ldapconfigresponse" : { "ldapconfig" :
> {"hostname":"10.147.38.163","port":"389","ssl":"false","searchbase":"CN=Users,DC=hyd-qa,DC=com","queryfilter":"(&(mail=%e)sadhu","binddn":"CN=test,CN=Users,DC=hyd-qa,DC=com"}
> } }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-5182) Doc issue - "HA-Enabled Virtual Machines" and "HA for Hosts" have same content
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-5182. -- Resolution: Fixed > Doc issue - "HA-Enabled Virtual Machines" and "HA for Hosts" have same content > -- > > Key: CLOUDSTACK-5182 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5182 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.1.0, 4.2.0 >Reporter: Shanker Balan >Priority: Minor > > http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html-single/Admin_Guide/index.html#ha-enabled-vm > http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html-single/Admin_Guide/index.html#ha-for-hosts > 17.3. HA-Enabled Virtual Machines > 17.4. HA for Hosts > Both sections have same content as below: > "The user can specify a virtual machine as HA-enabled. By default, all > virtual router VMs and Elastic Load Balancing VMs are automatically > configured as HA-enabled. When an HA-enabled VM crashes, CloudStack detects > the crash and restarts the VM automatically within the same Availability > Zone. HA is never performed across different Availability Zones. CloudStack > has a conservative policy towards restarting VMs and ensures that there will > never be two instances of the same VM running at the same time. The > Management Server attempts to start the VM on another Host in the same > cluster. > HA features work with iSCSI or NFS primary storage. HA with local storage is > not supported." -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-1570) Document ability to manage basic and advanced zones
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-1570. -- Resolution: Fixed > Document ability to manage basic and advanced zones > --- > > Key: CLOUDSTACK-1570 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1570 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.2.0 >Reporter: Jessica Tomechak >Priority: Minor > Fix For: Future > > > If there are changes to the UI, it could affect documentation. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-5550) UI - Api key and secret key not fully visible in user detail view.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-5550. -- Resolution: Fixed > UI - Api key and secret key not fully visible in user detail view. > -- > > Key: CLOUDSTACK-5550 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5550 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Priority: Minor > Fix For: Future > > Attachments: api-key.png, secret-key.png > > > UI - Api key and secret key not fully visible in user detail view. > Steps to reproduce the problem: > Go to Accounts->select any account and use "View users". > Select any user and generate keys. > Notice that "api key" and "secret key" get truncated in the user detail view. > Attaching screenshots: -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-2535) Cleanup port-profiles that gets created on Nexus switch as part of network cleanup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-2535. -- Resolution: Fixed > Cleanup port-profiles that gets created on Nexus switch as part of network > cleanup > -- > > Key: CLOUDSTACK-2535 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2535 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: pre-4.0.0, 4.0.0 > Environment: Vmware >Reporter: Koushik Das >Assignee: Sateesh Chodapuneedi >Priority: Minor > Fix For: Future > > > Port profiles are not cleaned up when a guest network using it gets removed. > As part of network shutdown all port profiles that got created on the Nexus > switch should be removed. > The same problem is also there for vSwitch and dvSwitch. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-8368) [UI] Grouping/Categorization of Service Offerings
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-8368. -- Resolution: Incomplete Feature request that I did not understand the use and no one seemed to have worked on it > [UI] Grouping/Categorization of Service Offerings > - > > Key: CLOUDSTACK-8368 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8368 > Project: CloudStack > Issue Type: Wish > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jan-Arve Nygård >Priority: Trivial > > The option to group or categorize Service Offerings into groups would be > useful for installation with lots of different service offerings. > This could done as a expandable list view per defined group. Maybe dynamic > groups based on host and storage tags could be an option as well. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-2785) Missing css files : vnmcAsa1000v.css, vnmcNetworkProvider.css, infrastructure.css
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-2785. -- Resolution: Fixed > Missing css files : vnmcAsa1000v.css, vnmcNetworkProvider.css, > infrastructure.css > - > > Key: CLOUDSTACK-2785 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2785 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI > Environment: Master >Reporter: Isaac Chiang >Priority: Minor > Labels: ui > Attachments: Screen Shot 2013-05-31 at 5.29.05 PM.png > > > The following css files are failed to include : vnmcAsa1000v.css, > vnmcNetworkProvider.css, infrastructure.css -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-4071) [UI] - Word 'Default' is misspelled in descripiton of integration.api.port under Global settings.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-4071. Resolution: Fixed > [UI] - Word 'Default' is misspelled in descripiton of integration.api.port > under Global settings. > -- > > Key: CLOUDSTACK-4071 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4071 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 > Environment: Build: CloudPlatform-4.2-335-rhel6.3 >Reporter: Pradeep S >Assignee: Jessica Wang >Priority: Minor > Fix For: Future > > Attachments: api.JPG > > > Default is misspelled as "Defaul" in description of integration.api.port. > Screenshot is attached. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-4055) Windows Server 2012 (64-Bit) being deployed as 'Other OS' type
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-4055. Resolution: Fixed > Windows Server 2012 (64-Bit) being deployed as 'Other OS' type > -- > > Key: CLOUDSTACK-4055 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4055 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 >Reporter: Ahmad Emneina >Priority: Minor > Fix For: Future > > Attachments: win2012_other_os.png > > > Registered a Windows Server 2012 64-bit template in ACS and made sure Windows > Server 2012 (64-Bit) was selected as the OS type when registering the > template, however when we build an instance in CS it creates the OS type in > VMware as Other (64-Bit). Running VMware 5.1.0 and have confirmed that the OS > type is an available option in VMware. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-8873) listLoadBalancerRules response JSON publicport/privateport not an int, zonename missing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Weingärtner closed CLOUDSTACK-8873.
--
Resolution: Fixed
> listLoadBalancerRules response JSON publicport/privateport not an int,
> zonename missing
> ---
>
> Key: CLOUDSTACK-8873
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8873
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: René Moser
>Priority: Trivial
> Fix For: Future
>
>
> h2. actual
> {code:none}
> {
> "count": 1,
> "loadbalancerrule": [
> {
> "account": "foo",
> "algorithm": "source",
> "cidrlist": "",
> "domain": "STXT",
> "domainid": "3a291b29-b184-4ddc-bdcc-8298c237942e",
> "id": "22bf1066-8bc3-425d-a213-a49431f7b865",
> "name": "foo",
> "networkid": "48df88b1-c2e2-432d-811a-681a2be74dde",
> "privateport": "80",
> "publicip": "1.2.4.5",
> "publicipid": "5d94a86d-0ee9-429a-9a5b-f57da4ee60cb",
> "publicport": "80",
> "state": "Add",
> "tags": [],
> "zoneid": "9e683e49-f4db-4b44-82ad-708689e9c4c8"
> }
> ]
> }
> {code}
> h2. expected
> {code:none}
> {
> "count": 1,
> "loadbalancerrule": [
> {
> "account": "foo",
> "algorithm": "source",
> "cidrlist": "",
> "domain": "STXT",
> "domainid": "3a291b29-b184-4ddc-bdcc-8298c237942e",
> "id": "22bf1066-8bc3-425d-a213-a49431f7b865",
> "name": "foo",
> "networkid": "48df88b1-c2e2-432d-811a-681a2be74dde",
> "privateport": 80,
> "publicip": "1.2.4.5",
> "publicipid": "5d94a86d-0ee9-429a-9a5b-f57da4ee60cb",
> "publicport": 80,
> "state": "Add",
> "tags": [],
> "zoneid": "9e683e49-f4db-4b44-82ad-708689e9c4c8"
> "zonename": "myzone"
> }
> ]
> }
> {code}
> *Note: also check the response for createLoadBalancerRule when fixing this!*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-963) [cloud.utils.AnnotationHelper] class java.lang.Stringdoes not have a Table annotation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-963. - Resolution: Fixed > [cloud.utils.AnnotationHelper] class java.lang.Stringdoes not have a Table > annotation > -- > > Key: CLOUDSTACK-963 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-963 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API > Environment: Running on cloudstack - master branch >Reporter: Prasanna Santhanam >Priority: Minor > Fix For: Future > > > whenever a host is added to cloudstack i see the INFO message in the logs > about missing Table annotation: > Related to the recent cloud-utils refactor? The message also doesn't seem to > indicate any INFO, proobably a WARN/ERROR? > 2013-01-11 23:42:39,985 INFO [xen.discoverer.XcpServerDiscoverer] > (1589138432@qtp-1513148157-5:null) Found host acs-qa-h20 ip=10.223.78.20 > product version=6.0.2 > 2013-01-11 23:42:39,993 INFO [cloud.utils.AnnotationHelper] > (1589138432@qtp-1513148157-5:null) > class java.lang.Stringdoes not have a Table annotation > 2013-01-11 23:42:39,993 DEBUG [cloud.network.NetworkManagerImpl] > (1589138432@qtp-1513148157-5:null) Failed to retrive the default label for > storage traffic:zone: 1 hypervisor: XenServer due to:Unable to find the > default physical network with traffic=Storage in the specified zone id > -- > 2013-01-11 23:43:05,008 DEBUG [cloud.api.ApiServlet] > (1513306926@qtp-1513148157-0:null) ===START=== 0:0:0:0:0:0:0:1 -- GET > allocationstate=Enabled&apiKey=W7IfidZg8KCiCjO8X-jB46-BdndysOb1SvbDht3XdDBT99gWfPm6Z36Rk52j0IWrtMJZL6ItPV1AEhCoQMSVRA&command=updateZone&id=7b21e7ea-969d-49d9-8293-5ebea8be4cea&response=json&signature=d7hpLc16eXvooaq%2BQMbaVy4E9qE%3D > 2013-01-11 23:43:05,049 INFO [cloud.utils.AnnotationHelper] > (1513306926@qtp-1513148157-0:null) > class java.lang.Stringdoes not have a Table annotation > 2013-01-11 23:43:05,070 INFO [cloud.configuration.ConfigurationManagerImpl] > (1513306926@qtp-1513148157-0:null) No storage traffic type was specified by > admin, create default storage traffic on physical network 200 with same > configure of management traffic type > -- > 2013-01-11 23:43:46,675 INFO [xen.discoverer.XcpServerDiscoverer] > (1513306926@qtp-1513148157-0:null) Found host acs-qa-h21 ip=10.223.78.140 > product version=6.0.2 > 2013-01-11 23:43:46,681 INFO [cloud.utils.AnnotationHelper] > (1513306926@qtp-1513148157-0:null) > class java.lang.Stringdoes not have a Table annotation -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-1284) UI - Tooltip - Inconsistent tool tip rendering among installation wizards
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-1284. -- Resolution: Fixed > UI - Tooltip - Inconsistent tool tip rendering among installation wizards > - > > Key: CLOUDSTACK-1284 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1284 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.1.0, 4.2.0 > Environment: RHEL 6.3 Build #15 >Reporter: Parth Jagirdar >Priority: Minor > Attachments: 4 (1).jpg > > > ToolTips on Basic Zone installation wizard (The one you get at upon a fresh > install just after Login page) have Heading/Title "Hints" which is > inconsistent with all other tooltips presented in other wizards. (Screen 4) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-1870) Implement a 512 bit salted SHA authenticator/encoder for cloudstack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-1870. Resolution: Fixed > Implement a 512 bit salted SHA authenticator/encoder for cloudstack > --- > > Key: CLOUDSTACK-1870 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1870 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Venkata Siva Vijayendra Bhamidipati >Assignee: Chip Childers >Priority: Minor > Fix For: Future > > > As of now SHA 256 bit salted authentication is the best level of security we > have for users in cloudstack. Implement a SHA 512 bit salted authenticator > for better security. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-2213) russian language select failure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-2213. Resolution: Fixed > russian language select failure > --- > > Key: CLOUDSTACK-2213 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2213 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.0.1, 4.0.2 > Environment: centos 6.4 / kvm >Reporter: Valery Ciareszka >Priority: Minor > Fix For: Future > > Attachments: css_missing.jpg, messages_ru_RU.properties.jpg, > syntaxerror.jpg > > > 1. setup cloudstack management > 2. open it in web browser > 3. choose russian language > 4. try to login > you will see blank page > This issue is caused by 2(at least) problems: > 1. one incorrect translation string variable > message.action.change.service.warning.for.router in > /usr/share/cloud/management/webapps/client/WEB-INF/classes/resources/messages_ru_RU.properties > - there is \n symbol there instead of translated version > 2. missing > /usr/share/cloud/management/webapps/client/css/cloudstack3.ru_RU.css file > I replaced variable message.action.change.service.warning.for.router with > proper text and copied css from > /usr/share/cloud/management/webapps/client/css/cloudstack3.ja.css to get > quick fix -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-1702) Error messages returning numeric ID's in some places instead of UUIDs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-1702. Resolution: Fixed > Error messages returning numeric ID's in some places instead of UUIDs > - > > Key: CLOUDSTACK-1702 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1702 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0, 4.1.0, 4.2.0 >Reporter: Chip Childers >Priority: Minor > > As reported by George here: > http://markmail.org/message/ldmbf2i77tgrai7f -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-4238) invalid username and password when loggin in
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-4238. Resolution: Fixed > invalid username and password when loggin in > > > Key: CLOUDSTACK-4238 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4238 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup, Management Server >Affects Versions: 4.1.0 > Environment: Distributor ID: Ubuntu > Description:Ubuntu 12.04.2 LTS > Release:12.04 > Codename: precise > CloudStack version 4.1.1-1 using the >Reporter: John Cabs >Priority: Minor > > I installed cloudstack 4.1 from scratch with fresh Ubuntu OS. after the > installation, I hit this issue: > 1. first time to login to the UI but it pops-up with "invalid username and > password" > 2. restart the server, went to the UI and again it shows the same error > Alternative Solution: > I went to the logs /var/log/cloudstack/management/management-server.log wait > for the "Admin user enabled" to show and then I tried to login and it was > successful. > 2013-08-12 00:37:05,843 INFO [cloud.server.ManagementServerImpl] > (Timer-1:null) Startup CloudStack management server... > 2013-08-12 00:37:06,012 INFO [cloud.server.ManagementServerImpl] > (Timer-1:null) Admin user enabled > Is there a way to lessen the waiting time? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-1497) Alien VM's are deleted on migration by xenserver.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-1497. -- Resolution: Invalid > Alien VM's are deleted on migration by xenserver. > - > > Key: CLOUDSTACK-1497 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1497 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.0.0 > Environment: Cloudstack 4.0.0 managing xenserver 6.0.2 >Reporter: Javier Ayllon >Priority: Minor > Labels: cloudstack, xenserver > > On management server startup, several messages indicate that alien vm's are > recognized and ignored for vm management. > When trying to migrate an alien vm from one xenserver to another in the same > xenserver cluster, the alien vm is destroyed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-8949) Job timeout caused by improper/inconsistent application of wait parameters
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899768#comment-15899768
]
Rafael Weingärtner commented on CLOUDSTACK-8949:
LOL, I was being cited here, and I was not even aware.
No, it is not a bug. It is more a documentation/standardization issue.
> Job timeout caused by improper/inconsistent application of wait parameters
> --
>
> Key: CLOUDSTACK-8949
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8949
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Hypervisor Controller
>Affects Versions: 4.3.0
> Environment: XenServer 6.2
>Reporter: Ryan Farrington
>Priority: Minor
>
> when creating a "MigrateVolumeCommand" a timeout should be set, this way the
> ACS would not use the default value of parameter "wait". That timeout value
> should be the same as the one used on CitrixResourceBase and its children to
> control the migration of volumes.
> Environment:XenServer 6.2, multiple pre-setup primary storage locations
> that are iscsi SRs in XenServer.
> Summary of actions: Attempt to move a volume that is attached to a
> running instance to another primary storage location.
> What *I* assume should happen:Cloudstack communicates with the host of
> the VM in question and issues a xe vdi-pool-migrate. The command is
> synchronous and doesn't return control back until it has performed the
> action. Cloudstack should know this is a synchronous call and wait the
> configured amount of time for the migration to be performed.
> What *I* think is happening(with some education from Rafael Weingärtner):
> There are multiple timers being set in the process (please reference
> https://issues.apache.org/jira/browse/CLOUDSTACK-8946 for the strangely
> documented and implemented wait parameters) when the timer that should be
> used for all the timeouts is the one that is currently defined as the
> migratewait.
> Here is a full transaction of a 1TB volume migration for instance i-34-311.
> {noformat}
> 2015-10-12 16:41:20,456 DEBUG [c.c.a.t.Request] (Job-Executor-63:ctx-f7b6817d
> ctx-c6b92515) Seq 38-996939857: Sending { Cmd , MgmtId: 42756806312036, via:
> 38(xen-nc-bc2b7), Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.storage.MigrateVolumeCommand":{"volumeId":808,"volumePath":"0cd3ec8c-9fa9-4caf-8380-1a85cdfd0958","pool":{"id":246,"uuid":"VNX_PR5_LUN2003","host":"localhost","path":"/VNX_PR5_LUN2003","port":0,"type":"PreSetup"},"attachedVmName":"i-34-311-VM","wait":0}}]
> }
> 2015-10-12 16:41:20,456 DEBUG [c.c.a.t.Request] (Job-Executor-63:ctx-f7b6817d
> ctx-c6b92515) Seq 38-996939857: Executing: { Cmd , MgmtId: 42756806312036,
> via: 38(xen-nc-bc2b7), Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.storage.MigrateVolumeCommand":{"volumeId":808,"volumePath":"0cd3ec8c-9fa9-4caf-8380-1a85cdfd0958","pool":{"id":246,"uuid":"VNX_PR5_LUN2003","host":"localhost","path":"/VNX_PR5_LUN2003","port":0,"type":"PreSetup"},"attachedVmName":"i-34-311-VM","wait":0}}]
> }
> 2015-10-12 16:41:20,457 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-494:ctx-5aac3f29) Seq 38-996939857: Executing request
> 2015-10-12 17:41:20,457 DEBUG [c.c.a.m.AgentAttache]
> (Job-Executor-63:ctx-f7b6817d ctx-c6b92515) Seq 38-996939857: Waiting some
> more time because this is the current command
> 2015-10-12 18:41:20,457 DEBUG [c.c.a.m.AgentAttache]
> (Job-Executor-63:ctx-f7b6817d ctx-c6b92515) Seq 38-996939857: Waiting some
> more time because this is the current command
> 2015-10-12 18:41:20,457 INFO [c.c.u.e.CSExceptionErrorCode]
> (Job-Executor-63:ctx-f7b6817d ctx-c6b92515) Could not find exception:
> com.cloud.exception.OperationTimedoutException in error code list for
> exceptions
> 2015-10-12 18:41:20,465 WARN [c.c.a.m.AgentAttache]
> (Job-Executor-63:ctx-f7b6817d ctx-c6b92515) Seq 38-996939857: Timed out on
> Seq 38-996939857: { Cmd , MgmtId: 42756806312036, via: 38(xen-nc-bc2b7),
> Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.storage.MigrateVolumeCommand":{"volumeId":808,&
[jira] [Comment Edited] (CLOUDSTACK-8949) Job timeout caused by improper/inconsistent application of wait parameters
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899768#comment-15899768
]
Rafael Weingärtner edited comment on CLOUDSTACK-8949 at 3/7/17 4:58 PM:
LOL, I was being cited here, and I was not even aware.
No, it is not a bug. It is more a documentation/standardization issue.
I will change the information on this and on the other (CLOUDSTACK-8946) to
improvements on code and docs.
was (Author: rafaelweingartner):
LOL, I was being cited here, and I was not even aware.
No, it is not a bug. It is more a documentation/standardization issue.
> Job timeout caused by improper/inconsistent application of wait parameters
> --
>
> Key: CLOUDSTACK-8949
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8949
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Hypervisor Controller
>Affects Versions: 4.3.0
> Environment: XenServer 6.2
>Reporter: Ryan Farrington
>Priority: Minor
>
> when creating a "MigrateVolumeCommand" a timeout should be set, this way the
> ACS would not use the default value of parameter "wait". That timeout value
> should be the same as the one used on CitrixResourceBase and its children to
> control the migration of volumes.
> Environment:XenServer 6.2, multiple pre-setup primary storage locations
> that are iscsi SRs in XenServer.
> Summary of actions: Attempt to move a volume that is attached to a
> running instance to another primary storage location.
> What *I* assume should happen:Cloudstack communicates with the host of
> the VM in question and issues a xe vdi-pool-migrate. The command is
> synchronous and doesn't return control back until it has performed the
> action. Cloudstack should know this is a synchronous call and wait the
> configured amount of time for the migration to be performed.
> What *I* think is happening(with some education from Rafael Weingärtner):
> There are multiple timers being set in the process (please reference
> https://issues.apache.org/jira/browse/CLOUDSTACK-8946 for the strangely
> documented and implemented wait parameters) when the timer that should be
> used for all the timeouts is the one that is currently defined as the
> migratewait.
> Here is a full transaction of a 1TB volume migration for instance i-34-311.
> {noformat}
> 2015-10-12 16:41:20,456 DEBUG [c.c.a.t.Request] (Job-Executor-63:ctx-f7b6817d
> ctx-c6b92515) Seq 38-996939857: Sending { Cmd , MgmtId: 42756806312036, via:
> 38(xen-nc-bc2b7), Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.storage.MigrateVolumeCommand":{"volumeId":808,"volumePath":"0cd3ec8c-9fa9-4caf-8380-1a85cdfd0958","pool":{"id":246,"uuid":"VNX_PR5_LUN2003","host":"localhost","path":"/VNX_PR5_LUN2003","port":0,"type":"PreSetup"},"attachedVmName":"i-34-311-VM","wait":0}}]
> }
> 2015-10-12 16:41:20,456 DEBUG [c.c.a.t.Request] (Job-Executor-63:ctx-f7b6817d
> ctx-c6b92515) Seq 38-996939857: Executing: { Cmd , MgmtId: 42756806312036,
> via: 38(xen-nc-bc2b7), Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.storage.MigrateVolumeCommand":{"volumeId":808,"volumePath":"0cd3ec8c-9fa9-4caf-8380-1a85cdfd0958","pool":{"id":246,"uuid":"VNX_PR5_LUN2003","host":"localhost","path":"/VNX_PR5_LUN2003","port":0,"type":"PreSetup"},"attachedVmName":"i-34-311-VM","wait":0}}]
> }
> 2015-10-12 16:41:20,457 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-494:ctx-5aac3f29) Seq 38-996939857: Executing request
> 2015-10-12 17:41:20,457 DEBUG [c.c.a.m.AgentAttache]
> (Job-Executor-63:ctx-f7b6817d ctx-c6b92515) Seq 38-996939857: Waiting some
> more time because this is the current command
> 2015-10-12 18:41:20,457 DEBUG [c.c.a.m.AgentAttache]
> (Job-Executor-63:ctx-f7b6817d ctx-c6b92515) Seq 38-996939857: Waiting some
> more time because this is the current command
> 2015-10-12 18:41:20,457 INFO [c.c.u.e.CSExceptionErrorCode]
> (Job-Executor-63:ctx-f7b6817d ctx-c6b92515) Could not find exception:
> com.cloud.exception.OperationTimedoutException in error code list for
> exceptions
> 2015-10-12 18:41:20,465 WAR
[jira] [Updated] (CLOUDSTACK-8946) Refactor migratewait global setting
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner updated CLOUDSTACK-8946: --- Priority: Minor (was: Trivial) > Refactor migratewait global setting > --- > > Key: CLOUDSTACK-8946 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8946 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Ryan Farrington >Priority: Minor > > Rafael Weingärtner [rafaelweingart...@gmail.com] suggested in the users > mailing list that the global setting "migratewait" be refactored as in his > words "I think that is a terrible parameter name. We should refactor that". -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (CLOUDSTACK-8949) Job timeout caused by improper/inconsistent application of wait parameters
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899768#comment-15899768
]
Rafael Weingärtner edited comment on CLOUDSTACK-8949 at 3/7/17 4:59 PM:
LOL, I was being cited here, and I was not even aware of.
No, it is not a bug. It is more a documentation/standardization issue.
I will change the information on this and on the other (CLOUDSTACK-8946) to
improvements on code and docs.
was (Author: rafaelweingartner):
LOL, I was being cited here, and I was not even aware.
No, it is not a bug. It is more a documentation/standardization issue.
I will change the information on this and on the other (CLOUDSTACK-8946) to
improvements on code and docs.
> Job timeout caused by improper/inconsistent application of wait parameters
> --
>
> Key: CLOUDSTACK-8949
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8949
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Doc, Hypervisor Controller
>Reporter: Ryan Farrington
>Priority: Minor
> Fix For: Future
>
>
> when creating a "MigrateVolumeCommand" a timeout should be set, this way the
> ACS would not use the default value of parameter "wait". That timeout value
> should be the same as the one used on CitrixResourceBase and its children to
> control the migration of volumes.
> Environment:XenServer 6.2, multiple pre-setup primary storage locations
> that are iscsi SRs in XenServer.
> Summary of actions: Attempt to move a volume that is attached to a
> running instance to another primary storage location.
> What *I* assume should happen:Cloudstack communicates with the host of
> the VM in question and issues a xe vdi-pool-migrate. The command is
> synchronous and doesn't return control back until it has performed the
> action. Cloudstack should know this is a synchronous call and wait the
> configured amount of time for the migration to be performed.
> What *I* think is happening(with some education from Rafael Weingärtner):
> There are multiple timers being set in the process (please reference
> https://issues.apache.org/jira/browse/CLOUDSTACK-8946 for the strangely
> documented and implemented wait parameters) when the timer that should be
> used for all the timeouts is the one that is currently defined as the
> migratewait.
> Here is a full transaction of a 1TB volume migration for instance i-34-311.
> {noformat}
> 2015-10-12 16:41:20,456 DEBUG [c.c.a.t.Request] (Job-Executor-63:ctx-f7b6817d
> ctx-c6b92515) Seq 38-996939857: Sending { Cmd , MgmtId: 42756806312036, via:
> 38(xen-nc-bc2b7), Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.storage.MigrateVolumeCommand":{"volumeId":808,"volumePath":"0cd3ec8c-9fa9-4caf-8380-1a85cdfd0958","pool":{"id":246,"uuid":"VNX_PR5_LUN2003","host":"localhost","path":"/VNX_PR5_LUN2003","port":0,"type":"PreSetup"},"attachedVmName":"i-34-311-VM","wait":0}}]
> }
> 2015-10-12 16:41:20,456 DEBUG [c.c.a.t.Request] (Job-Executor-63:ctx-f7b6817d
> ctx-c6b92515) Seq 38-996939857: Executing: { Cmd , MgmtId: 42756806312036,
> via: 38(xen-nc-bc2b7), Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.storage.MigrateVolumeCommand":{"volumeId":808,"volumePath":"0cd3ec8c-9fa9-4caf-8380-1a85cdfd0958","pool":{"id":246,"uuid":"VNX_PR5_LUN2003","host":"localhost","path":"/VNX_PR5_LUN2003","port":0,"type":"PreSetup"},"attachedVmName":"i-34-311-VM","wait":0}}]
> }
> 2015-10-12 16:41:20,457 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-494:ctx-5aac3f29) Seq 38-996939857: Executing request
> 2015-10-12 17:41:20,457 DEBUG [c.c.a.m.AgentAttache]
> (Job-Executor-63:ctx-f7b6817d ctx-c6b92515) Seq 38-996939857: Waiting some
> more time because this is the current command
> 2015-10-12 18:41:20,457 DEBUG [c.c.a.m.AgentAttache]
> (Job-Executor-63:ctx-f7b6817d ctx-c6b92515) Seq 38-996939857: Waiting some
> more time because this is the current command
> 2015-10-12 18:41:20,457 INFO [c.c.u.e.CSExceptionErrorCode]
> (Job-Executor-63:ctx-f7b6817d ctx-c6b92515) Could not find exception:
> com.cloud.exception.Operation
[jira] [Updated] (CLOUDSTACK-8949) Job timeout caused by improper/inconsistent application of wait parameters
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Weingärtner updated CLOUDSTACK-8949:
---
Affects Version/s: (was: 4.3.0)
Environment: (was: XenServer 6.2)
Fix Version/s: Future
Component/s: Doc
Issue Type: Improvement (was: Bug)
> Job timeout caused by improper/inconsistent application of wait parameters
> --
>
> Key: CLOUDSTACK-8949
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8949
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Doc, Hypervisor Controller
>Reporter: Ryan Farrington
>Priority: Minor
> Fix For: Future
>
>
> when creating a "MigrateVolumeCommand" a timeout should be set, this way the
> ACS would not use the default value of parameter "wait". That timeout value
> should be the same as the one used on CitrixResourceBase and its children to
> control the migration of volumes.
> Environment:XenServer 6.2, multiple pre-setup primary storage locations
> that are iscsi SRs in XenServer.
> Summary of actions: Attempt to move a volume that is attached to a
> running instance to another primary storage location.
> What *I* assume should happen:Cloudstack communicates with the host of
> the VM in question and issues a xe vdi-pool-migrate. The command is
> synchronous and doesn't return control back until it has performed the
> action. Cloudstack should know this is a synchronous call and wait the
> configured amount of time for the migration to be performed.
> What *I* think is happening(with some education from Rafael Weingärtner):
> There are multiple timers being set in the process (please reference
> https://issues.apache.org/jira/browse/CLOUDSTACK-8946 for the strangely
> documented and implemented wait parameters) when the timer that should be
> used for all the timeouts is the one that is currently defined as the
> migratewait.
> Here is a full transaction of a 1TB volume migration for instance i-34-311.
> {noformat}
> 2015-10-12 16:41:20,456 DEBUG [c.c.a.t.Request] (Job-Executor-63:ctx-f7b6817d
> ctx-c6b92515) Seq 38-996939857: Sending { Cmd , MgmtId: 42756806312036, via:
> 38(xen-nc-bc2b7), Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.storage.MigrateVolumeCommand":{"volumeId":808,"volumePath":"0cd3ec8c-9fa9-4caf-8380-1a85cdfd0958","pool":{"id":246,"uuid":"VNX_PR5_LUN2003","host":"localhost","path":"/VNX_PR5_LUN2003","port":0,"type":"PreSetup"},"attachedVmName":"i-34-311-VM","wait":0}}]
> }
> 2015-10-12 16:41:20,456 DEBUG [c.c.a.t.Request] (Job-Executor-63:ctx-f7b6817d
> ctx-c6b92515) Seq 38-996939857: Executing: { Cmd , MgmtId: 42756806312036,
> via: 38(xen-nc-bc2b7), Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.storage.MigrateVolumeCommand":{"volumeId":808,"volumePath":"0cd3ec8c-9fa9-4caf-8380-1a85cdfd0958","pool":{"id":246,"uuid":"VNX_PR5_LUN2003","host":"localhost","path":"/VNX_PR5_LUN2003","port":0,"type":"PreSetup"},"attachedVmName":"i-34-311-VM","wait":0}}]
> }
> 2015-10-12 16:41:20,457 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-494:ctx-5aac3f29) Seq 38-996939857: Executing request
> 2015-10-12 17:41:20,457 DEBUG [c.c.a.m.AgentAttache]
> (Job-Executor-63:ctx-f7b6817d ctx-c6b92515) Seq 38-996939857: Waiting some
> more time because this is the current command
> 2015-10-12 18:41:20,457 DEBUG [c.c.a.m.AgentAttache]
> (Job-Executor-63:ctx-f7b6817d ctx-c6b92515) Seq 38-996939857: Waiting some
> more time because this is the current command
> 2015-10-12 18:41:20,457 INFO [c.c.u.e.CSExceptionErrorCode]
> (Job-Executor-63:ctx-f7b6817d ctx-c6b92515) Could not find exception:
> com.cloud.exception.OperationTimedoutException in error code list for
> exceptions
> 2015-10-12 18:41:20,465 WARN [c.c.a.m.AgentAttache]
> (Job-Executor-63:ctx-f7b6817d ctx-c6b92515) Seq 38-996939857: Timed out on
> Seq 38-996939857: { Cmd , MgmtId: 42756806312036, via: 38(xen-nc-bc2b7),
> Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.storage.MigrateVolumeCommand":{"volumeId":808,"volumePath"
[jira] [Comment Edited] (CLOUDSTACK-8949) Job timeout caused by improper/inconsistent application of wait parameters
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899768#comment-15899768
]
Rafael Weingärtner edited comment on CLOUDSTACK-8949 at 3/7/17 4:59 PM:
LOL, I was being cited here, and I was not even aware.
No, it is not a bug. It is more a documentation/standardization issue.
I will change the information on this and on the other (CLOUDSTACK-8946) to
improvements on code and docs.
was (Author: rafaelweingartner):
LOL, I was being cited here, and I was not even aware of.
No, it is not a bug. It is more a documentation/standardization issue.
I will change the information on this and on the other (CLOUDSTACK-8946) to
improvements on code and docs.
> Job timeout caused by improper/inconsistent application of wait parameters
> --
>
> Key: CLOUDSTACK-8949
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8949
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Doc, Hypervisor Controller
>Reporter: Ryan Farrington
>Priority: Minor
> Fix For: Future
>
>
> when creating a "MigrateVolumeCommand" a timeout should be set, this way the
> ACS would not use the default value of parameter "wait". That timeout value
> should be the same as the one used on CitrixResourceBase and its children to
> control the migration of volumes.
> Environment:XenServer 6.2, multiple pre-setup primary storage locations
> that are iscsi SRs in XenServer.
> Summary of actions: Attempt to move a volume that is attached to a
> running instance to another primary storage location.
> What *I* assume should happen:Cloudstack communicates with the host of
> the VM in question and issues a xe vdi-pool-migrate. The command is
> synchronous and doesn't return control back until it has performed the
> action. Cloudstack should know this is a synchronous call and wait the
> configured amount of time for the migration to be performed.
> What *I* think is happening(with some education from Rafael Weingärtner):
> There are multiple timers being set in the process (please reference
> https://issues.apache.org/jira/browse/CLOUDSTACK-8946 for the strangely
> documented and implemented wait parameters) when the timer that should be
> used for all the timeouts is the one that is currently defined as the
> migratewait.
> Here is a full transaction of a 1TB volume migration for instance i-34-311.
> {noformat}
> 2015-10-12 16:41:20,456 DEBUG [c.c.a.t.Request] (Job-Executor-63:ctx-f7b6817d
> ctx-c6b92515) Seq 38-996939857: Sending { Cmd , MgmtId: 42756806312036, via:
> 38(xen-nc-bc2b7), Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.storage.MigrateVolumeCommand":{"volumeId":808,"volumePath":"0cd3ec8c-9fa9-4caf-8380-1a85cdfd0958","pool":{"id":246,"uuid":"VNX_PR5_LUN2003","host":"localhost","path":"/VNX_PR5_LUN2003","port":0,"type":"PreSetup"},"attachedVmName":"i-34-311-VM","wait":0}}]
> }
> 2015-10-12 16:41:20,456 DEBUG [c.c.a.t.Request] (Job-Executor-63:ctx-f7b6817d
> ctx-c6b92515) Seq 38-996939857: Executing: { Cmd , MgmtId: 42756806312036,
> via: 38(xen-nc-bc2b7), Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.storage.MigrateVolumeCommand":{"volumeId":808,"volumePath":"0cd3ec8c-9fa9-4caf-8380-1a85cdfd0958","pool":{"id":246,"uuid":"VNX_PR5_LUN2003","host":"localhost","path":"/VNX_PR5_LUN2003","port":0,"type":"PreSetup"},"attachedVmName":"i-34-311-VM","wait":0}}]
> }
> 2015-10-12 16:41:20,457 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-494:ctx-5aac3f29) Seq 38-996939857: Executing request
> 2015-10-12 17:41:20,457 DEBUG [c.c.a.m.AgentAttache]
> (Job-Executor-63:ctx-f7b6817d ctx-c6b92515) Seq 38-996939857: Waiting some
> more time because this is the current command
> 2015-10-12 18:41:20,457 DEBUG [c.c.a.m.AgentAttache]
> (Job-Executor-63:ctx-f7b6817d ctx-c6b92515) Seq 38-996939857: Waiting some
> more time because this is the current command
> 2015-10-12 18:41:20,457 INFO [c.c.u.e.CSExceptionErrorCode]
> (Job-Executor-63:ctx-f7b6817d ctx-c6b92515) Could not find exception:
> com.cloud.exception.Operation
[jira] [Resolved] (CLOUDSTACK-8578) listVirtualMachines does not return deleted machines when zone is specified
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] René Moser resolved CLOUDSTACK-8578. Resolution: Fixed > listVirtualMachines does not return deleted machines when zone is specified > --- > > Key: CLOUDSTACK-8578 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8578 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.1.1, 4.2.1, 4.3.1, 4.4.3, 4.5.1 >Reporter: René Moser >Priority: Minor > > A REST API query "command=listVirtualMachines&zoneid=" does not > return destroyed virtual machines in the response. > There was a similar issue reported in #284 and fixed but in accidentally > re-implemented in > https://github.com/apache/cloudstack/commit/c167ad45e3480160c086e5bf532a72d9704c072b#diff-20f157170d9a50e3010375d071fd4db5R747 > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (CLOUDSTACK-8873) listLoadBalancerRules response JSON publicport/privateport not an int, zonename missing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
René Moser reopened CLOUDSTACK-8873:
Assignee: René Moser
> listLoadBalancerRules response JSON publicport/privateport not an int,
> zonename missing
> ---
>
> Key: CLOUDSTACK-8873
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8873
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: René Moser
>Assignee: René Moser
>Priority: Trivial
> Fix For: Future
>
>
> h2. actual
> {code:none}
> {
> "count": 1,
> "loadbalancerrule": [
> {
> "account": "foo",
> "algorithm": "source",
> "cidrlist": "",
> "domain": "STXT",
> "domainid": "3a291b29-b184-4ddc-bdcc-8298c237942e",
> "id": "22bf1066-8bc3-425d-a213-a49431f7b865",
> "name": "foo",
> "networkid": "48df88b1-c2e2-432d-811a-681a2be74dde",
> "privateport": "80",
> "publicip": "1.2.4.5",
> "publicipid": "5d94a86d-0ee9-429a-9a5b-f57da4ee60cb",
> "publicport": "80",
> "state": "Add",
> "tags": [],
> "zoneid": "9e683e49-f4db-4b44-82ad-708689e9c4c8"
> }
> ]
> }
> {code}
> h2. expected
> {code:none}
> {
> "count": 1,
> "loadbalancerrule": [
> {
> "account": "foo",
> "algorithm": "source",
> "cidrlist": "",
> "domain": "STXT",
> "domainid": "3a291b29-b184-4ddc-bdcc-8298c237942e",
> "id": "22bf1066-8bc3-425d-a213-a49431f7b865",
> "name": "foo",
> "networkid": "48df88b1-c2e2-432d-811a-681a2be74dde",
> "privateport": 80,
> "publicip": "1.2.4.5",
> "publicipid": "5d94a86d-0ee9-429a-9a5b-f57da4ee60cb",
> "publicport": 80,
> "state": "Add",
> "tags": [],
> "zoneid": "9e683e49-f4db-4b44-82ad-708689e9c4c8"
> "zonename": "myzone"
> }
> ]
> }
> {code}
> *Note: also check the response for createLoadBalancerRule when fixing this!*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (CLOUDSTACK-4603) Ability to configure a syslog destination for a virtual router / systemvm
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner reopened CLOUDSTACK-4603: Reopened per thinktwo (Jan-Arve Nygård) request > Ability to configure a syslog destination for a virtual router / systemvm > - > > Key: CLOUDSTACK-4603 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4603 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM, Virtual Router >Reporter: Roeland Kuipers > > In order to improve monitoring and insights in a system / routervm. > We like to see an option to send logging from system / routing vm's to a > syslog server. > Destination preferably configurable per network and globally. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-9634) fix marvin test test_router_dhcp_opts failure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-9634. Resolution: Fixed > fix marvin test test_router_dhcp_opts failure > - > > Key: CLOUDSTACK-9634 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9634 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.8.0, 4.9.0, 4.10.0.0 >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: 4.8.1, 4.10.0.0, 4.9.2.0 > > > test_router_dhcp_opts has been failing on the smoke tests on 4.8 ,4.9, 4.10. > This is new test added as part of fix for "CLOUDSTACK-9598: wrong defaut > gateway for the nic in non-default network" > Marvin VirtualMachine object's nic attribute, does not store nics in any > particular order. test made the assumption the nic[0] is default nic of the > virtual machine which may not necessarily true all the time > nic objects 'isdefault' attribute can be used to verify if the nic is default > nic. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-9509) KVM Hosts connect with no storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-9509. Resolution: Fixed > KVM Hosts connect with no storage > - > > Key: CLOUDSTACK-9509 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9509 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.8.1, 4.10.0.0, 4.9.1.0 > > > KVM hosts on shared storage failure was accepted by mgmt server with the > host state as Up, even though there was no primary/shared storage available > on it. They fail the ModifyStoragePoolCommand, but the management server > continues on with adding SSH keys and marking them as up. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-9635) fix test_privategw_acl.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-9635. Resolution: Fixed > fix test_privategw_acl.py > - > > Key: CLOUDSTACK-9635 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9635 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.8.0, 4.9.0, 4.10.0.0 >Reporter: Murali Reddy > Fix For: 4.8.1, 4.10.0.0, 4.9.2.0 > > > Marvin test cases in test suite test_privategw_acl.py fail intermittently > with error 'createprivategateway failed, due to: errorCode: 431, > errorText:Network with vlan vlan://549 already exists in zone 1' > Test cases use a VLAN from the zone VLAN range, to create VPC private > gateway. But the VPC private gateway implementation does not book keep the > info on op_dc_vent_alloc. So when test case create network they end up using > same VLAN, resulting failure of createVpcPrivateGateway -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-350) Storage stats in admin dashboard are not pragmatic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-350. --- Resolution: Fixed > Storage stats in admin dashboard are not pragmatic > -- > > Key: CLOUDSTACK-350 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-350 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: David Nalley >Priority: Minor > Attachments: snapshot7.png > > > UI reports storage seemingly at the byte level, with numbers like this: > 105689374720 > Why aren't there units, and if you must use really low level units like > bytes, at least add commas to make it a bit more easily parseable. That said > bytes is a really non-practical unit of measure for a cloud - MB, or even GB > - and in some cases TB would be far more useful. > I'll attach a screenshot -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-212) Switch java package structure from com.cloud to org.apache
[ https://issues.apache.org/jira/browse/CLOUDSTACK-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-212. --- Resolution: Fixed > Switch java package structure from com.cloud to org.apache > -- > > Key: CLOUDSTACK-212 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-212 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: pre-4.0.0 >Reporter: Chip Childers >Assignee: Dharmesh Kakadia >Priority: Minor > Fix For: Future > > > Since the project has moved over to ASF, I'd like to suggest that we move > from com.cloud to org.apache for the java package structure of our modules. > If there is agreement, we can take this up after 4.0 is out the door. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-9598) wrong defaut gateway in guest VM with nics in isolated and a shared network
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Weingärtner resolved CLOUDSTACK-9598.
Resolution: Fixed
> wrong defaut gateway in guest VM with nics in isolated and a shared network
> ---
>
> Key: CLOUDSTACK-9598
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9598
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Murali Reddy
> Fix For: 4.8.1, 4.10.0.0, 4.9.1.0
>
>
> When a guest instance is created with nic's in a isolated network and a
> shared network (with just DHCP and DNS), with isolated network as default
> network, DHCP lease on shared network from the shared network VR has wrong
> gateway. gateway is pointed to the virtual router IP.
> /etc/cloudstack/dhcpentry.json in shared network VR will have default gateway
> set to 0.0.0.0
> root@r-11-VM:~# cat /etc/cloudstack/dhcpentry.json
> {
> "10.6.9.165": {
> "default_entry": false,
> "default_gateway": "0.0.0.0",
> "dns_adresses": "10.1.1.1",
> "host_name": "VM-fce34d73-dc99-4559-b077-64711509907a",
> "ipv4_adress": "10.6.9.165",
> "ipv6_duid": "00:03:00:01:06:5a:da:00:00:6a",
> "mac_address": "06:5a:da:00:00:6a",
> "type": "dhcpentry"
> },
> "id": "dhcpentry"
> DhcpCommand network element command sent from the management server is like
> below with "defaultRouter":"0.0.0.0"
> 2016-11-15 19:15:29,319 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-25:ctx-a9aca0bb job-69/job-70 ctx-82c3fd7e)
> (logid:6ca37cdb) Seq 2-4650811040190170578: Sending { Cmd , MgmtId:
> 7150818625286, via: 2(trl-202-k-cs49-mreddy-kvm2), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.routing.DhcpEntryCommand":{"vmMac":"06:5a:da:00:00:6a","vmIpAddress":"10.6.9.165","vmName":"VM-fce34d73-dc99-4559-b077-64711509907a","defaultRouter":"0.0.0.0","defaultDns":"10.1.1.1","duid":"00:03:00:01:06:5a:da:00:00:6a","isDefault":false,"executeInSequence":false,"accessDetails":{"zone.network.type":"Advanced","router.guest.ip":"10.6.9.164","router.ip":"169.254.2.18","router.name":"r-11-VM"},"wait":0}}]
> }
> NIC details in the DB for the nic in the shared network has correct gateway.
> Gateway is set to 0.0.0.0, for every non-default nic [1]
> In case where shared network is non default network, then guest VM will end
> up treating VR in the shared network as gateway instead of actual shared
> network gateway.
> [1]
> https://github.com/apache/cloudstack/blob/4.9/server/src/com/cloud/network/router/CommandSetupHelper.java#L224
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-9540) createPrivateGateway create private network does not create proper VLAN network on XenServer
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-9540. Resolution: Fixed > createPrivateGateway create private network does not create proper VLAN > network on XenServer > > > Key: CLOUDSTACK-9540 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9540 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.8.0, 4.9.0, 4.10.0.0 >Reporter: Murali Reddy > Fix For: 4.8.1, 4.10.0.0, 4.9.2.0 > > > While running the smoke tests in test_privategw_acl.py its observed, that > due to bug in the test suite (CLOUDSTACK-9511), same VLAN ends being used > across four test cases. createPrivateGateway API which creates a VLAN network > on the XenServer, skips creating the network when it exists on the XenServer > hosts. But PIF never gets attached to the bridge, hence traffic from private > gateway never leaves the host. > Private gateway tests consistently failed in smoke tests on the XenServer, as > you can see in https://github.com/apache/cloudstack/pull/1692 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-535) Virtual Router DNS is restricted to UDP only
[ https://issues.apache.org/jira/browse/CLOUDSTACK-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-535. --- Resolution: Fixed > Virtual Router DNS is restricted to UDP only > > > Key: CLOUDSTACK-535 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-535 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.0.0 >Reporter: Tamas Monos >Priority: Minor > > Issue: > When a new router VM is generated and started the initial firewall rules > allow only port 53 on UDP. Router VMs should allow port 53 on TCP is well due > to longer resolutions can switch to TCP for example cPanel. The cPanel > installer will not run if it cannot resolve over TCP. > Workaround: > Login to the router VM and execute: > iptables -A INPUT -i eth0 -p tcp -m tcp --dport 53 -j ACCEPT > Resolution: > I'm not sure where the initial firewall rules are coming from (maybe systemVM > ISO?) but there this new rule should be added. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-7633) Most init scripts provide an invalid name for LSB header "Provides"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Weingärtner resolved CLOUDSTACK-7633.
Resolution: Fixed
> Most init scripts provide an invalid name for LSB header "Provides"
> ---
>
> Key: CLOUDSTACK-7633
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7633
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Packaging
>Affects Versions: 4.2.0, 4.3.0, 4.4.0, Future
>Reporter: Vincent Bernat
>Priority: Minor
>
> Many init scripts have an LSB "Provides" header like this:
> {code}
> # Provides: cloud agent
> {code}
> This means that this script provides "cloud" and "agent". This needs to be
> fixed to say "cloud-agent" instead.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-3054) modify cloud-set-guest-sshkey.in initscript to handle SELinux configuration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-3054. Resolution: Fixed > modify cloud-set-guest-sshkey.in initscript to handle SELinux configuration > --- > > Key: CLOUDSTACK-3054 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3054 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Environment: CentOS 6.4 VM >Reporter: Ian Service >Priority: Minor > > https://reviews.apache.org/r/11934/ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-698) Modify build to generate the LICENSE and NOTICE files
[ https://issues.apache.org/jira/browse/CLOUDSTACK-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-698. --- Resolution: Fixed Fix Version/s: (was: Future) > Modify build to generate the LICENSE and NOTICE files > - > > Key: CLOUDSTACK-698 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-698 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Reporter: Chip Childers >Assignee: Chip Childers >Priority: Minor > > We need to modify the build to generate the LICENSE and NOTICE files, using > the latest changes from the Apache Whisker project. > We also need to ensure that the manually completed change to resolve > CLOUDSTACK-697 is included in the 4.1.0 fix. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-7405) ec2 metadata service requires trailing / for listing items
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-7405. Resolution: Fixed > ec2 metadata service requires trailing / for listing items > -- > > Key: CLOUDSTACK-7405 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7405 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: AWSAPI >Reporter: Scott Moser >Priority: Minor > > This came to me through bug reports to cloud-init: > https://bugs.launchpad.net/cloud-init/+bug/1356855 > and > https://bugs.launchpad.net/cloud-init/+bug/1311107 > Apparently, the EC2 metadata service that cloudstack provides returns a 404 > for "dictionary" entries that do not have a trailing /. > Example (as reported to me, i have no first hand experience). > $ wget http://169.254.169.254/latest/meta-data ; > 404 > $ wget http://169.254.169.254/latest/meta-data/ > $ cat index.html ; echo > ami-id > ami-launch-index > ami-manifest-path > block-device-mapping/ > hostname > instance-action > instance-id > instance-type > local-hostname > local-ipv4 > mac > metrics/ > network/ > placement/ > profile > public-hostname > public-ipv4 > public-keys/ > reservation-id > security-groups > services/ > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-8976) Sorting of security groups
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-8976. Resolution: Fixed Fix Version/s: (was: Future) > Sorting of security groups > -- > > Key: CLOUDSTACK-8976 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8976 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.2 >Reporter: CS User >Priority: Minor > > Within the instance creation wizard, when using a basic zone with a large > number of security groups, it can be difficult for the user to select the > required group when presented with a long list. > Currently the list not ordered. It would be better if the groups were sorted > alphabetically. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-9533) gateway of public IP is not handled correctly when parsing the cmd_line.json to create ips.json databag
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Weingärtner resolved CLOUDSTACK-9533.
Resolution: Fixed
> gateway of public IP is not handled correctly when parsing the cmd_line.json
> to create ips.json databag
> ---
>
> Key: CLOUDSTACK-9533
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9533
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.9.0, 4.10.0.0
>Reporter: Murali Reddy
> Fix For: 4.8.1, 4.10.0.0, 4.9.2.0
>
>
> gateway of public IP is not handled correctly when parsing the cmd_line.json
> to create ips.json databag
> In systemvm/patches/debian/config/opt/cloud/bin/merge.py
> processCLItem following piece of code sets the local gateway as public
> interface/ip gateway, as there is no check on the network type.
>if('localgw' in self.qFile.data['cmd_line']):
> dp['gateway'] = self.qFile.data['cmd_line']['localgw']
> for public network type, it should be read from cmd_line.gateway
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-272) Delete failure message for network with a VM is not informative
[
https://issues.apache.org/jira/browse/CLOUDSTACK-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Weingärtner closed CLOUDSTACK-272.
-
Resolution: Fixed
Fix Version/s: (was: Future)
> Delete failure message for network with a VM is not informative
> ---
>
> Key: CLOUDSTACK-272
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-272
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: pre-4.0.0
>Reporter: David Noland
>Priority: Minor
>
> The following delete network API call is failing because there is a VM
> running in the network:
> http://localhost:8080/client/api?command=deleteNetwork&id=ba5a58e8-a803-4ab1-9b1e-5389e03e2d58&response=json&sessionkey=VEubeThTbte%2FufpplNGM6NYHWlQ%3D&_=1349483483336
> The popup states: "Failed to delete network", which is coming from the JSON
> response:
> { "queryasyncjobresultresponse" :
> {"accountid":"d0236100-db1a-4262-939b-d5a235e87d35","userid":"9cffba2c-54c9-4fde-8b5d-7e62c01eb9ee","cmd":"com.cloud.api.commands.DeleteNetworkCmd","jobstatus":2,"jobprocstatus":0,"jobresultcode":530,"jobresulttype":"object","jobresult":{"errorcode":530,"errortext":"Failed
> to delete
> network"},"created":"2012-10-06T00:25:43+","jobid":"f3ee91a6-c4ca-48fb-bff5-8d2f5eee7a9d"}
> }
> This gives the user too little information on why the network deletion
> failed. The error message should state that the network could not be deleted
> because there are VM(s) still running in the network.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-371) When naming physical networks in the zone wizard, special characters like () break the wizard
[ https://issues.apache.org/jira/browse/CLOUDSTACK-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-371. --- Resolution: Fixed > When naming physical networks in the zone wizard, special characters like () > break the wizard > - > > Key: CLOUDSTACK-371 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-371 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.0.0 > Environment: Tested with ACS build 733 on Centos 6,3 in > Chrome/Firefox/IE >Reporter: kelcey damage >Priority: Minor > > When naming physical networks in the zone wizard, special characters like () > break the wizard. > This will cause further pages in the wizard to render blank. Also attempting > to go back and fix the name will cause traffic tokens to get frozen and > corrupt, as well as fail to re-draw correctly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-245) VPC ACLs are not stored and programmed consistently
[ https://issues.apache.org/jira/browse/CLOUDSTACK-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-245. - Resolution: Unresolved Assignee: (was: Kishan Kavala) Fix Version/s: (was: Future) > VPC ACLs are not stored and programmed consistently > --- > > Key: CLOUDSTACK-245 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-245 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: pre-4.0.0 >Reporter: David Noland >Priority: Minor > > If user specifies 1.2.3.4/24 as the CIDR for an ACL the firewall rule is > being programmed as 1.2.3.0/24. Both CIDRs are correct, but it's inconsistent > to store one thing in the database and program the firewall using another > rule. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-429) Agent rebalancing is broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-429. - Resolution: Fixed > Agent rebalancing is broken > --- > > Key: CLOUDSTACK-429 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-429 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server >Affects Versions: pre-4.0.0 > Environment: KVM, Cloudstack 3.0.2 >Reporter: Roland Kool >Priority: Minor > > After setting agent.lb.enabled to true and restarting my management servers, > the agent rebalancing gets stuck after trying to rebalance the first 16 > machines. > The error from the management log is: > 2012-07-05 15:09:43,643 DEBUG [agent.manager.ClusteredAgentManagerImpl] > (AgentTaskPool-6:null) Rebalancing host id=9 > 2012-07-05 15:09:43,646 WARN [agent.manager.ClusteredAgentManagerImpl] > (AgentTaskPool-6:null) Unable to rebalance host id=9 > java.lang.ClassCastException: com.cloud.agent.manager.ClusteredAgentAttache > cannot be cast to com.cloud.agent.manager.ClusteredDirectAgentAttache > at > com.cloud.agent.manager.ClusteredAgentManagerImpl.startRebalance(ClusteredAgentManagerImpl.java:1014) > at > com.cloud.agent.manager.ClusteredAgentManagerImpl.rebalanceHost(ClusteredAgentManagerImpl.java:905) > at > com.cloud.agent.manager.ClusteredAgentManagerImpl$RebalanceTask.run(ClusteredAgentManagerImpl.java:1070) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-438) Custom DNS entries
[ https://issues.apache.org/jira/browse/CLOUDSTACK-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-438. - Resolution: Fixed > Custom DNS entries > -- > > Key: CLOUDSTACK-438 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-438 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, UI >Reporter: Andreas Fuchs >Assignee: Murali Reddy >Priority: Minor > > A possibility to add custom DNS entries to the automgically generated would > be great. > Also LB services should get an automatically generated entry for the LB > service name. > We understand that this can be done on the "upstream" DNS but as this often > is not a multinant DNS it would be really cool if each tenant can add DNS > entries to his account or project. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (CLOUDSTACK-458) xen:snapshots:Storage gc fail to clean the failed snapshot images from secondarystorage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner closed CLOUDSTACK-458. - Resolution: Fixed Fix Version/s: (was: Future) > xen:snapshots:Storage gc fail to clean the failed snapshot images from > secondarystorage > --- > > Key: CLOUDSTACK-458 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-458 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot >Affects Versions: 4.0.0 >Reporter: deepti dohare >Assignee: edison su >Priority: Minor > > After storage cleanup still see the snapshot image oin the secondary storage > snapshot folder for the failure snapshots > In this case : next hourly snapshot was successful but previous snapshot was > stuck in backingupstate > Steps: > *** > 1.Deploy a VM and set concurrent.snapshots.threshold.per host to 2 > 2.Once its successful,schedule the recurring snapshots hourly on the root > volume and also perform snapshot on other instance volumes > 3.configure the storage.cleanup.interval to 150 and restart the > cloud-management service while hourly snapshot on root volume is in progress > 4.check the secondary storage snapshot folder > 5. after few hours,delete all the created snapshots from Cloudstack and check > the storage cleanup thread cleansup all the snapshots form the snapshot > folder or not. > Actual result: > step4:snapshots job failed and secondary storage has copied image file and > database shows snapshot job status as "Backing UP" > next hourly snapshot was successful. > Step5: > It cleans all the successful hourly snapshot images except the failed > snapshot image files > Expected result: > ** > Storage GC should clean all image files exists in the snapshot folder when we > delete the all the snapshots from Cloud stack. > also when previous hourly snapshot stuck in backing up state ,the next hourly > snapshot is successful,Cloudstack should intelligent enough to update the > status of failure jobs properly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-582) Cannot perform password reset for Windows instances on VMWare
[
https://issues.apache.org/jira/browse/CLOUDSTACK-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Weingärtner resolved CLOUDSTACK-582.
---
Resolution: Fixed
> Cannot perform password reset for Windows instances on VMWare
> -
>
> Key: CLOUDSTACK-582
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-582
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Hypervisor Controller, Network Devices, VMware
>Affects Versions: pre-4.0.0
> Environment: CentOS6 2.6.32-279.14.1.el6.x86_64
> ESXi 5.1
>Reporter: Bill Rich
>Priority: Minor
>
> When I attempt password reset on a Windows instance on ESXi, the job fails
> because the management server is attempting to connect to the routing vm on
> the link local ip address which is not used for VMWare system VMs. Below are
> the relevant log entries from the management log.
> 2012-12-04 12:35:37,651 DEBUG [agent.transport.Request]
> (Job-Executor-81:job-268) Seq 2-1745947325: Executing: { Cmd , MgmtId:
> 161332719936, via: 2, Ver: v1, Flags: 100101,
> [{"routing.SavePasswordCommand":{"password":"nI9eufdes","vmIpAddress":"198.23.64.87","vmName":"78764853-99a4-40a4-b299-43748f0546b8","accessDetails":{"zone.network.type":"Basic","router.ip":"0.0.0.0","router.name":"r-6-VM"},"wait":0}}]
> }
> 2012-12-04 12:35:37,651 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-306:null) Seq 2-1745947325: Executing request
> 2012-12-04 12:35:37,652 INFO [vmware.resource.VmwareResource]
> (DirectAgent-306:10.54.227.25) Executing resource SavePasswordCommand.
> vmName: 78764853-99a4-40a4-b299-43748f0546b8, vmIp: 198.23.64.87, password:
> n
> 2012-12-04 12:35:37,652 DEBUG [vmware.resource.VmwareResource]
> (DirectAgent-306:10.54.227.25) Use router's private IP for SSH control. IP :
> 0.0.0.0
> 2012-12-04 12:35:37,652 DEBUG [vmware.resource.VmwareResource]
> (DirectAgent-306:10.54.227.25) Run command on domain router 0.0.0.0,
> /root/savepassword.sh -v 198.23.64.87 -p n
> 2012-12-04 12:35:37,652 ERROR [vmware.resource.VmwareResource]
> (DirectAgent-306:10.54.227.25) SavePasswordCommand failed due to Exception:
> java.io.IOException
> Message: There was a problem while connecting to 0.0.0.0:3922
> java.io.IOException: There was a problem while connecting to 0.0.0.0:3922
> at com.trilead.ssh2.Connection.connect(Connection.java:791)
> at
> com.cloud.hypervisor.vmware.resource.SshHelper.sshExecute(SshHelper.java:127)
> at
> com.cloud.hypervisor.vmware.resource.SshHelper.sshExecute(SshHelper.java:32)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:1780)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:339)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:187)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> Caused by: java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:191)
> at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
> at java.net.Socket.connect(Socket.java:546)
> at
> com.trilead.ssh2.transport.TransportManager.establishConnection(TransportManager.java:341)
> at
> com.trilead.ssh2.transport.TransportManager.initialize(Trans
[jira] [Resolved] (CLOUDSTACK-561) createNetwork can block for long periods causing clients to time out when called at certain times
[ https://issues.apache.org/jira/browse/CLOUDSTACK-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-561. --- Resolution: Fixed > createNetwork can block for long periods causing clients to time out when > called at certain times > - > > Key: CLOUDSTACK-561 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-561 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.0.0 > Environment: KVM or Xen (maybe all environments) >Reporter: Marcus Sorensen >Priority: Minor > > createNetwork can block for minutes if called when VPC router is being > created (maybe non-vpc router too?), whether it's the first time or if VPC > router is deleted. If I call createNetwork any time after the new VPC router > is running it's fine, wether the router is stopped, starting, or running > state. If I destroy the router then createNetwork also still works instantly, > but when router is recreating and in 'starting' state, createNetwork blocks > until this is done. Since it's a sync call this causes trouble for us, and > we've worked around it in our client by never calling createNetwork if the > VPC router is not 'running', but since createNetwork is sync we should really > either fix the block or return 'try again later' if this state is found. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-486) Clicking UI notifications for System VM or Virtual Router opens Instances page
[ https://issues.apache.org/jira/browse/CLOUDSTACK-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-486. --- Resolution: Fixed > Clicking UI notifications for System VM or Virtual Router opens Instances page > -- > > Key: CLOUDSTACK-486 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-486 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.0.0 >Reporter: Kirk Kosinski >Priority: Minor > > If you click a notification in the UI for a System VM or Virtual Router, > instead of opening the relevant System VMs or Virtual Routers page, the > Instances page is opened. This is not useful since System VMs and Virtual > Routers do not show up on the Instances page. The relevant page should be > opened instead. > To reproduce: > 1. Log on to the UI. > 2. Navigate to Infrastructure > System VMs or Virtual Routers. > 3. Perform an action on one of them. For example, stop a System VM. > 4. Wait for a notification to be generated. > 5. Open the notifications list and click on the notification. For the example > in step 3, click "Stop System VM". > 6. Notice that the Instances page is opened. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CLOUDSTACK-506) [UI] Unable to execute API command liststoragepools
[ https://issues.apache.org/jira/browse/CLOUDSTACK-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-506. --- Resolution: Fixed > [UI] Unable to execute API command liststoragepools > --- > > Key: CLOUDSTACK-506 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-506 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.0.0 > Environment: CentOS 6.3 > kernel-2.6.32-279.14.1.el6.x86_64 > lvm2-2.02.95-10.el6_3.2.x86_64 > lvm2-cluster-2.02.95-10.el6_3.2.x86_64 > lvm2-libs-2.02.95-10.el6_3.2.x86_64 > qemu-kvm-0.12.1.2-2.295.el6_3.2.x86_64 > libvirt-0.9.10-21.el6_3.5.x86_64 > libvirt-client-0.9.10-21.el6_3.5.x86_64 >Reporter: Richard Shevel >Priority: Minor > Attachments: error.png > > > When i try add the primary storage (CLVM). I get an error , such as > Unable to execute API command liststoragepools due to invalid value. Obhect > storage_pool(uuid: undefined) does not exist. And there is no information > about the newly added primary storage. > But if i reload the page, the primary storage displayed normally. > I attached screenshot -- This message was sent by Atlassian JIRA (v6.3.15#6346)
