Re: Is anyone using SRX Integration?

[Jayapal Uradi]

On 07-Jun-2019, at 1:19 PM, Richard Lawley 
mailto:rich...@richardlawley.com>> wrote:

Are you using them, or is this just something which has been seen in the past?

We would like to get the current versions supported, but I don't want
to break functionality for existing systems.  JunOS 10 is very old!  I
don't have access to anything older than 15, so I don't know at what
point the syntax changed to prevent the current code from working.

The last version we used is JunOS 10.x only.
You can check the xml config files at the code path  scripts/network/juniper/,  
in JunOS 15 to see configuration differences.

Thanks,
Jayapal


On Fri, 7 Jun 2019 at 08:20, Jayapal Uradi 
mailto:jayapal.ur...@accelerite.com>> wrote:

Hi,

The mentioned functionalities works with  JunOs 10.x.
Not used JunOs 15.x. May be backward compatibility issues.


Thanks,
Jayapal


On 07-Jun-2019, at 12:45 PM, Richard Lawley 
mailto:rich...@richardlawley.com><mailto:rich...@richardlawley.com>>
 wrote:

Hi,

We've recently added a couple of Juniper SRXs, but are finding that
the integration with CloudStack is very broken.  So far there have
been a number of things which just don't work:
* Adding Static NAT Rules
* Adding Port Forwarding Rules
* Removing Port Forwarding Rules

I've found and fixed locally some of these things, but I'm trying to
work out whether this functionality ever worked?  The "Supported
External Devices" on the CloudStack website lists "SRX (Model srx100b)
versions 10.3 to 10.4 R7.5" - JunOS 10 went EOL in 2014.  We've been
using 15.x, so either the functionality never worked, or the changes
in JunOS broke compatibility with CloudStack.

I'm working finding and fixing the functionality, but I'd be
interested to know whether anyone was actively using any of this
integration, as if so, the fixes I apply may well break compatibility
with (much) older versions.

Regards,

Richard

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: Is anyone using SRX Integration?

[Jayapal Uradi]

Hi,

The mentioned functionalities works with  JunOs 10.x.
Not used JunOs 15.x. May be backward compatibility issues.


Thanks,
Jayapal


On 07-Jun-2019, at 12:45 PM, Richard Lawley 
mailto:rich...@richardlawley.com>> wrote:

Hi,

We've recently added a couple of Juniper SRXs, but are finding that
the integration with CloudStack is very broken.  So far there have
been a number of things which just don't work:
* Adding Static NAT Rules
* Adding Port Forwarding Rules
* Removing Port Forwarding Rules

I've found and fixed locally some of these things, but I'm trying to
work out whether this functionality ever worked?  The "Supported
External Devices" on the CloudStack website lists "SRX (Model srx100b)
versions 10.3 to 10.4 R7.5" - JunOS 10 went EOL in 2014.  We've been
using 15.x, so either the functionality never worked, or the changes
in JunOS broke compatibility with CloudStack.

I'm working finding and fixing the functionality, but I'd be
interested to know whether anyone was actively using any of this
integration, as if so, the fixes I apply may well break compatibility
with (much) older versions.

Regards,

Richard

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: Switching backup VR to master manually

[Jayapal Uradi]

Hi Rakesh,


When backup upgraded to newer version and master is destroying backup suppose 
to become master and pickup the connections automatically. RVR is there to 
avoid downtime.
Changing the state of backup is time critical and practically it is difficult. 
In your case it seems there is bug, due to that connections info is  shared.

-Jayapal

On 20-May-2019, at 1:46 PM, Rakesh Venkatesh 
mailto:www.rakeshv@gmail.com>> wrote:

Hello

Is there a way to switch the backup virtual router to master state manually
by triggering something or running some scripts?

Currently when I restart network with cleanup option, first the backup will
be upgraded to newer cloudstack version and when the master is destroyed
then only backup becomes the master and this process might take atleast
5-10 seconds. In the meantime there will be dowmtime. Is there a way to
quickly change the state?

Im thinking on stopping the keeaplived on master so that backup will become
master quickly. Is there a better way to do it?

--
Thanks and regards
Rakesh venkatesh

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: SSL offload in the VR

[Jayapal Uradi]

What I remember is ssl offload feature  added for netscaler  and  
assignCertToLoadBalancer API added during that time.

-Jayapal

> On 21-Nov-2018, at 5:06 AM, Pierre-Luc Dion  wrote:
> 
> Hey Paul, I'm not aware the vr support ssl offload. What you are trying to
> achieve, there might be a work around.
> 
> Le mar. 20 nov. 2018 07 h 08, Paul Angus  a
> écrit :
> 
>> Apologies if my GitHub foo has abandoned me (it wouldn’t me the first
>> time);
>> 
>> I searched for files which contained the API command
>> ‘assignCertToLoadBalancer’ and found ‘AssignCertToLoadBalancerCmd.java’
>> 
>> According to the history it was first committed as part of PR #2283
>> “CLOUDSTACK-10105: Use maven standard project structure in all projects” [1]
>> 
>> 
>> https://github.com/apache/cloudstack/commits/1d05fead49f5c856257a741b07122f5633d2e359/api/src/main/java/org/apache/cloudstack/api/command/user/loadbalancer/AssignCertToLoadBalancerCmd.java
>> 
>> again, sorry if I’ve misread or misinterpreted the history…
>> 
>> Kind regards,
>> 
>> Paul Angus
>> 
>> From: Marc-Aurèle Brothier 
>> Sent: 20 November 2018 11:23
>> To: Paul Angus 
>> Cc: dev@cloudstack.apache.org
>> Subject: Re: SSL offload in the VR
>> 
>> Hi Paul,
>> 
>> What made you think so? I haven’t pushed any change related to the VR. At
>> Exoscale, we removed the VR entirely instead and moved the services down at
>> the HV level.
>> 
>> Kind regards,
>> Marc-Aurèle
>> 
>> 
>> paul.an...@shapeblue.com
>> www.shapeblue.com
>> Amadeus House, Floral Street, London  WC2E 9DPUK
>> @shapeblue
>> 
>> 
>> 
>> On 20 Nov 2018, at 09:04, Paul Angus > paul.an...@shapeblue.com>> wrote:
>> Hi Marc-Aurèle,
>> 
>> As far as I can tell, I believe that you added the ability to upload an
>> SSL certificate to the VR in 4.11
>> I can’t find any user documentation for it in our Wiki or the in
>> read-the-docs.
>> I guess it’s something that you use at Exoscale, could you do a pull
>> request to cloudstack-documentation or forward me some documentation which
>> I can then add to the users documentation.
>> 
>> 
>> Kind regards,
>> 
>> Paul Angus
>> 
>> 
>> paul.an...@shapeblue.com
>> www.shapeblue.com
>> @shapeblue
>> 
>> 
>> 
>> 

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: [ANNOUNCE] New committer: Andrija Panić

[Jayapal Uradi]

Congratulations Andrija Panić

-Jayapal

On 19-Nov-2018, at 9:57 AM, Tutkowski, Mike 
mailto:mike.tutkow...@netapp.com>> wrote:

Hi everyone,

The Project Management Committee (PMC) for Apache CloudStack
has invited Andrija Panić to become a committer and I am pleased
to announce that he has accepted.

Please join me in congratulating Andrija on this accomplishment.

Thanks!
Mike

Re: [DISCUSS] Why we MARK packets?

[Jayapal Uradi]

Rohit,

My comments inline.

On Apr 19, 2018, at 1:52 AM, Rohit Yadav 
> wrote:

Nevermind, found the use of custom routing tables. In case someone want to 
refer, hints are here:

https://github.com/apache/cloudstack/pull/2514#issuecomment-382510915


Jayapal and others - I've another one, is there a way to do routing without 
marking packets at all, even in case of VRs with additional public interfaces?

AFAIK marking is the only way to do it.
Do you have any performance numbers with and without mark rules.

- Rohit

>




From: Rohit Yadav >
Sent: Wednesday, April 18, 2018 10:39:02 PM
To: dev@cloudstack.apache.org; 
us...@cloudstack.apache.org
Subject: [DISCUSS] Why we MARK packets?

All,


I could not find any history around 'why' we MARK or CONNMARK packets in mangle 
table in VRs? I found an issue in case of VPCs where `MARK` iptable rules 
failed hair-pin nat (as described in this PR: 
https://github.com/apache/cloudstack/pull/2514)


The valid usage I found was wrt VPN_STATS, however, the usage is not exported 
at all, it is commented:

https://github.com/apache/cloudstack/blob/master/systemvm/debian/opt/cloud/bin/vpc_netusage.sh#L141


Other than for debugging purposes in the VR, marking packets and connections I 
could not find any valid use. Please do share if you're using marked packets 
(such as VPN ones etc) outside of VR scope?


I propose we remove MARK on packets which is cpu intensive and slows the 
traffic (a bit), instead CONNMARK can still be used to mark connections and 
debug VRs without actually changing the packet marking permanently. Thoughts?


- Rohit





rohit.ya...@shapeblue.com
www.shapeblue.com>
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue




rohit.ya...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: [DISCUSS] Why we MARK packets?

[Jayapal Uradi]

Hi,

Below are the uses of marking packets.

1. Marking is required to route the packets into correct interface in case 
additional public interfaces in VR.
2. Packets with VPN marking are accepted in first place of NAT POSTROUTING. 
Without marking these packets source ip will be replaced with source-nat IP.

Thanks,
Jayapal


> On Apr 18, 2018, at 10:39 PM, Rohit Yadav  wrote:
> 
> All,
> 
> 
> I could not find any history around 'why' we MARK or CONNMARK packets in 
> mangle table in VRs? I found an issue in case of VPCs where `MARK` iptable 
> rules failed hair-pin nat (as described in this PR: 
> https://github.com/apache/cloudstack/pull/2514)
> 
> 
> The valid usage I found was wrt VPN_STATS, however, the usage is not exported 
> at all, it is commented:
> 
> https://github.com/apache/cloudstack/blob/master/systemvm/debian/opt/cloud/bin/vpc_netusage.sh#L141
> 
> 
> Other than for debugging purposes in the VR, marking packets and connections 
> I could not find any valid use. Please do share if you're using marked 
> packets (such as VPN ones etc) outside of VR scope?
> 
> 
> I propose we remove MARK on packets which is cpu intensive and slows the 
> traffic (a bit), instead CONNMARK can still be used to mark connections and 
> debug VRs without actually changing the packet marking permanently. Thoughts?
> 
> 
> - Rohit
> 
> 
> 
> 
> 
> rohit.ya...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> 
> 
> 

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: ConfigDrive status

[Jayapal Uradi]

Yes. 
In case shared network there is only DHCP and DNS and user data. If the DHCP 
and DNS is external then I don’t want to launch a VR only for user data.
Initially it was started to address only specific requirement.

We can have a config drive provider and it can be extended to all 
networks/zones.

Thanks,
Jayapal

> On Mar 27, 2018, at 1:48 PM, Nux! <n...@li.nux.ro> wrote:
> 
> Hi Jayapal,
> 
> This has probably already been discussed and am missing a lot of context, but 
> can you summarise why this is not applied in all zones?
> A network independent userdata provider should seem like the lowest common 
> denominator, right?
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> - Original Message -
>> From: "Jayapal Uradi" <jayapal.ur...@accelerite.com>
>> To: "dev" <dev@cloudstack.apache.org>
>> Sent: Tuesday, 27 March, 2018 05:34:44
>> Subject: Re: ConfigDrive status
> 
>> Hi Nux,
>> 
>> It is developed only for advanced zone shared network (offering without any
>> services).
>> This feature is developed on xenserver, kvm and vmware hypervisor.
>> 
>> It can be extended to other networks.
>> 
>> -Jayapal
>>> On Mar 26, 2018, at 9:56 PM, Nux! <n...@li.nux.ro> wrote:
>>> 
>>> Thanks for all the feedback, I'll do some reading then.
>>> 
>>> Lucian
>>> 
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>> 
>>> Nux!
>>> www.nux.ro
>>> 
>>> - Original Message -
>>>> From: "ilya musayev" <ilya.mailing.li...@gmail.com>
>>>> To: "dev" <dev@cloudstack.apache.org>
>>>> Sent: Monday, 26 March, 2018 17:03:30
>>>> Subject: Re: ConfigDrive status
>>> 
>>>> Lucian
>>>> 
>>>> We reported 3-4 issues with config drive. It’s being worked on. It does
>>>> work - but not per agreed upon specifications.
>>>> 
>>>> See below
>>>> 
>>>> 
>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-10287
>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-10288
>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-10289
>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-10290
>>>> 
>>>> Regards
>>>> Ilya
>>>> 
>>>> On Mon, Mar 26, 2018 at 8:58 AM Dag Sonstebo <dag.sonst...@shapeblue.com>
>>>> wrote:
>>>> 
>>>>> Hi Lucian,
>>>>> 
>>>>> I’m maybe not the right person to answer this – but my understanding is it
>>>>> only kicks in when you have a network offering without a VR, at which 
>>>>> point
>>>>> the metadata etc. is presented as the config drive. Happy to be corrected
>>>>> on this.
>>>>> 
>>>>> We did however have a really major gotcha 18 months ago – when a customer
>>>>> did a CloudStack upgrade and ended up with new unexpected config drives
>>>>> causing changes to all the VMware disk controller addressing – meaning VMs
>>>>> wouldn’t boot, couldn’t see disks, etc. If you use VMware I would test
>>>>> beforehand.
>>>>> 
>>>>> Regards,
>>>>> Dag Sonstebo
>>>>> Cloud Architect
>>>>> ShapeBlue
>>>>> 
>>>>> On 26/03/2018, 14:50, "Nux!" <n...@li.nux.ro> wrote:
>>>>> 
>>>>>   Hi,
>>>>> 
>>>>>   I am interested in the ConfigDrive feature.
>>>>>   Before I potentially waste time on it, is anyone around here using it
>>>>> or can clarify whether it's usable or not or gotchas etc?
>>>>> 
>>>>>   Regards,
>>>>>   Lucian
>>>>> 
>>>>>   --
>>>>>   Sent from the Delta quadrant using Borg technology!
>>>>> 
>>>>>   Nux!
>>>>>   www.nux.ro
>>>>> 
>>>>> 
>>>>> 
>>>>> dag.sonst...@shapeblue.com
>>>>> www.shapeblue.com
>>>>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>>>>> @shapeblue
>>>>> 
>>>>> 
>>>>> 
>> 
>> DISCLAIMER
>> ==
>> This e-mail may contain privileged and confidential information which is the
>> property of Accelerite, a Persistent Systems business. It is intended only 
>> for
>> the use of the individual or entity to which it is addressed. If you are not
>> the intended recipient, you are not authorized to read, retain, copy, print,
>> distribute or use this message. If you have received this communication in
>> error, please notify the sender and delete all copies of this message.
>> Accelerite, a Persistent Systems business does not accept any liability for
>> virus infected mails.

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: ConfigDrive status

[Jayapal Uradi]

Hi Nux,

It is developed only for advanced zone shared network (offering without any 
services).
This feature is developed on xenserver, kvm and vmware hypervisor.

It can be extended to other networks.

-Jayapal
> On Mar 26, 2018, at 9:56 PM, Nux!  wrote:
> 
> Thanks for all the feedback, I'll do some reading then.
> 
> Lucian
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> - Original Message -
>> From: "ilya musayev" 
>> To: "dev" 
>> Sent: Monday, 26 March, 2018 17:03:30
>> Subject: Re: ConfigDrive status
> 
>> Lucian
>> 
>> We reported 3-4 issues with config drive. It’s being worked on. It does
>> work - but not per agreed upon specifications.
>> 
>> See below
>> 
>> 
>> https://issues.apache.org/jira/browse/CLOUDSTACK-10287
>> https://issues.apache.org/jira/browse/CLOUDSTACK-10288
>> https://issues.apache.org/jira/browse/CLOUDSTACK-10289
>> https://issues.apache.org/jira/browse/CLOUDSTACK-10290
>> 
>> Regards
>> Ilya
>> 
>> On Mon, Mar 26, 2018 at 8:58 AM Dag Sonstebo 
>> wrote:
>> 
>>> Hi Lucian,
>>> 
>>> I’m maybe not the right person to answer this – but my understanding is it
>>> only kicks in when you have a network offering without a VR, at which point
>>> the metadata etc. is presented as the config drive. Happy to be corrected
>>> on this.
>>> 
>>> We did however have a really major gotcha 18 months ago – when a customer
>>> did a CloudStack upgrade and ended up with new unexpected config drives
>>> causing changes to all the VMware disk controller addressing – meaning VMs
>>> wouldn’t boot, couldn’t see disks, etc. If you use VMware I would test
>>> beforehand.
>>> 
>>> Regards,
>>> Dag Sonstebo
>>> Cloud Architect
>>> ShapeBlue
>>> 
>>> On 26/03/2018, 14:50, "Nux!"  wrote:
>>> 
>>>Hi,
>>> 
>>>I am interested in the ConfigDrive feature.
>>>Before I potentially waste time on it, is anyone around here using it
>>> or can clarify whether it's usable or not or gotchas etc?
>>> 
>>>Regards,
>>>Lucian
>>> 
>>>--
>>>Sent from the Delta quadrant using Borg technology!
>>> 
>>>Nux!
>>>www.nux.ro
>>> 
>>> 
>>> 
>>> dag.sonst...@shapeblue.com
>>> www.shapeblue.com
>>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>>> @shapeblue
>>> 
>>> 
>>> 

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: Welcoming Mike as the new Apache CloudStack VP

[Jayapal Uradi]

Congratulations, Milke!

-Jayapal

> On Mar 27, 2018, at 2:38 AM, Nitin Kumar Maharana 
>  wrote:
> 
> Congratulations, Mike!!
> 
> -
> Nitin
> On 26-Mar-2018, at 7:41 PM, Wido den Hollander 
> > wrote:
> 
> Hi all,
> 
> It's been a great pleasure working with the CloudStack project as the
> ACS VP over the past year.
> 
> A big thank you from my side for everybody involved with the project in
> the last year.
> 
> Hereby I would like to announce that Mike Tutkowski has been elected to
> replace me as the Apache Cloudstack VP in our annual VP rotation.
> 
> Mike has a long history with the project and I am are happy welcome him
> as the new VP for CloudStack.
> 
> Welcome Mike!
> 
> Thanks,
> 
> Wido
> 
> DISCLAIMER
> ==
> This e-mail may contain privileged and confidential information which is the 
> property of Accelerite, a Persistent Systems business. It is intended only 
> for the use of the individual or entity to which it is addressed. If you are 
> not the intended recipient, you are not authorized to read, retain, copy, 
> print, distribute or use this message. If you have received this 
> communication in error, please notify the sender and delete all copies of 
> this message. Accelerite, a Persistent Systems business does not accept any 
> liability for virus infected mails.

Re: [PROPOSE] RM for 4.11

[Jayapal Uradi]

+1
Thanks Rohit!

> On Nov 30, 2017, at 4:43 AM, Nicolas Vazquez  
> wrote:
> 
> +1
> 
> 
> Thanks Rohit!
> 
> 
> From: Rohit Yadav 
> Sent: Wednesday, November 29, 2017 7:14:54 AM
> To: dev@cloudstack.apache.org
> Subject: [PROPOSE] RM for 4.11
> 
> Hi All,
> 
> I’d like to put myself forward as release manager for 4.11. The 4.11
> releases will be the next major version LTS release since 4.9 and will be
> supported for 20 months per the LTS manifesto [2] until 1 July 2019.
> 
> Daan Hoogland and Paul Angus will assist during the process and all of us
> will be the gatekeepers for reviewing/testing/merging the PRs, others will
> be welcome to support as well.
> 
> As a community member, I will try to help get PRs reviewed, tested and
> merged (as would everyone else I hope) but with an RM hat on I would like
> to see if we can make that role less inherently life-consuming and put the
> onus back on the community to get stuff done.
> 
> Here the plan:
> 1. As RM I put forward the freeze date of the 8th of January 2018, hoping
> for community approval.
> 2. After the freeze date (8th Jan) until GA release, features will not be
> allowed and fixes only as long as there are blocker issues outstanding.
> Fixes for other issues will be individually judged on their merit and risk.
> 3. RM will triage/report critical and blocker bugs for 4.11 [4] and
> encourage people to get them fixed.
> 4. RM will create RCs and start voting once blocker bugs are cleared and
> baseline smoke test results are on par with previous 4.9.3.0/4.10.0.0 smoke
> test results.
> 5. RM will allocate at least a week for branch stabilization and testing.
> At the earliest, on 15th January, RM will put 4.11.0.0-rc1 for voting from
> the 4.11 branch, and master will be open to accepting new features.
> 6. RM will repeat 3-5 as required. Voting/testing of -rc2, -rc3 and so on
> will be created as required.
> 7. Once vote passes - RM will continue with the release procedures [1].
> 
> In conjunction with that, I also propose and put forward the date of 4.12
> cut-off as 4 months [3] after GA release of 4.11 (so everyone knows when
> the next one is coming hopefully giving peace of mind to those who have
> features which would not make the proposed 4.11 cut off).
> 
> I’d like the community (including myself and colleagues) to:
> - Up to 8th January, community members try to review, test and merge as
> many fixes as possible, while super-diligent to not de-stabilize the master
> branch.
> - Engage with gatekeepers to get your PRs reviewed, tested and merged
> (currently myself, Daan and Paul, others are welcome to engage as well). Do
> not merge the PRs
> - A pull request may be reverted where the author(s) are not responding and
> authors may be asked to re-submit their changes after taking suitable
> remedies.
> - Find automated method to show (at a glance) statuses of PRs with respect
> to:
>  · Number of LGTMs
>  · Smoke tests
>  · Functional tests
>  · Travis tests passing
>  · Mergeability
> - Perform a weekly run of a component-test matrix against the master branch
> before Jan 8th cut off (based on current hypervisors including basic (KVM)
> and advanced networking).
> - Continue to fix broken tests.
> 
> Thoughts, feedback, comments?
> 
> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
> [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
> [3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases
> [4] The current list of blocker and critical bugs currently stands as per
> the following list:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CLOUDSTACK%20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20priority%20in%20(Blocker%2C%20Critical)%20AND%20affectedVersion%20in%20(4.10.0.0%2C%204.10.1.0%2C%204.11.0.0%2C%20Future)%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> 
> Regards,
> Rohit Yadav
> 
> nicolas.vazq...@shapeblue.com 
> www.shapeblue.com
> ,   
> @shapeblue
> 
> 
> 

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: egress fw problems in 4.10?

[Jayapal Uradi]

Please review the PR.
https://github.com/apache/cloudstack/pull/2334

-Jayapal

On Nov 21, 2017, at 5:37 PM, Rohit Yadav 
<rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>> wrote:

Jayapal - nice, can you send a PR please?


- Rohit

____
From: Jayapal Uradi 
<jayapal.ur...@accelerite.com<mailto:jayapal.ur...@accelerite.com>>
Sent: Tuesday, November 21, 2017 5:33:19 PM
To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>
Subject: Re: egress fw problems in 4.10?

Hi,

When there is 0.0.0.0/0 for dest cidr, while adding iptables do not include ' 
-m set --match-set destCidrIpset-4 dst’ .
For 0.0.0.0/0 no need to add this in  ipset.

This should be fixed in VR code.

Thanks,
Jayapal





rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>
www.shapeblue.com<http://www.shapeblue.com/>
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue



On Nov 21, 2017, at 5:22 PM, Rohit Yadav 
<rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>> wrote:

Jayapal - I tried that, that leaves the ipset empty and egress traffic does not 
work for guest VMs.


This is seen in iptables (filter):

[..snipped..]
-A FW_EGRESS_RULES -m set --match-set destCidrIpset-4 dst -j ACCEPT
-A FW_EGRESS_RULES -j DROP
[..snipped..]


And no members are seen:


root@r-4-VM:/var/cache/cloud/processed# ipset list destCidrIpset-4
Name: destCidrIpset-4
Type: hash:net
Revision: 6
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 352
References: 1
Members:

At this point from a guest VM, egress traffic won't be allowed.


However, with the workaround I mentioned (see the bugzilla discussion for 
reference) egress works:


root@r-4-VM:/var/cache/cloud/processed# ipset list destCidrIpset-4
Name: destCidrIpset-4
Type: hash:net
Revision: 6
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 480
References: 1
Members:
0.0.0.0/1
128.0.0.0/1


- Rohit


From: Jayapal Uradi 
<jayapal.ur...@accelerite.com<mailto:jayapal.ur...@accelerite.com>>
Sent: Tuesday, November 21, 2017 5:15:57 PM
To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>
Subject: Re: egress fw problems in 4.10?

When there is 0.0.0.0/0 for dest cidr do not add/skip the ipset match option in 
iptables. This will fix the issue.

-Jayapal



rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>
www.shapeblue.com<http://www.shapeblue.com/><http://www.shapeblue.com<http://www.shapeblue.com/>>
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue



On Nov 21, 2017, at 5:07 PM, Rohit Yadav 
<rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>> wrote:

Hi Lucian,


It looks like a legit bug: https://bugzilla.redhat.com/show_bug.cgi?id=1297092


When you add 0.0.0.0/0 as destination cidr, this execute on VR and fails:

# ipset add destCidrIpset-4 1.0.0.0/0
ipset v6.30: The value of the CIDR parameter of the IP address is invalid


The workaround are to use these destination cidrs, split in two egress traffic 
rules:

0.0.0.0/1 and 128.0.0.0/1.


Regards.


From: Nux! <n...@li.nux.ro<mailto:n...@li.nux.ro>>
Sent: Tuesday, November 21, 2017 3:16:00 PM
To: dev
Subject: Re: egress fw problems in 4.10?

Rohit,

I see it accepts 0.0.0.0/0 on the source CIDR, but then transforms that into 
10.1.1.0/24 (or whatever), I'd imagine it could do the same with the 
destination CIDR and just "rename" 0.0.0.0/0 into 0.0.0.0/1.
However this is not a Cloudstack problem as I see it, it's an ipset 
bug/feature, so we should just "deal with it", perhaps update the documentation 
at least.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro<http://www.nux.ro>


rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>
www.shapeblue.com<http://www.shapeblue.com/>
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue



- Original Message -
From: "Rohit Yadav" 
<rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>>
To: "dev" <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>
Sent: Tuesday, 21 November, 2017 09:23:00
Subject: Re: egress fw problems in 4.10?

I hit the same issue with the debian9-systemvmtemplate PR. Earlier, the egress
traffic option used to accept 0.0.0.0/0.


- Rohit


From: Nux! <n...@li.nux.ro<mailto:n...@li.nux.ro>>
Sent: Friday, November 17, 2017 11:09:26 PM
To: dev
Subject: Re: egress fw problems in 4.10?

Thanks Jayapal,

Indeed, I checked and 0.0.0.0/0 is not there. When I tried to add it manually I
got an error:
ipset v6.12.1: The value of the CIDR parameter of the IP address is invalid


Hash:net types will not accept 0 prefix, it's happy to accept 0.0.0.0/1 though,
however I still can't do any egress e

Re: Fail with vpn customer gateway creation through terraform

[Jayapal Uradi]

Hi Lucian,

Try the the following in config, ‘-‘ instead of ‘;’ after the aes256 in the 
config.

New: "sha1-aes256-modp3072”
Old: "sha1-aes256;modp3072”

Thanks,
Jayapal
On Nov 22, 2017, at 5:44 AM, Pierre-Luc Dion 
> wrote:

Hi Nux,

Could it be your cloudstack version ?  modp3072 is recent I think in
CloudStack so if you run a older version maybe it's not there?



On Tue, Nov 21, 2017 at 6:55 PM, Nux! > 
wrote:

Thanks Chiradeep,

Checked but brain says no. What should I have learned from there?

AFAIK this is a terraform fail.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
From: "Chiradeep Vittal" 
To: "dev" 
Sent: Tuesday, 21 November, 2017 19:14:16
Subject: Re: Fail with vpn customer gateway creation through terraform

Check
https://github.com/apache/cloudstack/blob/77864992fe8f80dbabd1240f6373d2
ba3e98713c/utils/src/main/java/com/cloud/utils/net/NetUtils.java#L1221

On Tue, Nov 21, 2017 at 10:11 AM, Nux!  wrote:

Hi,

I'm trying out terraform and had success so far, except for the vpn
customer gateway feature.
For some reason, terraform fails to create it, though I use the same
options as in UI/cloudmonkey where it works just fine.

The snippet for it is:

resource "cloudstack_vpn_customer_gateway" "default" {
 name   = "test-vpc"
 cidr   = "10.0.0.0/24"
 esp_policy = "aes256-sha1"
 gateway= "1.2.3.4"
 ike_policy = "sha1-aes256;modp3072"
 ipsec_psk  = "terraformxyz7"
}

It always complains about the ike_policy:
* cloudstack_vpn_customer_gateway.default: Error creating VPN Customer
Gateway test-vpc: Undefined error: {"errorcode":431,"errortext":"The
customer gateway IKE policy sha1-aes256;modp3072 is invalid!  Verify the
required Diffie Hellman (DH) group is specified."}

I tried all sorts of ways to write the ike_policy, escaped, web
encoded/decoded, nothing worked. What am I missing?
The example terraform docs provide suffers the same fate.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro


DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: egress fw problems in 4.10?

[Jayapal Uradi]

Hi,

When there is 0.0.0.0/0 for dest cidr, while adding iptables do not include ' 
-m set --match-set destCidrIpset-4 dst’ .
For 0.0.0.0/0 no need to add this in  ipset.

This should be fixed in VR code.

Thanks,
Jayapal




> On Nov 21, 2017, at 5:22 PM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote:
> 
> Jayapal - I tried that, that leaves the ipset empty and egress traffic does 
> not work for guest VMs.
> 
> 
> This is seen in iptables (filter):
> 
> [..snipped..]
> -A FW_EGRESS_RULES -m set --match-set destCidrIpset-4 dst -j ACCEPT
> -A FW_EGRESS_RULES -j DROP
> [..snipped..]
> 
> 
> And no members are seen:
> 
> 
> root@r-4-VM:/var/cache/cloud/processed# ipset list destCidrIpset-4
> Name: destCidrIpset-4
> Type: hash:net
> Revision: 6
> Header: family inet hashsize 1024 maxelem 65536
> Size in memory: 352
> References: 1
> Members:
> 
> At this point from a guest VM, egress traffic won't be allowed.
> 
> 
> However, with the workaround I mentioned (see the bugzilla discussion for 
> reference) egress works:
> 
> 
> root@r-4-VM:/var/cache/cloud/processed# ipset list destCidrIpset-4
> Name: destCidrIpset-4
> Type: hash:net
> Revision: 6
> Header: family inet hashsize 1024 maxelem 65536
> Size in memory: 480
> References: 1
> Members:
> 0.0.0.0/1
> 128.0.0.0/1
> 
> 
> - Rohit
> 
> 
> From: Jayapal Uradi <jayapal.ur...@accelerite.com>
> Sent: Tuesday, November 21, 2017 5:15:57 PM
> To: dev@cloudstack.apache.org
> Subject: Re: egress fw problems in 4.10?
> 
> When there is 0.0.0.0/0 for dest cidr do not add/skip the ipset match option 
> in iptables. This will fix the issue.
> 
> -Jayapal
> 
> 
> 
> rohit.ya...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> 
> 
> 
> On Nov 21, 2017, at 5:07 PM, Rohit Yadav 
> <rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>> wrote:
> 
> Hi Lucian,
> 
> 
> It looks like a legit bug: https://bugzilla.redhat.com/show_bug.cgi?id=1297092
> 
> 
> When you add 0.0.0.0/0 as destination cidr, this execute on VR and fails:
> 
> # ipset add destCidrIpset-4 1.0.0.0/0
> ipset v6.30: The value of the CIDR parameter of the IP address is invalid
> 
> 
> The workaround are to use these destination cidrs, split in two egress 
> traffic rules:
> 
> 0.0.0.0/1 and 128.0.0.0/1.
> 
> 
> Regards.
> 
> 
> From: Nux! <n...@li.nux.ro<mailto:n...@li.nux.ro>>
> Sent: Tuesday, November 21, 2017 3:16:00 PM
> To: dev
> Subject: Re: egress fw problems in 4.10?
> 
> Rohit,
> 
> I see it accepts 0.0.0.0/0 on the source CIDR, but then transforms that into 
> 10.1.1.0/24 (or whatever), I'd imagine it could do the same with the 
> destination CIDR and just "rename" 0.0.0.0/0 into 0.0.0.0/1.
> However this is not a Cloudstack problem as I see it, it's an ipset 
> bug/feature, so we should just "deal with it", perhaps update the 
> documentation at least.
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro<http://www.nux.ro>
> 
> 
> rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>
> www.shapeblue.com<http://www.shapeblue.com/>
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> 
> 
> 
> - Original Message -
> From: "Rohit Yadav" 
> <rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>>
> To: "dev" <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>
> Sent: Tuesday, 21 November, 2017 09:23:00
> Subject: Re: egress fw problems in 4.10?
> 
> I hit the same issue with the debian9-systemvmtemplate PR. Earlier, the egress
> traffic option used to accept 0.0.0.0/0.
> 
> 
> - Rohit
> 
> 
> From: Nux! <n...@li.nux.ro<mailto:n...@li.nux.ro>>
> Sent: Friday, November 17, 2017 11:09:26 PM
> To: dev
> Subject: Re: egress fw problems in 4.10?
> 
> Thanks Jayapal,
> 
> Indeed, I checked and 0.0.0.0/0 is not there. When I tried to add it manually 
> I
> got an error:
> ipset v6.12.1: The value of the CIDR parameter of the IP address is invalid
> 
> 
> Hash:net types will not accept 0 prefix, it's happy to accept 0.0.0.0/1 
> though,
> however I still can't do any egress except for ICMP ping for some reason.
> 
> If I omit specifying a a dest CIDR, then I get trully unrestricted egress.
> 
> I need to investigate some more when I get time, something's fishy.
> 
> --
> Sent from the Delt

Re: egress fw problems in 4.10?

[Jayapal Uradi]

When there is 0.0.0.0/0 for dest cidr do not add/skip the ipset match option in 
iptables. This will fix the issue.

-Jayapal


On Nov 21, 2017, at 5:07 PM, Rohit Yadav 
<rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>> wrote:

Hi Lucian,


It looks like a legit bug: https://bugzilla.redhat.com/show_bug.cgi?id=1297092


When you add 0.0.0.0/0 as destination cidr, this execute on VR and fails:

# ipset add destCidrIpset-4 1.0.0.0/0
ipset v6.30: The value of the CIDR parameter of the IP address is invalid


The workaround are to use these destination cidrs, split in two egress traffic 
rules:

0.0.0.0/1 and 128.0.0.0/1.


Regards.


From: Nux! <n...@li.nux.ro<mailto:n...@li.nux.ro>>
Sent: Tuesday, November 21, 2017 3:16:00 PM
To: dev
Subject: Re: egress fw problems in 4.10?

Rohit,

I see it accepts 0.0.0.0/0 on the source CIDR, but then transforms that into 
10.1.1.0/24 (or whatever), I'd imagine it could do the same with the 
destination CIDR and just "rename" 0.0.0.0/0 into 0.0.0.0/1.
However this is not a Cloudstack problem as I see it, it's an ipset 
bug/feature, so we should just "deal with it", perhaps update the documentation 
at least.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro<http://www.nux.ro>


rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>
www.shapeblue.com<http://www.shapeblue.com/>
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue



- Original Message -
From: "Rohit Yadav" 
<rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>>
To: "dev" <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>
Sent: Tuesday, 21 November, 2017 09:23:00
Subject: Re: egress fw problems in 4.10?

I hit the same issue with the debian9-systemvmtemplate PR. Earlier, the egress
traffic option used to accept 0.0.0.0/0.


- Rohit


From: Nux! <n...@li.nux.ro<mailto:n...@li.nux.ro>>
Sent: Friday, November 17, 2017 11:09:26 PM
To: dev
Subject: Re: egress fw problems in 4.10?

Thanks Jayapal,

Indeed, I checked and 0.0.0.0/0 is not there. When I tried to add it manually I
got an error:
ipset v6.12.1: The value of the CIDR parameter of the IP address is invalid


Hash:net types will not accept 0 prefix, it's happy to accept 0.0.0.0/1 though,
however I still can't do any egress except for ICMP ping for some reason.

If I omit specifying a a dest CIDR, then I get trully unrestricted egress.

I need to investigate some more when I get time, something's fishy.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro<http://www.nux.ro>


rohit.ya...@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com/><http://www.shapeblue.com<http://www.shapeblue.com/>>
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue



- Original Message -
From: "Jayapal Uradi" <jayapal.ur...@accelerite.com>
To: "dev" <dev@cloudstack.apache.org>
Sent: Friday, 17 November, 2017 04:02:13
Subject: Re: egress fw problems in 4.10?

Hi Nux,

I think the the ipset for destination cidr is not configured with 0.0.0.0/0 due
this you might see this issue.
Please check the ipset and iptables rules once.

iptables -L -nv
ipset -L

Thanks,
Jayapal


On Nov 17, 2017, a t 6:55 AM, Nux! <n...@li.nux.ro> wrote:

Hi,

Just installed 4.10 today for a demo, but seems there are some problems with the
egress rules in isolated networks.
Is there anything wrong with this rule? ACS allows me to add it, but no outbound
traffic is allowed at all.

10.1.1.0/24  0.0.0.0/0   All All All

http://img.nux.ro/gL3-Selection_002.png

If I replace 0.0.0.0/0 with a certain IP/32, then traffic works.


Also, if I don't mention a destination cidr at all, outbound traffic also works,
but the docs state 0.0.0.0/0 should be honoured as valid destination cidr.

Any ideas? I know there was recent work done on egress recently, maybe related
to that?

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the
property of Accelerite, a Persistent Systems business. It is intended only for
the use of the individual or entity to which it is addressed. If you are not
the intended recipient, you are not authorized to read, retain, copy, print,
distribute or use this message. If you have received this communication in
error, please notify the sender and delete all copies of this message.
Accelerite, a Persistent Systems business does not accept any liability for
virus infected mails.

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it

Re: egress fw problems in 4.10?

[Jayapal Uradi]

Hi Nux,

I think the the ipset for destination cidr is not configured with 0.0.0.0/0 due 
this you might see this issue. 
Please check the ipset and iptables rules once.

iptables -L -nv
ipset -L 

Thanks,
Jayapal


> On Nov 17, 2017, a t 6:55 AM, Nux!  wrote:
> 
> Hi,
> 
> Just installed 4.10 today for a demo, but seems there are some problems with 
> the egress rules in isolated networks.
> Is there anything wrong with this rule? ACS allows me to add it, but no 
> outbound traffic is allowed at all.
> 
> 10.1.1.0/24   0.0.0.0/0   All All All 
> 
> http://img.nux.ro/gL3-Selection_002.png
> 
> If I replace 0.0.0.0/0 with a certain IP/32, then traffic works.
> 
> 
> Also, if I don't mention a destination cidr at all, outbound traffic also 
> works, but the docs state 0.0.0.0/0 should be honoured as valid destination 
> cidr.
> 
> Any ideas? I know there was recent work done on egress recently, maybe 
> related to that?
> 
> Lucian
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: POLL: ACL default egress policy rule in VPC

[Jayapal Uradi]

Hi Rene,

Please look at my inline comments.
Let me add some context for the VPC egress/ingress rules behavior.

Pre 4.5 (subject to correction) the behavior of VPC acl is as follows.

1. Default egress is ALLOW and ingress is DROP.
   a.  When a rule is added to egress then that particular rule traffic is 
allowed and rest is blocked in egress.
   b.  When a rule is added to ingress then that particular rule traffic is 
allowed and rest is blocked in egress.

After 4.5 ACL lists and ACL items feature is introduced there we have ‘default 
allow’ and ‘default deny’ ACLs. User can also
create a custom acl. In ACL feature we can add mix of allow and deny rules and 
the ordering of rules is maintained.

1.  when ‘default allow’ is selected while creating the vpc tier
By default traffic is ALLOWED and rules can be added to ALLOW/DENY the 
traffic
   After adding the rules there will be ACCEPT at the end
2.  when ‘default deny’ is selected while creating the vpc tier
By default traffic is DENY and rules can be added to DENY/ALLOW the traffic.
  After adding the rules there will be DROP at the end
3. If no ACL selected for the ACL then Pre 4.5 behavior will be there.
4. With custom acl default ingress is DROP and egress is ALLOW. User can add 
rules for allow/deny rules.

If you see behavior other than above then there will be bug.

Currently in VPC egress behavior is controlled from the ACLs. If include  
‘egressdefaultpolicy’ then there will be confusion.

What I feel is that current VPC ACLs are flexible enough  to configure the 
required behavior.

Thanks,
Jayapal





> On Nov 13, 2017, at 11:17 PM, Rene Moser  wrote:
> 
> Hi Devs
> 
> The last days I fought with the ACL egress rule behaviour and I would
> like to make a poll in which direction the fix should go.
> 
> Short Version:
> 
> We need to define a better default behaviour for acl default egress
> rule. I see 3 different options:
> 
> 1. always add a default deny all egress rule.
> 
> This would be super easy to do (should probably also the intermediate
> fix for 4.9, see https://github.com/apache/cloudstack/pull/2323)
> 
> 
> 2. add a deny all egress rule in case if have at least one egress allow
> rule.
> 
> A bit intransparent to the user, but doable. This seems to be the
> behaviour how it was designed and should have been implemented.
> 
Currently we can configure the ACLs to get this behavior.
> 
> 3. use the default setting in the network offering "egressdefaultpolicy"
> to specify the default behavior.
> 
> There is already a setting which specifies this behaviour but is not
> used in VPC. Why not use it?
> 
> As a consequence when using this setting, the user should get more infos
> about the policy of the network offering while choosing it for the tier.
> 
> 
> Poll:
> 
> 1. []
> 2. []
> 3. []
> 4. [] Other? What?
> 
> 
> Long Version:
> 
> First, let's have a look of the issue:
> 
> In version 4.5, creating a new acl with no egress (ACL_OUTBOUND) rule
> would result in a "accept egress all":
> 
> -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state
> NEW -j ACL_OUTBOUND_eth2
> -A ACL_OUTBOUND_eth2 -j ACCEPT
> 
> When an egress (here deny 25 egress) rule (no mather if deny or allow)
> gets added the result is a "deny all" appended:
> 
> -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state
> NEW -j ACL_OUTBOUND_eth2
> -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 25 -j DROP
> -A ACL_OUTBOUND_eth2 -j DROP
This is seen because default egress is drop and user added rule to deny port 25 
traffic.
User has choice of adding allow/deny rules with priority number.
> 
> This does not make any sense and is a bug IMHO.
> 
> 
> In 4.9 the behaviour is different:
> 
> (note there is a bug in the ordering of egress rules which is fixed by
> https://github.com/apache/cloudstack/pull/2313)
> 
> The default policy is kept accept egress all.
> 
> -A PREROUTING -s 10.11.1.0/24 ! -d 10.11.1.1/32 -i eth2 -m state --state
> NEW -j ACL_OUTBOUND_eth2
> -A ACL_OUTBOUND_eth2 -d 224.0.0.18/32 -j ACCEPT
> -A ACL_OUTBOUND_eth2 -d 225.0.0.50/32 -j ACCEPT
> -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 80 -j ACCEPT

In 4.9 it is a bug. After accept rules there supposed to DROP all at the end.
> 
> 
> To me it looks like the wanted behavior was "egress all as default. If
> we have allow rules, append deny all". This would make sense but is
> quite instransparent.
> 
> But let's poll
> 
> 

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business 

Re: DHCP Cleanup after VM destroy

[Jayapal Uradi]

Hi Syed,

Reminding you the cases so that do don’t miss 2 and 3.

1. Deleting vm corresponding entry from the VR when VM is deleted
2. When VR is stopped, deleted a VM and started VR.
3. When VR is stopped, the last VM is deleted.

Thanks,
Jayapal

> On Oct 20, 2017, at 8:41 PM, Syed Ahmed  wrote:
> 
> Hi All,
> 
> I was investigating an issue where we had a problem with DNS where, even
> after deleting the VM, the DNS still resolved to an IP address. Going
> through the code, I found out that there is no functionality that exisits
> currently that cleans up DHCP entries. When you destroy a VM and create
> another VM with the same name, there are some race conditions that lead to
> old IPs being used for resolution.
> 
> Past issues [1,2] have pointed out to the same problem but I could not find
> a fix that addresses them. I'm gong to work on a fix right now. If someone
> has more info or has already fixed it. I would be delighted if you could
> share that.
> 
> Thanks,
> -Syed
> 
> [1] https://issues.apache.org/jira/browse/CLOUDSTACK-7974
> [2] https://issues.apache.org/jira/browse/CLOUDSTACK-8060

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: Marvin Install Issue

[Jayapal Uradi]

Hi Mike,

Long back I got issue related to mysql-connector. I followed the below steps, 
see if this helps for installing mysql-connector.

#mysql-connector-python
http://stackoverflow.com/questions/31748278/how-do-you-install-mysql-connector-python-development-version-through-pip
$  git clone https://github.com/mysql/mysql-connector-python.git
$  cd mysql-connector-python
$  python ./setup.py build
$  sudo python ./setup.py install
...
>>> import mysql.connector as msc
>>> msc.__version__
‘2.1.3'

Thanks,
Jayapal

On Jul 27, 2017, at 7:46 AM, Tutkowski, Mike 
> wrote:

Hi everyone,

I am having trouble installing Marvin on Ubuntu 14.04 from master.

It’s complaining that it’s having trouble with mysql-connector-python.

mtutkowski@mike-ubuntu:~/cloudstack/cloudstack$ sudo pip install --upgrade 
tools/marvin/dist/Marvin-*.tar.gz
Unpacking ./tools/marvin/dist/Marvin-4.11.0.0-SNAPSHOT.tar.gz
 Running setup.py (path:/tmp/pip-5URDXT-build/setup.py) egg_info for package 
from 
file:///home/mtutkowski/cloudstack/cloudstack/tools/marvin/dist/Marvin-4.11.0.0-SNAPSHOT.tar.gz
   /usr/local/lib/python2.7/dist-packages/setuptools/dist.py:340: UserWarning: 
The version specified ('4.11.0.0-SNAPSHOT') is an invalid version, this may not 
work as expected with newer versions of setuptools, pip, and PyPI. Please see 
PEP 440 for more details.
 "details." % self.metadata.version

   warning: no files found matching '*.txt' under directory 'docs'
Could not find any downloads that satisfy the requirement 
mysql-connector-python>=1.1.6 in /usr/lib/python2.7/dist-packages (from 
Marvin==4.11.0.0-SNAPSHOT)
Downloading/unpacking mysql-connector-python>=1.1.6 (from 
Marvin==4.11.0.0-SNAPSHOT)
Cleaning up...
No distributions at all found for mysql-connector-python>=1.1.6 in 
/usr/lib/python2.7/dist-packages (from Marvin==4.11.0.0-SNAPSHOT)
Storing debug log for failure in /home/mtutkowski/.pip/pip.log

But it seems to be installed:

python-mysql.connector/trusty,now 1.1.6-1 all [installed]

Thoughts?

Thanks!
Mike

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: [DISCUSS] Move to Debian9 systemvmtemplate

[Jayapal Uradi]

First one come to my mind is VPN feature. 
But other general issues will depend on what are changed in debain9.

Thanks,
Jayapal



> On Jul 24, 2017, at 9:54 AM, Satki Badal <satki.ba...@gmail.com> wrote:
> 
> Hi Jayapal,
> 
> Do we know what all features re covered by Marvin and what all will require 
> manual testing ?
> I guess without this list we can never be sure is all the features got tested 
> or not.
> 
> Thanks,
> Satki
> 
>> On 24-Jul-2017, at 9:48 AM, Jayapal Uradi <jayapal.ur...@accelerite.com> 
>> wrote:
>> 
>> Hi,
>> 
>> We should throughly check all the VR features to see feature breakage 
>> because of  Debian9.
>> 
>> Thanks,
>> Jayapal
>> 
>> 
>>> On Jul 23, 2017, at 9:38 PM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote:
>>> 
>>> All,
>>> 
>>> 
>>> Just want to kick an initial discussion around migration to Debian9 based 
>>> systemvmtemplate, and get your feedback on the same.
>>> 
>>> Here's a work-in-progress PR: https://github.com/apache/cloudstack/pull/2198
>>> 
>>> 
>>> Regards.
>>> 
>>> rohit.ya...@shapeblue.com 
>>> www.shapeblue.com
>>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>>> @shapeblue
>>> 
>>> 
>>> 
>> 
>> DISCLAIMER
>> ==
>> This e-mail may contain privileged and confidential information which is the 
>> property of Accelerite, a Persistent Systems business. It is intended only 
>> for the use of the individual or entity to which it is addressed. If you are 
>> not the intended recipient, you are not authorized to read, retain, copy, 
>> print, distribute or use this message. If you have received this 
>> communication in error, please notify the sender and delete all copies of 
>> this message. Accelerite, a Persistent Systems business does not accept any 
>> liability for virus infected mails.
>> 
> 

Re: [DISCUSS] Move to Debian9 systemvmtemplate

[Jayapal Uradi]

Hi,

We should throughly check all the VR features to see feature breakage because 
of  Debian9.

Thanks,
Jayapal


> On Jul 23, 2017, at 9:38 PM, Rohit Yadav  wrote:
> 
> All,
> 
> 
> Just want to kick an initial discussion around migration to Debian9 based 
> systemvmtemplate, and get your feedback on the same.
> 
> Here's a work-in-progress PR: https://github.com/apache/cloudstack/pull/2198
> 
> 
> Regards.
> 
> rohit.ya...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> 
> 
> 

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: Private Gateway on REDUNDANT VPC

[Jayapal Uradi]

Did you check iptables, Is it blocking on the VR ?

> On Jun 20, 2017, at 1:30 PM, Paul Angus  wrote:
> 
> Hi All,
> 
> I've been looking at the failing Marvin tests for Private Gateways.It 
> passes on std VPC and fails on rVPC.
> The test tries to ping a VM on a remote VPC via the private gateways on both 
> VRs.
> Digging into it, I found that an ARP request goes out for the remote VM from 
> the local VR to the remote VR, the local VR receives it, then nothing.  On 
> the std VRs a reply goes back out.
> 
> I've checked all interfaces to see if the reply is going out of the wrong 
> interface, but it just isn't going out anywhere.  I can't figure out why no 
> reply seems to be generated...  Obviously the answer is in the difference in 
> config and packages on VPC vs rVPC - but I can't find it.
> 
> HELP!  Any ideas anyone?
> 
> 
> Kind regards,
> 
> Paul Angus
> 
> 
> paul.an...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> 
> 
> 

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

tier network interface ip in VR is assigned to additional public interface

[Jayapal Uradi]

Hi,

I have observed the below issue in my VR where tier network ip is added to 
additional public network interface.
This is an inconsistent issue. Did any one observed similar issue ?

Please see the below logs.

root@r-135-QA:~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:03:73 brd ff:ff:ff:ff:ff:ff
inet 169.254.3.115/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 1e:00:f9:00:00:14 brd ff:ff:ff:ff:ff:ff
inet 10.147.46.108/24 brd 10.147.46.255 scope global eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:29:c5:00:05 brd ff:ff:ff:ff:ff:ff
5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:45:73:00:06 brd ff:ff:ff:ff:ff:ff
inet 10.1.2.1/24 brd 10.1.2.255 scope global eth3
6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 1e:00:b7:00:00:34 brd ff:ff:ff:ff:ff:ff
inet 10.147.52.101/24 brd 10.147.52.255 scope global eth4
inet 10.1.1.1/24 brd 10.1.1.255 scope global eth4
root@r-135-QA:~# cat /etc/cloudstack/ips.json
{
"eth0": [
{
"add": true,
"broadcast": "169.254.255.255",
"cidr": "169.254.3.115/16",
"device": "eth0",
"gateway": "None",
"netmask": "255.255.0.0",
"network": "169.254.0.0/16",
"nic_dev_id": "0",
"nw_type": "control",
"one_to_one_nat": false,
"public_ip": "169.254.3.115",
"size": "16",
"source_nat": false
}
],
"eth1": [
{
"add": true,
"broadcast": "10.147.46.255",
"cidr": "10.147.46.108/24",
"device": "eth1",
"first_i_p": true,
"gateway": "10.147.46.1",
"netmask": "255.255.255.0",
"network": "10.147.46.0/24",
"new_nic": false,
"nic_dev_id": 1,
"nw_type": "public",
"one_to_one_nat": false,
"public_ip": "10.147.46.108",
"size": "24",
"source_nat": true,
"vif_mac_address": "1e:00:f9:00:00:14"
}
],
"eth2": [],
"eth3": [
{
"add": true,
"broadcast": "10.1.2.255",
"cidr": "10.1.2.1/24",
"device": "eth3",
"gateway": "10.1.2.1",
"netmask": "255.255.255.0",
"network": "10.1.2.0/24",
"nic_dev_id": "3",
"nw_type": "guest",
"one_to_one_nat": false,
"public_ip": "10.1.2.1",
"size": "24",
"source_nat": false
}
],
"eth4": [
{
"add": true,
"broadcast": "10.147.52.255",
"cidr": "10.147.52.101/24",
"device": "eth4",
"first_i_p": true,
"gateway": "10.147.52.1",
"netmask": "255.255.255.0",
"network": "10.147.52.0/24",
"new_nic": false,
"nic_dev_id": 4,
"nw_type": "public",
"one_to_one_nat": true,
"public_ip": "10.147.52.101",
"size": "24",
"source_nat": true,
"vif_mac_address": "1e:00:b7:00:00:34"
},
{
"add": true,
"broadcast": "10.1.1.255",
"cidr": "10.1.1.1/24",
"device": "eth4",
"gateway": "10.1.1.1",
"netmask": "255.255.255.0",
"network": "10.1.1.0/24",
"nic_dev_id": "4",
"nw_type": "guest",
"one_to_one_nat": false,
"public_ip": "10.1.1.1",
"size": "24",
"source_nat": false
}
],
"eth5": [
{
"add": false,
"broadcast": "10.147.44.255",
"cidr": "10.147.44.100/24",
"device": "eth5",
"first_i_p": false,
"gateway": "10.147.44.1",
"netmask": "255.255.255.0",
"network": "10.147.44.0/24",
"new_nic": false,
"nic_dev_id": 5,
"nw_type": "guest",
"one_to_one_nat": false,
"public_ip": "10.147.44.100",
"size": "24",
"source_nat": true,
"vif_mac_address": "1e:00:92:00:00:3a"
}
],
"id": "ips"
}root@r-135-QA:~#




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is 

Re: PR#1866 egress destination has template change merged

[Jayapal Uradi]

Yes Rohit.

Thanks,
Jayapal

> On Jun 7, 2017, at 12:17 PM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote:
>
> I believe - we'll need to build/publish a new 4.10/master systemvmtemplate?
>
>
> Regards.
>
> ________
> From: Jayapal Uradi <jayapal.ur...@accelerite.com>
> Sent: 07 June 2017 10:27:49
> To: dev@cloudstack.apache.org
> Subject: PR#1866 egress destination has template change merged
>
> Hi,
>
> For testing please generate new systemvm template on master/4.10 . PR#1866 
> has template change (ipset package installation)
> Without  new template egress firewall test cases will be impacted.
>
> https://github.com/apache/cloudstack/pull/1866
>
>
> Thanks,
> Jayapal
>
>
>
>
> DISCLAIMER
> ==
> This e-mail may contain privileged and confidential information which is the 
> property of Accelerite, a Persistent Systems business. It is intended only 
> for the use of the individual or entity to which it is addressed. If you are 
> not the intended recipient, you are not authorized to read, retain, copy, 
> print, distribute or use this message. If you have received this 
> communication in error, please notify the sender and delete all copies of 
> this message. Accelerite, a Persistent Systems business does not accept any 
> liability for virus infected mails.
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

PR#1866 egress destination has template change merged

[Jayapal Uradi]

Hi,

For testing please generate new systemvm template on master/4.10 . PR#1866 has 
template change (ipset package installation)
Without  new template egress firewall test cases will be impacted.

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


Thanks,
Jayapal




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Jayapal Uradi]

Today I am working  on this PR. Hopefully I will complete it.

Yesterday fixed test_01_isolate_network_FW_PF_default_routes_egress_true, 
test_01_isolate_network_FW_PF_default_routes_egress_false. Today working on RVR 
related tests.

Thanks,
Jayapal
On May 11, 2017, at 10:38 AM, Will Stevens 
<williamstev...@gmail.com<mailto:williamstev...@gmail.com>> wrote:

Is 1866 ready? It looks like CI is failing on a lot of relevant network tests.

On May 11, 2017 12:48 AM, "Jayapal Uradi" 
<jayapal.ur...@accelerite.com<mailto:jayapal.ur...@accelerite.com>> wrote:
Hi Rajani,

Also please  include the PR#1866.

Thanks,
Jayapal

> On May 11, 2017, at 10:10 AM, Rajani Karuturi 
> <raj...@apache.org<mailto:raj...@apache.org>> wrote:
>
> Thanks for testing Mike.
>
> RC3=RC2+PR#2089+Mike'sPR
>
> Any other additions?
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On May 10, 2017 at 7:47 PM, Tutkowski, Mike
> (mike.tutkow...@netapp.com<mailto:mike.tutkow...@netapp.com>) wrote:
>
> I've been running regression tests against the release candidate.
>
> So far, all tests but one have passed.
>
> The failing test is related to the storage cleanup thread. It
> looks like some code was changed in 4.10 with regards to this
> thread and that change is causing a problem around cleanup for
> managed storage in a particular situation.
>
> As a result of this, I was going to vote -1.
>
> I'm guessing the fix will not be complicated, but is important.
>
> I don't yet have the fix, however. Once I do, I can reply to
> this thread.
>
> On May 10, 2017, at 5:47 AM, Rajani Karuturi 
> <raj...@apache.org<mailto:raj...@apache.org>>
> wrote:
>
> I agree to your concerns Wido. I did check the PR before
> creating
> RC2. There were some outstanding comments on it.
>
> If no one has started testing RC2 and there are no objections,
> we
> can cancel this vote, quickly merge the PR and create RC3.
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On May 10, 2017 at 3:04 PM, Wido den Hollander 
> (w...@widodh.nl<mailto:w...@widodh.nl>)
> wrote:
>
> Op 10 mei 2017 om 0:33 schreef Will Stevens
> <williamstev...@gmail.com<mailto:williamstev...@gmail.com>>:
>
> Just to clarify. Wido, the issue you are experiencing is only
> with basic
> networks and also exists in 4.9 right? The issue becomes
> noticeable when
> you have a lot of networks. Is that a fair statement?
>
> Well, the provisioning is the same between Basic and Advanced.
> The VR is utterly slow in doing that.
>
> It happens when you have a lot of VMs in those networks.
>
> In our case we have a couple of thousands VMs.
>
> What I'd like to prevent is that this is merged into 4.9.3, but
> is not in 4.10.
>
> However, I don't want to delay 4.10 any longer.
>
> Wido
>
> On May 9, 2017 5:39 PM, "Wido den Hollander" 
> <w...@widodh.nl<mailto:w...@widodh.nl>>
> wrote:
>
> +0
>
> I don't want to VOTE -1 due to a bug we are facing, but for us
> 4.10 would
> be a problem due to the VR performance.
>
> A PR is open for this, but I also don't want to delay 4.10 any
> longer:
> https://github.com/apache/cloudstack/pull/2089
>
> Technically the VR works, it is just that deployment is utterly
> slow.
>
> Wido
>
> Op 9 mei 2017 om 7:31 schreef Rajani Karuturi
> <raj...@apache.org<mailto:raj...@apache.org>>:
>
> Hi All,
>
> I've created a 4.10.0.0 release, with the following artifacts up
> for a
>
> vote:
>
> Git Branch and Commit SH:
> https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=commit;h=
>
> fadc80d50f9e95012c9ff3644b60b600c6f65204
>
> Commit:fadc80d50f9e95012c9ff3644b60b600c6f65204
> Branch: 4.10.0.0-RC20170509T1030
>
> Source release (checksums and signatures are available at the
> same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
>
> PGP release keys (signed using CBB44821):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> Vote will be open for 72 hours.
>
> For sanity in tallying the vote, can PMC members please be sure
> to
>
> indicate
>
> "(binding)" with their vote
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> ~Rajani
> http://cloudplatform.accelerite.com/




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized 

Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Jayapal Uradi]

Hi Rajani,

Also please  include the PR#1866.

Thanks,
Jayapal

> On May 11, 2017, at 10:10 AM, Rajani Karuturi  wrote:
>
> Thanks for testing Mike.
>
> RC3=RC2+PR#2089+Mike'sPR
>
> Any other additions?
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On May 10, 2017 at 7:47 PM, Tutkowski, Mike
> (mike.tutkow...@netapp.com) wrote:
>
> I've been running regression tests against the release candidate.
>
> So far, all tests but one have passed.
>
> The failing test is related to the storage cleanup thread. It
> looks like some code was changed in 4.10 with regards to this
> thread and that change is causing a problem around cleanup for
> managed storage in a particular situation.
>
> As a result of this, I was going to vote -1.
>
> I'm guessing the fix will not be complicated, but is important.
>
> I don't yet have the fix, however. Once I do, I can reply to
> this thread.
>
> On May 10, 2017, at 5:47 AM, Rajani Karuturi 
> wrote:
>
> I agree to your concerns Wido. I did check the PR before
> creating
> RC2. There were some outstanding comments on it.
>
> If no one has started testing RC2 and there are no objections,
> we
> can cancel this vote, quickly merge the PR and create RC3.
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
> wrote:
>
> Op 10 mei 2017 om 0:33 schreef Will Stevens
> :
>
> Just to clarify. Wido, the issue you are experiencing is only
> with basic
> networks and also exists in 4.9 right? The issue becomes
> noticeable when
> you have a lot of networks. Is that a fair statement?
>
> Well, the provisioning is the same between Basic and Advanced.
> The VR is utterly slow in doing that.
>
> It happens when you have a lot of VMs in those networks.
>
> In our case we have a couple of thousands VMs.
>
> What I'd like to prevent is that this is merged into 4.9.3, but
> is not in 4.10.
>
> However, I don't want to delay 4.10 any longer.
>
> Wido
>
> On May 9, 2017 5:39 PM, "Wido den Hollander" 
> wrote:
>
> +0
>
> I don't want to VOTE -1 due to a bug we are facing, but for us
> 4.10 would
> be a problem due to the VR performance.
>
> A PR is open for this, but I also don't want to delay 4.10 any
> longer:
> https://github.com/apache/cloudstack/pull/2089
>
> Technically the VR works, it is just that deployment is utterly
> slow.
>
> Wido
>
> Op 9 mei 2017 om 7:31 schreef Rajani Karuturi
> :
>
> Hi All,
>
> I've created a 4.10.0.0 release, with the following artifacts up
> for a
>
> vote:
>
> Git Branch and Commit SH:
> https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=commit;h=
>
> fadc80d50f9e95012c9ff3644b60b600c6f65204
>
> Commit:fadc80d50f9e95012c9ff3644b60b600c6f65204
> Branch: 4.10.0.0-RC20170509T1030
>
> Source release (checksums and signatures are available at the
> same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
>
> PGP release keys (signed using CBB44821):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> Vote will be open for 72 hours.
>
> For sanity in tallying the vote, can PMC members please be sure
> to
>
> indicate
>
> "(binding)" with their vote
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> ~Rajani
> http://cloudplatform.accelerite.com/




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: Very slow Virtual Router provisioning with 4.9.2.0

[Jayapal Uradi]

Another reason of slow can be VR configuration(persistent VR configuration 
design).  When one component config apply, whole VR configuration apply is 
executed. Due to this the VR boot up time will increase.

Thanks,
Jayapal


> On May 3, 2017, at 1:55 PM, Marc-Aurèle Brothier  wrote:
> 
> Hi Wido,
> 
> Well for us, it's not a version problem, it's simply a design problem. This
> VR is very problematic during any upgrade of cloudstack (which I perform
> every week almost on our platform), same goes for the secondary storage VMs
> which scans all templates. We've planned on our roadmap to get rid of the
> system vms. The VR is really a SPoF.
> 
> On Tue, May 2, 2017 at 7:57 PM, Wido den Hollander  wrote:
> 
>> Hi,
>> 
>> Last night I upgraded a CloudStack 4.5.2 setup to 4.9.2.0. All went well,
>> but the VR provisioning is terribly slow which causes all kinds of problems.
>> 
>> The vr_cfg.sh and update_config.py scripts start to run. Restart dnsmasq,
>> add metadata, etc.
>> 
>> But for just 1800 hosts this can take up to 2 hours and that causes
>> timeouts in the management server and other problems.
>> 
>> 2 hours is just very, very slow. So I am starting to wonder if something
>> is wrong here.
>> 
>> Did anybody else see this?
>> 
>> Running Basic Networking with CloudStack 4.9.2.0
>> 
>> Wido
>> 




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: Alternative Cloudstack UI for KVM and Basic Zones (with SG)

[Jayapal Uradi]

New UI pages looks good.

Thanks,
Jayapal
> On Apr 25, 2017, at 1:55 PM, Rajani Karuturi  wrote:
>
> Looks very good. Thanks for open sourcing it :)
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On April 25, 2017 at 12:42 PM, Ivan Kudryavtsev
> (kudryavtsev...@bw-sw.com) wrote:
>
> Hello, Cloudstack community.
>
> We are proud to present our last development effort to you.
> During the last
> 5 months we spend some time to develop alternative Cloudstack UI
> for basic
> zones with KVM hypervisor and security groups. This is basically
> the thing
> we are using in our clouds. During the design of the software we
> tried to
> fulfill the expectations of our average cloud users and simplify
> operations
> as much as possible.
>
> The project is OSS and can be found at GitHub with bunch of
> screenshots and
> deployment guide. It's under active development so, we will ge
> glad if you
> join and provide us with additional feedback, UX considerations
> and other
> interesting information.
>
> Project page at GitHub: https://bwsw.github.io/cloudstack-ui/
> Source code: https://github.com/bwsw/cloudstack-ui
>
> Have a good day. Looking forward hearing your feedback.
>
> --
> With best regards, Ivan Kudryavtsev
> Bitworks Software, Ltd.
> Cell: +7-923-414-1515
> WWW: http://bw-sw.com/




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Travis CI failures in PR#1996

[Jayapal Uradi]

Hi All,

In PR# 1996 travis CI is failing for the 9 tests always. I tried force pushing 
many times but still the issues are failing.

I have gone through the logs[1] for the travis CI. I have observed the below.

1. It seems the deploy datacenter is not up correctly.

Connection to localhost 8096 port [tcp/*] succeeded!

Starting DataCenter deployment

 Log Folder Path: 
/tmp//MarvinLogs//DeployDataCenter__Apr_13_2017_09_05_04_ET95HW. All logs will 
be available here 

 Deploy DC Started 

=== Data Center Settings are dumped to 
/tmp//MarvinLogs//DeployDataCenter__Apr_13_2017_09_05_04_ET95HW/dc_entries.obj===

Deploy DC Successful=
/home/travis/.travis/job_stages: line 153: 16004 Terminated  
travis_jigger $! $timeout $cmd

2. The tests setup is failing  and the TestName is showing None.

 Marvin Init Successful 
=== TestName: None | Status : EXCEPTION ===

===final results are now copied to: /tmp//MarvinLogs/test_suite_C0SKM5===



+---+-+-++
|   Test|   Result| Tim | Test file 
 |
|   | |  e  |   
 |
+===+=+=++
| ContextSuite context=TestDeployVm | exceptions. | 0   | test_affinity_groups  
 |
| WithAffinityGroup>:setup  | TypeError   | |   
 |


Can some one who has access, please look into it.

[1] https://s3.amazonaws.com/archive.travis-ci.org/jobs/221647776/log.txt


Thanks,
Jayapal



DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: VR Question

[Jayapal Uradi]

Hi Mike,

Can you please check the following
1. In  kvm host logs once to see any security group rules got failed.
2. Check the VR /etc/dhcphosts.txt entry for the vm is configured
3. tcpdump on VR interface to see whether the dhcp request reached to VR.

Thanks,
Jayapal

> On Apr 2, 2017, at 12:34 AM, Tutkowski, Mike  
> wrote:
> 
> I migrated my system VMs (including the VR) to KVM hosts today (from 
> XenServer hosts).
> 
> I still cannot get IP addresses assigned to user VMs in a Basic Zone.
> 
> This seems like a 4.10 blocker, too.
> 
> Is anyone else able to get IP addresses assigned to user VMs in a Basic Zone 
> when using KVM?
> 
> From: "Tutkowski, Mike" 
> Date: Wednesday, March 29, 2017 at 7:47 PM
> To: "dev@cloudstack.apache.org" 
> Subject: VR Question
> 
> Hi,
> 
> With 4.10 (master), I’m currently running all of my system VMs (including the 
> VR) on XenServer. When I create a user VM on VMware, it acquires an IP 
> address; however, when I create one on KVM, it does not.
> 
> All of this is running in a single, basic zone.
> 
> Thoughts on this?
> 
> Thanks!
> Mike




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: :[VOTE] Apache Cloudstack 4.10.0.0

[Jayapal Uradi]

Created the PR.
https://github.com/apache/cloudstack/pull/1991

Thanks,
Jayapal

On Mar 6, 2017, at 3:58 PM, Rajani Karuturi 
> wrote:

Thanks Wei Zhow. Will ping Jayapal.

~ Rajani
http://cloudplatform.accelerite.com/

On March 6, 2017 at 3:25 PM, Wei ZHOU 
(ustcweiz...@gmail.com) wrote:
about ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-9821


this seems to be caused by commit 175c8d83b8a628566a4c443db0de587874718c8c

Author: Jayapal 
>
AuthorDate: Mon Feb 20 18:29:14 2017 +0530
Commit: Jayapal 
>
CommitDate: Mon Feb 20 18:34:13 2017 +0530

CLOUDSTACK-8871: fixed issue with the xenserver 6.2 ipset nethash
---
scripts/vm/hypervisor/xenserver/vmops | 25 +++--
1 files changed, 19 insertions(+), 6 deletions(-)

Jayapal, could you please have a look ?

2017-03-04 2:41 GMT+01:00 Rajani Karuturi 
>:
Thanks for the update mike.

@wido, weizhou
Can you take a look at the issue please?

~Rajani
Sent from phone.

On 4 Mar 2017 3:25 a.m., "Tutkowski, Mike" 
>
wrote:
-1 (binding)

Per my previous e-mails concerning this issue, here is a ticket I
created:

https://issues.apache.org/jira/browse/CLOUDSTACK-9821

We should get someone from the networking side of things to investigate.

Thanks!

On 3/3/17, 1:28 AM, "Rohit Yadav" 
> wrote:

-1 (binding)


All, I've found an upgrade blocker. Pre 4.6 users are required to
seed
4.6 systemvmtemplate to proceed with the upgrade otherwise upgrade fails,
and from 4.9 upgrade to 4.10 does no check/enforcement that 4.10 based
systemvmtemplate has been seeded/registered, nor the minimum required
systemvmtemplate version is changed from 4.6.0 to 4.10.0.


After we have merged the strongswan/java8 PR, I had updated the
upgrade docs on how to upgrade the systemvmtemplate here:

http://docs.cloudstack.apache.org/projects/cloudstack-
release-notes/en/4.10/upgrade/upgrade-4.9.html


Using the above, I've tried to fix these issues here, please review
and merge for RC2:

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


With
 above fix, the
aim is that users only seed the 4.10 systemvmtemplate before upgrade and
post-upgrade the upgrade paths fix the entries, global setting etc.


Regards.


From: Tutkowski, Mike 
>
Sent: 02 March 2017 22:39:08
To: dev@cloudstack.apache.org
Subject: Re: :[VOTE] Apache Cloudstack 4.10.0.0

I rolled back to my master branch at da66b06e7d562393da2e4b52206943
f8bad49d10
and it works.

It appears something that went into after that commit has broken
this.
It looks like this SHA is about two weeks old and that 43 commits have
gone
into master since it.

On 3/2/17, 7:06 AM, "Tutkowski, Mike" 
>
wrote:

According to where the code fails, though, it appears to be a
networking problem. If I set a breakpoint before the failure and change a
variable to say that security groups are not being used, then the VM
starts.

I think this is a recently introduced problem because I have
another branch based off of a slightly older version of master and it
works
fine here.
On Mar 2, 2017, at 6:51 AM, Pierre-Luc Dion <
pd...@cloudops.com>
wrote: > wrote: in a Basic
VMs NFS null?! 10.117.40.53, Exception: xenbase. xenbase. java:266) xenbase. 
xenbase. java:266) (Network-Scavenger-1:ctx- checkResponse(Types.java:693) 457) 
xenbase. xenbase. java:266) checkResponse(Types.java:693) 457) xenbase. 
xenbase. java:266) checkResponse(Types.java:693) 457) xenbase. xenbase. 
java:266) VM orchestrateStart( orchestrateStart( java:266) dataCenterId:: 
VirtualMachineEntityImpl.java: dispatch(ApiDispatcher.java: java:266) 
orchestrateStart( orchestrateStart( artifacts the org/repos/dist/dev/cloudstack/




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: Removed IPs with add = true in /etc/cloudstack/ips.json on router

[Jayapal Uradi]

Hi Jeff,

I tested in my setup with latest master rebasing.
I did not see the add:true (ips.json) when ips are removed from the UI.

Removed public ip is not configured on the eth2 interface.

Here is the output:

4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:f6:cc:00:00:0e brd ff:ff:ff:ff:ff:ff
inet 10.147.46.102/24 brd 10.147.46.255 scope global eth2
inet 10.147.46.112/24 brd 10.147.46.255 scope global secondary eth2

"eth2": [
{
"add": true,
"broadcast": "10.147.46.255",
"cidr": "10.147.46.102/24",
"device": "eth2",
"first_i_p": true,
"gateway": "10.147.46.1",
"netmask": "255.255.255.0",
"network": "10.147.46.0/24",
"new_nic": false,
"nic_dev_id": 2,
"nw_type": "public",
"one_to_one_nat": false,
"public_ip": "10.147.46.102",
"size": "24",
"source_nat": true,
"vif_mac_address": "06:4a:54:00:00:0e"
},
{
"add": false,
"broadcast": "10.147.46.255",
"cidr": "10.147.46.107/24",
"device": "eth2",
"first_i_p": true,
"gateway": "10.147.46.1",
"netmask": "255.255.255.0",
"network": "10.147.46.0/24",
"new_nic": false,
"nic_dev_id": 2,
"nw_type": "public",
"one_to_one_nat": true,
"public_ip": "10.147.46.107",
"size": "24",
"source_nat": true,
"vif_mac_address": "06:b5:36:00:00:13"
},
{
"add": false,
"broadcast": "10.147.46.255",
"cidr": "10.147.46.108/24",
"device": "eth2",
"first_i_p": true,
"gateway": "10.147.46.1",
"netmask": "255.255.255.0",
"network": "10.147.46.0/24",
"new_nic": false,
"nic_dev_id": 2,
"nw_type": "public",
"one_to_one_nat": true,
"public_ip": "10.147.46.108",
"size": "24",
"source_nat": true,
"vif_mac_address": "06:6d:c8:00:00:14"
},
{
"add": false,
"broadcast": "10.147.46.255",
"cidr": "10.147.46.111/24",
"device": "eth2",
"first_i_p": true,
"gateway": "10.147.46.1",
"netmask": "255.255.255.0",
"network": "10.147.46.0/24",
    "new_nic": false,
"nic_dev_id": 2,
"nw_type": "public",
"one_to_one_nat": true,
"public_ip": "10.147.46.111",
"size": "24",
"source_nat": true,
"vif_mac_address": "06:32:90:00:00:17"
},
{
"add": true,
"broadcast": "10.147.46.255",
"cidr": "10.147.46.112/24",
"device": "eth2",
"first_i_p": true,
"gateway": "10.147.46.1",
"netmask": "255.255.255.0",
"network": "10.147.46.0/24",
"new_nic": false,
"nic_dev_id": 2,
"nw_type": "public",
"one_to_one_nat": true,
"public_ip": "10.147.46.112",
"size": "24",
"source_nat": true,
"vif_mac_address": "06:83:68:00:00:18"
}


Thanks,
Jayapal

On Mar 3, 2017, at 10:08 AM, Jayapal Uradi 
<jayapal.ur...@accelerite.com<mailto:jayapal.ur...@accelerite.com>> wrote:

Let me have quick look at my setup and will respond to you.

Thanks,
Jaya

Re: Removed IPs with add = true in /etc/cloudstack/ips.json on router

[Jayapal Uradi]

Let me have quick look at my setup and will respond to you.

Thanks,
Jayapal
> On Mar 2, 2017, at 3:48 PM, Jeff Hair <j...@greenqloud.com> wrote:
>
> Jayapal,
>
> As far as I understand and it (and what I've seen based on some testing),
> IPs shouldn't be getting reconfigured (and thus arpinged) once PR 1907 is
> applied. The JSON entry is not removed from the DataBag, but they SHOULD
> have the "add" property set to false, at least.
>
> Can you clarify: Is the problem with 1907 still happening on 1908? This was
> my original fear, but as far as I can tell in my testing, it's not
> happening.
>
> Jeff
>
> *Jeff Hair*
> Technical Lead and Software Developer
>
> Tel: (+354) 415 0200
> j...@greenqloud.com
> www.greenqloud.com
>
> On Thu, Mar 2, 2017 at 4:52 AM, Jayapal Uradi <jayapal.ur...@accelerite.com>
> wrote:
>
>> Because of removed ips get configured again on VR, it is giving the
>> perception that  PR #1908 is not removing the static nat ips in VR.
>>
>> Thanks,
>> Jayapal
>>
>>> On Mar 1, 2017, at 10:12 PM, Will Stevens <wstev...@cloudops.com> wrote:
>>>
>>> Hey Jeff,
>>> We were having this issue as well before we implemented 1907 and we have
>>> not had it since.  We don't user RvR yet though, so that could be a
>>> different story.
>>>
>>> We had tried a couple other implementations previously and we were still
>>> having the issue.  So far 1907 has been working without issues for us.
>> We
>>> have been running it in production for a couple months now and we were
>>> running into the issue you described quite a bit before that.
>>>
>>> *Will STEVENS*
>>> Lead Developer
>>>
>>> <https://goo.gl/NYZ8KK>
>>>
>>> On Wed, Mar 1, 2017 at 8:41 AM, Jeff Hair <j...@greenqloud.com> wrote:
>>>
>>>> Yes, i know it's been merged. The problem is that this issue seems to
>> come
>>>> up "randomly" (of course, nothing is ever really random), and I was
>>>> wondering if anyone else has run into it.
>>>>
>>>> My initial testing of PR 1907 hasn't yielded the issue happening yet,
>> and
>>>> the only place I've seen it so far is on a router that doesn't have 1907
>>>> applied. But I'm not convinced that it won't happen ever after applying
>>>> 1907...
>>>>
>>>> *Jeff Hair*
>>>> Technical Lead and Software Developer
>>>>
>>>> Tel: (+354) 415 0200
>>>> j...@greenqloud.com
>>>> www.greenqloud.com
>>>>
>>>> On Wed, Mar 1, 2017 at 1:39 PM, Wei ZHOU <ustcweiz...@gmail.com> wrote:
>>>>
>>>>> PR 1907 has been merged. You can test with it.
>>>>>
>>>>>
>>>>> 2017-03-01 14:12 GMT+01:00 Jeff Hair <j...@greenqloud.com>:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> In the testing of PR 1908 (https://github.com/apache/
>>>>> cloudstack/pull/1908
>>>>>> ),
>>>>>> it has come up that some IPs which are removed from the router get put
>>>>> into
>>>>>> the /etc/cloudstack/ips.json data bag with add = True. This causes the
>>>>> IPs
>>>>>> to be re-added to the interface and arpinged, breaking connectivity
>> and
>>>>>> causing IP conflicts.
>>>>>>
>>>>>> Does anyone know anything about this? Is it due to old routers that
>>>> were
>>>>>> affected by CLOUDSTACK-9500 (fixed in PR 1907), or is this behavior
>>>> still
>>>>>> actively happening on master?
>>>>>>
>>>>>> Jeff
>>>>>>
>>>>>
>>>>
>>
>>
>>
>>
>> DISCLAIMER
>> ==
>> This e-mail may contain privileged and confidential information which is
>> the property of Accelerite, a Persistent Systems business. It is intended
>> only for the use of the individual or entity to which it is addressed. If
>> you are not the intended recipient, you are not authorized to read, retain,
>> copy, print, distribute or use this message. If you have received this
>> communication in error, please notify the sender and delete all copies of
>> this message. Accelerite, a Persistent Systems business does not accept any
>> liability for virus infected mails.
>>




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: Removed IPs with add = true in /etc/cloudstack/ips.json on router

[Jayapal Uradi]

Because of removed ips get configured again on VR, it is giving the perception 
that  PR #1908 is not removing the static nat ips in VR.

Thanks,
Jayapal

> On Mar 1, 2017, at 10:12 PM, Will Stevens  wrote:
>
> Hey Jeff,
> We were having this issue as well before we implemented 1907 and we have
> not had it since.  We don't user RvR yet though, so that could be a
> different story.
>
> We had tried a couple other implementations previously and we were still
> having the issue.  So far 1907 has been working without issues for us.  We
> have been running it in production for a couple months now and we were
> running into the issue you described quite a bit before that.
>
> *Will STEVENS*
> Lead Developer
>
> 
>
> On Wed, Mar 1, 2017 at 8:41 AM, Jeff Hair  wrote:
>
>> Yes, i know it's been merged. The problem is that this issue seems to come
>> up "randomly" (of course, nothing is ever really random), and I was
>> wondering if anyone else has run into it.
>>
>> My initial testing of PR 1907 hasn't yielded the issue happening yet, and
>> the only place I've seen it so far is on a router that doesn't have 1907
>> applied. But I'm not convinced that it won't happen ever after applying
>> 1907...
>>
>> *Jeff Hair*
>> Technical Lead and Software Developer
>>
>> Tel: (+354) 415 0200
>> j...@greenqloud.com
>> www.greenqloud.com
>>
>> On Wed, Mar 1, 2017 at 1:39 PM, Wei ZHOU  wrote:
>>
>>> PR 1907 has been merged. You can test with it.
>>>
>>>
>>> 2017-03-01 14:12 GMT+01:00 Jeff Hair :
>>>
 Hi,

 In the testing of PR 1908 (https://github.com/apache/
>>> cloudstack/pull/1908
 ),
 it has come up that some IPs which are removed from the router get put
>>> into
 the /etc/cloudstack/ips.json data bag with add = True. This causes the
>>> IPs
 to be re-added to the interface and arpinged, breaking connectivity and
 causing IP conflicts.

 Does anyone know anything about this? Is it due to old routers that
>> were
 affected by CLOUDSTACK-9500 (fixed in PR 1907), or is this behavior
>> still
 actively happening on master?

 Jeff

>>>
>>




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Travis CI test cases failure in PR 1908

[Jayapal Uradi]

Hi,

In PR 1908 few of the test cases are failing which are not related to the this.
vgpu test case is failing. I think this test is not required to run on 
simulator.

Is this the same case for all or I am only getting these error.

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


Thanks,
Jayapal


DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: re-introduction

[Jayapal Uradi]

Welcome back Daan!

-Jayapal
> On Feb 1, 2017, at 1:56 PM, Daan Hoogland  wrote:
>
> Hello,
>
>
> My name is Daan Hoogland. I've been mostly out of the community since May 
> last year. I am now back through the generous sponsorship of my new employer 
> and will be working (mostly) as developer on cloudstack.
>
> For those who remember me and are curious, I've been learning some scala and 
> some rust in the meanwhile and have been working on financial middleware in 
> between.
>
>
> I expect to have good times back in here :)
>
> daan.hoogl...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, Utrecht Utrecht 3531 VENetherlands
> @shapeblue
>
>
>




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: [ANNOUNCE] New committer: Syed Ahmed

[Jayapal Uradi]

Congrats Syed!

-Jayapal

> On Oct 6, 2016, at 9:45 AM, Rajani Karuturi  wrote:
>
> Congratulations Syed!
>
> ~ Rajani
> http://cloudplatform.accelerite.com/
>
> On October 6, 2016 at 1:37 AM, Will Stevens
> (williamstev...@gmail.com) wrote:
> The Project Management Committee (PMC) for Apache CloudStack
> has asked Syed Ahmed to become a committer and we are pleased to
> announce that he has accepted.
>
> Being a committer allows many contributors to contribute more
> autonomously. For developers, it makes it easier to submit
> changes and
> eliminates the need to have contributions reviewed via the patch
> submission process. Whether contributions are development-related
> or
> otherwise, it is a recognition of a contributor's participation
> in the
> project and commitment to the project and the Apache Way.
>
> Please join me in congratulating Syed!
>
> Will Stevens
> on behalf of the CloudStack PMC




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: [DISCUSS] Replacing the VR

[Jayapal Uradi]

Hi,

Instead of replacing the VR in first place we should add VyOS/cloudrouter as 
provider. Once it is stable, network offerings (on upgrade) can be updated to 
use it and we can drop the VR if we want at that release onwards.

VR is stabilized over a period of time and some of them are running without 
issues.  When we replicate the ACS VR features in new solution it takes some to 
find the missing pieces (hidden bugs).

Thanks,
Jayapal

> On Sep 13, 2016, at 2:52 PM, Nux! <

> n...@li.nux.ro> wrote:
>
> Hi,
>
> I like the idea.
>
> Cloudrouter looks really promising, I'm not too keen on VyOS (it doesn't have 
> a proper http api etc).
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
>> From: "Will Stevens" 
>> To: dev@cloudstack.apache.org
>> Sent: Monday, 12 September, 2016 21:20:11
>> Subject: [DISCUSS] Replacing the VR
>
>> *Disclaimer:* This is a thought experiment and should be treated as such.
>> Please weigh in with the good and bad of this idea...
>>
>> A couple of us have been discussing the idea of potentially replacing the
>> ACS VR with the VyOS [1] (Open Source Vyatta VM).  There may be a license
>> issue because I think it is licensed under GPL, but for the sake of
>> discussion, let's assume we can overcome any license issues.
>>
>> I have spent some time recently with the VyOS and I have to admit, I was
>> pretty impressed.  It is simple and intuitive and it gives you a lot more
>> options for auditing the configuration etc...
>>
>> Items of potential interest:
>> - Clean up our current VR script spaghetti to a simpler more auditable
>> configuration workflow.
>> - Gives a cleaner path for IPv6 support.
>> - Handles VPN configuration via the same configuration interface.
>> - Support for OSPF & BGP.
>> - VPN support through OpenVPN & StrongSwan.
>> - Easily supports HA (redundant routers) through VRRP.
>> - VXLAN support.
>> - Transaction based changes to the VR with rollback on error.
>>
>> Items that could be difficult to solve:
>> - Userdata password reset workflow and implementation.
>> - Upgrade process.
>>
>> The VyOS is not the only option if we were to consider this approach.
>> Another option, which I don't know as well, would be CloudRouter (AGPL
>> license) [2] which is purely API driven.
>>
>> Anyway, would love to hear your thoughts...
>>
>> Will
>>
>> [1] https://vyos.io/
>> [2] https://cloudrouter.org/




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: JuniperSRX firewall configure plugin source bug

[Jayapal Uradi]

Hi Gust,

The changes look good  please go head and raise a PR for it.

Thanks,
Jayapal
> On Aug 24, 2016, at 8:14 AM, Gust  wrote:
>
> Hi , all
>
> There is a bug in com.cloud.network.resource.JuniperSrxResource
>
> It will report syntax error when configure  outgress rule to Juniper srx 
> hardware firewall.
>
>
> begin line 2830 :
>
>if 
> (type.equals(SecurityPolicyType.SECURITYPOLICY_EGRESS_DEFAULT)) {
>if (defaultEgressAction == false) {
>//for default policy is false add default deny 
> rules
>action = "";
>} else {
>action = "";
>}
>
>} else {
>if (defaultEgressAction == true) {
>//configure egress rules to deny the traffic when 
> default egress is allow
>action = "";
>} else {
>action = "";
>}
> //error here
>xml = replaceXmlValue(xml, "action", action);
>
>}
>
> fix:
>
>if 
> (type.equals(SecurityPolicyType.SECURITYPOLICY_EGRESS_DEFAULT)) {
>if (defaultEgressAction == false) {
>//for default policy is false add default deny 
> rules
>action = "";
>} else {
>action = "";
>}
>
>} else {
>if (defaultEgressAction == true) {
>//configure egress rules to deny the traffic when 
> default egress is allow
>action = "";
>} else {
>action = "";
>}
>}
> //move replace  out
>xml = replaceXmlValue(xml, "action", action);
>
>
>
> gust
>
> Being china.
> 2016-08-24
>
>
>
>




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: Working Site-to-Site VPN gets disconnected and VPC seems to forgets ACL’s

[Jayapal Uradi]

Hi Jonas,

It seems the connection is going down because the dead period detection.

In router run the command 'ipsec auto —status’  to vpn connection  status.
When the connection is down initiate traffic from the guest vm to other end of 
vpn and go to router check the ipsec vpn status (ipsec auto —status).
This gives wether the connection is up or not in the VR.  It takes router 
status get interval to update the VPN status.

The browsing you mentioned is about browsing the other end of vpn servers ?

Thanks,
Jayapal

> On Jul 21, 2016, at 5:25 PM, Jonas Schlichtenbrede 
>  wrote:
> 
> Hi CloudStack Users and Developers,
> 
> we’re currently implementing a new CloudStack environment based on 4.8.0.1
> (System VM Template is 4.6) with XenServer 6.5 SP1 and all the latest
> updates.
> 
> So far everything works as expected we only have an issue regarding the
> stability of Site-to-Site VPNs within VPCs and we think ACL’s.
> 
> I’ll try to describe the problem and behaviour:
> 
> A connected and working S2S VPN switches to disconnected after some time
> (usually a few hours). In relation to that the VPC seems to “forget” it’s
> ACLs. Restarting only the Network Tier (a VM lives within) solves the
> issues for a short period of time (1-3 hours). The state of the VPN
> switches to connected and the S2S VPN is working again. Also pinging from
> the VM to any public address is working again. Strange is, that for example
> browsing to a website is working all the time. Isolated networks however
> work like a charm.
> 
> We tried to solve this issue through several tests. We changing the network
> setup and reducing the complexity just to get this behaviour isolated. But
> it’s always the same. We also tried several different connections to
> different customer gateways (firewalls) and a VPC-VPN to VPC-VPN connection
> to another CloudStack deployment (based on Version 4.5.2) without any
> success.
> 
> In addition, we tested several setups like CentOS 6 and CentOS 7, but again
> always the same. We updated one installation to the master from yesterday
> 4.9.0.0-snapshot – again no success. We do not have any issues with version
> 4.5.2 – but this installation is in a different datacentre.
> 
> Below you’ll find some logs – the relevant IP for this test connection is:
> *85.88.16.104*
> 
> CloudStack 4.8.0.1 Logs (Google Docs):
> 
> https://drive.google.com/open?id=1gqIjDdG1htps4p1t7m1uHSs7aNHplWp1Np83nH6e7zM
> 
> 
> IPsec Logs from the Virtual Router:
> https://drive.google.com/open?id=1ZWvhFu2P_Wv_lF8TgYMmexeS_KDag1Mp-kmuhl8l7uU
> 
> 
> Thank you in advance for your help!
> 
> Jonas
> 
> PS: If possible from your site we can do a remote session to take a look at
> the setup.




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: 4.7 - VPC Network ACL rules

[Jayapal Uradi]

Hi Patrick,

Can you please send the DB entries of ACL rules and iptables rules output 
(iptables  -L -nv)
These will helps to understand the issue better.

-Jayapal

> On Jun 1, 2016, at 7:24 PM, Patrick Dube  wrote:
>
> Hello
>
> I have been hitting problems with Network ACL rules in VPCs with 4.7 (
> looked at the code for 4.8 and it looks similar). It seems that the rule
> ordering is actually inverted on the VR. So the rules with higher rule
> numbers are getting checked before the lower ones. As an example, this can
> be problematic if you want a DENY all and to whitelist certain traffic.
> Also, changing the rule number does not apply the new order to the VR.
>
> Anyone else having problems?
>
> Patrick




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: [ANNOUNCE] Will Stevens as new Apache CloudStack VP

[Jayapal Uradi]

Congrats Will.

Thanks,
Jayapal
> On 19-May-2016, at 1:54 pm, Rohit Yadav  wrote:
>
> Congrats Will.
>
> Regards,
> Rohit Yadav
>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
> On May 19 2016, at 12:26 pm, Sebastien Goasguen  wrote:
>
> Morning Everyone,
>
> Yesterday at the ASF board meeting, the board passed the resolution making 
> Will Stevens the new Vice President of the Apache CloudStack project.
>
> Join me in congratulating Will on this appointment, wish him luck and bring 
> your unwavering support !
>
> You may have noticed that Will took on RM duties for the new releases going 
> forward and has also taken a very active role to finish bringing us to github 
> based workflow and CI. Will has some updates on that front that I am sure you 
> will all like.
>
> -Sebastien
> Former VP CloudStack




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: [ANNOUNCE] New committer: Simon Weller

[Jayapal Uradi]

Congrats Simon!

Thanks,
Jayapal


> On 04-May-2016, at 7:19 pm, Suresh Sadhu  wrote:
>
> Congrats Simon.
>
> -Original Message-
> From: Ahmad Emneina [mailto:aemne...@gmail.com]
> Sent: Wednesday, May 4, 2016 8:11 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [ANNOUNCE] New committer: Simon Weller
>
> Congratulations Simon!
>
> On Thu, Apr 28, 2016 at 12:23 AM, Erik Weber  wrote:
>
>> The Project Management Committee (PMC) for Apache CloudStack has asked
>> Simon Weller to become a committer and we are pleased to announce that
>> they have accepted.
>>
>>
>> Being a committer allows many contributors to contribute more
>> autonomously. For developers, it makes it easier to submit changes and
>> eliminates the need to have contributions reviewed via the patch
>> submission process. Whether contributions are development-related or
>> otherwise, it is a recognition of a contributor's participation in the
>> project and commitment to the project and the Apache Way.
>>
>> Please join me in congratulating Simon
>>
>> --Erik
>> on behalf of the CloudStack PMC
>>
>
>
>
> DISCLAIMER
> ==
> This e-mail may contain privileged and confidential information which is the 
> property of Accelerite, a Persistent Systems business. It is intended only 
> for the use of the individual or entity to which it is addressed. If you are 
> not the intended recipient, you are not authorized to read, retain, copy, 
> print, distribute or use this message. If you have received this 
> communication in error, please notify the sender and delete all copies of 
> this message. Accelerite, a Persistent Systems business does not accept any 
> liability for virus infected mails.




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: Hooking into the SecurityGroups

[Jayapal Uradi]

Hi Nux,

I think ipset ‘myipset’ changes might be there in other commits. If you do not 
have special requirement then you can use the existing ipset which is with the 
vmname ex: i-2-3-VM. Except this it looks good to me.


Thanks,
Jayapal


> On 04-Apr-2016, at 10:17 pm, Nux!  wrote:
> 
> Well, this is what we got working in the end. If someone has any suggestions 
> on how to improve it, that'd be great.
> 
> https://github.com/NuxRo/cloudstack/commit/de6f97367fc2dc02378f367c462eaaec8f92e234
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> - Original Message -
>> From: "Nux!" 
>> To: "dev" 
>> Sent: Friday, 1 April, 2016 11:42:10
>> Subject: Hooking into the SecurityGroups
> 
>> Hi,
>> 
>> I want to hook into the SGs and add a few iptables rules every time a VM is
>> spawned and delete them when the VM is moved/deleted.
>> Has anyone done this before? Any pointers before I go and butcher it? :-)
>> 
>> Lucian
>> 
>> --
>> Sent from the Delta quadrant using Borg technology!
>> 
>> Nux!
>> www.nux.ro




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: Hooking into the SecurityGroups

[Jayapal Uradi]

Hi Nux,

You need to look at the vmops file for xenserver and security_group.py for the 
kvm.

Look at the below methods in these file.
 destroy_network_rules_for_vm, default_network_rules.

Thanks,
jayapal


On 01-Apr-2016, at 4:12 pm, Nux! > wrote:

Hi,

I want to hook into the SGs and add a few iptables rules every time a VM is 
spawned and delete them when the VM is moved/deleted.
Has anyone done this before? Any pointers before I go and butcher it? :-)

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: introduction

[Jayapal Uradi]

Welcome back Murali.

-Jayapal

> On 23-Mar-2016, at 8:24 pm, Will Stevens  wrote:
>
> Great to have you back Murali.  Looking forward to working with you. :)
> On Mar 23, 2016 10:49 AM, "Ahmad Emneina"  wrote:
>
>> Great to see you back working on CloudStack!
>>
>> Ahmad E
>>
>>> On Mar 23, 2016, at 4:50 AM, Murali Reddy 
>> wrote:
>>>
>>> All,
>>>
>>> Just wanted to let the community know that I have decided to work on
>> Apache CloudStack again. I have taken up a position at ShapeBlue, so you
>> will be seeing me around @dev and @users. For the new members of the
>> community and others who I have not interacted with, here is small self
>> introduction. I started my journey with CloudStack, in late 2010 as
>> cloud.com employee. Later spent 4 years till late 2014 working on various
>> CloudStack features (EIP, GSLB, NAAS, NetScaler integration, native SDN
>> controller, distributed virtual router, event bus to name few). I was
>> working on NFV solution on OpenStack over a year. I am excited to join back
>> the community, looking forward to interact with you.
>>>
>>> Thanks,
>>> Murali
>>




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.