[jira] [Commented] (CLOUDSTACK-8672) NCC Integration with CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15934165#comment-15934165 ] ASF GitHub Bot commented on CLOUDSTACK-8672: Github user karuturi commented on the issue: https://github.com/apache/cloudstack/pull/1859 When debugging, I have seen issues with humongous commits with little or no history. They are very difficult to understand. This is a feature and it need not be backported. so, backporting to previous releases is out of question. up-porting automatically happens. If we want to revert the feature, we revert the merge which is very easy to do. Also, reverting (for feature stability reasons) is just temporary. I agree that the number of commits is high. But, the amount of code is also high and from different authors who wants to keep it this way. I am +1 with keeping it as is. I prefer merges with proper history and small logical units. > NCC Integration with CloudStack > --- > > Key: CLOUDSTACK-8672 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8672 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.6.0 >Reporter: Rajesh Battala >Assignee: Rajesh Battala >Priority: Critical > Fix For: Future > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9827) Storage tags stored in multiple places
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15933546#comment-15933546
]
ASF GitHub Bot commented on CLOUDSTACK-9827:
Github user serg38 commented on the issue:
https://github.com/apache/cloudstack/pull/1994
@nvazquez Looks like Travis cant SSH into management server during the test
.
2017-03-17 19:26:58,672 - DEBUG - mount -t nfs
nfs:/export/automation/1/testprimary
/mnt/marvin-1b4190cb-b9f5-4441-9bdc-bd89e9b7567b
2017-03-17 19:27:13,468 - CRITICAL - EXCEPTION:
test_03_migration_options_storage_tags: ['Traceback (most recent call
last):\n', ' File "/opt/python/2.7.12/lib/python2.7/unittest/case.py", line
329, in run\ntestMethod()\n', ' File
"/home/travis/.local/lib/python2.7/site-packages/marvin/lib/decoratorGenerators.py",
line 30, in test_wrapper\nreturn test(self, *args, **kwargs)\n', ' File
"/home/travis/build/apache/cloudstack/test/integration/smoke/test_primary_storage.py",
line 559, in test_03_migration_options_storage_tags\n
log_lvl=logging.INFO\n', ' File
"/home/travis/.local/lib/python2.7/site-packages/marvin/sshClient.py", line 81,
in __init__\nraise internalError("SSH Connection Failed")\n',
'internalError: SSH Connection Failed\n']
> Storage tags stored in multiple places
> --
>
> Key: CLOUDSTACK-9827
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9827
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.10.0.0
> Environment: N/A
>Reporter: Mike Tutkowski
>Assignee: Nicolas Vazquez
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> I marked this as a Blocker because it concerns me that we are not handling
> storage tags correctly in 4.10 and, as such, VM storage might get placed in
> locations that users don't want.
> From e-mails I sent to dev@ (most recent to oldest):
> If I add a new primary storage and give it a storage tag, the tag ends up in
> storage_pool_details.
> If I edit an existing storage pool’s storage tags, it places them in
> storage_pool_tags.
> **
> I believe I have found another bug (one that we should either fix or examine
> in detail before releasing 4.10).
> It looks like we have a new table: cloud.storage_pool_tags.
> The addition of this table seems to have broken the listStorageTags API
> command. When this command runs, it doesn’t pick up any storage tags for me
> (and I know I have one storage tag).
> This data used to be stored in the cloud.storage_pool_details table. It’s
> good to put it in its own table, but will our upgrade process move the
> existing tags from storage_pool_details to storage_pool_tags?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15933300#comment-15933300 ] ASF GitHub Bot commented on CLOUDSTACK-9317: Github user cloudmonger commented on the issue: https://github.com/apache/cloudstack/pull/1908 ### ACS CI BVT Run **Sumarry:** Build Number 5 Hypervisor xenserver NetworkType Advanced Passed=464 Failed=341 Skipped=53 _Link to logs Folder (search by build_no):_ https://www.dropbox.com/sh/yj3wnzbceo9uef2/AAB6u-Iap-xztdm6jHX9SjPja?dl=0 **Failed tests:** * test_dhcp_dns_offload.py * ContextSuite context=TestDeployVMs>:setup Failing since 2 runs * test_affinity_groups_projects.py * test_01_deploy_vm_anti_affinity_group Failing since 2 runs * test_02_deploy_vm_anti_affinity_group_fail_on_not_enough_hosts Failing since 2 runs * test_01_list_aff_grps_for_vm Failing since 3 runs * test_02_list_multiple_aff_grps_for_vm Failing since 3 runs * test_07_list_all_vms_in_aff_grp Failing since 2 runs * test_01_update_aff_grp_by_ids Failed * test_ps_domain_limits.py * test_04_create_template_snapshot Failing since 2 runs * test_VirtualRouter_alerts.py * test_01_VRServiceFailureAlerting Failed * test_ss_domain_limits.py * test_04_create_template_delete_account Failing since 3 runs * test_04_create_template_delete_account Failing since 4 runs * test_01_multiple_domains_secondary_storage_limits Failing since 3 runs * test_02_multiple_domains_secondary_storage_counts Failing since 2 runs * test_deploy_vm_userdata_multi_nic.py * test_deployvm_multinic Failing since 2 runs * test_vpn_service.py * test_01_VPN_service Failing since 2 runs * test_organization_states.py * ContextSuite context=TestOrganizationStates>:setup Failing since 2 runs * test_escalations_snapshots.py * ContextSuite context=TestSnapshots>:setup Failing since 2 runs * test_haproxy.py * test_01_create_sticky_policy_default_values Failed * test_02_create_sticky_policy_custom_values Failed * test_03_supported_policies_by_network Failed * test_04_delete_lb_rule Failed * test_05_error_alerts_after_create Failed * test_06_release_ip Failed * test_07_delete_account Failed * test_08_create_policy_router_stopped Failed * test_09_create_policy_router_destroy Failed * test_10_create_policy_enable_disable_vpn Failed * test_11_invalid_params Failed * test_dynamic_compute_offering.py * test_max_account_cpus_scale_VM_1_ADMIN_ACCOUNT Failed * test_max_account_cpus_scale_VM_2_USER_ACCOUNT Failed * test_max_account_memory_scale_VM_1_ADMIN_ACCOUNT Failing since 2 runs * test_max_account_memory_scale_VM_2_USER_ACCOUNT Failing since 2 runs * test_deploy_VM_with_affinity_group_1_ADMIN_ACCOUNT Failing since 2 runs * test_deploy_VM_with_affinity_group_2_USER_ACCOUNT Failing since 2 runs * ContextSuite context=TestDynamicServiceOffering>:setup Failing since 2 runs * test_change_so_running_vm_dynamic_to_dynamic_1_ADMIN_ACCOUNT Failing since 2 runs * test_change_so_running_vm_dynamic_to_dynamic_2_USER_ACCOUNT Failing since 2 runs * test_change_so_running_vm_dynamic_to_static_1_ADMIN_ACCOUNT Failing since 2 runs * test_change_so_running_vm_dynamic_to_static_2_USER_ACCOUNT Failing since 2 runs * test_change_so_running_vm_static_to_dynamic_1_ADMIN_ACCOUNT Failing since 2 runs * test_change_so_running_vm_static_to_dynamic_2_USER_ACCOUNT Failing since 2 runs * test_change_so_running_vm_static_to_static_1_ADMIN_ACCOUNT Failing since 2 runs * test_change_so_running_vm_static_to_static_2_USER_ACCOUNT Failing since 2 runs * test_change_so_stopped_vm_dynamic_to_dynamic_1_ADMIN_ACCOUNT Failing since 2 runs * test_change_so_stopped_vm_dynamic_to_dynamic_2_USER_ACCOUNT Failing since 2 runs * test_change_so_stopped_vm_dynamic_to_static_1_ADMIN_ACCOUNT Failing since 2 runs * test_change_so_stopped_vm_dynamic_to_static_2_USER_ACCOUNT Failing since 2 runs * test_change_so_stopped_vm_static_to_dynamic_1_ADMIN_ACCOUNT Failing since 2 runs * test_change_so_stopped_vm_static_to_dynamic_2_USER_ACCOUNT Failing since 2 runs * test_change_so_stopped_vm_static_to_static_1_ADMIN_ACCOUNT Failing since 2 runs * test_change_so_stopped_vm_static_to_static_2_USER_ACCOUNT Failed * test_ps_resource_limits_volume.py * test_attach_volume_exceeding_primary_limit
[jira] [Commented] (CLOUDSTACK-9408) remove runtime references to http://download.cloud.com
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15933296#comment-15933296 ] ASF GitHub Bot commented on CLOUDSTACK-9408: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1582 Trillian test result (tid-959) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 33646 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1582-t959-kvm-centos7.zip Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py Intermitten failure detected: /marvin/tests/smoke/test_router_dhcphosts.py Intermitten failure detected: /marvin/tests/smoke/test_snapshots.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py Test completed. 47 look ok, 2 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_04_rvpc_privategw_static_routes | `Failure` | 300.25 | test_privategw_acl.py test_02_list_snapshots_with_removed_data_store | `Error` | 0.04 | test_snapshots.py test_01_vpc_site2site_vpn | Success | 144.74 | test_vpc_vpn.py test_01_vpc_remote_access_vpn | Success | 61.16 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | Success | 235.44 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 284.14 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 488.00 | test_vpc_router_nics.py test_05_rvpc_multi_tiers | Success | 505.37 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | Success | 1432.64 | test_vpc_redundant.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 528.49 | test_vpc_redundant.py test_02_redundant_VPC_default_routes | Success | 743.93 | test_vpc_redundant.py test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1264.70 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 156.41 | test_volumes.py test_08_resize_volume | Success | 156.36 | test_volumes.py test_07_resize_fail | Success | 161.42 | test_volumes.py test_06_download_detached_volume | Success | 156.29 | test_volumes.py test_05_detach_volume | Success | 155.80 | test_volumes.py test_04_delete_attached_volume | Success | 146.13 | test_volumes.py test_03_download_attached_volume | Success | 156.27 | test_volumes.py test_02_attach_volume | Success | 95.39 | test_volumes.py test_01_create_volume | Success | 711.05 | test_volumes.py test_03_delete_vm_snapshots | Success | 275.19 | test_vm_snapshots.py test_02_revert_vm_snapshots | Success | 95.72 | test_vm_snapshots.py test_01_create_vm_snapshots | Success | 133.68 | test_vm_snapshots.py test_deploy_vm_multiple | Success | 267.90 | test_vm_life_cycle.py test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py test_10_attachAndDetach_iso | Success | 26.58 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.23 | test_vm_life_cycle.py test_08_migrate_vm | Success | 30.85 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.14 | test_vm_life_cycle.py test_06_destroy_vm | Success | 125.80 | test_vm_life_cycle.py test_03_reboot_vm | Success | 125.82 | test_vm_life_cycle.py test_02_start_vm | Success | 10.17 | test_vm_life_cycle.py test_01_stop_vm | Success | 35.28 | test_vm_life_cycle.py test_CreateTemplateWithDuplicateName | Success | 30.37 | test_templates.py test_08_list_system_templates | Success | 0.03 | test_templates.py test_07_list_public_templates | Success | 0.04 | test_templates.py test_05_template_permissions | Success | 0.06 | test_templates.py test_04_extract_template | Success | 5.22 | test_templates.py test_03_delete_template | Success | 5.11 | test_templates.py test_02_edit_template | Success | 90.16 | test_templates.py test_01_create_template | Success | 30.35 | test_templates.py test_10_destroy_cpvm | Success | 191.64 | test_ssvm.py test_09_destroy_ssvm | Success | 133.08 | test_ssvm.py test_08_reboot_cpvm | Success | 101.35 | test_ssvm.py test_07_reboot_ssvm | Success | 133.49 | test_ssvm.py test_06_stop_cpvm | Success | 131.46 | test_ssvm.py test_05_stop_ssvm | Success | 163.58 | test_ssvm.py test_04_cpvm_internals | Success | 1.03 | test_ssvm.py test_03_ssvm_internals | Success | 3.26 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.12 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.14 | test_ssvm.py test_01_snapshot_root_disk | Success | 11.09 | test_snapshots.py test_04_change_offering_small | Success | 209.65 | test_service_offerings.py test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py
[jira] [Commented] (CLOUDSTACK-9840) Datetime format of snapshot events is inconsistent with other events
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15933211#comment-15933211 ] ASF GitHub Bot commented on CLOUDSTACK-9840: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/2008 Trillian test result (tid-961) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 27589 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2008-t961-kvm-centos7.zip Intermitten failure detected: /marvin/tests/smoke/test_outofbandmanagement.py Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py Intermitten failure detected: /marvin/tests/smoke/test_snapshots.py Test completed. 47 look ok, 2 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_04_rvpc_privategw_static_routes | `Failure` | 305.43 | test_privategw_acl.py test_02_list_snapshots_with_removed_data_store | `Error` | 0.04 | test_snapshots.py test_01_vpc_site2site_vpn | Success | 155.01 | test_vpc_vpn.py test_01_vpc_remote_access_vpn | Success | 66.15 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | Success | 230.65 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 281.79 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 493.39 | test_vpc_router_nics.py test_05_rvpc_multi_tiers | Success | 510.93 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | Success | 1404.00 | test_vpc_redundant.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 529.02 | test_vpc_redundant.py test_02_redundant_VPC_default_routes | Success | 728.24 | test_vpc_redundant.py test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1280.56 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 156.46 | test_volumes.py test_08_resize_volume | Success | 156.37 | test_volumes.py test_07_resize_fail | Success | 161.44 | test_volumes.py test_06_download_detached_volume | Success | 151.40 | test_volumes.py test_05_detach_volume | Success | 150.75 | test_volumes.py test_04_delete_attached_volume | Success | 151.23 | test_volumes.py test_03_download_attached_volume | Success | 156.30 | test_volumes.py test_02_attach_volume | Success | 89.17 | test_volumes.py test_01_create_volume | Success | 620.73 | test_volumes.py test_03_delete_vm_snapshots | Success | 275.23 | test_vm_snapshots.py test_02_revert_vm_snapshots | Success | 95.69 | test_vm_snapshots.py test_01_create_vm_snapshots | Success | 158.72 | test_vm_snapshots.py test_deploy_vm_multiple | Success | 242.50 | test_vm_life_cycle.py test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py test_advZoneVirtualRouter | Success | 0.03 | test_vm_life_cycle.py test_10_attachAndDetach_iso | Success | 26.53 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.15 | test_vm_life_cycle.py test_08_migrate_vm | Success | 30.83 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.13 | test_vm_life_cycle.py test_06_destroy_vm | Success | 126.14 | test_vm_life_cycle.py test_03_reboot_vm | Success | 125.82 | test_vm_life_cycle.py test_02_start_vm | Success | 10.17 | test_vm_life_cycle.py test_01_stop_vm | Success | 40.38 | test_vm_life_cycle.py test_CreateTemplateWithDuplicateName | Success | 75.64 | test_templates.py test_08_list_system_templates | Success | 0.03 | test_templates.py test_07_list_public_templates | Success | 0.04 | test_templates.py test_05_template_permissions | Success | 0.06 | test_templates.py test_04_extract_template | Success | 5.12 | test_templates.py test_03_delete_template | Success | 5.11 | test_templates.py test_02_edit_template | Success | 90.18 | test_templates.py test_01_create_template | Success | 25.33 | test_templates.py test_10_destroy_cpvm | Success | 131.32 | test_ssvm.py test_09_destroy_ssvm | Success | 163.62 | test_ssvm.py test_08_reboot_cpvm | Success | 101.37 | test_ssvm.py test_07_reboot_ssvm | Success | 103.05 | test_ssvm.py test_06_stop_cpvm | Success | 101.43 | test_ssvm.py test_05_stop_ssvm | Success | 133.21 | test_ssvm.py test_04_cpvm_internals | Success | 0.97 | test_ssvm.py test_03_ssvm_internals | Success | 2.87 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.12 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.13 | test_ssvm.py test_01_snapshot_root_disk | Success | 11.12 | test_snapshots.py test_04_change_offering_small | Success | 204.46 | test_service_offerings.py test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py test_02_edit_service_offering | Success | 0.05 | test_service_offerin
[jira] [Created] (CLOUDSTACK-9841) Usage server transaction rolled back
Konstanty Wubbufetowicz created CLOUDSTACK-9841: --- Summary: Usage server transaction rolled back Key: CLOUDSTACK-9841 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9841 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.9.0, 4.9.2.0 Environment: CentOS 6.8, Mysql 5.6, Cloudstack 4.9.0 Reporter: Konstanty Wubbufetowicz Attachments: usage-logs.tgz While trying to generate usage records I am getting the following error at the end of the process. I also tested if this is happening with cloudstack-usage 4.9.2 (but with 4.9.0 management-server) - getting exactly the same issue. Might be related to https://issues.apache.org/jira/browse/CLOUDSTACK-6988 Steps to reproduce: I guess that must be something specific about my cloud database content. However, this is a production setup so I am rather not keen on sharing it... Desired results: Usage records created Actual results: javax.persistence.EntityExistsException: Entity already exists is thrown Stack trace: ERROR [cloud.usage.UsageManagerImpl] (Usage-Job-1:null) (logid:) Exception in usage manager javax.persistence.EntityExistsException: Entity already exists: at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1425) at com.cloud.usage.dao.UsageVMInstanceDaoImpl_EnhancerByCloudStack_3e9e482f.CGLIB$persist$32() at com.cloud.usage.dao.UsageVMInstanceDaoImpl_EnhancerByCloudStack_3e9e482f_FastClassByCloudStack_33ae4cfc.invoke() at net.sf.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:122) at com.cloud.usage.dao.UsageVMInstanceDaoImpl_EnhancerByCloudStack_3e9e482f.persist() at com.cloud.usage.UsageManagerImpl.populateDynamicComputeOfferingDetailsAndPersist(UsageManagerImpl.java:1245) at com.cloud.usage.UsageManagerImpl.createVMHelperEvent(UsageManagerImpl.java:1173) at com.cloud.usage.UsageManagerImpl.createHelperRecord(UsageManagerImpl.java:946) at com.cloud.usage.UsageManagerImpl.parse(UsageManagerImpl.java:628) at com.cloud.usage.UsageManagerImpl.runInContextInternal(UsageManagerImpl.java:384) at com.cloud.usage.UsageManagerImpl$1.runInContext(UsageManagerImpl.java:326) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at com.cloud.usage.UsageManagerImpl.run(UsageManagerImpl.java:323) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry '581-2-2017-01-09 16:27:16' for key 'vm_instance_id' 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:526) 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:1040) 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
[jira] [Updated] (CLOUDSTACK-9829) automation:root volume resize-regression
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sadhu suresh updated CLOUDSTACK-9829: - Summary: automation:root volume resize-regression (was: automation:root volume resize-additional sceanrios) > automation:root volume resize-regression > > > Key: CLOUDSTACK-9829 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9829 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.9.0.1 >Reporter: sadhu suresh >Assignee: sadhu suresh > > automate the root volume resize functionality -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9829) automation:root volume resize-additional sceanrios
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932467#comment-15932467 ] sadhu suresh commented on CLOUDSTACK-9829: -- added additional logic for smoke tests to implement -update full clone for vmware . fine tune code by adding setup class and tear down class and added common code there. > automation:root volume resize-additional sceanrios > -- > > Key: CLOUDSTACK-9829 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9829 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.9.0.1 >Reporter: sadhu suresh >Assignee: sadhu suresh > > automate the root volume resize functionality -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9840) Datetime format of snapshot events is inconsistent with other events
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932448#comment-15932448 ] ASF GitHub Bot commented on CLOUDSTACK-9840: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/2008 @borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests > Datetime format of snapshot events is inconsistent with other events > > > Key: CLOUDSTACK-9840 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9840 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: eventbus >Affects Versions: 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1, 4.4.2, 4.4.3, 4.3.2, > 4.5.1, 4.4.4, 4.5.2, 4.6.0, 4.6.1, 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0, > 4.9.2.0, 4.9.1.0, 4.8.1.1, 4.9.0.1, 4.5.2.2 >Reporter: Olivier Lemasle >Assignee: Olivier Lemasle > > The timezone is not included in datetime format of snapshot events, whereas > it is included for other events. > "eventDateTime" was added by [~chipchilders] in commit 14ee684 and was > updated the same day to add the timezone (commit bf967eb) except for > Snapshots. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9840) Datetime format of snapshot events is inconsistent with other events
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932447#comment-15932447 ] ASF GitHub Bot commented on CLOUDSTACK-9840: Github user borisstoyanov commented on the issue: https://github.com/apache/cloudstack/pull/2008 thanks @olivierlemasle that look ok, marvin tests seem to fail, will rerun then now. @blueorangutan test > Datetime format of snapshot events is inconsistent with other events > > > Key: CLOUDSTACK-9840 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9840 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: eventbus >Affects Versions: 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1, 4.4.2, 4.4.3, 4.3.2, > 4.5.1, 4.4.4, 4.5.2, 4.6.0, 4.6.1, 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0, > 4.9.2.0, 4.9.1.0, 4.8.1.1, 4.9.0.1, 4.5.2.2 >Reporter: Olivier Lemasle >Assignee: Olivier Lemasle > > The timezone is not included in datetime format of snapshot events, whereas > it is included for other events. > "eventDateTime" was added by [~chipchilders] in commit 14ee684 and was > updated the same day to add the timezone (commit bf967eb) except for > Snapshots. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9840) Datetime format of snapshot events is inconsistent with other events
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932418#comment-15932418 ] ASF GitHub Bot commented on CLOUDSTACK-9840: Github user olivierlemasle commented on the issue: https://github.com/apache/cloudstack/pull/2008 @borisstoyanov Thanks, I've renamed the pull request. Do you want me to rename to commit as well? Additionally, the travis checks hit a timeout; I've closed and opened again this pull request twice to trigger a new build, with no success. > Datetime format of snapshot events is inconsistent with other events > > > Key: CLOUDSTACK-9840 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9840 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: eventbus >Affects Versions: 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1, 4.4.2, 4.4.3, 4.3.2, > 4.5.1, 4.4.4, 4.5.2, 4.6.0, 4.6.1, 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0, > 4.9.2.0, 4.9.1.0, 4.8.1.1, 4.9.0.1, 4.5.2.2 >Reporter: Olivier Lemasle >Assignee: Olivier Lemasle > > The timezone is not included in datetime format of snapshot events, whereas > it is included for other events. > "eventDateTime" was added by [~chipchilders] in commit 14ee684 and was > updated the same day to add the timezone (commit bf967eb) except for > Snapshots. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CLOUDSTACK-9840) Datetime format of snapshot events is inconsistent with other events
Olivier Lemasle created CLOUDSTACK-9840: --- Summary: Datetime format of snapshot events is inconsistent with other events Key: CLOUDSTACK-9840 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9840 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: eventbus 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.9.2.0, 4.9.1.0 Reporter: Olivier Lemasle Assignee: Olivier Lemasle The timezone is not included in datetime format of snapshot events, whereas it is included for other events. "eventDateTime" was added by [~chipchilders] in commit 14ee684 and was updated the same day to add the timezone (commit bf967eb) except for Snapshots. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932367#comment-15932367
]
ASF GitHub Bot commented on CLOUDSTACK-9317:
Github user ProjectMoon commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1908#discussion_r106855504
--- Diff:
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
---
@@ -1764,9 +1765,12 @@ protected ExecutionResult
cleanupNetworkElementCommand(final IpAssocCommand cmd)
}
nicNum =
broadcastUriAllocatedToVM.get(ip.getBroadcastUri());
-if (numOfIps == 1 && !ip.isAdd()) {
-vifHotUnPlug(conn, routerName, ip.getVifMacAddress());
-networkUsage(routerIp, "deleteVif", "eth" + nicNum);
+if (lastIp != null && lastIp.equalsIgnoreCase("true") &&
!ip.isAdd()) {
--- End diff --
`StringUtils.equalsIgnoreCase` can check both null and the value.
> Disabling static NAT on many IPs can leave wrong IPs on the router
> --
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, Virtual Router
>Affects Versions: 4.7.0, 4.7.1, 4.7.2
>Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply
> IP associations method in the management server. The method is not
> thread-safe. If it's called from multiple threads, each thread will load up
> the list of public IPs in different states (add or revoke)--correct for the
> thread, but not correct overall. Depending on execution order on the virtual
> router, the router can end up with public IPs assigned to it that are not
> supposed to be on it anymore. When another account acquires the same IP, this
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all
> recently released versions. Affected version is set to 4.7.x because that's
> what we verified against.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932368#comment-15932368
]
ASF GitHub Bot commented on CLOUDSTACK-9317:
Github user ProjectMoon commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1908#discussion_r106857110
--- Diff: server/src/com/cloud/network/router/CommandSetupHelper.java ---
@@ -848,13 +849,37 @@ public int compare(final PublicIpAddress o1, final
PublicIpAddress o2) {
associatedWithNetworkId = ipAddrList.get(0).getNetworkId();
}
+// for network if the ips does not have any rules, then only
last ip
+List userIps =
_ipAddressDao.listByAssociatedNetwork(associatedWithNetworkId, null);
+
+int ipsWithrules = 0;
+int ipsStaticNat = 0;
+for (IPAddressVO ip : userIps) {
+if ( _rulesDao.countRulesByIpIdAndState(ip.getId(),
FirewallRule.State.Active) > 0 ) {
+ipsWithrules++;
+}
+
+// check onetoonenat and also check if the ip "add":false.
If there are 2 PF remove 1 static nat add
+if (ip.isOneToOneNat() && ip.getRuleState() == null) {
--- End diff --
Similar to the comments about checking if `lastIp` isn't null, I find that
checking rule state to be null is a bit ... obscure. What is null supposed to
mean in this context? It seems the `rule_state` column is only changed to
`Releasing` when releasing an IP and nothing else. I guess that's intentional?
> Disabling static NAT on many IPs can leave wrong IPs on the router
> --
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, Virtual Router
>Affects Versions: 4.7.0, 4.7.1, 4.7.2
>Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply
> IP associations method in the management server. The method is not
> thread-safe. If it's called from multiple threads, each thread will load up
> the list of public IPs in different states (add or revoke)--correct for the
> thread, but not correct overall. Depending on execution order on the virtual
> router, the router can end up with public IPs assigned to it that are not
> supposed to be on it anymore. When another account acquires the same IP, this
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all
> recently released versions. Affected version is set to 4.7.x because that's
> what we verified against.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932369#comment-15932369
]
ASF GitHub Bot commented on CLOUDSTACK-9317:
Github user ProjectMoon commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1908#discussion_r106856634
--- Diff: server/src/com/cloud/network/router/CommandSetupHelper.java ---
@@ -848,13 +849,37 @@ public int compare(final PublicIpAddress o1, final
PublicIpAddress o2) {
associatedWithNetworkId = ipAddrList.get(0).getNetworkId();
}
+// for network if the ips does not have any rules, then only
last ip
+List userIps =
_ipAddressDao.listByAssociatedNetwork(associatedWithNetworkId, null);
+
+int ipsWithrules = 0;
+int ipsStaticNat = 0;
+for (IPAddressVO ip : userIps) {
+if ( _rulesDao.countRulesByIpIdAndState(ip.getId(),
FirewallRule.State.Active) > 0 ) {
+ipsWithrules++;
+}
+
+// check onetoonenat and also check if the ip "add":false.
If there are 2 PF remove 1 static nat add
+if (ip.isOneToOneNat() && ip.getRuleState() == null) {
+ipsStaticNat++;
+}
+}
+
final IpAssocCommand cmd = new IpAssocCommand(ipsToSend);
cmd.setAccessDetail(NetworkElementCommand.ROUTER_IP,
_routerControlHelper.getRouterControlIp(router.getId()));
cmd.setAccessDetail(NetworkElementCommand.ROUTER_GUEST_IP,
_routerControlHelper.getRouterIpInNetwork(associatedWithNetworkId,
router.getId()));
cmd.setAccessDetail(NetworkElementCommand.ROUTER_NAME,
router.getInstanceName());
final DataCenterVO dcVo =
_dcDao.findById(router.getDataCenterId());
cmd.setAccessDetail(NetworkElementCommand.ZONE_NETWORK_TYPE,
dcVo.getNetworkType().toString());
+// if there 1 static nat then it will be checked for remove at
the resource
+if (ipsWithrules == 0 && ipsStaticNat == 0 ) {
--- End diff --
There's an extraneous space between the `0` and the `)` here. Also, this is
probably just me misunderstanding the code, but wouldn't you want to check if
`ipsStaticNat` equals `1` in this case? Or maybe you're checking for both to be
`0` because if both are 0 we're generating a removal command?
> Disabling static NAT on many IPs can leave wrong IPs on the router
> --
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, Virtual Router
>Affects Versions: 4.7.0, 4.7.1, 4.7.2
>Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply
> IP associations method in the management server. The method is not
> thread-safe. If it's called from multiple threads, each thread will load up
> the list of public IPs in different states (add or revoke)--correct for the
> thread, but not correct overall. Depending on execution order on the virtual
> router, the router can end up with public IPs assigned to it that are not
> supposed to be on it anymore. When another account acquires the same IP, this
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all
> recently released versions. Affected version is set to 4.7.x because that's
> what we verified against.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932370#comment-15932370
]
ASF GitHub Bot commented on CLOUDSTACK-9317:
Github user ProjectMoon commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1908#discussion_r106855300
--- Diff:
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
---
@@ -625,15 +627,20 @@ protected ExecutionResult
cleanupNetworkElementCommand(final IpAssocCommand cmd)
// there is only one ip in this public vlan and removing
it, so
// remove the nic
-if (ipsCount == 1 && !ip.isAdd()) {
-removeVif = true;
+if (lastIp != null && lastIp.equalsIgnoreCase("true") &&
!ip.isAdd()) {
--- End diff --
`StringUtils.equalsIgnoreCase` can replace checking both null and the
value:
https://commons.apache.org/proper/commons-lang/javadocs/api-2.6/org/apache/commons/lang/StringUtils.html#equalsIgnoreCase(java.lang.String,
java.lang.String)
> Disabling static NAT on many IPs can leave wrong IPs on the router
> --
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, Virtual Router
>Affects Versions: 4.7.0, 4.7.1, 4.7.2
>Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply
> IP associations method in the management server. The method is not
> thread-safe. If it's called from multiple threads, each thread will load up
> the list of public IPs in different states (add or revoke)--correct for the
> thread, but not correct overall. Depending on execution order on the virtual
> router, the router can end up with public IPs assigned to it that are not
> supposed to be on it anymore. When another account acquires the same IP, this
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all
> recently released versions. Affected version is set to 4.7.x because that's
> what we verified against.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9282) VPC Inline LB plugin (VPC Public Load Balancing)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932365#comment-15932365 ] ASF GitHub Bot commented on CLOUDSTACK-9282: Github user prashanthvarma commented on the issue: https://github.com/apache/cloudstack/pull/2010 Added Marvin test code PEP8 and PyFlakes compliance: CloudStack$ CloudStack$ pyflakes test/integration/plugins/nuagevsp/.py CloudStack$ CloudStack$ pep8 test/integration/plugins/nuagevsp/.py CloudStack$ CloudStack$ pyflakes test/integration/component/test_vpcinlinelbvm.py CloudStack$ CloudStack$ pep8 test/integration/component/test_vpcinlinelbvm.py CloudStack$ Validation: Marvin test results: => Native ACS Environment: nosetests --with-marvin --marvin-config=nuage.cfg test/integration/component/test_vpcinlinelbvm.py Test VpcInlineLbVm basic functionality ... === TestName: test_01_vpcinlinelbvm | Status : SUCCESS === ok Test VpcInlineLbVm basic functionality with traffic ... === TestName: test_02_vpcinlinelbvm_with_traffic | Status : SUCCESS === ok Test VpcInlineLbVm functionality with multiple public IP addresses ... === TestName: test_03_vpcinlinelbvm_with_multiple_public_ips_traffic | Status : SUCCESS === ok Test VpcInlineLbVm functionality with lb rule events by performing ... === TestName: test_04_vpcinlinelbvm_with_lb_rule_events_traffic | Status : SUCCESS === ok Test VpcInlineLbVm functionality with different LB algorithms by ... === TestName: test_05_vpcinlinelbvm_with_algorithms_traffic | Status : SUCCESS === ok Test VpcInlineLbVm functionality with VpcInlineLbVm appliance ... === TestName: test_06_vpcinlinelbvm_appliance_operations_traffic | Status : EXCEPTION === ERROR Test VpcInlineLbVm provider with network restarts and reboots by ... === TestName: test_07_vpcinlinelbvm_with_network_restarts_and_reboots | Status : EXCEPTION === ERROR ... Ran 7 tests in 9684.676s FAILED (errors=2) [failed_plus_exceptions.txt](https://github.com/apache/cloudstack/files/854289/failed_plus_exceptions.txt) [results.txt](https://github.com/apache/cloudstack/files/854288/results.txt) [runinfo.txt](https://github.com/apache/cloudstack/files/854290/runinfo.txt) Note: The above test failures are due to the bug: https://issues.apache.org/jira/browse/CLOUDSTACK-9837 => ACS + Nuage VSP Environment: nosetests --with-marvin --marvin-config=nuage.cfg test/integration/plugins/nuagevsp/test_nuage_vpc_vpcinlinelb.py Test Nuage VSP VpcInlineLbVm basic functionality ... === TestName: test_01_nuage_vpcinlinelbvm | Status : SUCCESS === ok Test Nuage VSP VpcInlineLbVm basic functionality with traffic ... === TestName: test_02_nuage_vpcinlinelbvm_with_traffic | Status : SUCCESS === ok Test Nuage VSP VpcInlineLbVm functionality with multiple public IP ... === TestName: test_03_nuage_vpcinlinelbvm_with_multiple_public_ips_traffic | Status : SUCCESS === ok Test Nuage VSP VpcInlineLbVm functionality with lb rule events by ... === TestName: test_04_nuage_vpcinlinelbvm_with_lb_rule_events_traffic | Status : FAILED === FAIL Test Nuage VSP VpcInlineLbVm functionality with different LB ... === TestName: test_05_nuage_vpcinlinelbvm_with_algorithms_traffic | Status : SUCCESS === ok Test Nuage VSP VpcInlineLbVm functionality with VpcInlineLbVm ... === TestName: test_06_nuage_vpcinlinelbvm_appliance_operations_traffic | Status : EXCEPTION === ERROR Test Nuage VSP VpcInlineLbVm functionality with network reboots and ... === TestName: test_07_nuage_vpcinlinelbvm_with_network_restarts_and_reboots | Status : SUCCESS === ok Ran 7 tests in 12848.175s FAILED (errors=1, failures=1) [failed_plus_exceptions.txt](https://github.com/apache/cloudstack/files/854302/failed_plus_exceptions.txt) [results.txt](https://github.com/apache/cloudstack/files/854301/results.txt) [runinfo.txt](https://github.com/apache/cloudstack/files/854300/runinfo.txt) Note: The above failure is a random failure on Nuage VSP environment, which we are debugging. => Concurrency tests Thread Count: 15 nosetests --with-marvin --marvin-config=nuage.cfg test/integration/plugins/nuagevsp/test_nuage_vpc_vpcinlinelb.py Test Nuage VSP VPC Network Public Load Balancing Rules Concurrency ... === TestName: test_01_nuage_vpc_network_public_lb_rules_concurrency | Status : SUCCESS === ok -- Ran 1 test in 1606.907s OK [results.txt](https://github.com/apache/cloudstack/files/854313/results.txt) [runinfo.txt](https://github.com/apache/cloudstack/
[jira] [Commented] (CLOUDSTACK-9369) Security issue! Local login open with SAML implementation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932355#comment-15932355 ] ASF GitHub Bot commented on CLOUDSTACK-9369: Github user karuturi commented on the issue: https://github.com/apache/cloudstack/pull/2009 I am seeing the same Travis timeout on all the PRs. Will force push again > Security issue! Local login open with SAML implementation > - > > Key: CLOUDSTACK-9369 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9369 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SAML >Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0 > Environment: ACS 4.5.2 > XS 6.2/6.5 >Reporter: Cyrano Rizzo >Assignee: Rajani Karuturi >Priority: Critical > Labels: login, loginmodule, saml > Attachments: > 4.5-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch, > 4.7plus-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch, > master-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch > > Original Estimate: 8h > Remaining Estimate: 8h > > All SAML enabled accounts can login localy with any password -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9369) Security issue! Local login open with SAML implementation
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932352#comment-15932352
]
ASF GitHub Bot commented on CLOUDSTACK-9369:
Github user karuturi commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/2009#discussion_r106854397
--- Diff:
server/src/com/cloud/api/auth/DefaultLoginAPIAuthenticatorCmd.java ---
@@ -166,7 +166,7 @@ public String authenticate(String command, Map params, HttpSes
throw new CloudAuthenticationException("Unable to find
the domain from the path " + domain);
}
final UserAccount userAccount =
_accountService.getActiveUserAccount(username[0], domainId);
-if (userAccount == null ||
!(User.Source.UNKNOWN.equals(userAccount.getSource()) ||
User.Source.LDAP.equals(userAccount.getSource( {
+if (userAccount != null && User.Source.SAML2 ==
userAccount.getSource()) {
--- End diff --
in case of LDAP, account will be created if it doesnt already exist.
https://cwiki.apache.org/confluence/display/CLOUDSTACK/LDAP%3A+Trust+AD+and+Auto+Import
> Security issue! Local login open with SAML implementation
> -
>
> Key: CLOUDSTACK-9369
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9369
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SAML
>Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0
> Environment: ACS 4.5.2
> XS 6.2/6.5
>Reporter: Cyrano Rizzo
>Assignee: Rajani Karuturi
>Priority: Critical
> Labels: login, loginmodule, saml
> Attachments:
> 4.5-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch,
> 4.7plus-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch,
> master-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> All SAML enabled accounts can login localy with any password
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932351#comment-15932351 ] ASF GitHub Bot commented on CLOUDSTACK-9811: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/2011 @borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests > VR will not start, looking to configure eth3 while no such device exists on > the VR. On KVM-CentOS6.8 physical host > -- > > Key: CLOUDSTACK-9811 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.10.0.0 >Reporter: Boris Stoyanov >Priority: Blocker > Attachments: agent.log, cloud.log, management.log > > > This issue appears only on 4.10. When you add an instance with a new network > the VR starts and fails at the configuration point. Looks like it is looking > to configure eth3 adapter while no such device should be available on the VR. > The VR does not start and aborts the deployment of the VM. > Pease note that this issue was reproduced on physical KVM hosts in our lab. > Hardware Hosts details: > - 4x Dell C6100 > - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant) > OS: > CentOS 6.8. > Management: > VM, running CentOS 6.8 > ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67 > In a nested virtualization environment it was working fine with CentOS6.8. > Attached are the management log and the cloud.log form the VR. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932349#comment-15932349 ] ASF GitHub Bot commented on CLOUDSTACK-9811: Github user borisstoyanov commented on the issue: https://github.com/apache/cloudstack/pull/2011 @blueorangutan test > VR will not start, looking to configure eth3 while no such device exists on > the VR. On KVM-CentOS6.8 physical host > -- > > Key: CLOUDSTACK-9811 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.10.0.0 >Reporter: Boris Stoyanov >Priority: Blocker > Attachments: agent.log, cloud.log, management.log > > > This issue appears only on 4.10. When you add an instance with a new network > the VR starts and fails at the configuration point. Looks like it is looking > to configure eth3 adapter while no such device should be available on the VR. > The VR does not start and aborts the deployment of the VM. > Pease note that this issue was reproduced on physical KVM hosts in our lab. > Hardware Hosts details: > - 4x Dell C6100 > - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant) > OS: > CentOS 6.8. > Management: > VM, running CentOS 6.8 > ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67 > In a nested virtualization environment it was working fine with CentOS6.8. > Attached are the management log and the cloud.log form the VR. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932348#comment-15932348 ] ASF GitHub Bot commented on CLOUDSTACK-9811: Github user borisstoyanov commented on the issue: https://github.com/apache/cloudstack/pull/2003 @DaanHoogland you could review it as well it addressed in https://github.com/apache/cloudstack/pull/2011/files > VR will not start, looking to configure eth3 while no such device exists on > the VR. On KVM-CentOS6.8 physical host > -- > > Key: CLOUDSTACK-9811 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.10.0.0 >Reporter: Boris Stoyanov >Priority: Blocker > Attachments: agent.log, cloud.log, management.log > > > This issue appears only on 4.10. When you add an instance with a new network > the VR starts and fails at the configuration point. Looks like it is looking > to configure eth3 adapter while no such device should be available on the VR. > The VR does not start and aborts the deployment of the VM. > Pease note that this issue was reproduced on physical KVM hosts in our lab. > Hardware Hosts details: > - 4x Dell C6100 > - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant) > OS: > CentOS 6.8. > Management: > VM, running CentOS 6.8 > ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67 > In a nested virtualization environment it was working fine with CentOS6.8. > Attached are the management log and the cloud.log form the VR. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932343#comment-15932343 ] ASF GitHub Bot commented on CLOUDSTACK-9811: Github user DaanHoogland commented on the issue: https://github.com/apache/cloudstack/pull/2003 code LGTM but @ustcweizhou 's patch still makes sense to me. Maybe you can add that separately? travis still fails! > VR will not start, looking to configure eth3 while no such device exists on > the VR. On KVM-CentOS6.8 physical host > -- > > Key: CLOUDSTACK-9811 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.10.0.0 >Reporter: Boris Stoyanov >Priority: Blocker > Attachments: agent.log, cloud.log, management.log > > > This issue appears only on 4.10. When you add an instance with a new network > the VR starts and fails at the configuration point. Looks like it is looking > to configure eth3 adapter while no such device should be available on the VR. > The VR does not start and aborts the deployment of the VM. > Pease note that this issue was reproduced on physical KVM hosts in our lab. > Hardware Hosts details: > - 4x Dell C6100 > - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant) > OS: > CentOS 6.8. > Management: > VM, running CentOS 6.8 > ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67 > In a nested virtualization environment it was working fine with CentOS6.8. > Attached are the management log and the cloud.log form the VR. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932342#comment-15932342 ] ASF GitHub Bot commented on CLOUDSTACK-9811: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/2011 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-597 > VR will not start, looking to configure eth3 while no such device exists on > the VR. On KVM-CentOS6.8 physical host > -- > > Key: CLOUDSTACK-9811 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.10.0.0 >Reporter: Boris Stoyanov >Priority: Blocker > Attachments: agent.log, cloud.log, management.log > > > This issue appears only on 4.10. When you add an instance with a new network > the VR starts and fails at the configuration point. Looks like it is looking > to configure eth3 adapter while no such device should be available on the VR. > The VR does not start and aborts the deployment of the VM. > Pease note that this issue was reproduced on physical KVM hosts in our lab. > Hardware Hosts details: > - 4x Dell C6100 > - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant) > OS: > CentOS 6.8. > Management: > VM, running CentOS 6.8 > ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67 > In a nested virtualization environment it was working fine with CentOS6.8. > Attached are the management log and the cloud.log form the VR. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932316#comment-15932316 ] ASF GitHub Bot commented on CLOUDSTACK-9811: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/2011 @borisstoyanov a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > VR will not start, looking to configure eth3 while no such device exists on > the VR. On KVM-CentOS6.8 physical host > -- > > Key: CLOUDSTACK-9811 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.10.0.0 >Reporter: Boris Stoyanov >Priority: Blocker > Attachments: agent.log, cloud.log, management.log > > > This issue appears only on 4.10. When you add an instance with a new network > the VR starts and fails at the configuration point. Looks like it is looking > to configure eth3 adapter while no such device should be available on the VR. > The VR does not start and aborts the deployment of the VM. > Pease note that this issue was reproduced on physical KVM hosts in our lab. > Hardware Hosts details: > - 4x Dell C6100 > - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant) > OS: > CentOS 6.8. > Management: > VM, running CentOS 6.8 > ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67 > In a nested virtualization environment it was working fine with CentOS6.8. > Attached are the management log and the cloud.log form the VR. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932315#comment-15932315 ] ASF GitHub Bot commented on CLOUDSTACK-9811: Github user borisstoyanov commented on the issue: https://github.com/apache/cloudstack/pull/2011 @blueorangutan package > VR will not start, looking to configure eth3 while no such device exists on > the VR. On KVM-CentOS6.8 physical host > -- > > Key: CLOUDSTACK-9811 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.10.0.0 >Reporter: Boris Stoyanov >Priority: Blocker > Attachments: agent.log, cloud.log, management.log > > > This issue appears only on 4.10. When you add an instance with a new network > the VR starts and fails at the configuration point. Looks like it is looking > to configure eth3 adapter while no such device should be available on the VR. > The VR does not start and aborts the deployment of the VM. > Pease note that this issue was reproduced on physical KVM hosts in our lab. > Hardware Hosts details: > - 4x Dell C6100 > - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant) > OS: > CentOS 6.8. > Management: > VM, running CentOS 6.8 > ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67 > In a nested virtualization environment it was working fine with CentOS6.8. > Attached are the management log and the cloud.log form the VR. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932314#comment-15932314 ] ASF GitHub Bot commented on CLOUDSTACK-9811: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/2011 Packaging result: ✖centos6 ✔centos7 ✔debian. JID-596 > VR will not start, looking to configure eth3 while no such device exists on > the VR. On KVM-CentOS6.8 physical host > -- > > Key: CLOUDSTACK-9811 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.10.0.0 >Reporter: Boris Stoyanov >Priority: Blocker > Attachments: agent.log, cloud.log, management.log > > > This issue appears only on 4.10. When you add an instance with a new network > the VR starts and fails at the configuration point. Looks like it is looking > to configure eth3 adapter while no such device should be available on the VR. > The VR does not start and aborts the deployment of the VM. > Pease note that this issue was reproduced on physical KVM hosts in our lab. > Hardware Hosts details: > - 4x Dell C6100 > - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant) > OS: > CentOS 6.8. > Management: > VM, running CentOS 6.8 > ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67 > In a nested virtualization environment it was working fine with CentOS6.8. > Attached are the management log and the cloud.log form the VR. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9369) Security issue! Local login open with SAML implementation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932307#comment-15932307 ] ASF GitHub Bot commented on CLOUDSTACK-9369: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/2009 @karuturi done, can you check Travis failure; push -f or close/reopen the PR to kick it again? > Security issue! Local login open with SAML implementation > - > > Key: CLOUDSTACK-9369 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9369 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SAML >Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0 > Environment: ACS 4.5.2 > XS 6.2/6.5 >Reporter: Cyrano Rizzo >Assignee: Rajani Karuturi >Priority: Critical > Labels: login, loginmodule, saml > Attachments: > 4.5-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch, > 4.7plus-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch, > master-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch > > Original Estimate: 8h > Remaining Estimate: 8h > > All SAML enabled accounts can login localy with any password -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9369) Security issue! Local login open with SAML implementation
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932305#comment-15932305
]
ASF GitHub Bot commented on CLOUDSTACK-9369:
Github user rhtyd commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/2009#discussion_r106849093
--- Diff:
server/src/com/cloud/api/auth/DefaultLoginAPIAuthenticatorCmd.java ---
@@ -166,7 +166,7 @@ public String authenticate(String command, Map params, HttpSes
throw new CloudAuthenticationException("Unable to find
the domain from the path " + domain);
}
final UserAccount userAccount =
_accountService.getActiveUserAccount(username[0], domainId);
-if (userAccount == null ||
!(User.Source.UNKNOWN.equals(userAccount.getSource()) ||
User.Source.LDAP.equals(userAccount.getSource( {
+if (userAccount != null && User.Source.SAML2 ==
userAccount.getSource()) {
--- End diff --
Why do we need to remove the check `userAccount == null`? Comparision
against Source.SAML2 is fine as long as there are no other user sources other
than LDAP, SAML2 and UNKNOWN. (UNKNOWN should be NATIVE though)
> Security issue! Local login open with SAML implementation
> -
>
> Key: CLOUDSTACK-9369
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9369
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SAML
>Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0
> Environment: ACS 4.5.2
> XS 6.2/6.5
>Reporter: Cyrano Rizzo
>Assignee: Rajani Karuturi
>Priority: Critical
> Labels: login, loginmodule, saml
> Attachments:
> 4.5-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch,
> 4.7plus-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch,
> master-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> All SAML enabled accounts can login localy with any password
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932291#comment-15932291 ] ASF GitHub Bot commented on CLOUDSTACK-9811: Github user ustcweizhou commented on the issue: https://github.com/apache/cloudstack/pull/2011 @borisstoyanov first 4.9, then merge into master. this patch can also be applied to master. ``` wget --no-check-certificate https://github.com/apache/cloudstack/pull/2011.patch git am 2011.patch (or patch -p1 <2011.patch) ``` > VR will not start, looking to configure eth3 while no such device exists on > the VR. On KVM-CentOS6.8 physical host > -- > > Key: CLOUDSTACK-9811 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.10.0.0 >Reporter: Boris Stoyanov >Priority: Blocker > Attachments: agent.log, cloud.log, management.log > > > This issue appears only on 4.10. When you add an instance with a new network > the VR starts and fails at the configuration point. Looks like it is looking > to configure eth3 adapter while no such device should be available on the VR. > The VR does not start and aborts the deployment of the VM. > Pease note that this issue was reproduced on physical KVM hosts in our lab. > Hardware Hosts details: > - 4x Dell C6100 > - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant) > OS: > CentOS 6.8. > Management: > VM, running CentOS 6.8 > ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67 > In a nested virtualization environment it was working fine with CentOS6.8. > Attached are the management log and the cloud.log form the VR. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932285#comment-15932285 ] ASF GitHub Bot commented on CLOUDSTACK-9811: Github user borisstoyanov commented on the issue: https://github.com/apache/cloudstack/pull/2003 ping @rhtyd @DaanHoogland @abhinandanprateek @PaulAngus for review. > VR will not start, looking to configure eth3 while no such device exists on > the VR. On KVM-CentOS6.8 physical host > -- > > Key: CLOUDSTACK-9811 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.10.0.0 >Reporter: Boris Stoyanov >Priority: Blocker > Attachments: agent.log, cloud.log, management.log > > > This issue appears only on 4.10. When you add an instance with a new network > the VR starts and fails at the configuration point. Looks like it is looking > to configure eth3 adapter while no such device should be available on the VR. > The VR does not start and aborts the deployment of the VM. > Pease note that this issue was reproduced on physical KVM hosts in our lab. > Hardware Hosts details: > - 4x Dell C6100 > - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant) > OS: > CentOS 6.8. > Management: > VM, running CentOS 6.8 > ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67 > In a nested virtualization environment it was working fine with CentOS6.8. > Attached are the management log and the cloud.log form the VR. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932281#comment-15932281 ] ASF GitHub Bot commented on CLOUDSTACK-9811: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/2011 @borisstoyanov a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > VR will not start, looking to configure eth3 while no such device exists on > the VR. On KVM-CentOS6.8 physical host > -- > > Key: CLOUDSTACK-9811 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.10.0.0 >Reporter: Boris Stoyanov >Priority: Blocker > Attachments: agent.log, cloud.log, management.log > > > This issue appears only on 4.10. When you add an instance with a new network > the VR starts and fails at the configuration point. Looks like it is looking > to configure eth3 adapter while no such device should be available on the VR. > The VR does not start and aborts the deployment of the VM. > Pease note that this issue was reproduced on physical KVM hosts in our lab. > Hardware Hosts details: > - 4x Dell C6100 > - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant) > OS: > CentOS 6.8. > Management: > VM, running CentOS 6.8 > ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67 > In a nested virtualization environment it was working fine with CentOS6.8. > Attached are the management log and the cloud.log form the VR. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932282#comment-15932282 ] ASF GitHub Bot commented on CLOUDSTACK-9811: Github user borisstoyanov commented on the issue: https://github.com/apache/cloudstack/pull/2011 Hi @ustcweizhou, out of curiosity why 4.9 instead of master? > VR will not start, looking to configure eth3 while no such device exists on > the VR. On KVM-CentOS6.8 physical host > -- > > Key: CLOUDSTACK-9811 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.10.0.0 >Reporter: Boris Stoyanov >Priority: Blocker > Attachments: agent.log, cloud.log, management.log > > > This issue appears only on 4.10. When you add an instance with a new network > the VR starts and fails at the configuration point. Looks like it is looking > to configure eth3 adapter while no such device should be available on the VR. > The VR does not start and aborts the deployment of the VM. > Pease note that this issue was reproduced on physical KVM hosts in our lab. > Hardware Hosts details: > - 4x Dell C6100 > - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant) > OS: > CentOS 6.8. > Management: > VM, running CentOS 6.8 > ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67 > In a nested virtualization environment it was working fine with CentOS6.8. > Attached are the management log and the cloud.log form the VR. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932280#comment-15932280 ] ASF GitHub Bot commented on CLOUDSTACK-9811: Github user borisstoyanov commented on the issue: https://github.com/apache/cloudstack/pull/2011 @blueorangutan package > VR will not start, looking to configure eth3 while no such device exists on > the VR. On KVM-CentOS6.8 physical host > -- > > Key: CLOUDSTACK-9811 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.10.0.0 >Reporter: Boris Stoyanov >Priority: Blocker > Attachments: agent.log, cloud.log, management.log > > > This issue appears only on 4.10. When you add an instance with a new network > the VR starts and fails at the configuration point. Looks like it is looking > to configure eth3 adapter while no such device should be available on the VR. > The VR does not start and aborts the deployment of the VM. > Pease note that this issue was reproduced on physical KVM hosts in our lab. > Hardware Hosts details: > - 4x Dell C6100 > - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant) > OS: > CentOS 6.8. > Management: > VM, running CentOS 6.8 > ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67 > In a nested virtualization environment it was working fine with CentOS6.8. > Attached are the management log and the cloud.log form the VR. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9408) remove runtime references to http://download.cloud.com
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932272#comment-15932272 ] ASF GitHub Bot commented on CLOUDSTACK-9408: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1582 @borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests > remove runtime references to http://download.cloud.com > -- > > Key: CLOUDSTACK-9408 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9408 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0, 4.9.0 >Reporter: Daan Hoogland >Assignee: Daan Hoogland >Priority: Blocker > > As cloud.com was bought and sold, We have no assurance and can give none to > our users as to wether downloads from that site will remain possible. This is > to investigate what occurances of cloud.com can remain and which need to > change, and change them. > [~chiradeep][~widodh] I am assigning this to me but am going to ask for some > further assistance. > [~wstevens]I got no pushback so I am marking this as blocker for now. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9408) remove runtime references to http://download.cloud.com
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932271#comment-15932271 ] ASF GitHub Bot commented on CLOUDSTACK-9408: Github user borisstoyanov commented on the issue: https://github.com/apache/cloudstack/pull/1582 @blueorangutan test > remove runtime references to http://download.cloud.com > -- > > Key: CLOUDSTACK-9408 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9408 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0, 4.9.0 >Reporter: Daan Hoogland >Assignee: Daan Hoogland >Priority: Blocker > > As cloud.com was bought and sold, We have no assurance and can give none to > our users as to wether downloads from that site will remain possible. This is > to investigate what occurances of cloud.com can remain and which need to > change, and change them. > [~chiradeep][~widodh] I am assigning this to me but am going to ask for some > further assistance. > [~wstevens]I got no pushback so I am marking this as blocker for now. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9408) remove runtime references to http://download.cloud.com
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932261#comment-15932261 ] ASF GitHub Bot commented on CLOUDSTACK-9408: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1582 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-595 > remove runtime references to http://download.cloud.com > -- > > Key: CLOUDSTACK-9408 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9408 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0, 4.9.0 >Reporter: Daan Hoogland >Assignee: Daan Hoogland >Priority: Blocker > > As cloud.com was bought and sold, We have no assurance and can give none to > our users as to wether downloads from that site will remain possible. This is > to investigate what occurances of cloud.com can remain and which need to > change, and change them. > [~chiradeep][~widodh] I am assigning this to me but am going to ask for some > further assistance. > [~wstevens]I got no pushback so I am marking this as blocker for now. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9408) remove runtime references to http://download.cloud.com
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932251#comment-15932251 ] ASF GitHub Bot commented on CLOUDSTACK-9408: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1582 @borisstoyanov a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > remove runtime references to http://download.cloud.com > -- > > Key: CLOUDSTACK-9408 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9408 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0, 4.9.0 >Reporter: Daan Hoogland >Assignee: Daan Hoogland >Priority: Blocker > > As cloud.com was bought and sold, We have no assurance and can give none to > our users as to wether downloads from that site will remain possible. This is > to investigate what occurances of cloud.com can remain and which need to > change, and change them. > [~chiradeep][~widodh] I am assigning this to me but am going to ask for some > further assistance. > [~wstevens]I got no pushback so I am marking this as blocker for now. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9408) remove runtime references to http://download.cloud.com
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932250#comment-15932250 ] ASF GitHub Bot commented on CLOUDSTACK-9408: Github user borisstoyanov commented on the issue: https://github.com/apache/cloudstack/pull/1582 @blueorangutan package > remove runtime references to http://download.cloud.com > -- > > Key: CLOUDSTACK-9408 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9408 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0, 4.9.0 >Reporter: Daan Hoogland >Assignee: Daan Hoogland >Priority: Blocker > > As cloud.com was bought and sold, We have no assurance and can give none to > our users as to wether downloads from that site will remain possible. This is > to investigate what occurances of cloud.com can remain and which need to > change, and change them. > [~chiradeep][~widodh] I am assigning this to me but am going to ask for some > further assistance. > [~wstevens]I got no pushback so I am marking this as blocker for now. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
