[GitHub] cloudstack issue #872: Strongswan vpn feature

[swill]

Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/872
  
@rhtyd have you gotten this system VM to build?  I am having trouble 
getting it to finish building.

My build is failing here...
```
+ log DEBUG 'on_exit: clean_vbox'
+ local level=DEBUG
+ shift
+ [[ 1 != \1 ]]
+ local code=
++ date '+%F %T'
+ local 'line=[2016-09-19 17:55:41] DEBUG: on_exit: clean_vbox'
+ '[' -t 2 ']'
+ echo '[2016-09-19 17:55:41] DEBUG: on_exit: clean_vbox'
[2016-09-19 17:55:41] DEBUG: on_exit: clean_vbox
+ eval clean_vbox
++ clean_vbox
++ log INFO 'deleting all virtualbox vms and disks for jenkins'
++ local level=INFO
++ shift
++ [[ 1 != \1 ]]
++ local code=
+++ date '+%F %T'
++ local 'line=[2016-09-19 17:55:41] INFO: deleting all virtualbox vms and 
disks for jenkins'
++ '[' -t 2 ']'
++ echo '[2016-09-19 17:55:41] INFO: deleting all virtualbox vms and disks 
for jenkins'
[2016-09-19 17:55:41] INFO: deleting all virtualbox vms and disks for 
jenkins
++ bundle exec ./vbox_vm_clean.rb --delete --kill
++ bundle exec ./vbox_disk_clean.rb
+ (( i--  ))
+ (( i>=0  ))
... it just hangs here for hours ...
```

To make sure it is not my jenkins box which has a problem, I try building 
my port of the changes (https://github.com/swill/cloudstack/tree/strongswan) 
made in this PR (prior to the latest update, back when it still had merge 
conflicts), and that builds fine.

Jenkins is basically running:
```
whoami
export PATH=/home/jenkins/.rvm/bin:$PATH
export rvm_path=/home/jenkins/.rvm
export HOME=/home/jenkins/
#wget 
http://download.virtualbox.org/virtualbox/4.2.6/VBoxGuestAdditions_4.2.6.iso
cd tools/appliance
if [ -d iso ]; then
rm -fvr iso
fi
if [ -d dist ]; then
rm -fvr dist
fi
if [ -d box ]; then
rm -fvr box
fi
if [ -d /home/jenkins/iso ]; then
cp -rv /home/jenkins/iso .
fi

if [ ! -d iso ]; then
mkdir iso
ln -s $WORKSPACE/*.iso iso/
fi


export clean_vbox=1
export BUILD_NUMBER=
export version=4.6.0
export branch=master
chmod +x build.sh
./build.sh systemvm64template
```

Any ideas???


---
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 #1676: CLOUDSTACK-9502: DS template copies don’t get dele...

[serg38]

Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1676
  
@jburwell We just re-run  integration tests. The same environment as 1560. 
You can now safely back out 1560 and forward merge this one.
'''
test DeployVM in anti-affinity groups for project ... === TestName: 
test_DeployVmAntiAffinityGroup_in_project | Status : SUCCESS ===
test DeployVM in anti-affinity groups ... === TestName: 
test_DeployVmAntiAffinityGroup | Status : SUCCESS ===
Test Deploy Virtual Machine ... SKIP: Skipping test because suitable 
hypervisor/host notpresent
Test Deploy Virtual Machine from ISO ... === TestName: 
test_deploy_vm_from_iso | Status : SUCCESS ===
Test deploy virtual machine with root resize ... === TestName: 
test_00_deploy_vm_root_resize | Status : SUCCESS ===
Test proper failure to deploy virtual machine with rootdisksize of 0 ... 
=== TestName: test_01_deploy_vm_root_resize | Status : SUCCESS ===
Test proper failure to deploy virtual machine with rootdisksize less than 
template size ... === TestName: test_02_deploy_vm_root_resize | Status : 
SUCCESS ===
Test to deploy vm with a first fit offering ... === TestName: 
test_deployvm_firstfit | Status : SUCCESS ===
Test deploy VMs using user concentrated planner ... === TestName: 
test_deployvm_userconcentrated | Status : SUCCESS ===
Test deploy VMs using user dispersion planner ... === TestName: 
test_deployvm_userdispersing | Status : SUCCESS ===
Test userdata as GET, size > 2k ... === TestName: test_deployvm_userdata | 
Status : SUCCESS ===
Test userdata as POST, size > 2k ... === TestName: 
test_deployvm_userdata_post | Status : SUCCESS ===
Test to create disk offering ... === TestName: test_01_create_disk_offering 
| Status : SUCCESS ===
Test to create  a sparse type disk offering ... === TestName: 
test_02_create_sparse_type_disk_offering | Status : SUCCESS ===
Test to create  a sparse type disk offering ... === TestName: 
test_04_create_fat_type_disk_offering | Status : SUCCESS ===
Test to update existing disk offering ... === TestName: 
test_02_edit_disk_offering | Status : SUCCESS ===
Test to delete disk offering ... === TestName: test_03_delete_disk_offering 
| Status : SUCCESS ===
Test to ensure 4 default roles cannot be deleted ... SKIP: Dynamic 
Role-Based API checker not enabled, skipping test
Test to check role, role permissions and account life cycles ... SKIP: 
Dynamic Role-Based API checker not enabled, skipping test
Test for role-rule enforcement in case of multiple mgmt servers ... SKIP: 
Dynamic Role-Based API checker not enabled, skipping test
Test to ensure role in use cannot be deleted ... SKIP: Dynamic Role-Based 
API checker not enabled, skipping test
Tests normal lifecycle operations for roles ... SKIP: Dynamic Role-Based 
API checker not enabled, skipping test
Tests role update ... SKIP: Dynamic Role-Based API checker not enabled, 
skipping test
Tests that default four roles exist ... SKIP: Dynamic Role-Based API 
checker not enabled, skipping test
Tests role update ... SKIP: Dynamic Role-Based API checker not enabled, 
skipping test
Tests role update when role is in use by an account ... SKIP: Dynamic 
Role-Based API checker not enabled, skipping test
Tests concurrent order updation of role permission ... SKIP: Dynamic 
Role-Based API checker not enabled, skipping test
Tests creation of role permission ... SKIP: Dynamic Role-Based API checker 
not enabled, skipping test
Tests deletion of role permission ... SKIP: Dynamic Role-Based API checker 
not enabled, skipping test
Tests listing of default role's permission ... SKIP: Dynamic Role-Based API 
checker not enabled, skipping test
Tests order updation of role permission ... SKIP: Dynamic Role-Based API 
checker not enabled, skipping test
test update configuration setting at zone level scope ... === TestName: 
test_UpdateConfigParamWithScope | Status : SUCCESS ===
Test guest vlan range dedication ... === TestName: 
test_dedicateGuestVlanRange | Status : SUCCESS ===
Test create public & private ISO ... === TestName: test_01_create_iso | 
Status : SUCCESS ===
Test Edit ISO ... === TestName: test_02_edit_iso | Status : SUCCESS ===
Test delete ISO ... === TestName: test_03_delete_iso | Status : SUCCESS ===
Test for extract ISO ... === TestName: test_04_extract_Iso | Status : 
SUCCESS ===
Update & Test for ISO permissions ... === TestName: test_05_iso_permissions 
| Status : SUCCESS ===
Test for copy ISO from one zone to another ... SKIP: Not enough zones 
available to perform copy template
Test delete ISO ... === TestName: test_07_list_default_iso | Status : 
SUCCESS ===
Test listing Volumes using 'ids' parameter ... === TestName: 
test_01_list_volumes | Status : SUCCESS ===
Test listing Templates using 'ids' parameter ... === TestName: 

Re: [DISCUSS] Replacing the VR

[Matthew Smart]

Abstracting that interaction would also make future implementations MUCH 
less painful and allows third parties who want their networking products 
to be CS compatible to write their own implementation of a published API 
that CS defines. Let them do the legwork for their products, expand CS 
compatibility, and ease future refactors of VR all in one package. I 
like it.


Caveat: I am clueless about how VR configuration happens under the hood 
currently or if abstracting it is a monumental task.


Matthew Smart
President
Smart Software Solutions Inc.
108 S Pierre St.
Pierre, SD 57501

Phone: (605) 280-0383
Skype: msmart13
Email: msm...@smartsoftwareinc.com

On 09/19/2016 11:50 AM, Paul Angus wrote:

Hi All,

 From the looks of this thread and the different preferences that parties have, 
the way forward looks to be a model that allows multiple different VRs to be 
used is the answer.

This is something that I have had in mind for some time now.

By abstracting the roles and configuration of the VR, drivers can be written 
which transform requests such as 'add these firewall rules' into something that 
a VyOs, Fortigate, pfSense, Cisco ASAv, a Juniper vSRX or a homebrew VR can 
understand and implement.

Ideally I'd like to see the features separated and service chaining introduced 
such that someone might use a stock VR with a VPN appliance or a Cisco ASAv in 
front of a VR doing load balancing.

This moves us forward into a much more NFV-like world.




Kind regards,

Paul Angus

paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
   
  



-Original Message-
From: Syed Ahmed [mailto:sah...@cloudops.com]
Sent: 19 September 2016 17:07
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Replacing the VR

Hey Guys,

Will and I had a discussion in the morning on around VyOS and I have an
idea that could work, here me out.

The way Cloudstack currently communicates with VR is via the Hypervisor
(let's assume KVM and XenServer for now). The management server sends a
command as a JSON to the hypervisor which proxies them to the VR and they
get executed there. Now, what we could do is add a proxy on the hypervisor
which translates the management server JSON to VyOS commands (and
vice-versa). There is a VyOS API lib in python which we clould use. Now
this would require 0 changes on the Cloudstack core networking side. There
may be a few minor changes required to push this proxy on the hypervisor
but other than that there is nothing major. Now in the mean time, the VyOS
guys can work on their v2.0 and when they have a stable enough API we can
make it a first class citizen in Cloudstack.

This approach would not work for VMWare as in VMWare the management server
directly talks to the VR. However, this problem could be fixed by adding a
middle VM which does the proxying to-and-from the VR. This would also
improve the overall security of the system in VMWare as well.

I am not too concerned about VMWare at the moment as most of us use either
KVM or XenServer. What do you guys think of this approach?

-Syed

On Mon, Sep 19, 2016 at 11:42 AM, Stephan Seitz <
s.se...@secretresearchfacility.com> wrote:


Hi!

Just to add my 2 cents to that thread:

I'ld really like to see something like vyatta or pfsense integrated as
"standard" VR.

We'd also talked internally about replacing the VR with some more
mature "appliance"-like router distro.

pfsense e.g. comes AFAIK with no defined API but instead has a very
nice GUI.
How would this fit into the concept of configuring the VR via ACS?
Would parts of the GUI - like IP configuration and basic firewall rules
  - hidden or greyed?
Where would one save the configuration, VPN certificates and so on?


- Stephan


Am Sonntag, den 18.09.2016, 15:19 + schrieb Marty Godsey:

On this note I also mentioned pfsense earlier.

www.pfsense.org


Regards,
Marty Godsey

-Original Message-
From: ilya [mailto:ilya.mailing.li...@gmail.com]
Sent: Sunday, September 18, 2016 1:09 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Replacing the VR

Our options become much better if we consider BSD based routers.

Would that be on the table?

https://en.wikipedia.org/wiki/List_of_router_and_firewall_distributio
ns


On 9/16/16 12:04 PM, Will Stevens wrote:

Ya, your points are all valid Simon.  The lack of standard
libraries
to handle a lot of the details is a problem.  I don't think it is
an
unsolvable problem, but if we spend the time to do that, will we
have
something that will work for us for the next 5 years?  This may be
the
shortest path to getting us where we need to be for the time being.

What is the best case scenario for the VR going forward which will
last us the next 5 years?  Maybe we just clean up what we have to
do a
major restructuring of the pieces and how they are
implemented.  We
need to keep in mind how maintainable this implementation is
because
that is going to be key going forward IMO.



*Will 

[GitHub] cloudstack issue #1677: CLOUDSTACK-8830 : CLONE - VM snapshot fails for 12 m...

[nvazquez]

Github user nvazquez commented on the issue:

https://github.com/apache/cloudstack/pull/1677
  
@jburwell I took code from @maneesha-p and added some changes from your 
review in last 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: [DISCUSS] Replacing the VR

[Paul Angus]

Hi All,

From the looks of this thread and the different preferences that parties have, 
the way forward looks to be a model that allows multiple different VRs to be 
used is the answer.

This is something that I have had in mind for some time now.

By abstracting the roles and configuration of the VR, drivers can be written 
which transform requests such as 'add these firewall rules' into something that 
a VyOs, Fortigate, pfSense, Cisco ASAv, a Juniper vSRX or a homebrew VR can 
understand and implement.

Ideally I'd like to see the features separated and service chaining introduced 
such that someone might use a stock VR with a VPN appliance or a Cisco ASAv in 
front of a VR doing load balancing.

This moves us forward into a much more NFV-like world.




Kind regards,

Paul Angus

paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Syed Ahmed [mailto:sah...@cloudops.com] 
Sent: 19 September 2016 17:07
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Replacing the VR

Hey Guys,

Will and I had a discussion in the morning on around VyOS and I have an
idea that could work, here me out.

The way Cloudstack currently communicates with VR is via the Hypervisor
(let's assume KVM and XenServer for now). The management server sends a
command as a JSON to the hypervisor which proxies them to the VR and they
get executed there. Now, what we could do is add a proxy on the hypervisor
which translates the management server JSON to VyOS commands (and
vice-versa). There is a VyOS API lib in python which we clould use. Now
this would require 0 changes on the Cloudstack core networking side. There
may be a few minor changes required to push this proxy on the hypervisor
but other than that there is nothing major. Now in the mean time, the VyOS
guys can work on their v2.0 and when they have a stable enough API we can
make it a first class citizen in Cloudstack.

This approach would not work for VMWare as in VMWare the management server
directly talks to the VR. However, this problem could be fixed by adding a
middle VM which does the proxying to-and-from the VR. This would also
improve the overall security of the system in VMWare as well.

I am not too concerned about VMWare at the moment as most of us use either
KVM or XenServer. What do you guys think of this approach?

-Syed

On Mon, Sep 19, 2016 at 11:42 AM, Stephan Seitz <
s.se...@secretresearchfacility.com> wrote:

> Hi!
>
> Just to add my 2 cents to that thread:
>
> I'ld really like to see something like vyatta or pfsense integrated as
> "standard" VR.
>
> We'd also talked internally about replacing the VR with some more
> mature "appliance"-like router distro.
>
> pfsense e.g. comes AFAIK with no defined API but instead has a very
> nice GUI.
> How would this fit into the concept of configuring the VR via ACS?
> Would parts of the GUI - like IP configuration and basic firewall rules
>  - hidden or greyed?
> Where would one save the configuration, VPN certificates and so on?
>
>
> - Stephan
>
>
> Am Sonntag, den 18.09.2016, 15:19 + schrieb Marty Godsey:
> > On this note I also mentioned pfsense earlier.
> >
> > www.pfsense.org
> >
> >
> > Regards,
> > Marty Godsey
> >
> > -Original Message-
> > From: ilya [mailto:ilya.mailing.li...@gmail.com]
> > Sent: Sunday, September 18, 2016 1:09 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] Replacing the VR
> >
> > Our options become much better if we consider BSD based routers.
> >
> > Would that be on the table?
> >
> > https://en.wikipedia.org/wiki/List_of_router_and_firewall_distributio
> > ns
> >
> >
> > On 9/16/16 12:04 PM, Will Stevens wrote:
> > >
> > > Ya, your points are all valid Simon.  The lack of standard
> > > libraries
> > > to handle a lot of the details is a problem.  I don't think it is
> > > an
> > > unsolvable problem, but if we spend the time to do that, will we
> > > have
> > > something that will work for us for the next 5 years?  This may be
> > > the
> > > shortest path to getting us where we need to be for the time being.
> > >
> > > What is the best case scenario for the VR going forward which will
> > > last us the next 5 years?  Maybe we just clean up what we have to
> > > do a
> > > major restructuring of the pieces and how they are
> > > implemented.  We
> > > need to keep in mind how maintainable this implementation is
> > > because
> > > that is going to be key going forward IMO.
> > >
> > >
> > >
> > > *Will STEVENS*
> > > Lead Developer
> > >
> > > *CloudOps* *| *Cloud Solutions Experts
> > > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|*
> > > tw
> > > @CloudOps_
> > >
> > > On Fri, Sep 16, 2016 at 2:29 PM, Simon Weller 
> > > wrote:
> > >
> > > >
> > > > I think our other option is to take a real look at what it would
> > > > take
> > > > to fix the VR. In my opinion, a lot of the problems are related
> > > > to
> > > > the 

[GitHub] cloudstack pull request #1677: CLOUDSTACK-8830 : CLONE - VM snapshot fails f...

[nvazquez]

GitHub user nvazquez opened a pull request:

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

CLOUDSTACK-8830 : CLONE - VM snapshot fails for 12 min after instance 
creation Summary: Change in API behavior in vCenter 6.0.0. The name for VM 
Power On task is null on VMware vCenter 6.0, whereas PowerOnVM_Task in vCenter 
5.5. Reviewed-By: Sateesh

Continuing work by @maneesha-p in #798 

This closes #798

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

$ git pull https://github.com/nvazquez/cloudstack vmsnapshot12min

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

https://github.com/apache/cloudstack/pull/1677.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 #1677


commit d5e39ee6b9630d285dc0c6de5dcb8f42f013a52c
Author: nvazquez 
Date:   2016-09-19T16:26:38Z

CLOUDSTACK-8830 : CLONE - VM snapshot fails for 12 min after instance 
creation Summary: Change in API behavior in vCenter 6.0.0. The name for VM 
Power On task is null on VMware vCenter 6.0, whereas PowerOnVM_Task in vCenter 
5.5. Reviewed-By: Sateesh




---
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: [DISCUSS] Replacing the VR

[Syed Ahmed]

Hey Guys,

Will and I had a discussion in the morning on around VyOS and I have an
idea that could work, here me out.

The way Cloudstack currently communicates with VR is via the Hypervisor
(let's assume KVM and XenServer for now). The management server sends a
command as a JSON to the hypervisor which proxies them to the VR and they
get executed there. Now, what we could do is add a proxy on the hypervisor
which translates the management server JSON to VyOS commands (and
vice-versa). There is a VyOS API lib in python which we clould use. Now
this would require 0 changes on the Cloudstack core networking side. There
may be a few minor changes required to push this proxy on the hypervisor
but other than that there is nothing major. Now in the mean time, the VyOS
guys can work on their v2.0 and when they have a stable enough API we can
make it a first class citizen in Cloudstack.

This approach would not work for VMWare as in VMWare the management server
directly talks to the VR. However, this problem could be fixed by adding a
middle VM which does the proxying to-and-from the VR. This would also
improve the overall security of the system in VMWare as well.

I am not too concerned about VMWare at the moment as most of us use either
KVM or XenServer. What do you guys think of this approach?

-Syed

On Mon, Sep 19, 2016 at 11:42 AM, Stephan Seitz <
s.se...@secretresearchfacility.com> wrote:

> Hi!
>
> Just to add my 2 cents to that thread:
>
> I'ld really like to see something like vyatta or pfsense integrated as
> "standard" VR.
>
> We'd also talked internally about replacing the VR with some more
> mature "appliance"-like router distro.
>
> pfsense e.g. comes AFAIK with no defined API but instead has a very
> nice GUI.
> How would this fit into the concept of configuring the VR via ACS?
> Would parts of the GUI - like IP configuration and basic firewall rules
>  - hidden or greyed?
> Where would one save the configuration, VPN certificates and so on?
>
>
> - Stephan
>
>
> Am Sonntag, den 18.09.2016, 15:19 + schrieb Marty Godsey:
> > On this note I also mentioned pfsense earlier.
> >
> > www.pfsense.org
> >
> >
> > Regards,
> > Marty Godsey
> >
> > -Original Message-
> > From: ilya [mailto:ilya.mailing.li...@gmail.com]
> > Sent: Sunday, September 18, 2016 1:09 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] Replacing the VR
> >
> > Our options become much better if we consider BSD based routers.
> >
> > Would that be on the table?
> >
> > https://en.wikipedia.org/wiki/List_of_router_and_firewall_distributio
> > ns
> >
> >
> > On 9/16/16 12:04 PM, Will Stevens wrote:
> > >
> > > Ya, your points are all valid Simon.  The lack of standard
> > > libraries
> > > to handle a lot of the details is a problem.  I don't think it is
> > > an
> > > unsolvable problem, but if we spend the time to do that, will we
> > > have
> > > something that will work for us for the next 5 years?  This may be
> > > the
> > > shortest path to getting us where we need to be for the time being.
> > >
> > > What is the best case scenario for the VR going forward which will
> > > last us the next 5 years?  Maybe we just clean up what we have to
> > > do a
> > > major restructuring of the pieces and how they are
> > > implemented.  We
> > > need to keep in mind how maintainable this implementation is
> > > because
> > > that is going to be key going forward IMO.
> > >
> > >
> > >
> > > *Will STEVENS*
> > > Lead Developer
> > >
> > > *CloudOps* *| *Cloud Solutions Experts
> > > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|*
> > > tw
> > > @CloudOps_
> > >
> > > On Fri, Sep 16, 2016 at 2:29 PM, Simon Weller 
> > > wrote:
> > >
> > > >
> > > > I think our other option is to take a real look at what it would
> > > > take
> > > > to fix the VR. In my opinion, a lot of the problems are related
> > > > to
> > > > the monolithic python code base and the fact nothing is actually
> > > > separated.
> > > >
> > > > Secondly, the python scripts (and bash scripts) don't use any
> > > > established libraries to complete tasks and instead shell out and
> > > > run
> > > > commands that are both hard to track and hard to parse on return.
> > > >
> > > >
> > > > If we daemonized this, used a real api for Agent to VR
> > > > communication,
> > > > used common already existing libraries for the system service
> > > > and
> > > > network interactions and spent a bit of time separating out code
> > > > into
> > > > distinct modules, everything would behave a lot better.
> > > >
> > > >
> > > > The pain and suffering is due to years and years of patches and
> > > > constant shelling out to complete tasks in my opinion. If we
> > > > spend
> > > > time to rethink how we interact with the VR in general and we
> > > > abstract the systems and networking stuff and use well known and
> > > > stable libraries to do the work, the VR would be much easier to
> > > > maintain.
> > > >
> > > >
> > > > - Si
> 

Re: trigger scripts by event

[Stephan Seitz]

Thanks Simon!

That was exactly what I was looking for!


Am Montag, den 19.09.2016, 15:44 + schrieb Simon Weller:
> Stephan,
> 
> 
> ACS has supported publishing events to RabbitMQ and Kafta for a few
> releases now.  See this doc: http://docs.cloudstack.apache.org/projec
> ts/cloudstack-administration/en/4.9/events.html
> 
> 
> 
> It's pretty easy to setup and the events make it very easy to trigger
> third party interactions.
> 
> 
> - Si
> 
> 
> 
> From: Stephan Seitz 
> Sent: Monday, September 19, 2016 10:02 AM
> To: dev@cloudstack.apache.org
> Subject: trigger scripts by event
> 
> Hi!
> 
> We'ld like to add some of the provisioned Networks, IPs and VM into
> our
> docu / inventory DB.
> By now, we're gathering infos from the ACS DB as well as from the API
> -
> filtering start/end-date.
> To get things in a more elegant way, I'ld like to run our skripts
> event-triggered.
> 
> So my question is:
> 
> Is there some kind of event-queue where we could identify actions
> like
> provision/destroy vm, add/remove IPs, create/remove an isolated or
> shared network, ...?
> 
> Thanks!
> 
> - Stephan
> 
> 

[GitHub] cloudstack issue #798: CLOUDSTACK-8830 - [Vmware] VM snapshot fails for 12 m...

[nvazquez]

Github user nvazquez commented on the issue:

https://github.com/apache/cloudstack/pull/798
  
Hi @jburwell, yes, actually I was working on other PRs but now I can pick 
up this one, is it ok?


---
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: trigger scripts by event

[Simon Weller]

Stephan,


ACS has supported publishing events to RabbitMQ and Kafta for a few releases 
now.  See this doc: 
http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.9/events.html



It's pretty easy to setup and the events make it very easy to trigger third 
party interactions.


- Si



From: Stephan Seitz 
Sent: Monday, September 19, 2016 10:02 AM
To: dev@cloudstack.apache.org
Subject: trigger scripts by event

Hi!

We'ld like to add some of the provisioned Networks, IPs and VM into our
docu / inventory DB.
By now, we're gathering infos from the ACS DB as well as from the API -
filtering start/end-date.
To get things in a more elegant way, I'ld like to run our skripts
event-triggered.

So my question is:

Is there some kind of event-queue where we could identify actions like
provision/destroy vm, add/remove IPs, create/remove an isolated or
shared network, ...?

Thanks!

- Stephan

Re: [DISCUSS] Replacing the VR

[Stephan Seitz]

Hi!

Just to add my 2 cents to that thread:

I'ld really like to see something like vyatta or pfsense integrated as
"standard" VR.

We'd also talked internally about replacing the VR with some more
mature "appliance"-like router distro.

pfsense e.g. comes AFAIK with no defined API but instead has a very
nice GUI.
How would this fit into the concept of configuring the VR via ACS?
Would parts of the GUI - like IP configuration and basic firewall rules
 - hidden or greyed?
Where would one save the configuration, VPN certificates and so on?


- Stephan


Am Sonntag, den 18.09.2016, 15:19 + schrieb Marty Godsey:
> On this note I also mentioned pfsense earlier.
> 
> www.pfsense.org
> 
> 
> Regards,
> Marty Godsey
> 
> -Original Message-
> From: ilya [mailto:ilya.mailing.li...@gmail.com] 
> Sent: Sunday, September 18, 2016 1:09 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Replacing the VR
> 
> Our options become much better if we consider BSD based routers.
> 
> Would that be on the table?
> 
> https://en.wikipedia.org/wiki/List_of_router_and_firewall_distributio
> ns
> 
> 
> On 9/16/16 12:04 PM, Will Stevens wrote:
> > 
> > Ya, your points are all valid Simon.  The lack of standard
> > libraries 
> > to handle a lot of the details is a problem.  I don't think it is
> > an 
> > unsolvable problem, but if we spend the time to do that, will we
> > have 
> > something that will work for us for the next 5 years?  This may be
> > the 
> > shortest path to getting us where we need to be for the time being.
> > 
> > What is the best case scenario for the VR going forward which will 
> > last us the next 5 years?  Maybe we just clean up what we have to
> > do a 
> > major restructuring of the pieces and how they are
> > implemented.  We 
> > need to keep in mind how maintainable this implementation is
> > because 
> > that is going to be key going forward IMO.
> > 
> > 
> > 
> > *Will STEVENS*
> > Lead Developer
> > 
> > *CloudOps* *| *Cloud Solutions Experts
> > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|*
> > tw 
> > @CloudOps_
> > 
> > On Fri, Sep 16, 2016 at 2:29 PM, Simon Weller 
> > wrote:
> > 
> > > 
> > > I think our other option is to take a real look at what it would
> > > take 
> > > to fix the VR. In my opinion, a lot of the problems are related
> > > to 
> > > the monolithic python code base and the fact nothing is actually
> > > separated.
> > > 
> > > Secondly, the python scripts (and bash scripts) don't use any 
> > > established libraries to complete tasks and instead shell out and
> > > run 
> > > commands that are both hard to track and hard to parse on return.
> > > 
> > > 
> > > If we daemonized this, used a real api for Agent to VR
> > > communication, 
> > > used common already existing libraries for the system service
> > > and 
> > > network interactions and spent a bit of time separating out code
> > > into 
> > > distinct modules, everything would behave a lot better.
> > > 
> > > 
> > > The pain and suffering is due to years and years of patches and 
> > > constant shelling out to complete tasks in my opinion. If we
> > > spend 
> > > time to rethink how we interact with the VR in general and we 
> > > abstract the systems and networking stuff and use well known and 
> > > stable libraries to do the work, the VR would be much easier to
> > > maintain.
> > > 
> > > 
> > > - Si
> > > 
> > > 
> > > 
> > > 
> > > 
> > > From: Marty Godsey 
> > > Sent: Friday, September 16, 2016 12:24 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: RE: [DISCUSS] Replacing the VR
> > > 
> > > So based upon this discussion would it be prudent to wait on
> > > VyOS 
> > > 2.0? The current VR is giving us issues but would the time
> > > invested 
> > > in another "solution" be wasted especially if by the time
> > > another 
> > > option is chose, then coded, then tested, then implemented and
> > > right 
> > > as that time happened to be when VyOS 2.0 is released.  Of course
> > > you 
> > > said they are just in the scoping range so this could still be a
> > > year or more out.
> > > 
> > > Thoughts?
> > > 
> > > Regards,
> > > Marty Godsey
> > > nSource Solutions
> > > 
> > > -Original Message-
> > > From: williamstev...@gmail.com [mailto:williamstev...@gmail.com]
> > > On 
> > > Behalf Of Will Stevens
> > > Sent: Friday, September 16, 2016 10:31 AM
> > > To: dev@cloudstack.apache.org
> > > Cc: dan...@baturin.org
> > > Subject: Re: [DISCUSS] Replacing the VR
> > > 
> > > I just had a quick chat with a couple of the guys over on the
> > > VyOS chat.
> > > I have CC'ed one of them in case we have more licensing
> > > questions.
> > > 
> > > So here is the status with the license "the code inherited from 
> > > Vyatta and our modifications from it is GPLv2 (strict, not v2+).
> > > The 
> > > config reading library is GPLv2 too, so anything that links to is
> > > is GPLv2.
> > > Some 

Re: [DISCUSS] Replacing the VR

[Will Stevens]

Thank you for the feedback Matthew.  The Debian 6 EOL thing is something
that VyOS has taken very seriously.  Everything has been ported to Debian 8
now, but it is still in beta and is not considered 'stable' yet because
they have not been able to regression test the entire feature set yet.  In
talking to them on Friday, the Debian 8 version should be the stable
release within the next 6 months.

Our team discussed some of the implementation details regarding VyOS this
morning and Syed had some really good ideas.  I will see if I can get him
to post his ideas to the list.

Cheers,

*Will STEVENS*
Lead Developer

*CloudOps* *| *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_

On Mon, Sep 19, 2016 at 11:32 AM, Matthew Smart  wrote:

> We have been using Vyatta (and then Vyos) after the fork for all of our
> production routers for over four years now. It is rock solid and performs
> better than the Juniper routers we replaced them with. It is debian based
> underneath its custom shell whose syntax is very much like Juniper. A sudo
> su gets you a standard bash shell just like in any other debian distro and
> I have installed additional packages in the past. It is really easy to
> configure in that the entire router config is held in a single file with a
> dead simple file structure. You can use the commands in their custom shell
> to alter the config but I prefer to just upload a mod to that file... I
> know, I like to live dangerously! lol. Seriously though, they do have
> versioning/rollback capability but last I checked a rollback forced a
> reboot of the router.
>
> The major downside, and one we are struggling with now is that it is
> running an EOL version of debian and that is a HUGE liability for something
> as security critical as an edge router. They have a lot of work ahead of
> them to get out 2.0 but aside from the EOL Debian, Vyos "just works" and
> out of the box would exceed the current VR in pretty much every way.
> Personally, I find the API issue to be less important. #1 priority has to
> be getting a VR that functions at an enterprise level. API integration is
> important but pales compared to that.
>
> Conversely, we are still not in production with Cloudstack specifically
> because of the current state of the VR. IOW, the current VR implementation
> is directly affecting Cloudstack adoption at least anecdotally.
>
> My team is very new to contributing to CS and our time is limited but,
> given my many years of experience administering networks with Vyos at the
> core, if you go that route I will gladly lend my knowledge in helping you
> map out an implementation.
>
> I have evaluated Cloud Router in the past and found it lacking in basic
> features (and especially documentation) that made it a no go for even a
> test build. It is promising and I hope it continues to mature but Vyos is a
> battle hardened and proven technology. Given the option, I always go with
> the known good solution over the shiny one.
>
> I have also used PFsense. Really great project but I have not found it to
> be as stable for me as Vyos, though that might be my lack of BSD experience.
>
> Thanks,
>
>
> Matthew Smart
> President
> Smart Software Solutions Inc.
> 108 S Pierre St.
> Pierre, SD 57501
>
> Phone: (605) 280-0383
> Skype: msmart13
> Email: msm...@smartsoftwareinc.com
>
> On 09/18/2016 11:09 AM, Will Stevens wrote:
>
>> At this point in the discussion, I don't think we should rule anything
>> out.
>> I think it makes sense to explore all the options and then isolate some
>> front runners in terms of software and architecture.
>>
>> On Sep 18, 2016 1:08 AM, "ilya"  wrote:
>>
>> Our options become much better if we consider BSD based routers.
>>>
>>> Would that be on the table?
>>>
>>> https://en.wikipedia.org/wiki/List_of_router_and_firewall_distributions
>>>
>>>
>>> On 9/16/16 12:04 PM, Will Stevens wrote:
>>>
 Ya, your points are all valid Simon.  The lack of standard libraries to
 handle a lot of the details is a problem.  I don't think it is an
 unsolvable problem, but if we spend the time to do that, will we have
 something that will work for us for the next 5 years?  This may be the
 shortest path to getting us where we need to be for the time being.

 What is the best case scenario for the VR going forward which will last

>>> us
>>>
 the next 5 years?  Maybe we just clean up what we have to do a major
 restructuring of the pieces and how they are implemented.  We need to

>>> keep
>>>
 in mind how maintainable this implementation is because that is going to

>>> be
>>>
 key going forward IMO.



 *Will STEVENS*
 Lead Developer

 *CloudOps* *| *Cloud Solutions Experts
 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
 w cloudops.com *|* tw @CloudOps_

 On Fri, Sep 16, 2016 at 2:29 PM, 

[GitHub] cloudstack pull request #1615: CLOUDSTACK-9438: Fix for CLOUDSTACK-9252 - Ma...

[nvazquez]

Github user nvazquez commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1615#discussion_r79419754
  
--- Diff: test/integration/smoke/test_ssvm.py ---
@@ -1197,3 +1205,148 @@ def test_10_destroy_cpvm(self):
 # Call to verify cloud process is running
 self.test_04_cpvm_internals()
 return
+
+@attr(
+tags=[
+"advanced",
+"advancedns",
+"smoke",
+"basic",
+"sg"],
+required_hardware="true")
--- End diff --

Done, thanks @koushik-das 


---
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: [DISCUSS] Replacing the VR

[Matthew Smart]

We have been using Vyatta (and then Vyos) after the fork for all of our 
production routers for over four years now. It is rock solid and 
performs better than the Juniper routers we replaced them with. It is 
debian based underneath its custom shell whose syntax is very much like 
Juniper. A sudo su gets you a standard bash shell just like in any other 
debian distro and I have installed additional packages in the past. It 
is really easy to configure in that the entire router config is held in 
a single file with a dead simple file structure. You can use the 
commands in their custom shell to alter the config but I prefer to just 
upload a mod to that file... I know, I like to live dangerously! lol. 
Seriously though, they do have versioning/rollback capability but last I 
checked a rollback forced a reboot of the router.


The major downside, and one we are struggling with now is that it is 
running an EOL version of debian and that is a HUGE liability for 
something as security critical as an edge router. They have a lot of 
work ahead of them to get out 2.0 but aside from the EOL Debian, Vyos 
"just works" and out of the box would exceed the current VR in pretty 
much every way. Personally, I find the API issue to be less important. 
#1 priority has to be getting a VR that functions at an enterprise 
level. API integration is important but pales compared to that.


Conversely, we are still not in production with Cloudstack specifically 
because of the current state of the VR. IOW, the current VR 
implementation is directly affecting Cloudstack adoption at least 
anecdotally.


My team is very new to contributing to CS and our time is limited but, 
given my many years of experience administering networks with Vyos at 
the core, if you go that route I will gladly lend my knowledge in 
helping you map out an implementation.


I have evaluated Cloud Router in the past and found it lacking in basic 
features (and especially documentation) that made it a no go for even a 
test build. It is promising and I hope it continues to mature but Vyos 
is a battle hardened and proven technology. Given the option, I always 
go with the known good solution over the shiny one.


I have also used PFsense. Really great project but I have not found it 
to be as stable for me as Vyos, though that might be my lack of BSD 
experience.


Thanks,


Matthew Smart
President
Smart Software Solutions Inc.
108 S Pierre St.
Pierre, SD 57501

Phone: (605) 280-0383
Skype: msmart13
Email: msm...@smartsoftwareinc.com

On 09/18/2016 11:09 AM, Will Stevens wrote:

At this point in the discussion, I don't think we should rule anything out.
I think it makes sense to explore all the options and then isolate some
front runners in terms of software and architecture.

On Sep 18, 2016 1:08 AM, "ilya"  wrote:


Our options become much better if we consider BSD based routers.

Would that be on the table?

https://en.wikipedia.org/wiki/List_of_router_and_firewall_distributions


On 9/16/16 12:04 PM, Will Stevens wrote:

Ya, your points are all valid Simon.  The lack of standard libraries to
handle a lot of the details is a problem.  I don't think it is an
unsolvable problem, but if we spend the time to do that, will we have
something that will work for us for the next 5 years?  This may be the
shortest path to getting us where we need to be for the time being.

What is the best case scenario for the VR going forward which will last

us

the next 5 years?  Maybe we just clean up what we have to do a major
restructuring of the pieces and how they are implemented.  We need to

keep

in mind how maintainable this implementation is because that is going to

be

key going forward IMO.



*Will STEVENS*
Lead Developer

*CloudOps* *| *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_

On Fri, Sep 16, 2016 at 2:29 PM, Simon Weller  wrote:


I think our other option is to take a real look at what it would take to
fix the VR. In my opinion, a lot of the problems are related to the
monolithic python code base and the fact nothing is actually separated.

Secondly, the python scripts (and bash scripts) don't use any

established

libraries to complete tasks and instead shell out and run commands that

are

both hard to track and hard to parse on return.


If we daemonized this, used a real api for Agent to VR communication,

used

common already existing libraries for the system service and network
interactions and spent a bit of time separating out code into distinct
modules, everything would behave a lot better.


The pain and suffering is due to years and years of patches and constant
shelling out to complete tasks in my opinion. If we spend time to

rethink

how we interact with the VR in general and we abstract the systems and
networking stuff and use well known and stable libraries to do the work,
the VR would be much easier to maintain.


- Si

trigger scripts by event

[Stephan Seitz]

Hi!

We'ld like to add some of the provisioned Networks, IPs and VM into our
docu / inventory DB.
By now, we're gathering infos from the ACS DB as well as from the API -
filtering start/end-date.
To get things in a more elegant way, I'ld like to run our skripts
event-triggered.

So my question is:

Is there some kind of event-queue where we could identify actions like
provision/destroy vm, add/remove IPs, create/remove an isolated or
shared network, ...?

Thanks!

- Stephan

[GitHub] cloudstack issue #1560: CLOUDSTACK-9386: DS template copies don’t get dele...

[nvazquez]

Github user nvazquez commented on the issue:

https://github.com/apache/cloudstack/pull/1560
  
Thanks @jburwell, I've opened new PR (1676) against 4.9 release branch


---
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 pull request #1676: CLOUDSTACK-9502: DS template copies don’t g...

[nvazquez]

GitHub user nvazquez opened a pull request:

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

CLOUDSTACK-9502: DS template copies don’t get deleted in VMware ESXi with 
multiple clusters and zone wide storage (include CLOUDSTACK-9386 into 4.9 
release branch)

Include #1560 into 4.9 release branch

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

$ git pull https://github.com/nvazquez/cloudstack dstemplates49

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

https://github.com/apache/cloudstack/pull/1676.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 #1676


commit 69854e9e965810d06642f22bc4b343624edc55d8
Author: nvazquez 
Date:   2016-09-19T13:52:52Z

CLOUDSTACK-9502: DS template copies don’t get deleted in VMware ESXi with 
multiple clusters and zone wide storage




---
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 #872: Strongswan vpn feature

[swill]

Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/872
  
I will start doing some testing on this today.  Thanks...


---
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 pull request #1615: CLOUDSTACK-9438: Fix for CLOUDSTACK-9252 - Ma...

[nvazquez]

Github user nvazquez commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1615#discussion_r79389208
  
--- Diff: test/integration/smoke/test_ssvm.py ---
@@ -1197,3 +1205,148 @@ def test_10_destroy_cpvm(self):
 # Call to verify cloud process is running
 self.test_04_cpvm_internals()
 return
+
+@attr(
+tags=[
+"advanced",
+"advancedns",
+"smoke",
+"basic",
+"sg"],
+required_hardware="false")
--- End diff --

Done, thanks!


---
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 #1639: CLOUDSTACK-9453: WIP : Marvin optimizations and fixe...

[serg38]

Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1639
  
Macchinina template doesn't seem to work in vmware hypervisor. When VM 
deployed eth0 is not created. We probably need to make sure a template is fully 
operational on all 3 hypervisors to include it as a default.



---
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 #1675: CLOUDSTACK-9453: WIP

[serg38]

Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1675
  
Macchinina template doesn't seem to work in vmware hypervisor. When VM 
deployed eth0 is not created. We probably need to make sure a template is fully 
operational on all 3 hypervisors to include it as a default.


---
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 #1602: CLOUDSTACK-9422: Granular 'vmware.create.full.clone'...

[nvazquez]

Github user nvazquez commented on the issue:

https://github.com/apache/cloudstack/pull/1602
  
Thanks for your help @jburwell !


---
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 #872: Strongswan vpn feature

[rhtyd]

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/872
  
Thanks @jayapalu I'm rebuilding some infra, I'll get back to you soon.


---
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 #1591: Updating Alert codes

[rhtyd]

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1591
  
@jburwell we can merge this, since it's a doc change no tests are needed.


---
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 #1591: Updating Alert codes

[rhtyd]

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1591
  
LGTM @jburwell I checked the changes against the values defined in 
`AlertService` and they check out perfectly.


---
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 #1664: CLOUDSTACK-8676 Deploy user instance from vm snapsho...

[sateesh-chodapuneedi]

Github user sateesh-chodapuneedi commented on the issue:

https://github.com/apache/cloudstack/pull/1664
  
@jburwell Yes, currently working on breaking the methods into multiple 
smaller units, and adding unit tests. Along with these adding the marvin tests 
from the other PR so that PR contains functional tests as well.


---
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 #872: Strongswan vpn feature

[jayapalu]

Github user jayapalu commented on the issue:

https://github.com/apache/cloudstack/pull/872
  
@rhtyd @pdion891 @swill 
I have squashed the commits. Added the template changes to install 
strongswan 5.2.
Can one you trigger the systemvm template job on this branch. 


---
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 #1639: CLOUDSTACK-9453: WIP : Marvin optimizations and fixe...

[abhinandanprateek]

Github user abhinandanprateek commented on the issue:

https://github.com/apache/cloudstack/pull/1639
  
Thanks @karuturi @rhtyd 
I created a new one for 4.8 here 
https://github.com/apache/cloudstack/pull/1675 @jburwell 


---
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 pull request #1675: CLOUDSTACK-9453: WIP

[abhinandanprateek]

GitHub user abhinandanprateek opened a pull request:

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

CLOUDSTACK-9453: WIP

  1. Adding small sized macchinina template as built in templates
  2. Adding methods so the test writers haev choice to use any of these
  3. Updateing test_host_ha to use macchinina template
  4. Misc fixes encoutered while running component tests

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

$ git pull https://github.com/shapeblue/cloudstack marvin_opt_4_8

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

https://github.com/apache/cloudstack/pull/1675.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 #1675


commit 86946a9259980bcee8f60e15c18b6edc61508dc7
Author: Abhinandan Prateek 
Date:   2016-08-16T04:57:28Z

CLOUDSTACK-9453: WIP
  1. Adding small sized macchinina template as built in templates
  2. Adding methods so the test writers haev choice to use any of these
  3. Updateing test_host_ha to use macchinina template
  4. Misc fixes encoutered while running component tests




---
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 #1666: CLOUDSTACK-9480, CLOUDSTACK-9495 fix egress rule inc...

[karuturi]

Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1666
  
I think in the latest code change, `fwr` is not defined before and hence 
`fwr +=` operation will fail.
Also, the ICMP rule is still appended and not Inserted in the beginning. Is 
that ok? (I dont have enough iptables knowledge.)


---
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 #1666: CLOUDSTACK-9480, CLOUDSTACK-9495 fix egress rule inc...

[karuturi]

Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1666
  
@murali-reddy recurring failures will be listed as failing since last n 
runs. 
The router related tests(lb, network ops) are failing due to this PR. 
Are the tests running(manual or BVT) at your end after the new changes?


---
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 #1666: CLOUDSTACK-9480, CLOUDSTACK-9495 fix egress rule inc...

[murali-reddy]

Github user murali-reddy commented on the issue:

https://github.com/apache/cloudstack/pull/1666
  
@jburwell Jenkins was failing unrelated unit-test failure. I have triggered 
new Jenkins build which has passed. Changed the title of the PR to reflect that 
its fixing issues CLOUDSTACK-9480, CLOUDSTACK-9495. Will send a new PR for 4.8.

@karuturi @cloudmonger failed tests seems to have failed in build #99 as 
well. Is it environment issue? Failure in test_vm_snapshots.py are totally 
unrelated to changes in the fix.


---
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 #872: Strongswan vpn feature

[jayapalu]

Github user jayapalu commented on the issue:

https://github.com/apache/cloudstack/pull/872
  
@pdion891 

Below is the Remote access vpn config, update left with the VR public ip.
#ipsec remote access vpn configuration
conn L2TP-PSK
authby=psk
pfs=no
rekey=no
keyingtries=3
keyexchange=ikev1
forceencaps=yes
leftfirewall=yes
leftnexthop=%defaultroute
#
# --
# The VPN server.
#
# Allow incoming connections on the external network interface.
# If you want to use a different interface or if there is no
# defaultroute, you can use:   left=your.ip.addr.ess
#
left=172.26.0.151
#
leftprotoport=17/1701
# If you insist on supporting non-updated Windows clients,
# you can use:leftprotoport=17/%any
#
# --
# The remote user(s).
#
# Allow incoming connections only from this IP address.
right=%any
# If you want to allow multiple connections from any IP address,
# you can use:right=%any
#
rightprotoport=17/%any
#
# --
# Change 'ignore' to 'add' to enable this configuration.
#
rightsubnetwithin=0.0.0.0/0
auto=add


---
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 pull request #1615: CLOUDSTACK-9438: Fix for CLOUDSTACK-9252 - Ma...

[koushik-das]

Github user koushik-das commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1615#discussion_r79357165
  
--- Diff: test/integration/smoke/test_ssvm.py ---
@@ -1197,3 +1205,148 @@ def test_10_destroy_cpvm(self):
 # Call to verify cloud process is running
 self.test_04_cpvm_internals()
 return
+
+@attr(
+tags=[
+"advanced",
+"advancedns",
+"smoke",
+"basic",
+"sg"],
+required_hardware="false")
--- End diff --

Is it possible to run this test on Simulator? If not please change 
required_hardware to true.


---
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 #1643: CLOUDSTACK-9460: For long running transactions, if t...

[abhinandanprateek]

Github user abhinandanprateek commented on the issue:

https://github.com/apache/cloudstack/pull/1643
  
@jburwell created a new PR for 4.8 here 
https://github.com/apache/cloudstack/pull/1674. I was getting many conflicts 
due to which I decided to create a new PR and cherry picked the  commit.


---
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 pull request #1674: CLOUDSTACK-9460: For long running transaction...

[abhinandanprateek]

GitHub user abhinandanprateek opened a pull request:

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

CLOUDSTACK-9460: For long running transactions, if the connection is

timed out by the mysql server then refresh it

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

$ git pull https://github.com/shapeblue/cloudstack master_db_timout_4_8

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

https://github.com/apache/cloudstack/pull/1674.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 #1674


commit a813baed49e50c014fa22df81fc6bc8bc9095213
Author: Abhinandan Prateek 
Date:   2016-08-17T10:45:15Z

CLOUDSTACK-9460: For long running transactions, if the connection is
timed out by the mysql server then refresh it




---
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: CS 4.9 NIO Selector wait time PR-1601

[Rohit Yadav]

Thanks for sharing Martin, I'm glad it worked for you.

Regards.

From: martin kolly 
Sent: 13 September 2016 00:52:49
To: dev@cloudstack.apache.org; Rohit Yadav
Subject: Re: CS 4.9 NIO Selector wait time PR-1601


We could fix the issue by generating new pairs of ssh keys. Here the procedure 
we applied:

1) Stop Management Server

2) Delete SSH Keys in mysql Database:
delete from configuration  where name = "ssh.publickey" ;
delete from configuration  where name = "ssh.privatekey" ;

3) Delete the SSH Keys
rm /var/lib/cloudstack/management/.ssh/id_rsa.pub
rm /var/lib/cloudstack/management/.ssh/id_rsa

4) Start the Management Server
- SSH Keys are generated and mysql entries inserted

# grep  ssh-keygen /var/log/cloudstack/management/management-server.log
2016-09-12 20:47:40,000 DEBUG [c.c.u.s.Script] (main:null) (logid:) Executing: 
/bin/bash -c if [ -f /var/lib/cloudstack/management/.ssh/id_rsa ]; then rm -f 
/var/lib/cloudstack/management/.ssh/id_rsa; fi; ssh-keygen -t rsa -N '' -f 
/var/lib/cloudstack/management/.ssh/id_rsa -q
2016-09-12 20:54:23,835 DEBUG [c.c.u.s.Script] (main:null) (logid:) Executing: 
/bin/bash -c if [ -f /var/lib/cloudstack/management/.ssh/id_rsa ]; then rm -f 
/var/lib/cloudstack/management/.ssh/id_rsa; fi; ssh-keygen -t rsa -N '' -f 
/var/lib/cloudstack/management/.ssh/id_rsa -q

Now works like a charm!

thanks and regards
martin


On 09/12/2016 04:22 PM, martin kolly wrote:
Hi Rohit

Finally we had some time to dig deeper into this issue. The /bin/bash issue was 
a typo on our side, sorry!

System VM was destroyed/recreated several times.

But something with the ssh keys is still wrong. The KVM is still asking for the 
pass phrase when ssh into system vms.

# Management Server
mysql> select * from configuration where name = "ssh.publickey" \G;
*** 1. row ***
 category: Hidden
 instance: DEFAULT
component: management-server
 name: ssh.publickey
value: 
XiVYy4PpuS4nKoQZRsj+3VQr0dxXFt+s15ZVXiIbaacJ5RsLwlSEO75kbPaL7pDAhyZbcCtC3ICSDUAeJysZ958cTVrl390Lk0UtRoLOUKlNIuOEVzdJpZDmsrm90ZK+OYMaHKf2cVz3xekZv/BS5Kpr2dnieUNZlQlgCXgldwENNZ7+MSlPRLiJ+7/SEBtfn9VTUkXvedhbBtIh3fxexOR/xN+zGRTyotlYANxiypklrlZp6/364JfXoeQviE6aVzsVDboALW+ov6gFj8ziO7vhoUN9M6rJohGnPawjgMCBasVCjWqoFaezKlf/0vEDf3NkKOoi1kqvSDGOumCFyQ7+9BOBq8qdqnP3i4e4aJ3vLdVWlRKRaUps08xOP8+j36L9lrO0YAkGXH+bAQXzQMqIFLvjRGX+zOnEikRQ2Zv0JJSlAvftF13BQrTt1SV/ttDa0qo7fzqF1WUijZb/PcKLGUeC30U9kG4JLmrHcuaoe43I08qkGJEofUetZGQLIYhsUqXiVSflGEGfJTWJgMGKAVbGUF5a
  description: Public key for the entire CloudStack
default_value: NULL
  updated: NULL
scope: NULL
   is_dynamic: 0
1 row in set (0.00 sec)

mysql> select * from configuration where name = "ssh.privatekey" \G;
*** 1. row ***
 category: Hidden
 instance: DEFAULT
component: management-server
 name: ssh.privatekey
value: 
j+Z5ckPXUq7lwo2L4OYaaiDOA/fdUpadX3h7E/DA1rwPRSz967eckCbRRpCtCWxfQjtAgPNfLgGIQHX4K7o9yF9DBXG0ESXoECyrRAOTmfZdvdSZceRGd9TYcjwCAn4s8GKGQRKeQSQLL8Pusc/PmYLISIomkOHhZB3lp1bfniKC6uf6RwhRFNfX38ZeqVhRNgagK2hxOo67Ev7uUX1NIUWw/ROq/RC7bG58DD1uhUOX5Bm5wVMSmf3Pv7s/z2t7ZGcX8YMnW
.



/uPooWhUQpcG8Q8APvfEKMp0BVJATh4Gk4qkgnR4CHyefUYCDHmWZnpuCj1ra7Kn5LV7AdWG1+C7bl7hSmpxE8StLfEwe72zuPJsI86LekxhJJpsorjvSFYklJhGizSs4uuyRP2Dqayx1qFkFJe26AiWb86ld2gQ2Vwj3ozgHX2OMp60jQM8ZVM9VuroOEmiOZ5gkfhFFIf5Y78WcZU2ScSCAHVavNAIsfX+i01iNxwnXtrmrA9ctlZGuZZRR3TklAXQz4M69SFFYuo5e7OsJ2/Tr9K7AhUHA8kwR+BxPLFGRlJpyhmLUuPartDKRBAp2BwU1XsFiIs8Y6pn9wkRJaeeDdpUt9zPCYMHaHtXQvFMe+d96J4HMPvfLgGnd55Hz7GKsglX9su7XpuAqzkuPM5u6GY5LLAtXUOqE2Wm855sLRW1kbHnX8pAfIe9wQbfUQ9wsfCh66w1duce0vyuj4A7A8HC4V8+U2qXjwMIhLpfO5phfUy4drlUzBzx9ZMK+JUYP6kszj61M09psoYggUBXMYCfg6oWJSjA8=
  description: Private key for the entire CloudStack
default_value: NULL
  updated: NULL
scope: NULL
   is_dynamic: 0
1 row in set (0.00 sec)

# Secondary Storage VM (note that the key is equal to the management server 
database entry ssh.publickey)
root@s-252-VM:~# cat /root/.ssh/authorized_keys
XiVYy4PpuS4nKoQZRsj+3VQr0dxXFt+s15ZVXiIbaacJ5RsLwlSEO75kbPaL7pDAhyZbcCtC3ICSDUAeJysZ958cTVrl390Lk0UtRoLOUKlNIuOEVzdJpZDmsrm90ZK+OYMaHKf2cVz3xekZv/BS5Kpr2dnieUNZlQlgCXgldwENNZ7+MSlPRLiJ+7/SEBtfn9VTUkXvedhbBtIh3fxexOR/xN+zGRTyotlYANxiypklrlZp6/364JfXoeQviE6aVzsVDboALW+ov6gFj8ziO7vhoUN9M6rJohGnPawjgMCBasVCjWqoFaezKlf/0vEDf3NkKOoi1kqvSDGOumCFyQ7+9BOBq8qdqnP3i4e4aJ3vLdVWlRKRaUps08xOP8+j36L9lrO0YAkGXH+bAQXzQMqIFLvjRGX+zOnEikRQ2Zv0JJSlAvftF13BQrTt1SV/ttDa0qo7fzqF1WUijZb/PcKLGUeC30U9kG4JLmrHcuaoe43I08qkGJEofUetZGQLIYhsUqXiVSflGEGfJTWJgMGKAVbGUF5a

root@s-252-VM:~# ifconfig eth0
eth0  Link encap:Ethernet  HWaddr 0e:00:a9:fe:00:18
  inet addr:169.254.0.24  Bcast:169.254.255.255  Mask:255.255.0.0

#KVM Hosts
root@kvm704:~/.ssh# cat 
/root/.ssh/id_rsa.pub.cloud

[GitHub] cloudstack issue #1669: Make CloudStack JSP-free

[borisstoyanov]

Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/1669
  
LGTM, I've checkout the PR, builded it and deployed a simulator zone, then 
ran through a few localizations and did exploratory testing in the UI, all seem 
to work fine. 


---
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 pull request #1611: marvin: deploy clusters in separate threads

[rhtyd]

Github user rhtyd commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1611#discussion_r79337718
  
--- Diff: tools/marvin/marvin/deployDataCenter.py ---
@@ -224,6 +225,15 @@ def createClusters(self, clusters, zoneId, podId, 
vmwareDc=None):
podId,
clusterId)
 
+threads = []
+for cluster in clusters:
+t = threading.Thread(target=createCluster, args=(cluster,))
--- End diff --

Sure, that makes sense. I'll fix that.


---
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 #1511: 4.9/master bountycastle changes

[rhtyd]

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1511
  
@jburwell these are major changes so they need to go into master, 
targetting 4.10, or 4.11. This PR was created based on Daan's original PR, I'll 
resume working on this soon.


---
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 #1639: CLOUDSTACK-9453: WIP : Marvin optimizations and fixe...

[rhtyd]

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1639
  
@abhinandanprateek yes, click on `edit` on your PR you should be able to 
change the base branch.


---
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 #1669: Make CloudStack JSP-free

[rhtyd]

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1669
  
CloudStack UI used dictionary, dictionary2 and index jsp files.

The dictionary jsp files simply added a dictionary (java script object or 
map) by reading through messages properties for various translations. Replacing 
them was easy, we added a python script (`tools/transifex/gen-l10n.py`) that 
would generate js files (at build time) by reading through the `messages` files 
such that the generated dictionary (object or map) would be exactly same as 
what the jsp files did.

The `index.jsp` file primarily did two things: (1) include dictionary, 
dictionary2 jsp files, (2) used them for translating strings. By replacing the 
dictionary jsp files with auto-generated translation js file based on a `lang` 
cookie exactly the same dictionary object was still accessible to the index.jsp 
file. All the translated strings in index.jsp were replaced with a new/custom 
`DOM` element ``, and some code was added that would 
process and add text to this new dom element based on the translation key set. 
Replacement of `

[GitHub] cloudstack issue #1639: CLOUDSTACK-9453: WIP : Marvin optimizations and fixe...

[karuturi]

Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1639
  
@abhinandanprateek 
https://github.com/blog/2224-change-the-base-branch-of-a-pull-request


---
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 #1639: CLOUDSTACK-9453: WIP : Marvin optimizations and fixe...

[abhinandanprateek]

Github user abhinandanprateek commented on the issue:

https://github.com/apache/cloudstack/pull/1639
  
@jburwell rebased it 

@rhtyd is there a way to move a PR to another branch without creating a new 
one ?


---
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 #1643: CLOUDSTACK-9460: For long running transactions, if t...

[rhtyd]

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1643
  
@jburwell yes that is possible, @abhinandanprateek please edit the PR and 
change the base branch, then rebase your PR branch against 4.8 branch.


---
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.
---