[GitHub] cloudstack issue #1741: Updated StrongSwan VPN Implementation

2017-01-19 Thread swill
Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1741
  
I don't believe any of these issues are related to the StrongSwan feature...


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] cloudstack issue #1741: Updated StrongSwan VPN Implementation

2017-01-19 Thread swill
Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1741
  


### CI RESULTS

```
Tests Run: 87
  Skipped: 1
   Failed: 6
   Errors: 0
 Duration: 9h 25m 26s
```

**Summary of the problem(s):**
```
FAIL: Test redundant router internals
--
Traceback (most recent call last):
  File 
"/data/git/cs1/cloudstack/test/integration/smoke/test_routers_network_ops.py", 
line 338, in test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true
result = check_router_command(virtual_machine, nat_rule.ipaddress, 
ssh_command, check_string, self)
  File 
"/data/git/cs1/cloudstack/test/integration/smoke/test_routers_network_ops.py", 
line 64, in check_router_command
test_case.fail("Failed to SSH into the Virtual Machine: %s" % e)
AssertionError: Failed to SSH into the Virtual Machine: SSH connection has 
Failed. Waited 150s. Error is SSH Connection Failed
--
Additional details in: /tmp/MarvinLogs/test_network_AZXMBM/results.txt
```

```
FAIL: Test redundant router internals
--
Traceback (most recent call last):
  File 
"/data/git/cs1/cloudstack/test/integration/smoke/test_routers_network_ops.py", 
line 502, in test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false
result = check_router_command(virtual_machine, nat_rule.ipaddress, 
ssh_command, check_string, self)
  File 
"/data/git/cs1/cloudstack/test/integration/smoke/test_routers_network_ops.py", 
line 64, in check_router_command
test_case.fail("Failed to SSH into the Virtual Machine: %s" % e)
AssertionError: Failed to SSH into the Virtual Machine: SSH connection has 
Failed. Waited 150s. Error is SSH Connection Failed
--
Additional details in: /tmp/MarvinLogs/test_network_AZXMBM/results.txt
```

```
FAIL: Test redundant router internals
--
Traceback (most recent call last):
  File 
"/data/git/cs1/cloudstack/test/integration/smoke/test_routers_network_ops.py", 
line 693, in test_03_RVR_Network_check_router_state
self.fail("No Master or too many master routers found %s" % 
cnts[vals.index('MASTER')])
AssertionError: No Master or too many master routers found 0
--
Additional details in: /tmp/MarvinLogs/test_network_AZXMBM/results.txt
```

```
FAIL: test_02_vpc_privategw_static_routes 
(integration.smoke.test_privategw_acl.TestPrivateGwACL)
--
Traceback (most recent call last):
  File 
"/data/git/cs1/cloudstack/test/integration/smoke/test_privategw_acl.py", line 
271, in test_02_vpc_privategw_static_routes
self.performVPCTests(vpc_off)
  File 
"/data/git/cs1/cloudstack/test/integration/smoke/test_privategw_acl.py", line 
362, in performVPCTests
self.check_pvt_gw_connectivity(vm1, public_ip_1, [vm2.nic[0].ipaddress, 
vm1.nic[0].ipaddress])
  File 
"/data/git/cs1/cloudstack/test/integration/smoke/test_privategw_acl.py", line 
724, in check_pvt_gw_connectivity
"Ping to VM on Network Tier N from VM in Network Tier A should be 
successful at least for 2 out of 3 VMs"
AssertionError: Ping to VM on Network Tier N from VM in Network Tier A 
should be successful at least for 2 out of 3 VMs
--
Additional details in: /tmp/MarvinLogs/test_network_AZXMBM/results.txt
```

```
FAIL: test_03_vpc_privategw_restart_vpc_cleanup 
(integration.smoke.test_privategw_acl.TestPrivateGwACL)
--
Traceback (most recent call last):
  File 
"/data/git/cs1/cloudstack/test/integration/smoke/test_privategw_acl.py", line 
283, in test_03_vpc_privategw_restart_vpc_cleanup
self.performVPCTests(vpc_off, restart_with_cleanup = True)
  File 
"/data/git/cs1/cloudstack/test/integration/smoke/test_privategw_acl.py", line 
362, in performVPCTests
self.check_pvt_gw_connectivity(vm1, public_ip_1, [vm2.nic[0].ipaddress, 
vm1.nic[0].ipaddress])
  File 
"/data/git/cs1/cloudstack/test/integration/smoke/test_privategw_acl.py", line 
724, in check_pvt_gw_connectivity
"Ping to VM on Network Tier N from VM in Network Tier A should be 
successful at least for 2 out of 3 VMs"
AssertionError: Ping to VM on Network Tier N from VM in Network Tier A 
should be successful at least for 2 out of 3 VMs

[GitHub] cloudstack pull request #1912: CLOUDSTACK-9749: Disable password service on ...

2017-01-19 Thread fmaximus
GitHub user fmaximus opened a pull request:

https://github.com/apache/cloudstack/pull/1912

CLOUDSTACK-9749: Disable password service on ilb systemvm

Fix cloud-password-srvr correctly.
Made sure it runs on VPC VR, but not on Internal LB

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/fmaximus/cloudstack bugfix/CLOUDSTACK-9749

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1912.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1912


commit aea01bbf372645a45450cc7912795544917b000d
Author: Frank Maximus 
Date:   2017-01-19T15:55:46Z

CLOUDSTACK-9749: Disable password service on ilb systemvm




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


Re: RM for 4.10/master

2017-01-19 Thread Simon Weller

Great, thanks Rajani!



From: Rajani Karuturi 
Sent: Thursday, January 19, 2017 1:15 AM
To: dev@cloudstack.apache.org
Subject: Re: RM for 4.10/master

Yes. thats true. Offlate I was busy with $dayjob activities and
wasnt able to give it enough time.

Starting next week, I will start working on it.

@Rohit, Is it possible to give me access to run CI?

~ Rajani

http://cloudplatform.accelerite.com/

On January 18, 2017 at 11:13 PM, Simon Weller (swel...@ena.com)
wrote:

I think Rajani had originally volunteered to be RM for 4.10 a
couple of months back.


From: Sergey Levitskiy 
Sent: Wednesday, January 18, 2017 11:34 AM
To: dev@cloudstack.apache.org
Subject: Re: RM for 4.10/master

There are many PR in the merge ready state or require
BlueOrangutan testing. Are there volunteers for 4.10 RM role?

On 1/16/17, 4:46 AM, "Rohit Yadav" 
wrote:

All,

I will be on holidays after 18th January and have other work
commitments, I won't be able to contribute much time on RM work.

Please feel free to take up RM responsibilities for 4.10
release, as per our schedule we wanted to freeze it by end of
this month. I can work with the new RM and help them use
@blueorangutan and Trillian for test related work.

Regards.

rohit.ya...@shapeblue.com
www.shapeblue.com
ShapeBlue - The CloudStack Company
www.shapeblue.com ( http://www.shapeblue.com )
Introduction Upgrading CloudStack can sometimes be a little
daunting - but as the 5P's proverb goes - Proper Planning
Prevents Poor Performance.

53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue


[GitHub] cloudstack issue #1662: Fix bug juniper srx

2017-01-19 Thread fmaximus
Github user fmaximus commented on the issue:

https://github.com/apache/cloudstack/pull/1662
  
Seems the fork is gone. I propose we close this PR.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


Re: Volumes created without HyperVisor specified

2017-01-19 Thread Rafael Weingärtner
Also, Could you provide us the error that happens when you plug this volume
without hypervisor in a VM? I would need this information to big deeper
into the problem.

On Wed, Jan 18, 2017 at 4:55 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> could you post the response of create volume command when you execute it
> as a normal user?
>
> On Wed, Jan 18, 2017 at 2:29 PM, Thomas Moroder 
> wrote:
>
>> I'm pretty sure you're correct on this. I don't think the hypervisor
>>> field gets populated until the volume is attached.
>>>
>>
>> yes, I have tested this and at least when using KVM this is correct - the
>> hypervisor field does not get populated till the volume is at least
>> attached once.
>>
>> So thank you for pointing this out.
>>
>> Could you put the agent on the host into debug mode and collect some
>>> logs? You can do this by running sed -i 's/INFO/DEBUG/g'
>>> /etc/cloudstack/agent/log4j-cloud.xml on the host and restarting the
>>> agent.
>>>
>>
>> I already had done this, but didn't see anything in particular.
>>
>> As described when creating the volume as ROOT, it is not possible to
>> attach it; then creating the volume from a specific account in a domain,
>> everything works as expected.
>>
>> So it runs out that ROOT/admin has no VMs running and this is why I am
>> unable to attach the volume :-) After upgrading and testing this I was
>> thinking it has to do with the upgrade, my fault.
>>
>> Thanks to everybody for the pointers.
>>
>> Sincerely,
>> Thomas Moroder
>>
>>
>>
>>>
>>> - Si
>>>
>>> 
>>> From: Rafael Weingärtner 
>>> Sent: Wednesday, January 18, 2017 1:05 PM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: Volumes created without HyperVisor specified
>>>
>>> You are only creating volumes and not attaching them anywhere. I think
>>> this
>>> “create volume” is only logical. It probably only creates entries in DB,
>>> but probably until you do something with the volume, it does not exist in
>>> reality.
>>>
>>> Have you tried to attach the volume in a VM?
>>>
>>> On Wed, Jan 18, 2017 at 2:00 PM, Thomas Moroder 
>>> wrote:
>>>
>>> Dear CloudStack dev-team,

 after upgrading a CloudStack installation to version 4.9.2 new volumes
 are
 created without HyperVisor specified. This happens when creating from
 the
 UI, as well as by using CloudMonkey/the API:

 ###
 (local)  > create volume name="testdisk2"
 diskofferingid=30fa0e20-47c7-40ad-92c9-c2b775e8d536
 zoneid=f563b3fc-2428-4414-9e58-0505ef11f8bf

 accountid = 90e8a863-ec61-11e5-bb13-bb66cccd9eae
 cmd = org.apache.cloudstack.api.command.admin.volume.CreateVolumeC
 mdByAdmin
 created = 2017-01-18T19:52:00+0100
 jobid = 5d544187-abcb-4a16-9b42-879aaae3fb25
 jobinstanceid = 37e1c2b6-7138-4572-879f-c9243433882b
 jobinstancetype = Volume
 jobprocstatus = 0
 jobresult:
 volume:
 id = 37e1c2b6-7138-4572-879f-c9243433882b
 name = testdisk2
 account = admin
 created = 2017-01-18T19:52:00+0100
 destroyed = False
 diskofferingdisplaytext = Small Disk, 5 GB
 diskofferingid = 30fa0e20-47c7-40ad-92c9-c2b775e8d536
 diskofferingname = Small
 displayvolume = True
 domain = ROOT
 domainid = 3c7c4ae5-ec61-11e5-bb13-bb66cccd9eae
 hypervisor = None
 isextractable = True
 jobid = 5d544187-abcb-4a16-9b42-879aaae3fb25
 jobstatus = 0
 provisioningtype = thin
 quiescevm = False
 size = 5368709120
 state = Allocated
 storagetype = shared
 tags:
 type = DATADISK
 zoneid = f563b3fc-2428-4414-9e58-0505ef11f8bf
 zonename = PrivateCloud_AdvancedZone1
 jobresultcode = 0
 jobresulttype = object
 jobstatus = 1
 userid = 76f8889a-1b88-44a9-bab8-0951190c1dd9
 ###

 In the specific case it should use KVM as the HyperVisor.

 No error message is found in the logs or the hosts/agents/SSVM, I am
 available for further debugging.

 Of course it is not possible to attach this volume to a VM thereafter
 (AFAIK volumes are hypervisor-specific).

 Any input or help would be greatly appreciated.

 Sincerely,
 Thomas Moroder

 --
 Incubatec GmbH - Srl
 Via Scurcia'str. 36, 39046 Ortisei(BZ), ITALIA
 Registered with the chamber of commerce of Bolzano the 8th of November
 2001 with
 REA-No. 168204 (s.c. of EUR 10.000 f.p.u.)
 President: Thomas Moroder, VAT-No. IT 02283140214
 Tel: +39.0471796829 - Fax: +39.0471797949

 IMPRINT:
 http://www.incubatec.com/imprint.html

>>> incubatec - impressum
>>> www.incubatec.com
>>> incubatec.com - vi offriamo registrazione di domini e webspace a prezzi
>>> bassi e vi offriamo ottima qualitá. incubatec.com - wir bieten Ihnen
>>> Domain-Registrierungen ...
>>>
>>>
>>>
>>> PRIVACY:

Re: Dedicated IP range for SSVM/CPVM

2017-01-19 Thread Rene Moser
https://issues.apache.org/jira/browse/CLOUDSTACK-9750