[jira] [Closed] (CLOUDSTACK-10377) Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for CLOUDSTACK-9114 in ACS 4.11
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets closed CLOUDSTACK-10377. --- > Nuage VSP regression fails in NetworksWithCleanup test since introduction of > fix for CLOUDSTACK-9114 in ACS 4.11 > --- > > Key: CLOUDSTACK-10377 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10377 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12, 4.11.1.0 > Environment: ACS 4.11 or master with Nuage VSP 5.2.x >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Major > > Nuage VSP regression fails in NetworksWithCleanup test since introduction of > fix for CLOUDSTACK-9114 in ACS 4.11 > In Nuage Networks QA regression cycle, cloudstackExpress is failing for > master & 4.11 in expressrestartNetworksWithCleanup test. > The error is Unable to create a deployment. > Issue is caused by fixing > https://issues.apache.org/jira/browse/CLOUDSTACK-9114 > > Reason is that for non-redundant routers, a strategy was implemented where > first a new VR is deployed, then old VR is powered-off/destroyed, and the new > VR is again re-programmed. With this strategy, two identical VRs may be up > for a brief moment (few seconds) where both can serve traffic, however the > new VR performs arp-ping on its interfaces to update neighbours. After the > old VR is removed, the new VR is re-programmed which among many things > performs another arpping. The theoretical downtime is therefore limited by > the arp-cache refresh which can be up to 30 seconds. In my experiments, > against various VMware, KVM and XenServer versions I found that the downtime > was indeed less than 30s, usually between 5-20 seconds. Compared to older ACS > versions, especially in cases where VRs deployment require full volume copy > (like in VMware) a 10x-12x improvement was seen.BUT NUAGE PLUGIN FAILS AS IP > ADDRESS IS ALREADY IN USE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CLOUDSTACK-10377) Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for CLOUDSTACK-9114 in ACS 4.11
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets resolved CLOUDSTACK-10377. - Resolution: Fixed Merged in 4.11 > Nuage VSP regression fails in NetworksWithCleanup test since introduction of > fix for CLOUDSTACK-9114 in ACS 4.11 > --- > > Key: CLOUDSTACK-10377 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10377 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12, 4.11.1.0 > Environment: ACS 4.11 or master with Nuage VSP 5.2.x >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Major > > Nuage VSP regression fails in NetworksWithCleanup test since introduction of > fix for CLOUDSTACK-9114 in ACS 4.11 > In Nuage Networks QA regression cycle, cloudstackExpress is failing for > master & 4.11 in expressrestartNetworksWithCleanup test. > The error is Unable to create a deployment. > Issue is caused by fixing > https://issues.apache.org/jira/browse/CLOUDSTACK-9114 > > Reason is that for non-redundant routers, a strategy was implemented where > first a new VR is deployed, then old VR is powered-off/destroyed, and the new > VR is again re-programmed. With this strategy, two identical VRs may be up > for a brief moment (few seconds) where both can serve traffic, however the > new VR performs arp-ping on its interfaces to update neighbours. After the > old VR is removed, the new VR is re-programmed which among many things > performs another arpping. The theoretical downtime is therefore limited by > the arp-cache refresh which can be up to 30 seconds. In my experiments, > against various VMware, KVM and XenServer versions I found that the downtime > was indeed less than 30s, usually between 5-20 seconds. Compared to older ACS > versions, especially in cases where VRs deployment require full volume copy > (like in VMware) a 10x-12x improvement was seen.BUT NUAGE PLUGIN FAILS AS IP > ADDRESS IS ALREADY IN USE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10380) changing passwordenabled to true while guest vm is running causes unexpected passwordreset again in startvm
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets updated CLOUDSTACK-10380: Description: changing passwordenabled to true while guest vm is running causes passwordreset again in startvm Steps to reproduce: 1.Template passwordenabled flag is set to false 2. Start Vm 3.Set template passwordenabled flag to true 4.StopVm 5.ResetPassword for Stopped Vm. Password is PasswordA. 6.StartVm. Password is PasswordB. This should not happen!! 7.SSH into VM only works with PasswordB. Next steps are as expected. 8.StopVm 9.ResetPassword for Stopped Vm. Password is PasswordC. 10.StartVm. No change in password. 11. SSH into VM works with PasswordC. This was found when test/integration/plugins/nuagevsp/test_nuage_passwordreset.py started to fail after merging of PR2651 https://github.com/apache/cloudstack/pull/2651. was: changing passwordenabled to true while guest vm is running causes passwordreset again in startvm Steps to reproduce: 1.Template passwordenabled flag is set to false 2. Start Vm 3.Set template passwordenabled flag to true 4.StopVm 5.ResetPassword for Stopped Vm. Password is PasswordA. 6.StartVm. Password is PasswordB. This should not happen!! 7.SSH into VM only works with PasswordB. Next steps are as expected. 8.StopVm 9.ResetPassword for Stopped Vm. Password is PasswordC. 10.StartVm. No change in password. 11. SSH into VM works with PasswordC. > changing passwordenabled to true while guest vm is running causes unexpected > passwordreset again in startvm > --- > > Key: CLOUDSTACK-10380 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10380 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12, 4.11.1.0 >Reporter: Raf Smeets >Priority: Major > > changing passwordenabled to true while guest vm is running causes > passwordreset again in startvm > > Steps to reproduce: > 1.Template passwordenabled flag is set to false > 2. Start Vm > 3.Set template passwordenabled flag to true > 4.StopVm > 5.ResetPassword for Stopped Vm. Password is PasswordA. > 6.StartVm. Password is PasswordB. This should not happen!! > 7.SSH into VM only works with PasswordB. > Next steps are as expected. > 8.StopVm > 9.ResetPassword for Stopped Vm. Password is PasswordC. > 10.StartVm. No change in password. > 11. SSH into VM works with PasswordC. > > This was found when > test/integration/plugins/nuagevsp/test_nuage_passwordreset.py started to fail > after merging of PR2651 https://github.com/apache/cloudstack/pull/2651. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CLOUDSTACK-10380) changing passwordenabled to true while guest vm is running causes unexpected passwordreset again in startvm
Raf Smeets created CLOUDSTACK-10380: --- Summary: changing passwordenabled to true while guest vm is running causes unexpected passwordreset again in startvm Key: CLOUDSTACK-10380 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10380 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.12, 4.11.1.0 Reporter: Raf Smeets changing passwordenabled to true while guest vm is running causes passwordreset again in startvm Steps to reproduce: 1.Template passwordenabled flag is set to false 2. Start Vm 3.Set template passwordenabled flag to true 4.StopVm 5.ResetPassword for Stopped Vm. Password is PasswordA. 6.StartVm. Password is PasswordB. This should not happen!! 7.SSH into VM only works with PasswordB. Next steps are as expected. 8.StopVm 9.ResetPassword for Stopped Vm. Password is PasswordC. 10.StartVm. No change in password. 11. SSH into VM works with PasswordC. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CLOUDSTACK-10375) Do not create DefaultNuageVspSharedNetworkOfferingWithSGService
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets closed CLOUDSTACK-10375. --- > Do not create DefaultNuageVspSharedNetworkOfferingWithSGService > --- > > Key: CLOUDSTACK-10375 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10375 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.11.0.0 > Environment: ACS 4.11 + Nuage >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Minor > > NuageVsp plugin is creating a network offering called > DefaultNuageVspSharedNetworkOfferingWithSGService. > This offering is unsupported, so do not create it anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10377) Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for CLOUDSTACK-9114 in ACS 4.11
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets updated CLOUDSTACK-10377: Summary: Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for CLOUDSTACK-9114 in ACS 4.11 (was: Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for Since fix for CLOUDSTACK-9114 in ACS 4.11) > Nuage VSP regression fails in NetworksWithCleanup test since introduction of > fix for CLOUDSTACK-9114 in ACS 4.11 > --- > > Key: CLOUDSTACK-10377 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10377 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12, 4.11.1.0 > Environment: ACS 4.11 or master with Nuage VSP 5.2.x >Reporter: Raf Smeets >Priority: Major > > Nuage VSP regression fails in NetworksWithCleanup test since introduction of > fix for Since fix for CLOUDSTACK-9114 in ACS 4.11 > In Nuage Networks QA regression cycle, cloudstackExpress is failing for > master & 4.11 in expressrestartNetworksWithCleanup test. > The error is Unable to create a deployment. > Issue is caused by fixing > https://issues.apache.org/jira/browse/CLOUDSTACK-9114 > > Reason is that for non-redundant routers, a strategy was implemented where > first a new VR is deployed, then old VR is powered-off/destroyed, and the new > VR is again re-programmed. With this strategy, two identical VRs may be up > for a brief moment (few seconds) where both can serve traffic, however the > new VR performs arp-ping on its interfaces to update neighbours. After the > old VR is removed, the new VR is re-programmed which among many things > performs another arpping. The theoretical downtime is therefore limited by > the arp-cache refresh which can be up to 30 seconds. In my experiments, > against various VMware, KVM and XenServer versions I found that the downtime > was indeed less than 30s, usually between 5-20 seconds. Compared to older ACS > versions, especially in cases where VRs deployment require full volume copy > (like in VMware) a 10x-12x improvement was seen.BUT NUAGE PLUGIN FAILS AS IP > ADDRESS IS ALREADY IN USE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10377) Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for CLOUDSTACK-9114 in ACS 4.11
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets updated CLOUDSTACK-10377: Description: Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for CLOUDSTACK-9114 in ACS 4.11 In Nuage Networks QA regression cycle, cloudstackExpress is failing for master & 4.11 in expressrestartNetworksWithCleanup test. The error is Unable to create a deployment. Issue is caused by fixing https://issues.apache.org/jira/browse/CLOUDSTACK-9114 Reason is that for non-redundant routers, a strategy was implemented where first a new VR is deployed, then old VR is powered-off/destroyed, and the new VR is again re-programmed. With this strategy, two identical VRs may be up for a brief moment (few seconds) where both can serve traffic, however the new VR performs arp-ping on its interfaces to update neighbours. After the old VR is removed, the new VR is re-programmed which among many things performs another arpping. The theoretical downtime is therefore limited by the arp-cache refresh which can be up to 30 seconds. In my experiments, against various VMware, KVM and XenServer versions I found that the downtime was indeed less than 30s, usually between 5-20 seconds. Compared to older ACS versions, especially in cases where VRs deployment require full volume copy (like in VMware) a 10x-12x improvement was seen.BUT NUAGE PLUGIN FAILS AS IP ADDRESS IS ALREADY IN USE. was: Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for Since fix for CLOUDSTACK-9114 in ACS 4.11 In Nuage Networks QA regression cycle, cloudstackExpress is failing for master & 4.11 in expressrestartNetworksWithCleanup test. The error is Unable to create a deployment. Issue is caused by fixing https://issues.apache.org/jira/browse/CLOUDSTACK-9114 Reason is that for non-redundant routers, a strategy was implemented where first a new VR is deployed, then old VR is powered-off/destroyed, and the new VR is again re-programmed. With this strategy, two identical VRs may be up for a brief moment (few seconds) where both can serve traffic, however the new VR performs arp-ping on its interfaces to update neighbours. After the old VR is removed, the new VR is re-programmed which among many things performs another arpping. The theoretical downtime is therefore limited by the arp-cache refresh which can be up to 30 seconds. In my experiments, against various VMware, KVM and XenServer versions I found that the downtime was indeed less than 30s, usually between 5-20 seconds. Compared to older ACS versions, especially in cases where VRs deployment require full volume copy (like in VMware) a 10x-12x improvement was seen.BUT NUAGE PLUGIN FAILS AS IP ADDRESS IS ALREADY IN USE. > Nuage VSP regression fails in NetworksWithCleanup test since introduction of > fix for CLOUDSTACK-9114 in ACS 4.11 > --- > > Key: CLOUDSTACK-10377 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10377 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12, 4.11.1.0 > Environment: ACS 4.11 or master with Nuage VSP 5.2.x >Reporter: Raf Smeets >Priority: Major > > Nuage VSP regression fails in NetworksWithCleanup test since introduction of > fix for CLOUDSTACK-9114 in ACS 4.11 > In Nuage Networks QA regression cycle, cloudstackExpress is failing for > master & 4.11 in expressrestartNetworksWithCleanup test. > The error is Unable to create a deployment. > Issue is caused by fixing > https://issues.apache.org/jira/browse/CLOUDSTACK-9114 > > Reason is that for non-redundant routers, a strategy was implemented where > first a new VR is deployed, then old VR is powered-off/destroyed, and the new > VR is again re-programmed. With this strategy, two identical VRs may be up > for a brief moment (few seconds) where both can serve traffic, however the > new VR performs arp-ping on its interfaces to update neighbours. After the > old VR is removed, the new VR is re-programmed which among many things > performs another arpping. The theoretical downtime is therefore limited by > the arp-cache refresh which can be up to 30 seconds. In my experiments, > against various VMware, KVM and XenServer versions I found that the downtime > was indeed less than 30s, usually between 5-20 seconds. Compared to older ACS > versions, especially in cases where VRs deployment require full volume copy > (like in VMware) a 10x-12x improvement was seen.BUT NUAGE PLUGIN FAILS AS IP > ADDRESS IS ALREADY IN USE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CLOUDSTACK-10377) Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for Since fix for CLOUDSTACK-9114 in ACS 4.11
Raf Smeets created CLOUDSTACK-10377: --- Summary: Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for Since fix for CLOUDSTACK-9114 in ACS 4.11 Key: CLOUDSTACK-10377 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10377 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.12, 4.11.1.0 Environment: ACS 4.11 or master with Nuage VSP 5.2.x Reporter: Raf Smeets Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for Since fix for CLOUDSTACK-9114 in ACS 4.11 In Nuage Networks QA regression cycle, cloudstackExpress is failing for master & 4.11 in expressrestartNetworksWithCleanup test. The error is Unable to create a deployment. Issue is caused by fixing https://issues.apache.org/jira/browse/CLOUDSTACK-9114 Reason is that for non-redundant routers, a strategy was implemented where first a new VR is deployed, then old VR is powered-off/destroyed, and the new VR is again re-programmed. With this strategy, two identical VRs may be up for a brief moment (few seconds) where both can serve traffic, however the new VR performs arp-ping on its interfaces to update neighbours. After the old VR is removed, the new VR is re-programmed which among many things performs another arpping. The theoretical downtime is therefore limited by the arp-cache refresh which can be up to 30 seconds. In my experiments, against various VMware, KVM and XenServer versions I found that the downtime was indeed less than 30s, usually between 5-20 seconds. Compared to older ACS versions, especially in cases where VRs deployment require full volume copy (like in VMware) a 10x-12x improvement was seen.BUT NUAGE PLUGIN FAILS AS IP ADDRESS IS ALREADY IN USE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CLOUDSTACK-10376) UI : no longer possible to select configdrive as userdata provider in a new VPC offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets closed CLOUDSTACK-10376. --- Verified UI it is now possible again to select configdrive as userdata provider in a new VPC offering > UI : no longer possible to select configdrive as userdata provider in a new > VPC offering > > > Key: CLOUDSTACK-10376 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10376 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.11.0.0 > Environment: ACS 4.11 + Nuage >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Major > > UI : no longer possible to select configdrive as userdata provider in a new > VPC offering -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CLOUDSTACK-10376) UI : no longer possible to select configdrive as userdata provider in a new VPC offering
Raf Smeets created CLOUDSTACK-10376: --- Summary: UI : no longer possible to select configdrive as userdata provider in a new VPC offering Key: CLOUDSTACK-10376 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10376 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.11.0.0 Environment: ACS 4.11 + Nuage Reporter: Raf Smeets UI : no longer possible to select configdrive as userdata provider in a new VPC offering -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CLOUDSTACK-10375) Remove obsolete DefaultNuageVspSharedNetworkOfferingWithSGService
Raf Smeets created CLOUDSTACK-10375: --- Summary: Remove obsolete DefaultNuageVspSharedNetworkOfferingWithSGService Key: CLOUDSTACK-10375 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10375 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.11.0.0 Environment: ACS 4.11 + Nuage Reporter: Raf Smeets Remove obsolete DefaultNuageVspSharedNetworkOfferingWithSGService -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CLOUDSTACK-10303) refactor plugins/nuagevsp tests to run from its own test_data.py file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets closed CLOUDSTACK-10303. --- Merged into 4.11 > refactor plugins/nuagevsp tests to run from its own test_data.py file > - > > Key: CLOUDSTACK-10303 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10303 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Affects Versions: 4.11.0.0 > Environment: nuagevsp, simulator >Reporter: Raf Smeets >Assignee: Sigert Goeminne >Priority: Major > > refactor plugins/nuagevsp tests to run from its own test_data.py file and > make sure that all nuagevsp tests run with simulator. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CLOUDSTACK-10298) Recreation of an earlier deleted Nuage managed isolated or vpc tier network fails
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets closed CLOUDSTACK-10298. --- Merged! > Recreation of an earlier deleted Nuage managed isolated or vpc tier network > fails > - > > Key: CLOUDSTACK-10298 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10298 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.11.0.0 >Reporter: Raf Smeets >Assignee: Sigert Goeminne >Priority: Major > > Scenario to reproduce for isolated network: (same applies for vpc tier > network) > Create L3Domain/Zone/Subnet/DefaultACLs in VSD and create a non-persistent > NetworkOffering in ACS, then createNetwork by specifying externalID attribute > in the request, which refers to the Subnet ID in VSD. > Then verify VSD objects and verify networking by deploying 2 VM's in this > network, enable static nat to one VM and ping to the other VM. > After that delete tall the VM's in this network and delete the network itself. > Don't delete data in VSD. > Recreate same network by specifying same externalID attribute in the request, > which refers to the Subnet ID in VSD. > management-server.log shows following error > 2018-02-07 00:15:27,464 DEBUG [c.c.a.ApiServlet] > (qtp66233253-20:ctx-a9727f69) (logid:13bd8add) ===START=== 10.30.39.11 - GET > acltype=Account=StjgrAiYEguhhZwogkx4SggkPhImhdxgSrDbfUZhLjL4As6bm4Xec8GC7WKFWuZXJmTAIl9zx_Qeh767T_yfpQ=f17d2601-984f-4cc6-ba78-4b89bdc87115=11ce9c88-0a46-11e8-bff2-faac09080700=Test+Network=10.0.0.1=b0fbe47b-173e-415b-b0e6-80fd17f75f1d=255.255.255.0=43897d72-6781-4e29-9a13-5ad9addbec01=json=test-a-TestNuageManagedSubnets-VL53W7=TestNet-10.0.0.1-NET_OFF-True-0KWFQ8=createNetwork=688UxfzAZdtoj%2BEFxHpwf6rrAoQ%3D > 2018-02-07 00:15:27,468 DEBUG [c.c.a.ApiServer] (qtp66233253-20:ctx-a9727f69 > ctx-3d2464e6) (logid:13bd8add) CIDRs from which account > 'Acct[555cb263-0a46-11e8-bff2-faac09080700-admin]' is allowed to perform API > calls: 0.0.0.0/0,::/0 > 2018-02-07 00:15:27,479 DEBUG [c.c.u.AccountManagerImpl] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) > Access granted to Acct[5ff94a35-075a-4023-bb2a-2186a6a00853-admin] to > Domain:1/ by AffinityGroupAccessChecker > 2018-02-07 00:15:27,488 DEBUG [c.c.r.ResourceLimitManagerImpl] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) > Checking if amount of resources of Type = 'network' for Account Name = > test-a-TestNuageManagedSubnets-VL53W7 in Domain Id = 1 is exceeded: Account > Resource Limit = 20, Current Account Resource Amount = 0, Requested Resource > Amount = 1. > 2018-02-07 00:15:27,506 DEBUG [c.c.n.g.BigSwitchBcfGuestNetworkGuru] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) > Refusing to design this network, the physical isolation type is not > BCF_SEGMENT > 2018-02-07 00:15:27,506 DEBUG [o.a.c.n.c.m.ContrailGuru] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) > Refusing to design this network > 2018-02-07 00:15:27,507 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) > Refusing to design this network > 2018-02-07 00:15:27,508 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) > Refusing to design this network > 2018-02-07 00:15:27,509 DEBUG [c.c.n.g.OvsGuestNetworkGuru] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) > Refusing to design this network > 2018-02-07 00:15:27,512 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) SSP > not configured to be active > 2018-02-07 00:15:27,513 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) > Refusing to design this network > 2018-02-07 00:15:27,515 DEBUG [c.c.n.g.NuageVspGuestNetworkGuru] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) > Refusing to design network. VsdManaged network object already present in zone. > 2018-02-07 00:15:27,516 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) > Releasing lock for > Acct[fe4ef34f-7563-4c66-8aba-15c600cd794e-test-a-TestNuageManagedSubnets-VL53W7] > 2018-02-07 00:15:27,537 DEBUG [c.c.u.d.T.Transaction] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) > Rolling back the transaction: Time = 52 Name = qtp66233253-20; called by >
[jira] [Resolved] (CLOUDSTACK-10303) refactor plugins/nuagevsp tests to run from its own test_data.py file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets resolved CLOUDSTACK-10303. - Resolution: Fixed PR upstream see https://github.com/apache/cloudstack/pull/2483 > refactor plugins/nuagevsp tests to run from its own test_data.py file > - > > Key: CLOUDSTACK-10303 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10303 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Affects Versions: 4.11.0.0 > Environment: nuagevsp, simulator >Reporter: Raf Smeets >Assignee: Sigert Goeminne >Priority: Major > > refactor plugins/nuagevsp tests to run from its own test_data.py file and > make sure that all nuagevsp tests run with simulator. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CLOUDSTACK-10303) refactor plugins/nuagevsp tests to run from its own test_data.py file
Raf Smeets created CLOUDSTACK-10303: --- Summary: refactor plugins/nuagevsp tests to run from its own test_data.py file Key: CLOUDSTACK-10303 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10303 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: marvin Affects Versions: 4.11.0.0 Environment: nuagevsp, simulator Reporter: Raf Smeets refactor plugins/nuagevsp tests to run from its own test_data.py file and make sure that all nuagevsp tests run with simulator. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CLOUDSTACK-10298) Recreation of an earlier deleted Nuage managed isolated or vpc tier network fails
Raf Smeets created CLOUDSTACK-10298: --- Summary: Recreation of an earlier deleted Nuage managed isolated or vpc tier network fails Key: CLOUDSTACK-10298 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10298 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.11.0.0 Reporter: Raf Smeets Scenario to reproduce for isolated network: (same applies for vpc tier network) Create L3Domain/Zone/Subnet/DefaultACLs in VSD and create a non-persistent NetworkOffering in ACS, then createNetwork by specifying externalID attribute in the request, which refers to the Subnet ID in VSD. Then verify VSD objects and verify networking by deploying 2 VM's in this network, enable static nat to one VM and ping to the other VM. After that delete tall the VM's in this network and delete the network itself. Don't delete data in VSD. Recreate same network by specifying same externalID attribute in the request, which refers to the Subnet ID in VSD. management-server.log shows following error 2018-02-07 00:15:27,464 DEBUG [c.c.a.ApiServlet] (qtp66233253-20:ctx-a9727f69) (logid:13bd8add) ===START=== 10.30.39.11 - GET acltype=Account=StjgrAiYEguhhZwogkx4SggkPhImhdxgSrDbfUZhLjL4As6bm4Xec8GC7WKFWuZXJmTAIl9zx_Qeh767T_yfpQ=f17d2601-984f-4cc6-ba78-4b89bdc87115=11ce9c88-0a46-11e8-bff2-faac09080700=Test+Network=10.0.0.1=b0fbe47b-173e-415b-b0e6-80fd17f75f1d=255.255.255.0=43897d72-6781-4e29-9a13-5ad9addbec01=json=test-a-TestNuageManagedSubnets-VL53W7=TestNet-10.0.0.1-NET_OFF-True-0KWFQ8=createNetwork=688UxfzAZdtoj%2BEFxHpwf6rrAoQ%3D 2018-02-07 00:15:27,468 DEBUG [c.c.a.ApiServer] (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6) (logid:13bd8add) CIDRs from which account 'Acct[555cb263-0a46-11e8-bff2-faac09080700-admin]' is allowed to perform API calls: 0.0.0.0/0,::/0 2018-02-07 00:15:27,479 DEBUG [c.c.u.AccountManagerImpl] (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) Access granted to Acct[5ff94a35-075a-4023-bb2a-2186a6a00853-admin] to Domain:1/ by AffinityGroupAccessChecker 2018-02-07 00:15:27,488 DEBUG [c.c.r.ResourceLimitManagerImpl] (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) Checking if amount of resources of Type = 'network' for Account Name = test-a-TestNuageManagedSubnets-VL53W7 in Domain Id = 1 is exceeded: Account Resource Limit = 20, Current Account Resource Amount = 0, Requested Resource Amount = 1. 2018-02-07 00:15:27,506 DEBUG [c.c.n.g.BigSwitchBcfGuestNetworkGuru] (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) Refusing to design this network, the physical isolation type is not BCF_SEGMENT 2018-02-07 00:15:27,506 DEBUG [o.a.c.n.c.m.ContrailGuru] (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) Refusing to design this network 2018-02-07 00:15:27,507 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) Refusing to design this network 2018-02-07 00:15:27,508 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) Refusing to design this network 2018-02-07 00:15:27,509 DEBUG [c.c.n.g.OvsGuestNetworkGuru] (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) Refusing to design this network 2018-02-07 00:15:27,512 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) SSP not configured to be active 2018-02-07 00:15:27,513 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru] (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) Refusing to design this network 2018-02-07 00:15:27,515 DEBUG [c.c.n.g.NuageVspGuestNetworkGuru] (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) Refusing to design network. VsdManaged network object already present in zone. 2018-02-07 00:15:27,516 DEBUG [o.a.c.e.o.NetworkOrchestrator] (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) Releasing lock for Acct[fe4ef34f-7563-4c66-8aba-15c600cd794e-test-a-TestNuageManagedSubnets-VL53W7] 2018-02-07 00:15:27,537 DEBUG [c.c.u.d.T.Transaction] (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) Rolling back the transaction: Time = 52 Name = qtp66233253-20; called by -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-Transaction.execute:43-Transaction.execute:47-NetworkOrchestrator.createGuestNetwork:2315-NetworkServiceImpl$4.doInTransaction:1383-NetworkServiceImpl$4.doInTransaction:1331-Transaction.execute:40-NetworkServiceImpl.commitNetwork:1331-NetworkServiceImpl.createGuestNetwork:1294-GeneratedMethodAccessor505.invoke:-1 2018-02-07 00:15:27,551 ERROR
[jira] [Closed] (CLOUDSTACK-10245) ResetPassword for guestVm in nuage isolated networks is not working, unable to login with new password
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets closed CLOUDSTACK-10245. --- > ResetPassword for guestVm in nuage isolated networks is not working, unable > to login with new password > -- > > Key: CLOUDSTACK-10245 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10245 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0, 4.12 >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Blocker > Fix For: 4.11.0.0, 4.12 > > > ResetPassword functionality for guestVm's in Nuage isolated networks is not > working as password_server is not running on VirtualRouter. Unable to login > with new password. > Scenario to reproduce: > # Execute ResetPassword on GuestVM > # Try to login with new password fails as passwordserver is not running on > port 8080 in VR. > After some further debugging, found that this bug is introduced while fixing > CLOUDSTACK-9749 by [https://github.com/apache/cloudstack/pull/2409] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CLOUDSTACK-10218) forced network update to a nuage network offering with vr fails with IllegalArgumentException
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets closed CLOUDSTACK-10218. --- > forced network update to a nuage network offering with vr fails with > IllegalArgumentException > - > > Key: CLOUDSTACK-10218 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10218 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Network Controller >Affects Versions: 4.11.0.0 > Environment: NuageVSP >Reporter: Raf Smeets >Assignee: Sigert Goeminne >Priority: Major > Attachments: configdrivemanagement-server.log > > > a forced network update from a nuage network offering without vr to a nuage > network offering with vr fails with java.lang.IllegalArgumentException > Message: 'null' is not an IP string literal. > It looks like this issue was introduced by recalculate broadcasturi > introduced by the network migration PR. Cause: > VspNetwork.getVirtualRouterIp() == "null" NuageVspElement:287 > Scenario to reproduce: > update network id networkofferingid > forced=true > In failing test , existing network offering is one withoutVR, > newnetworkoffering is one with VR as DNS requires VR. > The exception reported in cloudstack is : java.lang.IllegalArgumentException > Message: 'null' is not an IP string literal. > Full cloudstack management server logs are attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CLOUDSTACK-10245) ResetPassword for guestVm in nuage isolated networks is not working, unable to login with new password
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets resolved CLOUDSTACK-10245. - Resolution: Fixed Fix Version/s: 4.12 4.11.0.0 Merged into 4.11 , will be closed when merged into master. > ResetPassword for guestVm in nuage isolated networks is not working, unable > to login with new password > -- > > Key: CLOUDSTACK-10245 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10245 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0, 4.12 >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Blocker > Fix For: 4.11.0.0, 4.12 > > > ResetPassword functionality for guestVm's in Nuage isolated networks is not > working as password_server is not running on VirtualRouter. Unable to login > with new password. > Scenario to reproduce: > # Execute ResetPassword on GuestVM > # Try to login with new password fails as passwordserver is not running on > port 8080 in VR. > After some further debugging, found that this bug is introduced while fixing > CLOUDSTACK-9749 by [https://github.com/apache/cloudstack/pull/2409] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10245) ResetPassword for guestVm in nuage isolated networks is not working, unable to login with new password
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets updated CLOUDSTACK-10245: Description: ResetPassword functionality for guestVm's in Nuage isolated networks is not working as password_server is not running on VirtualRouter. Unable to login with new password. Scenario to reproduce: # Execute ResetPassword on GuestVM # Try to login with new password fails as passwordserver is not running on port 8080 in VR. After some further debugging, found that this bug is introduced while fixing CLOUDSTACK-9749 by [https://github.com/apache/cloudstack/pull/2409] was: ResetPassword functionality for guestVm's in Nuage isolated networks is not working as password_server is not running on VirtualRouter. Unable to login with new password. Scenario to reproduce: # Execute ResetPassword on GuestVM # Try to login with new password fails as passwordserver is not running on port 8080 in VR. After some further debugging, found that this bug is introduced while fixing CLOUDSTACK-9749 by [https://github.com/apache/cloudstack/pull/2409] There is a difference in between native and nuage VR in isolated networks:systemvm boot cmdline for native: type=router while it is type=dhcpsrvr in Nuage. It seems neither self.config.is_vpc() nor self.config.is_router() are true while the VPC VR is of type DHCP server. Moving the code block to the if self.config.has_metadata(): block fixes the bug. > ResetPassword for guestVm in nuage isolated networks is not working, unable > to login with new password > -- > > Key: CLOUDSTACK-10245 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10245 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0, 4.12 >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Blocker > > ResetPassword functionality for guestVm's in Nuage isolated networks is not > working as password_server is not running on VirtualRouter. Unable to login > with new password. > Scenario to reproduce: > # Execute ResetPassword on GuestVM > # Try to login with new password fails as passwordserver is not running on > port 8080 in VR. > After some further debugging, found that this bug is introduced while fixing > CLOUDSTACK-9749 by [https://github.com/apache/cloudstack/pull/2409] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10245) ResetPassword for guestVm in nuage isolated networks is not working, unable to login with new password
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets updated CLOUDSTACK-10245: Description: ResetPassword functionality for guestVm's in Nuage isolated networks is not working as password_server is not running on VirtualRouter. Unable to login with new password. Scenario to reproduce: # Execute ResetPassword on GuestVM # Try to login with new password fails as passwordserver is not running on port 8080 in VR. After some further debugging, found that this bug is introduced while fixing CLOUDSTACK-9749 by [https://github.com/apache/cloudstack/pull/2409] There is a difference in between native and nuage VR in isolated networks:systemvm boot cmdline for native: type=router while it is type=dhcpsrvr in Nuage. It seems neither self.config.is_vpc() nor self.config.is_router() are true while the VPC VR is of type DHCP server. Moving the code block to the if self.config.has_metadata(): block fixes the bug. was: ResetPassword functionality for guestVm's in isolated networks is not working as password_server is not running on VirtualRouter. Unable to login with new password. Scenario to reproduce: # Execute ResetPassword on GuestVM # Try to login with new password fails as passwordserver is not running on port 8080 in VR. After some further debugging, found that this bug is introduced while fixing CLOUDSTACK-9749 by [https://github.com/apache/cloudstack/pull/2409] It seems neither self.config.is_vpc() nor self.config.is_router() are true while the VPC VR is of type DHCP server. Moving the code block to the if self.config.has_metadata(): block fixes the bug. > ResetPassword for guestVm in nuage isolated networks is not working, unable > to login with new password > -- > > Key: CLOUDSTACK-10245 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10245 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0, 4.12 >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Blocker > > ResetPassword functionality for guestVm's in Nuage isolated networks is not > working as password_server is not running on VirtualRouter. Unable to login > with new password. > Scenario to reproduce: > # Execute ResetPassword on GuestVM > # Try to login with new password fails as passwordserver is not running on > port 8080 in VR. > After some further debugging, found that this bug is introduced while fixing > CLOUDSTACK-9749 by [https://github.com/apache/cloudstack/pull/2409] > There is a difference in between native and nuage VR in isolated > networks:systemvm boot cmdline for native: type=router while it is > type=dhcpsrvr in Nuage. > It seems neither self.config.is_vpc() nor self.config.is_router() are true > while the VPC VR is of type DHCP server. > Moving the code block to the if self.config.has_metadata(): block fixes the > bug. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10245) ResetPassword for guestVm in nuage isolated networks is not working, unable to login with new password
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets updated CLOUDSTACK-10245: Summary: ResetPassword for guestVm in nuage isolated networks is not working, unable to login with new password (was: ResetPassword for guestVm in isolated networks is not working, unable to login with new password) > ResetPassword for guestVm in nuage isolated networks is not working, unable > to login with new password > -- > > Key: CLOUDSTACK-10245 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10245 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0, 4.12 >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Blocker > > ResetPassword functionality for guestVm's in isolated networks is not working > as password_server is not running on VirtualRouter. Unable to login with new > password. > Scenario to reproduce: > # Execute ResetPassword on GuestVM > # Try to login with new password fails as passwordserver is not running on > port 8080 in VR. > After some further debugging, found that this bug is introduced while fixing > CLOUDSTACK-9749 by [https://github.com/apache/cloudstack/pull/2409] > It seems neither self.config.is_vpc() nor self.config.is_router() are true > while the VPC VR is of type DHCP server. > Moving the code block to the if self.config.has_metadata(): block fixes the > bug. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10245) ResetPassword for guestVm in isolated networks is not working, unable to login with new password
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets updated CLOUDSTACK-10245: Description: ResetPassword functionality for guestVm's in isolated networks is not working as password_server is not running on VirtualRouter. Unable to login with new password. Scenario to reproduce: # Execute ResetPassword on GuestVM # Try to login with new password fails as passwordserver is not running on port 8080 in VR. After some further debugging, found that this bug is introduced while fixing CLOUDSTACK-9749 by [https://github.com/apache/cloudstack/pull/2409] It seems neither self.config.is_vpc() nor self.config.is_router() are true while the VPC VR is of type DHCP server. Moving the code block to the if self.config.has_metadata(): block fixes the bug. was: ResetPassword functionality for guestVm's in isolated networks is not working as password_server is not running on VirtualRouter. Unable to login with new password. Scenario to reproduce: native run test/integration/component/test_vm_passwdenabled.py # Execute ResetPassword on GuestVM # Try to login with new password fails as passwordserver is not running on port 8080 in VR. After some further debugging, found that this bug is introduced while fixing CLOUDSTACK-9749 by [https://github.com/apache/cloudstack/pull/2409] It seems neither self.config.is_vpc() nor self.config.is_router() are true while the VPC VR is of type DHCP server. Moving the code block to the if self.config.has_metadata(): block fixes the bug. > ResetPassword for guestVm in isolated networks is not working, unable to > login with new password > > > Key: CLOUDSTACK-10245 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10245 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0, 4.12 >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Blocker > > ResetPassword functionality for guestVm's in isolated networks is not working > as password_server is not running on VirtualRouter. Unable to login with new > password. > Scenario to reproduce: > # Execute ResetPassword on GuestVM > # Try to login with new password fails as passwordserver is not running on > port 8080 in VR. > After some further debugging, found that this bug is introduced while fixing > CLOUDSTACK-9749 by [https://github.com/apache/cloudstack/pull/2409] > It seems neither self.config.is_vpc() nor self.config.is_router() are true > while the VPC VR is of type DHCP server. > Moving the code block to the if self.config.has_metadata(): block fixes the > bug. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10245) ResetPassword for guestVm in isolated networks is not working, unable to login with new password
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets updated CLOUDSTACK-10245: Description: ResetPassword functionality for guestVm's in isolated networks is not working as password_server is not running on VirtualRouter. Unable to login with new password. Scenario to reproduce: native run test/integration/component/test_vm_passwdenabled.py # Execute ResetPassword on GuestVM # Try to login with new password fails as passwordserver is not running on port 8080 in VR. After some further debugging, found that this bug is introduced while fixing CLOUDSTACK-9749 by [https://github.com/apache/cloudstack/pull/2409] It seems neither self.config.is_vpc() nor self.config.is_router() are true while the VPC VR is of type DHCP server. Moving the code block to the if self.config.has_metadata(): block fixes the bug. was: ResetPassword functionality for guestVm's in isolated networks is not working as password_server is not running on VirtualRouter. Unable to login with new password. Scenario to reproduce: # Execute ResetPassword on GuestVM # Try to login with new password fails as passwordserver is not running on port 8080 in VR. After some further debugging, found that this bug is introduced while fixing CLOUDSTACK-9749 by [https://github.com/apache/cloudstack/pull/2409] It seems neither self.config.is_vpc() nor self.config.is_router() are true while the VPC VR is of type DHCP server. Moving the code block to the if self.config.has_metadata(): block fixes the bug. > ResetPassword for guestVm in isolated networks is not working, unable to > login with new password > > > Key: CLOUDSTACK-10245 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10245 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0, 4.12 >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Blocker > > ResetPassword functionality for guestVm's in isolated networks is not working > as password_server is not running on VirtualRouter. Unable to login with new > password. > Scenario to reproduce: native run > test/integration/component/test_vm_passwdenabled.py > # Execute ResetPassword on GuestVM > # Try to login with new password fails as passwordserver is not running on > port 8080 in VR. > After some further debugging, found that this bug is introduced while fixing > CLOUDSTACK-9749 by [https://github.com/apache/cloudstack/pull/2409] > It seems neither self.config.is_vpc() nor self.config.is_router() are true > while the VPC VR is of type DHCP server. > Moving the code block to the if self.config.has_metadata(): block fixes the > bug. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CLOUDSTACK-10245) ResetPassword for guestVm in isolated networks is not working, unable to login with new password
Raf Smeets created CLOUDSTACK-10245: --- Summary: ResetPassword for guestVm in isolated networks is not working, unable to login with new password Key: CLOUDSTACK-10245 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10245 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.11.0.0, 4.12 Reporter: Raf Smeets ResetPassword functionality for guestVm's in isolated networks is not working as password_server is not running on VirtualRouter. Unable to login with new password. Scenario to reproduce: # Execute ResetPassword on GuestVM # Try to login with new password fails as passwordserver is not running on port 8080 in VR. After some further debugging, found that this bug is introduced while fixing CLOUDSTACK-9749 by [https://github.com/apache/cloudstack/pull/2409] It seems neither self.config.is_vpc() nor self.config.is_router() are true while the VPC VR is of type DHCP server. Moving the code block to the if self.config.has_metadata(): block fixes the bug. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CLOUDSTACK-10233) When installed ACS on Rhel7.4 with libvirt-3.2.0 the nuage-extension in metadata is missing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets resolved CLOUDSTACK-10233. - Resolution: Fixed Fix Version/s: 4.11.0.0 Fixed in 4.11 > When installed ACS on Rhel7.4 with libvirt-3.2.0 the nuage-extension in > metadata is missing > --- > > Key: CLOUDSTACK-10233 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10233 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: cloudstack-agent >Affects Versions: 4.11.0.0 > Environment: Nuage VSP plugin on RHEL 7.4 >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Critical > Fix For: 4.11.0.0 > > > When installed ACS 4.11 on top of Rhel7.4 baseimage with libvirt-3.2.0 ,there > is an issue with the metadata of the created VM in cloudstack. > It leads to password reset failure as the nuage vrs is not allowing passage > to DomainRouter. > After debugging , it was found that the nuage-extension in metadata was > missing. > When cloudstack-agent is preparing xml to be sent to openvswitch it contains > metadata with nuage-extension block as follows > > > > > > In /var/log/openvswitch/vm-monitor.log , the received XML of VM is without > nuage-extension block in metadata as follows: > Jan 15 18:17:17 ovs-1 vm-monitor.log: > So the metadata block is now empty. It seems libvirt 3.2.0 requires an url in > its metada, so the libvirt namespace needs to be adapted. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CLOUDSTACK-10233) When installed ACS on Rhel7.4 with libvirt-3.2.0 the nuage-extension in metadata is missing
Raf Smeets created CLOUDSTACK-10233: --- Summary: When installed ACS on Rhel7.4 with libvirt-3.2.0 the nuage-extension in metadata is missing Key: CLOUDSTACK-10233 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10233 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: cloudstack-agent Affects Versions: 4.11.0.0 Environment: Nuage VSP plugin on RHEL 7.4 Reporter: Raf Smeets When installed ACS 4.11 on top of Rhel7.4 baseimage with libvirt-3.2.0 ,there is an issue with the metadata of the created VM in cloudstack. It leads to password reset failure as the nuage vrs is not allowing passage to DomainRouter. After debugging , it was found that the nuage-extension in metadata was missing. When cloudstack-agent is preparing xml to be sent to openvswitch it contains metadata with nuage-extension block as follows In /var/log/openvswitch/vm-monitor.log , the received XML of VM is without nuage-extension block in metadata as follows: Jan 15 18:17:17 ovs-1 vm-monitor.log: So the metadata block is now empty. It seems libvirt 3.2.0 requires an url in its metada, so the libvirt namespace needs to be adapted. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CLOUDSTACK-9775) ListInternalLBVMsCmd shows blank in UI although VM is there via api
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raf Smeets closed CLOUDSTACK-9775.
--
Resolution: Cannot Reproduce
Cannot reproduce in ACS 4.11, so closing this bug.
> ListInternalLBVMsCmd shows blank in UI although VM is there via api
> ---
>
> Key: CLOUDSTACK-9775
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9775
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.9.0
>Reporter: Raf Smeets
>Priority: Major
> Attachments: InternalLBVMFail.png
>
>
> ListInternalLBVMsCmd shows blank in the UI although LB VM is there via api
> See attached UI screenshot.
> {NOFORMAT}
> [root@csc-1 ~]# cloudmonkey api listInternalLoadBalancerVMs
> zoneid=8f14b344-7080-4d1c-a37d-badbfb2e90c8 listAll=true
> count = 3
> internalloadbalancervm:
> ++--+---+---+--+-+--+--+--+---+--+---+--+---+-+-++--+--+--+-++--+--+-+---+--+--+--+-+---+--++---+++
> | domain | domainid | guestmacaddress |
> linklocalip |zoneid| linklocalmacaddress |
>linklocalnetworkid | linklocalnetmask | id
>| isredundantrouter | guestnetworkname
> | networkdomain |guestnetworkid|
> hostname | state | version | role |
> serviceofferingid | zonename |podid
> |
>
>
>
>
> nic
>
>
>
>
> | redundantstate |vpcid |
>templateid | requiresupgrade | account
>|hostid| name | created
> | dns2 | dns1 | vpcname
> | hypervisor | guestnetmask | guestipaddress |
> serviceofferingname |
>
[jira] [Commented] (CLOUDSTACK-9749) cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by password server on lb VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327229#comment-16327229 ] Raf Smeets commented on CLOUDSTACK-9749: I tested the fix via test/integration/plugins/nuagevsp/test_nuage_vpc_internal_lb.py and verified that this fix is working. Test Nuage VSP VPC Internal LB functionality by performing (wget) ... === TestName: test_05_nuage_internallb_traffic | Status : SUCCESS === ok Above test_05 was failing before and is now passingso LGTM. > cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by > password server on lb VM > -- > > Key: CLOUDSTACK-9749 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9749 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0, 4.9.2.0, 4.8.2.0, 4.11.0.0 >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Critical > Fix For: 4.10.0.0 > > Attachments: runinfo.txt > > > cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by > password server on lb VM > Executed test/integration/plugins/nuagevsp/test_nuage_vpc_internal_lb.py > which failed in test_05_nuage_internallb_traffic at the point where it is > checking the lb via wget of file using port 8080. > As port 8080 already is occupied by the password_server, it fails. > I have added the runinfo.txt of the failing test to this bugticket. > Similar issue was reported internally via CLOUD-972. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CLOUDSTACK-9749) cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by password server on lb VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16318448#comment-16318448 ] Raf Smeets edited comment on CLOUDSTACK-9749 at 1/9/18 2:30 PM: Since the introduction of Debian9 in 4.11 systemvmtemplate, test_05_nuage_internallb_traffic of test_nuage_vpc_internal_lb.py fails in connectivity check. Previously I had raised CLOUDSTACK-9749 as password service was using port 8080. Fix was to no longer run password service in internal_lb_vm, but it seems that with this new template, this fix is no longer working I can see password service is using port 8080 on internal_lb_vm. Last login: Tue Jan 9 10:52:52 2018 from 10.30.36.2 [root@ovs-2 ~]# virsh list --all IdName State 2 s-1-VM running 31i-12-61-VM running 32i-12-63-VM running 33b-64-VMrunning 34b-67-VMrunning 35i-12-69-VM running [root@ovs-2 ~]# ssh -i ~/.ssh/id_rsa.cloud -p 3922 169.254.2.46 Linux b-67-VM 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3 (2017-12-03) x86_64 root@b-67-VM:~# netstat -an | grep 8080 tcp0 0 10.1.2.55:8080 0.0.0.0:* LISTEN root@b-67-VM:~# netstat -tlpn Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp0 0 10.1.2.55:8080 0.0.0.0:* LISTEN 1165/python tcp0 0 169.254.2.46:3922 0.0.0.0:* LISTEN 1075/sshd root@b-67-VM:~# ps -ef | grep 1165 root 1165 1 0 13:32 ?00:00:00 python /opt/cloud/bin/passwd_server_ip.py 10.1.2.55 root 2044 2034 0 13:36 pts/000:00:00 grep 1165 root@b-67-VM:~# systemctl status cloud-password-server@10.1.2.55 ? cloud-password-server@10.1.2.55.service - Cloud password server on 10.1.2.55 Loaded: loaded (/etc/systemd/system/cloud-password-server@.service; disabled; vendor preset: enabled) Active: active (running) since Tue 2018-01-09 13:32:06 UTC; 7min ago Main PID: 1165 (python) Tasks: 1 (limit: 4915) CGroup: /system.slice/system-cloud\x2dpassword\x2dserver.slice/cloud-password-server@10.1.2.55.service +-1165 python /opt/cloud/bin/passwd_server_ip.py 10.1.2.55 Jan 09 13:32:06 b-67-VM systemd[1]: Started Cloud password server on 10.1.2.55. Jan 09 13:32:06 b-67-VM passwd_server_ip.py[1165]: serve_password running on 10.1.2.55:8080 root@b-67-VM:~# systemctl stop cloud-password-server@10.1.2.55 root@b-67-VM:~# systemctl status cloud-password-server@10.1.2.55 ? cloud-password-server@10.1.2.55.service - Cloud password server on 10.1.2.55 Loaded: loaded (/etc/systemd/system/cloud-password-server@.service; disabled; vendor preset: enabled) Active: inactive (dead) Jan 09 13:32:06 b-67-VM systemd[1]: Started Cloud password server on 10.1.2.55. Jan 09 13:32:06 b-67-VM passwd_server_ip.py[1165]: serve_password running on 10.1.2.55:8080 Jan 09 13:40:40 b-67-VM passwd_server_ip.py[1165]: serve_password: bad_request from IP 10.1.3.141 Jan 09 13:41:01 b-67-VM systemd[1]: Stopping Cloud password server on 10.1.2.55... Jan 09 13:41:01 b-67-VM systemd[1]: Stopped Cloud password server on 10.1.2.55. root@b-67-VM:~# systemctl disable cloud-password-server@10.1.2.55 root@b-67-VM:~# systemctl status cloud-password-server@10.1.2.55 ? cloud-password-server@10.1.2.55.service - Cloud password server on 10.1.2.55 Loaded: loaded (/etc/systemd/system/cloud-password-server@.service; disabled; vendor preset: enabled) Active: inactive (dead) Jan 09 13:32:06 b-67-VM systemd[1]: Started Cloud password server on 10.1.2.55. Jan 09 13:32:06 b-67-VM passwd_server_ip.py[1165]: serve_password running on 10.1.2.55:8080 Jan 09 13:40:40 b-67-VM passwd_server_ip.py[1165]: serve_password: bad_request from IP 10.1.3.141 Jan 09 13:41:01 b-67-VM systemd[1]: Stopping Cloud password server on 10.1.2.55... Jan 09 13:41:01 b-67-VM systemd[1]: Stopped Cloud password server on 10.1.2.55. root@b-67-VM:~# systemctl disable cloud-password-server@ root@b-67-VM:~# systemctl enable cloud-password-server@10.1.2.55 Created symlink /etc/systemd/system/multi-user.target.wants/cloud-password-server@10.1.2.55.service -> /etc/systemd/system/cloud-password-server@.service. root@b-67-VM:~# systemctl disable cloud-password-server@ Removed /etc/systemd/system/multi-user.target.wants/cloud-password-server@10.1.2.55.service. was (Author: smeetsr): Since the introduction of Debian9 systemvmtemplate, test_05_nuage_internallb_traffic of test_nuage_vpc_internal_lb.py fails in connectivity check. Previously I had raised CLOUDSTACK-9749 as password service was using port 8080. Fix
[jira] [Updated] (CLOUDSTACK-9749) cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by password server on lb VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets updated CLOUDSTACK-9749: --- Affects Version/s: 4.11.0.0 > cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by > password server on lb VM > -- > > Key: CLOUDSTACK-9749 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9749 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0, 4.9.2.0, 4.8.2.0, 4.11.0.0 >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Critical > Fix For: 4.10.0.0 > > Attachments: runinfo.txt > > > cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by > password server on lb VM > Executed test/integration/plugins/nuagevsp/test_nuage_vpc_internal_lb.py > which failed in test_05_nuage_internallb_traffic at the point where it is > checking the lb via wget of file using port 8080. > As port 8080 already is occupied by the password_server, it fails. > I have added the runinfo.txt of the failing test to this bugticket. > Similar issue was reported internally via CLOUD-972. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CLOUDSTACK-10218) forced network update to a nuage network offering with vr fails with IllegalArgumentException
Raf Smeets created CLOUDSTACK-10218: --- Summary: forced network update to a nuage network offering with vr fails with IllegalArgumentException Key: CLOUDSTACK-10218 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10218 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.11.0.0 Environment: NuageVSP Reporter: Raf Smeets Attachments: configdrivemanagement-server.log a forced network update from a nuage network offering without vr to a nuage network offering with vr fails with java.lang.IllegalArgumentException Message: 'null' is not an IP string literal. It looks like this issue was introduced by recalculate broadcasturi introduced by the network migration PR. Cause: VspNetwork.getVirtualRouterIp() == "null" NuageVspElement:287 Scenario to reproduce: update network id networkofferingid forced=true In failing test , existing network offering is one withoutVR, newnetworkoffering is one with VR as DNS requires VR. The exception reported in cloudstack is : java.lang.IllegalArgumentException Message: 'null' is not an IP string literal. Full cloudstack management server logs are attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CLOUDSTACK-10211) test_nuage_public_sharednetwork_userdata fails due to errortext changed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets resolved CLOUDSTACK-10211. - Resolution: Fixed PR with fix available See https://github.com/apache/cloudstack/pull/2385 > test_nuage_public_sharednetwork_userdata fails due to errortext changed > --- > > Key: CLOUDSTACK-10211 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10211 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Test >Affects Versions: 4.11.0.0 > Environment: Nuagevsp only >Reporter: Raf Smeets > > In > test/integration/plugins/nuagevsp/test_nuage_public_sharednetwork_userdata.py > , there are 4 failing tests as in master upstream the errortext in case of VM > deployment failure changed from errortext "Failed to deploy VM" has changed > to "Unable to start VM instance" > This failing test is nuagespecific and can only run in a NuageVSP environment. > Following tests are failing and need adapting. > Validate that Different gateway subnet fail as it is not supported ... === > TestName: test_06_verify_different_gateway_subnet_fails_sharednetwork_all | > Status : FAILED === > FAIL > Validate that Different gateway subnet fail as it is not supported ... === > TestName: test_07_different_gateway_subnet_fails_sharednetwork_domain | > Status : FAILED === > FAIL > Validate that Different gateway subnet fail as it is not supported ... === > TestName: test_08_different_gateway_subnet_fails_sharednetwork_nosubdomain | > Status : FAILED === > FAIL > Validate that Different gateway subnet fail as it is not supported ... === > TestName: test_09_different_gateway_subnet_fails_sharednetwork_account | > Status : FAILED === > FAIL > All above tests fails due to an AssertionError: correct exception is not > raised. > Solution is that errortext "Failed to deploy VM" needs to changed to "Unable > to start VM instance" > This bug is written to get this change in upstream master. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CLOUDSTACK-10211) test_nuage_public_sharednetwork_userdata fails due to errortext changed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets updated CLOUDSTACK-10211: Summary: test_nuage_public_sharednetwork_userdata fails due to errortext changed (was: test_nuage_public_sharednetwork_userdata fails due to errortext changed upstream) > test_nuage_public_sharednetwork_userdata fails due to errortext changed > --- > > Key: CLOUDSTACK-10211 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10211 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Test >Affects Versions: 4.11.0.0 > Environment: Nuagevsp only >Reporter: Raf Smeets > > In > test/integration/plugins/nuagevsp/test_nuage_public_sharednetwork_userdata.py > , there are 4 failing tests as in master upstream the errortext in case of VM > deployment failure changed from errortext "Failed to deploy VM" has changed > to "Unable to start VM instance" > This failing test is nuagespecific and can only run in a NuageVSP environment. > Following tests are failing and need adapting. > Validate that Different gateway subnet fail as it is not supported ... === > TestName: test_06_verify_different_gateway_subnet_fails_sharednetwork_all | > Status : FAILED === > FAIL > Validate that Different gateway subnet fail as it is not supported ... === > TestName: test_07_different_gateway_subnet_fails_sharednetwork_domain | > Status : FAILED === > FAIL > Validate that Different gateway subnet fail as it is not supported ... === > TestName: test_08_different_gateway_subnet_fails_sharednetwork_nosubdomain | > Status : FAILED === > FAIL > Validate that Different gateway subnet fail as it is not supported ... === > TestName: test_09_different_gateway_subnet_fails_sharednetwork_account | > Status : FAILED === > FAIL > All above tests fails due to an AssertionError: correct exception is not > raised. > Solution is that errortext "Failed to deploy VM" needs to changed to "Unable > to start VM instance" > This bug is written to get this change in upstream master. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CLOUDSTACK-10211) test_nuage_public_sharednetwork_userdata fails due to errortext changed upstream
Raf Smeets created CLOUDSTACK-10211: --- Summary: test_nuage_public_sharednetwork_userdata fails due to errortext changed upstream Key: CLOUDSTACK-10211 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10211 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Test Affects Versions: 4.11.0.0 Environment: Nuagevsp only Reporter: Raf Smeets In test/integration/plugins/nuagevsp/test_nuage_public_sharednetwork_userdata.py , there are 4 failing tests as in master upstream the errortext in case of VM deployment failure changed from errortext "Failed to deploy VM" has changed to "Unable to start VM instance" This failing test is nuagespecific and can only run in a NuageVSP environment. Following tests are failing and need adapting. Validate that Different gateway subnet fail as it is not supported ... === TestName: test_06_verify_different_gateway_subnet_fails_sharednetwork_all | Status : FAILED === FAIL Validate that Different gateway subnet fail as it is not supported ... === TestName: test_07_different_gateway_subnet_fails_sharednetwork_domain | Status : FAILED === FAIL Validate that Different gateway subnet fail as it is not supported ... === TestName: test_08_different_gateway_subnet_fails_sharednetwork_nosubdomain | Status : FAILED === FAIL Validate that Different gateway subnet fail as it is not supported ... === TestName: test_09_different_gateway_subnet_fails_sharednetwork_account | Status : FAILED === FAIL All above tests fails due to an AssertionError: correct exception is not raised. Solution is that errortext "Failed to deploy VM" needs to changed to "Unable to start VM instance" This bug is written to get this change in upstream master. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CLOUDSTACK-10031) change default configuration for router.aggregation.command.each.timeout from 3 to 600 seconds.
Raf Smeets created CLOUDSTACK-10031: --- Summary: change default configuration for router.aggregation.command.each.timeout from 3 to 600 seconds. Key: CLOUDSTACK-10031 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10031 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.11.0.0 Environment: KVM Reporter: Raf Smeets As CLOUDSTACK-9569: add router.aggregation.command.each.timeout to agent.properties was introduced, now VR is no longer spawned in time and is stopped. Looking into the code the value of 10 minutes (600 seconds) is most used. The default value of router.aggregation.command.each.timeout should be changed from 3 seconds to 600seconds. Refer to CLOUDSTACK-9569: add router.aggregation.command.each.timeout to agent.properties (#1933) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CLOUDSTACK-9775) ListInternalLBVMsCmd shows blank in UI although VM is there via api
Raf Smeets created CLOUDSTACK-9775:
--
Summary: ListInternalLBVMsCmd shows blank in UI although VM is
there via api
Key: CLOUDSTACK-9775
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9775
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: UI
Affects Versions: 4.9.0
Reporter: Raf Smeets
Attachments: InternalLBVMFail.png
ListInternalLBVMsCmd shows blank in the UI although LB VM is there via api
See attached UI screenshot.
{NOFORMAT}
[root@csc-1 ~]# cloudmonkey api listInternalLoadBalancerVMs
zoneid=8f14b344-7080-4d1c-a37d-badbfb2e90c8 listAll=true
count = 3
internalloadbalancervm:
++--+---+---+--+-+--+--+--+---+--+---+--+---+-+-++--+--+--+-++--+--+-+---+--+--+--+-+---+--++---+++
| domain | domainid | guestmacaddress |
linklocalip |zoneid| linklocalmacaddress |
linklocalnetworkid | linklocalnetmask | id
| isredundantrouter | guestnetworkname
| networkdomain |guestnetworkid|
hostname | state | version | role |
serviceofferingid | zonename |podid |
nic
|
redundantstate |vpcid | templateid
| requiresupgrade | account |
hostid| name | created | dns2 |
dns1 | vpcname |
hypervisor | guestnetmask | guestipaddress |serviceofferingname
|
[jira] [Comment Edited] (CLOUDSTACK-9729) Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to com.amazonaws.util.json.JSONException
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15842794#comment-15842794
]
Raf Smeets edited comment on CLOUDSTACK-9729 at 1/27/17 12:57 PM:
--
In total 181 marvin tests have passed, 1 test has failed, 7 tests are skipped.
Here are the details:
test_nuage_internal_dns.py 6 tests passed
test_nuage_non_public_sharednetwork_ip_range.py 5 tests PASSED
test_nuage_password_reset.py 1 test PASSED
test_nuage_public_sharednetwork_ip_range.py 8 tests PASSED
test_nuage_publicsharednetwork.py 51 tests PASSED
test_nuage_public_sharednetwork_userdata.py 14 tests PASSED
test_nuage_sharednetwork_deployVM.py 51 tests PASSED
test_nuage_sharednetwork_vpc_vm_monitor.py 10 tests PASSED
test_nuage_source_nat.py 2 tests PASSED, 6 are SKIPPED Configured Nuage VSP SDN
platform infrastructure does not support underlay networking
test_nuage_static_nat.py 10 tests PASSED
test_nuage_vpc_internal_lb.py 7 PASSED, 1 failed
test_05_nuage_internallb_traffic lb is not in correct state on VSD line1237
known issue https://issues.apache.org/jira/browse/CLOUDSTACK-9749 fix needs to
be implemented upstream.
test_nuage_vpc_network.py 1 test PASSED, 1 SKIPPED There is only one Zone
configured: skipping test
test_nuage_vsp.py 2 tests PASSED.
was (Author: smeetsr):
In total 180 marvin tests have passed, 2 tests have failed, 7 tests are skipped.
Here are the details:
test_nuage_internal_dns.py 6 tests passed
test_nuage_non_public_sharednetwork_ip_range.py 5 tests PASSED
test_nuage_password_reset.py 1 test PASSED
test_nuage_public_sharednetwork_ip_range.py 8 tests PASSED
test_nuage_publicsharednetwork.py 51 tests PASSED
test_nuage_public_sharednetwork_userdata.py 13 tests PASSED, 1 test FAILED
test_05 sometimes router vm state is not updated in VSD which can be fixed by
increasing the nbr of retries to 20 in verify_vsd_object_status
test_nuage_sharednetwork_deployVM.py 51 tests PASSED
test_nuage_sharednetwork_vpc_vm_monitor.py 10 tests PASSED
test_nuage_source_nat.py 2 tests PASSED, 6 are SKIPPED Configured Nuage VSP SDN
platform infrastructure does not support underlay networking
test_nuage_static_nat.py 10 tests PASSED
test_nuage_vpc_internal_lb.py 7 PASSED, 1 failed
test_05_nuage_internallb_traffic lb is not in correct state on VSD line1237
known issue CLOUD-972 fix needs to be implemented upstream.
test_nuage_vpc_network.py 1 test PASSED, 1 SKIPPED There is only one Zone
configured: skipping test
test_nuage_vsp.py 2 tests PASSED.
> Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to
> com.amazonaws.util.json.JSONException
> ---
>
> Key: CLOUDSTACK-9729
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9729
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.10.0.0
>Reporter: Kris Sterckx
>Assignee: Kris Sterckx
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> https://github.com/apache/cloudstack/pull/1638 has moved from
> {noformat}
> 1.10.64
> {noformat}
> to
> {noformat}
> 1.11.61
> {noformat}
> which breaks the use of com.amazonaws.util.json.JSONException
> This breaks Nuage VSP network plugin as of its dependency to
> {noformat}
> net.nuagenetworks.vsp
> nuage-vsp-acs-client
> 1.0.0
> {noformat}
>
> We need to fix that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9729) Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to com.amazonaws.util.json.JSONException
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15842794#comment-15842794
]
Raf Smeets commented on CLOUDSTACK-9729:
In total 180 marvin tests have passed, 2 tests have failed, 7 tests are skipped.
Here are the details:
test_nuage_internal_dns.py 6 tests passed
test_nuage_non_public_sharednetwork_ip_range.py 5 tests PASSED
test_nuage_password_reset.py 1 test PASSED
test_nuage_public_sharednetwork_ip_range.py 8 tests PASSED
test_nuage_publicsharednetwork.py 51 tests PASSED
test_nuage_public_sharednetwork_userdata.py 13 tests PASSED, 1 test FAILED
test_05 sometimes router vm state is not updated in VSD which can be fixed by
increasing the nbr of retries to 20 in verify_vsd_object_status
test_nuage_sharednetwork_deployVM.py 51 tests PASSED
test_nuage_sharednetwork_vpc_vm_monitor.py 10 tests PASSED
test_nuage_source_nat.py 2 tests PASSED, 6 are SKIPPED Configured Nuage VSP SDN
platform infrastructure does not support underlay networking
test_nuage_static_nat.py 10 tests PASSED
test_nuage_vpc_internal_lb.py 7 PASSED, 1 failed
test_05_nuage_internallb_traffic lb is not in correct state on VSD line1237
known issue CLOUD-972 fix needs to be implemented upstream.
test_nuage_vpc_network.py 1 test PASSED, 1 SKIPPED There is only one Zone
configured: skipping test
test_nuage_vsp.py 2 tests PASSED.
> Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to
> com.amazonaws.util.json.JSONException
> ---
>
> Key: CLOUDSTACK-9729
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9729
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.10.0.0
>Reporter: Kris Sterckx
>Assignee: Kris Sterckx
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> https://github.com/apache/cloudstack/pull/1638 has moved from
> {noformat}
> 1.10.64
> {noformat}
> to
> {noformat}
> 1.11.61
> {noformat}
> which breaks the use of com.amazonaws.util.json.JSONException
> This breaks Nuage VSP network plugin as of its dependency to
> {noformat}
> net.nuagenetworks.vsp
> nuage-vsp-acs-client
> 1.0.0
> {noformat}
>
> We need to fix that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9751) if a public IP is assigned to a VM when VR is in starting state, it does not get applied to the vport in Nuage VSD
Raf Smeets created CLOUDSTACK-9751: -- Summary: if a public IP is assigned to a VM when VR is in starting state, it does not get applied to the vport in Nuage VSD Key: CLOUDSTACK-9751 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9751 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.9.0, 4.10.0.0 Reporter: Raf Smeets if a public IP is assigned to a VM when VR is in starting state, it does not get applied to the vport in Nuage VSD. Steps to reproduce:- 1) Create a Isolated Network with Dns Network Offering. 2) Start a vm in it, it will start a VR 3) At this time accquire a Public IP and enable static nat (assigned it to VM , Till this time no vport is created for it on the Nuage VSD). No exception come cloudstack says successfully. 4) After the VM is in running state, the Public Ip in cloudstack is not applied to the Nuage VSD. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9749) cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by password server on lb VM
Raf Smeets created CLOUDSTACK-9749: -- Summary: cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by password server on lb VM Key: CLOUDSTACK-9749 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9749 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.10.0.0 Reporter: Raf Smeets Priority: Critical Fix For: 4.10.0.0 Attachments: runinfo.txt cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by password server on lb VM Executed test/integration/plugins/nuagevsp/test_nuage_vpc_internal_lb.py which failed in test_05_nuage_internallb_traffic at the point where it is checking the lb via wget of file using port 8080. As port 8080 already is occupied by the password_server, it fails. I have added the runinfo.txt of the failing test to this bugticket. Similar issue was reported internally via CLOUD-972. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
