Re: [ACS4.4] Cherry-pick e3bb8b98bd9055115004da2ec67b29271a3974c5

[Daan Hoogland]

On Thu, May 22, 2014 at 1:29 AM, Kelven Yang  wrote:
> e3bb8b98bd9055115004da2ec67b29271a3974c5


pulled, please note that there is trailing spaces in xml files and
log4j.properties. Reviewing I also encountered an old conflict in
comment. I'll look for that one in head and resolve it there.

-- 
Daan

[ACS44][PROPOSAL] old blocker bugs

[Daan Hoogland]

LS,

There are several blocker bugs registered for 4.4 that have not been
touched for over a week. I seems strange to me that a blocker would be
left alone for so long and I therefor propose to reduce priority of
blockers that have not been touched for over a week to trivial. I have
mailed reporters to a few querying about the status but this tactic
doesn't work.

thoughts?

-- 
Daan

Re: [ACS4.4] Cherry-pick 356f6121a78d147d72136044c90472234f667730

[Daan Hoogland]

On Thu, May 22, 2014 at 3:09 AM, Min Chen  wrote:
> 356f6121a78d147d72136044c90472234f667730


is in

-- 
Daan

Re: [ACS4.4] Cherry-pick request : b4457d92f4ceec83f09b4514a0164c7ec3775e4d

[Daan Hoogland]

On Thu, May 22, 2014 at 3:57 AM, Yoshikazu Nojima  wrote:
> b4457d92f4ceec83f09b4514a0164c7ec3775e4d


is in

-- 
Daan

Re: VPC Site to Site VPN CIDR RFC1918

[Daan Hoogland]

I ran a test with a colleague this week connecting two cs vpcs. this works.

On Thu, May 22, 2014 at 6:05 AM, Sanjeev Neelarapu
 wrote:
> In site-to-site vpn both sides need not to be under cloudstack control. Only 
> one site can be under cs control.
>
> -Original Message-
> From: Erik Weber [mailto:terbol...@gmail.com]
> Sent: Thursday, May 22, 2014 4:23 AM
> To: dev
> Subject: Re: VPC Site to Site VPN CIDR RFC1918
>
> The documentation says something else, excerpt:
> " The difference from Remote VPN is that Site-to-site VPNs connects entire 
> networks to each other, for example, connecting a branch office network to a 
> company headquarters network. In a site-to-site VPN, hosts do not have VPN 
> client software; they send and receive normal TCP/IP traffic through a VPN 
> gateway.".
>
> Assuming that both sides is under cloudstack control is just odd and makes no 
> sense.
>
> I'll file a ticket whenever I find the time, but still appreciate input :-)
>
> Erik Weber
> 22. mai 2014 00:16 skrev "Daan Hoogland"  følgende:
>
>> I guess you shouldn't use the site to site vpn but just a vpn. I am
>> not sure how to configure that but you should just create an active
>> (client side) vpn to the external network. I see no reason why it
>> should't work. the site to site assumes you have both sides in
>> cloudstack and thus with rfc1918 networks.
>>
>> On Wed, May 21, 2014 at 6:10 PM, Erik Weber  wrote:
>> > Site to site vpn.
>> >
>> > I'm not in control of the 50.0.1 network, but the client is.
>> >
>> > Basically the use case is that they want to secure the traffic to
>> > their cloud vms, and are fortunate enough to not have to use rfc1918
>> > on their network.
>> >
>> > I guess we could work around it by terminating the vpn on our
>> > equipment
>> and
>> > access it as a private gateway instead, but I'd prefer to use the
>> > technology that we so braverly tell our clients about.
>> >
>> > Erik
>> > 21. mai 2014 17:05 skrev "Daan Hoogland" 
>> følgende:
>> >
>> >> Are you creating a site to site vpn or connecting to an external
>> network?
>> >>
>> >> On Wed, May 21, 2014 at 5:02 PM, Daan Hoogland
>> >> > >
>> >> wrote:
>> >> > Erik, If it doesn't work it is probably been blocked on purpose
>> >> > but I don't see why it is. I don't know your use case either and
>> >> > it seems an unlikely one. But if the 50.0.1 net is out of your
>> >> > control you maybe should be able to configure this. So I would
>> >> > say it is a bug/lack of feature. I'll look into the code for the place 
>> >> > the error is generated.
>> >> >
>> >> > in short: file a ticket
>> >> >
>> >> > On Wed, May 21, 2014 at 2:34 PM, Erik Weber 
>> wrote:
>> >> >> I understand that, but what my client wants is to connect public
>> >> >> ips instead of rfc1918 on one of the sides.
>> >> >>
>> >> >> e.g. one network has 10.0.1.0/24 and ip 1.2.3.4 the other has
>> >> >> 50.0.1.0/24 and ip 50.0.0.1
>> >> >>
>> >> >> but cloudstack currently does not let you do that, because it
>> >> >> expects
>> >> cidrs
>> >> >> to be rfc1918. see log excerpt:
>> >> >>
>> >> >> 2014-05-21 12:30:42,326 WARN  [c.c.u.n.NetUtils]
>> >> >> (API-Job-Executor-7:job-3072 ctx-bf3922b1) cidr 50.0.1.0/24 is
>> >> >> not
>> RFC
>> >> 1918
>> >> >> compliant
>> >> >> 2014-05-21 12:30:42,335 ERROR [c.c.a.ApiAsyncJobDispatcher]
>> >> >> (API-Job-Executor-7:job-3072) Unexpected exception while
>> >> >> executing
>> >> >>
>> org.apache.cloudstack.api.command.user.vpn.CreateVpnCustomerGatewayCmd
>> >> >> com.cloud.exception.InvalidParameterValueException: The customer
>> gateway
>> >> >> guest cidr list 50.0.1.0/24 is invalid guest cidr!
>> >> >> at
>> >> >>
>> >>
>> com.cloud.network.vpn.Site2SiteVpnManagerImpl.createCustomerGateway(Si
>> te2SiteVpnManagerImpl.java:176)
>> >> >>
>> >> >> I'm wondering if this is a bug/lacking feature, or intended.
>> >> >> As I initially said I'm not a network guy, so there might be
>> perfectly
>> >> good
>> >> >> reasons this shouldn't be allowed.
>> >> >>
>> >> >> But if it's a bug/lacking feature it would be great to know so
>> >> >> that I
>> >> could
>> >> >> file a ticket for it.
>> >> >>
>> >> >> --
>> >> >> Erik Weber
>> >> >>
>> >> >>
>> >> >> On Wed, May 21, 2014 at 2:09 PM, Daan Hoogland <
>> daan.hoogl...@gmail.com
>> >> >wrote:
>> >> >>
>> >> >>> Erik,
>> >> >>>
>> >> >>> The vpn let's you connect to all the computers in the network
>> >> >>> on the other site on their private adresses. This means that
>> >> >>> you can give
>> the
>> >> >>> cidr of the remote network in the definition on vpn connection.
>> >> >>>
>> >> >>> one network has 10.0.1.0/24 and ip 1.2.3.4 the other has
>> >> >>> 10.0.2.0/24 and ip 4.3.2.1
>> >> >>>
>> >> >>> on the first you define endpoint/gateway 4.3.2.1 with cidr
>> 10.0.1.0/24
>> >> >>> and you make it passive
>> >> >>> on the second you define the adresses of the first and stat is
>> without
>> >> >>> the passive function
>> >> >>> now you can ping a machine with address 10.0.1.123 from

Re: Network IDS in VPC

[Daan Hoogland]

Marcus, you mention a permission issue that triggers the though:
should a root admin be allowed? I think not. This brings up extra
requirements on the IAM, does it?

I would implement the functionality on the router.

On Thu, May 22, 2014 at 6:42 AM, Marcus  wrote:
> I really like the lower overhead of just port mirroring from one of the
> router's interfaces to an instance interface host-side, but I really
> dislike the affinity it creates between the router and the listener, and
> all of the complications it creates for host maintenance and migrations. It
> may also require that whomever creates a network or vms on a network with
> this permission be a domain admin, since it has the ability to see
> everything on the wire for the whole VPC.
>
>
> On Wed, May 21, 2014 at 4:25 PM, Marcus  wrote:
>
>> Hi guys,
>>Not sure if this has been discussed before, but we are getting feature
>> requests for an IDS or packet-sniffing/monitoring capability. I have a
>> prototyped idea of how to do this (manual config), but would like some
>> input.
>>
>> We create a network offering or network capability/detail that is
>> specifically a 'sniffer net'. This would be relatively simple, and just do
>> two things:
>>
>> 1) when network is added to VPC, spin up a simple daemon on the VPC router
>> that does traffic mirroring (netsniff-ng or daemonlogger are debian
>> packages) from the public interface to the 'sniffer net' interface.
>>
>> 2) disables mac learning on the bridges created for the sniffer net, so
>> that an IDS system can come up in this net and see all of the mirrored
>> traffic. It wouldn't handle making the IDS appliance, that would be up to
>> the customer, it would simply create a network that enables traffic
>> monitoring for the VPC.
>>
>> I think we'd prefer any VMs brought up in this network to live on the same
>> host as the router for performance reasons, but that's probably not an
>> immediate requirement. I dislike the idea of trying to run an actual
>> capture saved to the VPC router, or an IDS software on the VPC router that
>> would need to be updated.
>>
>> We could also run traffic mirroring from the VPC router's interface
>> directly to another VM's interface, host side (daemonlogger -i vpcintf -o
>> idsintf), but it would need to be on the same host.
>>
>>
>>
>>



-- 
Daan

Re: VPC Site to Site VPN CIDR RFC1918

[Erik Weber]

We have no problem getting s2s to connect if the 'other end' from cs point
of view is within rfc1918.
Our problem is purely related to the limitation of only allowing rfc1918
networks on the other end.

Erik Weber


On Thu, May 22, 2014 at 10:21 AM, Daan Hoogland wrote:

> I ran a test with a colleague this week connecting two cs vpcs. this works.
>
> On Thu, May 22, 2014 at 6:05 AM, Sanjeev Neelarapu
>  wrote:
> > In site-to-site vpn both sides need not to be under cloudstack control.
> Only one site can be under cs control.
> >
> > -Original Message-
> > From: Erik Weber [mailto:terbol...@gmail.com]
> > Sent: Thursday, May 22, 2014 4:23 AM
> > To: dev
> > Subject: Re: VPC Site to Site VPN CIDR RFC1918
> >
> > The documentation says something else, excerpt:
> > " The difference from Remote VPN is that Site-to-site VPNs connects
> entire networks to each other, for example, connecting a branch office
> network to a company headquarters network. In a site-to-site VPN, hosts do
> not have VPN client software; they send and receive normal TCP/IP traffic
> through a VPN gateway.".
> >
> > Assuming that both sides is under cloudstack control is just odd and
> makes no sense.
> >
> > I'll file a ticket whenever I find the time, but still appreciate input
> :-)
> >
> > Erik Weber
> > 22. mai 2014 00:16 skrev "Daan Hoogland" 
> følgende:
> >
> >> I guess you shouldn't use the site to site vpn but just a vpn. I am
> >> not sure how to configure that but you should just create an active
> >> (client side) vpn to the external network. I see no reason why it
> >> should't work. the site to site assumes you have both sides in
> >> cloudstack and thus with rfc1918 networks.
> >>
> >> On Wed, May 21, 2014 at 6:10 PM, Erik Weber 
> wrote:
> >> > Site to site vpn.
> >> >
> >> > I'm not in control of the 50.0.1 network, but the client is.
> >> >
> >> > Basically the use case is that they want to secure the traffic to
> >> > their cloud vms, and are fortunate enough to not have to use rfc1918
> >> > on their network.
> >> >
> >> > I guess we could work around it by terminating the vpn on our
> >> > equipment
> >> and
> >> > access it as a private gateway instead, but I'd prefer to use the
> >> > technology that we so braverly tell our clients about.
> >> >
> >> > Erik
> >> > 21. mai 2014 17:05 skrev "Daan Hoogland" 
> >> følgende:
> >> >
> >> >> Are you creating a site to site vpn or connecting to an external
> >> network?
> >> >>
> >> >> On Wed, May 21, 2014 at 5:02 PM, Daan Hoogland
> >> >>  >> >
> >> >> wrote:
> >> >> > Erik, If it doesn't work it is probably been blocked on purpose
> >> >> > but I don't see why it is. I don't know your use case either and
> >> >> > it seems an unlikely one. But if the 50.0.1 net is out of your
> >> >> > control you maybe should be able to configure this. So I would
> >> >> > say it is a bug/lack of feature. I'll look into the code for the
> place the error is generated.
> >> >> >
> >> >> > in short: file a ticket
> >> >> >
> >> >> > On Wed, May 21, 2014 at 2:34 PM, Erik Weber 
> >> wrote:
> >> >> >> I understand that, but what my client wants is to connect public
> >> >> >> ips instead of rfc1918 on one of the sides.
> >> >> >>
> >> >> >> e.g. one network has 10.0.1.0/24 and ip 1.2.3.4 the other has
> >> >> >> 50.0.1.0/24 and ip 50.0.0.1
> >> >> >>
> >> >> >> but cloudstack currently does not let you do that, because it
> >> >> >> expects
> >> >> cidrs
> >> >> >> to be rfc1918. see log excerpt:
> >> >> >>
> >> >> >> 2014-05-21 12:30:42,326 WARN  [c.c.u.n.NetUtils]
> >> >> >> (API-Job-Executor-7:job-3072 ctx-bf3922b1) cidr 50.0.1.0/24 is
> >> >> >> not
> >> RFC
> >> >> 1918
> >> >> >> compliant
> >> >> >> 2014-05-21 12:30:42,335 ERROR [c.c.a.ApiAsyncJobDispatcher]
> >> >> >> (API-Job-Executor-7:job-3072) Unexpected exception while
> >> >> >> executing
> >> >> >>
> >> org.apache.cloudstack.api.command.user.vpn.CreateVpnCustomerGatewayCmd
> >> >> >> com.cloud.exception.InvalidParameterValueException: The customer
> >> gateway
> >> >> >> guest cidr list 50.0.1.0/24 is invalid guest cidr!
> >> >> >> at
> >> >> >>
> >> >>
> >> com.cloud.network.vpn.Site2SiteVpnManagerImpl.createCustomerGateway(Si
> >> te2SiteVpnManagerImpl.java:176)
> >> >> >>
> >> >> >> I'm wondering if this is a bug/lacking feature, or intended.
> >> >> >> As I initially said I'm not a network guy, so there might be
> >> perfectly
> >> >> good
> >> >> >> reasons this shouldn't be allowed.
> >> >> >>
> >> >> >> But if it's a bug/lacking feature it would be great to know so
> >> >> >> that I
> >> >> could
> >> >> >> file a ticket for it.
> >> >> >>
> >> >> >> --
> >> >> >> Erik Weber
> >> >> >>
> >> >> >>
> >> >> >> On Wed, May 21, 2014 at 2:09 PM, Daan Hoogland <
> >> daan.hoogl...@gmail.com
> >> >> >wrote:
> >> >> >>
> >> >> >>> Erik,
> >> >> >>>
> >> >> >>> The vpn let's you connect to all the computers in the network
> >> >> >>> on the other site on their private adresses. This means that
> >> >> >>> you can give
>

RE: Proxy Console (RealhostIP Retired) Question

[Alex Hitchins]

Hello Mo,

You can see our guide here : 
http://shapeblue.com/cloudstack/how-to-mitigate-openssl-heartbleed-vulnerability-in-apache-cloudstack/




Alex Hitchins | 07788 423 969 | 01892 523 587

-Original Message-
From: Mo [mailto:m...@daoenix.com] 
Sent: 22 May 2014 02:15
To: us...@cloudstack.apache.org; dev
Subject: Proxy Console (RealhostIP Retired) Question

Hello:

I am attempting to find more information (read: step by step) how to correct 
the issue that came to be when realhostip was retired.

The links I saw suggested I setup the following for every IP address in my DNS 
Zone:

192-168-1-1.cloud.domain.tldINA192.168.1.1

I have done that for ALL my IPs. Restarted my named/bind service. Not only am I 
not obtaining an A record with this configuration, but I am also still unable 
to proceed in getting console access as it states it's unable to resolve the 
DNS.

All my other DNS resolves without issue, please note; 192.x is just an IP 
address I tossed in this e-mail for general purposes, I am utilizing public 
subnets.

I have also purchased an SSL certificate went through all of that too, if 
someone could point me in the right direction or perhaps offer ideas
(alternates) that would be fantastic.

Thanks,
Mo

IRC and users@

[sebgoa]

Hi folks,

#cloudstack has been deserted lately on IRC. It would be nice to see more 
people in this channel, helping to answer questions from users.

also the mailing list users@ has lots of questions unanswered, a couple day 
focus on this ML would help clear the backlog.

thanks, 

-Sebastien

Review Request 21805: CLOUDSTACK-6748: Creating an instance with user-data when network doesn't support user-data should error

[Harikrishna Patnala]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21805/
---

Review request for cloudstack, Jayapal Reddy, Murali Reddy, and Shengsheng 
Huang.


Bugs: CLOUDSTACK-6748
https://issues.apache.org/jira/browse/CLOUDSTACK-6748


Repository: cloudstack-git


Description
---

CLOUDSTACK-6748: Creating an instance with user-data when network doesn't 
support user-data should error

When vm is deployed with userdata or ssh key or using password enabled template 
and in the default network that does not support userdata we should error the 
vm creation.


Diffs
-

  
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
 96dafe9 
  server/src/com/cloud/vm/UserVmManagerImpl.java cf04270 

Diff: https://reviews.apache.org/r/21805/diff/


Testing
---


Thanks,

Harikrishna Patnala

[EVENT] Xen User Summit

[sebgoa]

If you use Xen, you might be interested by the Xen User Summit.
Call for Papers is opened until May 31st:

http://events.linuxfoundation.org/events/xen-project-user-summit/program/cfp

-sebastien

[EVENT] CCC Budapest Nov 19-21

[sebgoa]

Hi,

CloudStack Collab is back in Europe on Nov 19-21st in Budapest,

CFP closes June 25th, so get your papers in quick and register

http://events.linuxfoundation.org/events/cloudstack-collaboration-conference-europe

-sebastien

Review Request 21806: Disable conntrackd-stats logging to prevent it from filling up /var

[Joris van Lieshout]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21806/
---

Review request for cloudstack, Abhinandan Prateek, daan Hoogland, Rajesh 
Battala, Rohit Yadav, and Hugo Trippaers.


Repository: cloudstack-git


Description
---

Conntrackd package has a bug where the comment in the default config file 
states that stats logging is disabled by default but the config parameter is 
set to on. The consequence for ACS is that a conntrackd-stats.log file is 
created during the build of the svm. This logfile gets rotated by logrotate 
which has a post action to restart conntrackd. Even if the svm is not a 
redundant router. On vpc routers for instance the stats logging file can grow 
quickly and fill up the /var volume killing the vm.


Diffs
-

  tools/appliance/definitions/systemvm64template/postinstall.sh cc8ead9 
  tools/appliance/definitions/systemvmtemplate/postinstall.sh 23e66dd 

Diff: https://reviews.apache.org/r/21806/diff/


Testing
---

We are running this fix in our production environment for a couple months 
allready.


Thanks,

Joris van Lieshout

Re: Proxy Console (RealhostIP Retired) Question

[Mo]

Alex,

I understood how to upgrade SSL, however; that's not the issue at hand. The
issue is I am looking for a guide to correctly setup a DNS Zone to allow
the console to work. As I mentioned in my first update, I have the
following:

192-168-1-1.cloud.domain.tldINA192.168.1.1 (reverted to
private IP to mask my actual IPs)

I have done that for each of my public facing IP addresses within my DNS
zone for the particular domain in question. However, in doing so, I am not
showing this to be resolving; thus resulting me being in a stand still
unable to continue setting up instances.

Any help would be greatly appreciated.

- mo


On Thu, May 22, 2014 at 6:00 AM, Alex Hitchins wrote:

> Hello Mo,
>
> You can see our guide here :
> http://shapeblue.com/cloudstack/how-to-mitigate-openssl-heartbleed-vulnerability-in-apache-cloudstack/
>
>
>
>
> Alex Hitchins | 07788 423 969 | 01892 523 587
>
> -Original Message-
> From: Mo [mailto:m...@daoenix.com]
> Sent: 22 May 2014 02:15
> To: us...@cloudstack.apache.org; dev
> Subject: Proxy Console (RealhostIP Retired) Question
>
> Hello:
>
> I am attempting to find more information (read: step by step) how to
> correct the issue that came to be when realhostip was retired.
>
> The links I saw suggested I setup the following for every IP address in my
> DNS Zone:
>
> 192-168-1-1.cloud.domain.tldINA192.168.1.1
>
> I have done that for ALL my IPs. Restarted my named/bind service. Not only
> am I not obtaining an A record with this configuration, but I am also still
> unable to proceed in getting console access as it states it's unable to
> resolve the DNS.
>
> All my other DNS resolves without issue, please note; 192.x is just an IP
> address I tossed in this e-mail for general purposes, I am utilizing public
> subnets.
>
> I have also purchased an SSL certificate went through all of that too, if
> someone could point me in the right direction or perhaps offer ideas
> (alternates) that would be fantastic.
>
> Thanks,
> Mo
>
>

Re: Proxy Console (RealhostIP Retired) Question

[Erik Weber]

If the domain names aren't resolving, it would be easier to help you if you
revealed your actual zone data and provided some dig / dns captures.

Do other records for the same domain resolve, e.g. foo.cloud.domain.tld?


Erik Weber


On Thu, May 22, 2014 at 1:46 PM, Mo  wrote:

> Alex,
>
> I understood how to upgrade SSL, however; that's not the issue at hand. The
> issue is I am looking for a guide to correctly setup a DNS Zone to allow
> the console to work. As I mentioned in my first update, I have the
> following:
>
> 192-168-1-1.cloud.domain.tldINA192.168.1.1 (reverted to
> private IP to mask my actual IPs)
>
> I have done that for each of my public facing IP addresses within my DNS
> zone for the particular domain in question. However, in doing so, I am not
> showing this to be resolving; thus resulting me being in a stand still
> unable to continue setting up instances.
>
> Any help would be greatly appreciated.
>
> - mo
>
>
> On Thu, May 22, 2014 at 6:00 AM, Alex Hitchins  >wrote:
>
> > Hello Mo,
> >
> > You can see our guide here :
> >
> http://shapeblue.com/cloudstack/how-to-mitigate-openssl-heartbleed-vulnerability-in-apache-cloudstack/
> >
> >
> >
> >
> > Alex Hitchins | 07788 423 969 | 01892 523 587
> >
> > -Original Message-
> > From: Mo [mailto:m...@daoenix.com]
> > Sent: 22 May 2014 02:15
> > To: us...@cloudstack.apache.org; dev
> > Subject: Proxy Console (RealhostIP Retired) Question
> >
> > Hello:
> >
> > I am attempting to find more information (read: step by step) how to
> > correct the issue that came to be when realhostip was retired.
> >
> > The links I saw suggested I setup the following for every IP address in
> my
> > DNS Zone:
> >
> > 192-168-1-1.cloud.domain.tldINA192.168.1.1
> >
> > I have done that for ALL my IPs. Restarted my named/bind service. Not
> only
> > am I not obtaining an A record with this configuration, but I am also
> still
> > unable to proceed in getting console access as it states it's unable to
> > resolve the DNS.
> >
> > All my other DNS resolves without issue, please note; 192.x is just an IP
> > address I tossed in this e-mail for general purposes, I am utilizing
> public
> > subnets.
> >
> > I have also purchased an SSL certificate went through all of that too, if
> > someone could point me in the right direction or perhaps offer ideas
> > (alternates) that would be fantastic.
> >
> > Thanks,
> > Mo
> >
> >
>

Re: IRC and users@

[Mo]

Agreed! I often find myself in IRC to ask a quick question, days gone by
that was the quickest way. Now, it seems, the mailing list & IRC are both
slightly delayed.

- Mo


On Thu, May 22, 2014 at 7:05 AM, sebgoa  wrote:

> Hi folks,
>
> #cloudstack has been deserted lately on IRC. It would be nice to see more
> people in this channel, helping to answer questions from users.
>
> also the mailing list users@ has lots of questions unanswered, a couple
> day focus on this ML would help clear the backlog.
>
> thanks,
>
> -Sebastien

[ACS4.4-Tests] Tests on ACS 4.4, latest code.

[Wilder Rodrigues]

Hi all,

I have been busy performing some basic tests on ACS 4.4 latest code. All manual 
tests, but still valuable.

So far I did:


· As Admin

o   Created 2 Advanced Zones

§  Summer Zone with Local Storage enabled

§  Spring Zone with Local Storage disabled

o   Created 3 VMs

§  2 in VMs in the Summer Zone

§  1 VM in the Spring Zone

o   Created 3 Networks

§  1 for each VM

o   Firewall and Port forwarding

§  On the 3 networks

o   SSH into all the VMs and also in all System VMs

o   Created 2 accounts: user and admin

· As normal User

o   Created 1 VM

o   Created 1 Network

o   Went through the whole ACL/Ports/SSH stuff

Environment:


· Management Server

o   Debian 7 Wheeze 64bits

§  Running inside Virtual Box

· Hosts

o   2 XenServer 6.2

§  Hosted by a CentOS 32bits

· Second Storage

o   Both NFS

· Primary Storage

o   NFS

§  Had problems setting up this one. Forgot one small detail about the local 
storage Global Settings option.

§  This issue reminded me of the problem: 
https://issues.apache.org/jira/browse/CLOUDSTACK-1053

§  I will assign the issue to my name and fix it.

Cheers,
Wilder

Re: Review Request 21806: Disable conntrackd-stats logging to prevent it from filling up /var

[Marcus Sorensen]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21806/#review43710
---


I thought I had fixed this awhile back, but it was from the other direction. 
Conntrackd no longer restarts on log rotate unless conntrackd was already 
running (6b7f91d7). I suppose this wouldn't be bad to put in as well, so long 
as we know that conntrackd will in fact get started when we want it (redundant 
virtual router). Another issue contributing to it was that we had split up the 
tiny disk into many partitions, leaving only a few hundred MB available and 
stranded across many parts of the file tree, since there are times when we want 
conntrackd we should probably have a system vm template that can handle its 
logfiles.

You need to create a bug report that we can tie this to.

- Marcus Sorensen


On May 22, 2014, 11:42 a.m., Joris van Lieshout wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21806/
> ---
> 
> (Updated May 22, 2014, 11:42 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, daan Hoogland, Rajesh 
> Battala, Rohit Yadav, and Hugo Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Conntrackd package has a bug where the comment in the default config file 
> states that stats logging is disabled by default but the config parameter is 
> set to on. The consequence for ACS is that a conntrackd-stats.log file is 
> created during the build of the svm. This logfile gets rotated by logrotate 
> which has a post action to restart conntrackd. Even if the svm is not a 
> redundant router. On vpc routers for instance the stats logging file can grow 
> quickly and fill up the /var volume killing the vm.
> 
> 
> Diffs
> -
> 
>   tools/appliance/definitions/systemvm64template/postinstall.sh cc8ead9 
>   tools/appliance/definitions/systemvmtemplate/postinstall.sh 23e66dd 
> 
> Diff: https://reviews.apache.org/r/21806/diff/
> 
> 
> Testing
> ---
> 
> We are running this fix in our production environment for a couple months 
> allready.
> 
> 
> Thanks,
> 
> Joris van Lieshout
> 
>

Review Request 21808: xenstore-utils on debian wheezy does not have /usr/sbin/xenstore so these commands file. It does have xenstore-write and xenstore-rm so by adding a - this is fixed easily.

[Joris van Lieshout]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21808/
---

Review request for cloudstack, Chiradeep Vittal, daan Hoogland, and Hugo 
Trippaers.


Repository: cloudstack-git


Description
---

The xenstore-utils package for debian wheezy does not have /usr/sbin/xenstore 
(https://packages.debian.org/wheezy/i386/xenstore-utils/filelist) but it does 
have xenstore-rm and xenstore-write so by adding a - in-between this is fixed 
easily.


Diffs
-

  systemvm/patches/debian/xe/xe-update-guest-attrs 30a4498 

Diff: https://reviews.apache.org/r/21808/diff/


Testing
---


Thanks,

Joris van Lieshout

Re: Network IDS in VPC

[Marcus]

I've always viewed the permissions to be additive, if a domain admin has
the ability to set up network sniffing on the VPC I'd imagine the root
admin should be able to as well. Although perhaps not. Even though they
have unfettered access to destroy all vms, networks, zones, the root admin
may not have access to the VM hosts, and may not already have access to the
VMs themselves if the root passwords are not known. This would introduce a
vector whereby a root admin without host access could spin up a network and
vm for a tenant and see their traffic where they'd normally only be able to
if they had access to the root passwords of the tenant's instances or the
hosts. I imagine the overwhelming majority of root admins have host or
network access, but not all. In the end I'm not sure such an untrusted user
should be a root admin, as there are many other attack vectors (such as
downloading a tenant's volume). Perhaps I'm missing the point.

It would certainly be easier to implement from an orchestration perspective
on the router. The collection could happen on the router, but the storage
of the packet data probably not, and for the analysis it seems kind of
dangerous to run more user-accessible tools on a system that is supposed to
be locked down.  Especially since it would likely be a web service of some
sort running on the public interface. IDS software setup and maintenance is
pretty involved, I'm not sure the CS community would be interested in
maintaining that. We generally promote the virtual router as an appliance,
and so I think we'd need to maintain that software install on the router.
These (along with the migration issues) are the reasons why I was leaning
toward a 'sniffer net', where the users could have what they'd normally
have in a datacenter with a 'port mirror', and they can decide how to
collect and analyze the data.


On Thu, May 22, 2014 at 2:34 AM, Daan Hoogland wrote:

> Marcus, you mention a permission issue that triggers the though:
> should a root admin be allowed? I think not. This brings up extra
> requirements on the IAM, does it?
>
> I would implement the functionality on the router.
>
> On Thu, May 22, 2014 at 6:42 AM, Marcus  wrote:
> > I really like the lower overhead of just port mirroring from one of the
> > router's interfaces to an instance interface host-side, but I really
> > dislike the affinity it creates between the router and the listener, and
> > all of the complications it creates for host maintenance and migrations.
> It
> > may also require that whomever creates a network or vms on a network with
> > this permission be a domain admin, since it has the ability to see
> > everything on the wire for the whole VPC.
> >
> >
> > On Wed, May 21, 2014 at 4:25 PM, Marcus  wrote:
> >
> >> Hi guys,
> >>Not sure if this has been discussed before, but we are getting
> feature
> >> requests for an IDS or packet-sniffing/monitoring capability. I have a
> >> prototyped idea of how to do this (manual config), but would like some
> >> input.
> >>
> >> We create a network offering or network capability/detail that is
> >> specifically a 'sniffer net'. This would be relatively simple, and just
> do
> >> two things:
> >>
> >> 1) when network is added to VPC, spin up a simple daemon on the VPC
> router
> >> that does traffic mirroring (netsniff-ng or daemonlogger are debian
> >> packages) from the public interface to the 'sniffer net' interface.
> >>
> >> 2) disables mac learning on the bridges created for the sniffer net, so
> >> that an IDS system can come up in this net and see all of the mirrored
> >> traffic. It wouldn't handle making the IDS appliance, that would be up
> to
> >> the customer, it would simply create a network that enables traffic
> >> monitoring for the VPC.
> >>
> >> I think we'd prefer any VMs brought up in this network to live on the
> same
> >> host as the router for performance reasons, but that's probably not an
> >> immediate requirement. I dislike the idea of trying to run an actual
> >> capture saved to the VPC router, or an IDS software on the VPC router
> that
> >> would need to be updated.
> >>
> >> We could also run traffic mirroring from the VPC router's interface
> >> directly to another VM's interface, host side (daemonlogger -i vpcintf
> -o
> >> idsintf), but it would need to be on the same host.
> >>
> >>
> >>
> >>
>
>
>
> --
> Daan
>

Re: Network IDS in VPC

[Erik Weber]

What prevents root from revealing and using the domain admin api / secret
Key?

Erik
22. mai 2014 15:54 skrev "Marcus"  følgende:

> I've always viewed the permissions to be additive, if a domain admin has
> the ability to set up network sniffing on the VPC I'd imagine the root
> admin should be able to as well. Although perhaps not. Even though they
> have unfettered access to destroy all vms, networks, zones, the root admin
> may not have access to the VM hosts, and may not already have access to the
> VMs themselves if the root passwords are not known. This would introduce a
> vector whereby a root admin without host access could spin up a network and
> vm for a tenant and see their traffic where they'd normally only be able to
> if they had access to the root passwords of the tenant's instances or the
> hosts. I imagine the overwhelming majority of root admins have host or
> network access, but not all. In the end I'm not sure such an untrusted user
> should be a root admin, as there are many other attack vectors (such as
> downloading a tenant's volume). Perhaps I'm missing the point.
>
> It would certainly be easier to implement from an orchestration perspective
> on the router. The collection could happen on the router, but the storage
> of the packet data probably not, and for the analysis it seems kind of
> dangerous to run more user-accessible tools on a system that is supposed to
> be locked down.  Especially since it would likely be a web service of some
> sort running on the public interface. IDS software setup and maintenance is
> pretty involved, I'm not sure the CS community would be interested in
> maintaining that. We generally promote the virtual router as an appliance,
> and so I think we'd need to maintain that software install on the router.
> These (along with the migration issues) are the reasons why I was leaning
> toward a 'sniffer net', where the users could have what they'd normally
> have in a datacenter with a 'port mirror', and they can decide how to
> collect and analyze the data.
>
>
> On Thu, May 22, 2014 at 2:34 AM, Daan Hoogland  >wrote:
>
> > Marcus, you mention a permission issue that triggers the though:
> > should a root admin be allowed? I think not. This brings up extra
> > requirements on the IAM, does it?
> >
> > I would implement the functionality on the router.
> >
> > On Thu, May 22, 2014 at 6:42 AM, Marcus  wrote:
> > > I really like the lower overhead of just port mirroring from one of the
> > > router's interfaces to an instance interface host-side, but I really
> > > dislike the affinity it creates between the router and the listener,
> and
> > > all of the complications it creates for host maintenance and
> migrations.
> > It
> > > may also require that whomever creates a network or vms on a network
> with
> > > this permission be a domain admin, since it has the ability to see
> > > everything on the wire for the whole VPC.
> > >
> > >
> > > On Wed, May 21, 2014 at 4:25 PM, Marcus  wrote:
> > >
> > >> Hi guys,
> > >>Not sure if this has been discussed before, but we are getting
> > feature
> > >> requests for an IDS or packet-sniffing/monitoring capability. I have a
> > >> prototyped idea of how to do this (manual config), but would like some
> > >> input.
> > >>
> > >> We create a network offering or network capability/detail that is
> > >> specifically a 'sniffer net'. This would be relatively simple, and
> just
> > do
> > >> two things:
> > >>
> > >> 1) when network is added to VPC, spin up a simple daemon on the VPC
> > router
> > >> that does traffic mirroring (netsniff-ng or daemonlogger are debian
> > >> packages) from the public interface to the 'sniffer net' interface.
> > >>
> > >> 2) disables mac learning on the bridges created for the sniffer net,
> so
> > >> that an IDS system can come up in this net and see all of the mirrored
> > >> traffic. It wouldn't handle making the IDS appliance, that would be up
> > to
> > >> the customer, it would simply create a network that enables traffic
> > >> monitoring for the VPC.
> > >>
> > >> I think we'd prefer any VMs brought up in this network to live on the
> > same
> > >> host as the router for performance reasons, but that's probably not an
> > >> immediate requirement. I dislike the idea of trying to run an actual
> > >> capture saved to the VPC router, or an IDS software on the VPC router
> > that
> > >> would need to be updated.
> > >>
> > >> We could also run traffic mirroring from the VPC router's interface
> > >> directly to another VM's interface, host side (daemonlogger -i vpcintf
> > -o
> > >> idsintf), but it would need to be on the same host.
> > >>
> > >>
> > >>
> > >>
> >
> >
> >
> > --
> > Daan
> >
>

Re: Review Request 21806: CLOUDSTACK-6751: Disable conntrackd-stats logging to prevent it from filling up /var

[Joris van Lieshout]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21806/
---

(Updated May 22, 2014, 2:35 p.m.)


Review request for cloudstack, Abhinandan Prateek, daan Hoogland, Rajesh 
Battala, Rohit Yadav, and Hugo Trippaers.


Summary (updated)
-

CLOUDSTACK-6751: Disable conntrackd-stats logging to prevent it from filling up 
/var


Bugs: CLOUDSTACK-6751
https://issues.apache.org/jira/browse/CLOUDSTACK-6751


Repository: cloudstack-git


Description
---

Conntrackd package has a bug where the comment in the default config file 
states that stats logging is disabled by default but the config parameter is 
set to on. The consequence for ACS is that a conntrackd-stats.log file is 
created during the build of the svm. This logfile gets rotated by logrotate 
which has a post action to restart conntrackd. Even if the svm is not a 
redundant router. On vpc routers for instance the stats logging file can grow 
quickly and fill up the /var volume killing the vm.


Diffs
-

  tools/appliance/definitions/systemvm64template/postinstall.sh cc8ead9 
  tools/appliance/definitions/systemvmtemplate/postinstall.sh 23e66dd 

Diff: https://reviews.apache.org/r/21806/diff/


Testing
---

We are running this fix in our production environment for a couple months 
allready.


Thanks,

Joris van Lieshout

Re: Review Request 21806: Disable conntrackd-stats logging to prevent it from filling up /var

[Joris van Lieshout]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21806/
---

(Updated May 22, 2014, 2:34 p.m.)


Review request for cloudstack, Abhinandan Prateek, daan Hoogland, Rajesh 
Battala, Rohit Yadav, and Hugo Trippaers.


Changes
---

create jira bug CLOUDSTACK-6751


Bugs: CLOUDSTACK-6751
https://issues.apache.org/jira/browse/CLOUDSTACK-6751


Repository: cloudstack-git


Description
---

Conntrackd package has a bug where the comment in the default config file 
states that stats logging is disabled by default but the config parameter is 
set to on. The consequence for ACS is that a conntrackd-stats.log file is 
created during the build of the svm. This logfile gets rotated by logrotate 
which has a post action to restart conntrackd. Even if the svm is not a 
redundant router. On vpc routers for instance the stats logging file can grow 
quickly and fill up the /var volume killing the vm.


Diffs
-

  tools/appliance/definitions/systemvm64template/postinstall.sh cc8ead9 
  tools/appliance/definitions/systemvmtemplate/postinstall.sh 23e66dd 

Diff: https://reviews.apache.org/r/21806/diff/


Testing
---

We are running this fix in our production environment for a couple months 
allready.


Thanks,

Joris van Lieshout

Re: Review Request 21806: Disable conntrackd-stats logging to prevent it from filling up /var

[Joris van Lieshout]

- Joris


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21806/#review43710
---


On May 22, 2014, 2:34 p.m., Joris van Lieshout wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21806/
> ---
> 
> (Updated May 22, 2014, 2:34 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, daan Hoogland, Rajesh 
> Battala, Rohit Yadav, and Hugo Trippaers.
> 
> 
> Bugs: CLOUDSTACK-6751
> https://issues.apache.org/jira/browse/CLOUDSTACK-6751
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Conntrackd package has a bug where the comment in the default config file 
> states that stats logging is disabled by default but the config parameter is 
> set to on. The consequence for ACS is that a conntrackd-stats.log file is 
> created during the build of the svm. This logfile gets rotated by logrotate 
> which has a post action to restart conntrackd. Even if the svm is not a 
> redundant router. On vpc routers for instance the stats logging file can grow 
> quickly and fill up the /var volume killing the vm.
> 
> 
> Diffs
> -
> 
>   tools/appliance/definitions/systemvm64template/postinstall.sh cc8ead9 
>   tools/appliance/definitions/systemvmtemplate/postinstall.sh 23e66dd 
> 
> Diff: https://reviews.apache.org/r/21806/diff/
> 
> 
> Testing
> ---
> 
> We are running this fix in our production environment for a couple months 
> allready.
> 
> 
> Thanks,
> 
> Joris van Lieshout
> 
>

Re: Network IDS in VPC

[Marcus]

Yet another vector


On Thu, May 22, 2014 at 8:07 AM, Erik Weber  wrote:

> What prevents root from revealing and using the domain admin api / secret
> Key?
>
> Erik
> 22. mai 2014 15:54 skrev "Marcus"  følgende:
>
> > I've always viewed the permissions to be additive, if a domain admin has
> > the ability to set up network sniffing on the VPC I'd imagine the root
> > admin should be able to as well. Although perhaps not. Even though they
> > have unfettered access to destroy all vms, networks, zones, the root
> admin
> > may not have access to the VM hosts, and may not already have access to
> the
> > VMs themselves if the root passwords are not known. This would introduce
> a
> > vector whereby a root admin without host access could spin up a network
> and
> > vm for a tenant and see their traffic where they'd normally only be able
> to
> > if they had access to the root passwords of the tenant's instances or the
> > hosts. I imagine the overwhelming majority of root admins have host or
> > network access, but not all. In the end I'm not sure such an untrusted
> user
> > should be a root admin, as there are many other attack vectors (such as
> > downloading a tenant's volume). Perhaps I'm missing the point.
> >
> > It would certainly be easier to implement from an orchestration
> perspective
> > on the router. The collection could happen on the router, but the storage
> > of the packet data probably not, and for the analysis it seems kind of
> > dangerous to run more user-accessible tools on a system that is supposed
> to
> > be locked down.  Especially since it would likely be a web service of
> some
> > sort running on the public interface. IDS software setup and maintenance
> is
> > pretty involved, I'm not sure the CS community would be interested in
> > maintaining that. We generally promote the virtual router as an
> appliance,
> > and so I think we'd need to maintain that software install on the router.
> > These (along with the migration issues) are the reasons why I was leaning
> > toward a 'sniffer net', where the users could have what they'd normally
> > have in a datacenter with a 'port mirror', and they can decide how to
> > collect and analyze the data.
> >
> >
> > On Thu, May 22, 2014 at 2:34 AM, Daan Hoogland  > >wrote:
> >
> > > Marcus, you mention a permission issue that triggers the though:
> > > should a root admin be allowed? I think not. This brings up extra
> > > requirements on the IAM, does it?
> > >
> > > I would implement the functionality on the router.
> > >
> > > On Thu, May 22, 2014 at 6:42 AM, Marcus  wrote:
> > > > I really like the lower overhead of just port mirroring from one of
> the
> > > > router's interfaces to an instance interface host-side, but I really
> > > > dislike the affinity it creates between the router and the listener,
> > and
> > > > all of the complications it creates for host maintenance and
> > migrations.
> > > It
> > > > may also require that whomever creates a network or vms on a network
> > with
> > > > this permission be a domain admin, since it has the ability to see
> > > > everything on the wire for the whole VPC.
> > > >
> > > >
> > > > On Wed, May 21, 2014 at 4:25 PM, Marcus  wrote:
> > > >
> > > >> Hi guys,
> > > >>Not sure if this has been discussed before, but we are getting
> > > feature
> > > >> requests for an IDS or packet-sniffing/monitoring capability. I
> have a
> > > >> prototyped idea of how to do this (manual config), but would like
> some
> > > >> input.
> > > >>
> > > >> We create a network offering or network capability/detail that is
> > > >> specifically a 'sniffer net'. This would be relatively simple, and
> > just
> > > do
> > > >> two things:
> > > >>
> > > >> 1) when network is added to VPC, spin up a simple daemon on the VPC
> > > router
> > > >> that does traffic mirroring (netsniff-ng or daemonlogger are debian
> > > >> packages) from the public interface to the 'sniffer net' interface.
> > > >>
> > > >> 2) disables mac learning on the bridges created for the sniffer net,
> > so
> > > >> that an IDS system can come up in this net and see all of the
> mirrored
> > > >> traffic. It wouldn't handle making the IDS appliance, that would be
> up
> > > to
> > > >> the customer, it would simply create a network that enables traffic
> > > >> monitoring for the VPC.
> > > >>
> > > >> I think we'd prefer any VMs brought up in this network to live on
> the
> > > same
> > > >> host as the router for performance reasons, but that's probably not
> an
> > > >> immediate requirement. I dislike the idea of trying to run an actual
> > > >> capture saved to the VPC router, or an IDS software on the VPC
> router
> > > that
> > > >> would need to be updated.
> > > >>
> > > >> We could also run traffic mirroring from the VPC router's interface
> > > >> directly to another VM's interface, host side (daemonlogger -i
> vpcintf
> > > -o
> > > >> idsintf), but it would need to be on the same host.
> > > >>
> > > >>
> > > >>
> > > >>
> > 

[ACS44] RN

[sebgoa]

Folks, 

Pierre-Luc has been working on the release notes for 4.4, it's here:

http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/latest/

We need to make sure all features are listed.

We need to test the upgrade instructions.

Please chime in, either as a reply to this or by sending a pr to the docs.

thanks,

-Sebastien

Re: Review Request 21806: CLOUDSTACK-6751: Disable conntrackd-stats logging to prevent it from filling up /var

[ASF Subversion and Git Services]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21806/#review43720
---


Commit 2c810d73e24411e767296b62e59d2acbb77b7df5 in cloudstack's branch 
refs/heads/master from Marcus Sorensen
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2c810d7 ]

CLOUDSTACK-6751 - Disable stats logging for conntrackd upon systemvm creation

Submitted-by: Joris van Lieshout 


- ASF Subversion and Git Services


On May 22, 2014, 2:35 p.m., Joris van Lieshout wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21806/
> ---
> 
> (Updated May 22, 2014, 2:35 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, daan Hoogland, Rajesh 
> Battala, Rohit Yadav, and Hugo Trippaers.
> 
> 
> Bugs: CLOUDSTACK-6751
> https://issues.apache.org/jira/browse/CLOUDSTACK-6751
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Conntrackd package has a bug where the comment in the default config file 
> states that stats logging is disabled by default but the config parameter is 
> set to on. The consequence for ACS is that a conntrackd-stats.log file is 
> created during the build of the svm. This logfile gets rotated by logrotate 
> which has a post action to restart conntrackd. Even if the svm is not a 
> redundant router. On vpc routers for instance the stats logging file can grow 
> quickly and fill up the /var volume killing the vm.
> 
> 
> Diffs
> -
> 
>   tools/appliance/definitions/systemvm64template/postinstall.sh cc8ead9 
>   tools/appliance/definitions/systemvmtemplate/postinstall.sh 23e66dd 
> 
> Diff: https://reviews.apache.org/r/21806/diff/
> 
> 
> Testing
> ---
> 
> We are running this fix in our production environment for a couple months 
> allready.
> 
> 
> Thanks,
> 
> Joris van Lieshout
> 
>

Re: Review Request 21806: CLOUDSTACK-6751: Disable conntrackd-stats logging to prevent it from filling up /var

[Marcus Sorensen]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21806/#review43721
---

Ship it!


Ship It!

- Marcus Sorensen


On May 22, 2014, 2:35 p.m., Joris van Lieshout wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21806/
> ---
> 
> (Updated May 22, 2014, 2:35 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, daan Hoogland, Rajesh 
> Battala, Rohit Yadav, and Hugo Trippaers.
> 
> 
> Bugs: CLOUDSTACK-6751
> https://issues.apache.org/jira/browse/CLOUDSTACK-6751
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Conntrackd package has a bug where the comment in the default config file 
> states that stats logging is disabled by default but the config parameter is 
> set to on. The consequence for ACS is that a conntrackd-stats.log file is 
> created during the build of the svm. This logfile gets rotated by logrotate 
> which has a post action to restart conntrackd. Even if the svm is not a 
> redundant router. On vpc routers for instance the stats logging file can grow 
> quickly and fill up the /var volume killing the vm.
> 
> 
> Diffs
> -
> 
>   tools/appliance/definitions/systemvm64template/postinstall.sh cc8ead9 
>   tools/appliance/definitions/systemvmtemplate/postinstall.sh 23e66dd 
> 
> Diff: https://reviews.apache.org/r/21806/diff/
> 
> 
> Testing
> ---
> 
> We are running this fix in our production environment for a couple months 
> allready.
> 
> 
> Thanks,
> 
> Joris van Lieshout
> 
>

[ACS44] 4.4 API doc

[sebgoa]

Hey Paul,

Since you generated the 4.3 api doc, would you be willing to generate them 
again for 4.4 ?

There is also a bug:
https://issues.apache.org/jira/browse/CLOUDSTACK-4912

that you might be able to check at the same time

-sebastien

Re: Review Request 21806: Disable conntrackd-stats logging to prevent it from filling up /var

[Joris van Lieshout]

> On May 22, 2014, 1:27 p.m., Marcus Sorensen wrote:
> > I thought I had fixed this awhile back, but it was from the other 
> > direction. Conntrackd no longer restarts on log rotate unless conntrackd 
> > was already running (6b7f91d7). I suppose this wouldn't be bad to put in as 
> > well, so long as we know that conntrackd will in fact get started when we 
> > want it (redundant virtual router). Another issue contributing to it was 
> > that we had split up the tiny disk into many partitions, leaving only a few 
> > hundred MB available and stranded across many parts of the file tree, since 
> > there are times when we want conntrackd we should probably have a system vm 
> > template that can handle its logfiles.
> > 
> > You need to create a bug report that we can tie this to.

Thank you for your response. I see your commit on the logrotate script. 
Although that alone would fix it I agree with you that fixing it both ways is 
more reliable. :)
I will create a but report as requested.

Regarding your comment on disk space we had issues with that as wel. Not so 
much for /var but in fact /usr (review 21696 CLOUDSTACK-6716). In my opinion 
having a lean and mean svm is fine. A better solution, when it comes to 
logging, would be to send it to the control ip with syslog. We're working on a 
patch that gives you the opportunity to do without losing local logging. I'll 
include you in the review request one i've finished it.


- Joris


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21806/#review43710
---


On May 22, 2014, 2:34 p.m., Joris van Lieshout wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21806/
> ---
> 
> (Updated May 22, 2014, 2:34 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, daan Hoogland, Rajesh 
> Battala, Rohit Yadav, and Hugo Trippaers.
> 
> 
> Bugs: CLOUDSTACK-6751
> https://issues.apache.org/jira/browse/CLOUDSTACK-6751
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Conntrackd package has a bug where the comment in the default config file 
> states that stats logging is disabled by default but the config parameter is 
> set to on. The consequence for ACS is that a conntrackd-stats.log file is 
> created during the build of the svm. This logfile gets rotated by logrotate 
> which has a post action to restart conntrackd. Even if the svm is not a 
> redundant router. On vpc routers for instance the stats logging file can grow 
> quickly and fill up the /var volume killing the vm.
> 
> 
> Diffs
> -
> 
>   tools/appliance/definitions/systemvm64template/postinstall.sh cc8ead9 
>   tools/appliance/definitions/systemvmtemplate/postinstall.sh 23e66dd 
> 
> Diff: https://reviews.apache.org/r/21806/diff/
> 
> 
> Testing
> ---
> 
> We are running this fix in our production environment for a couple months 
> allready.
> 
> 
> Thanks,
> 
> Joris van Lieshout
> 
>

RE: [ACS44] 4.4 API doc

[Alex Hitchins]

Hi Sebastien, if Paul can't I'll pick this up from him. Now I'm on Ubuntu
this works!


Alex Hitchins | 07788 423 969 | 01892 523 587

-Original Message-
From: sebgoa [mailto:run...@gmail.com] 
Sent: 22 May 2014 16:21
To: dev@cloudstack.apache.org
Cc: Paul Angus
Subject: [ACS44] 4.4 API doc

Hey Paul,

Since you generated the 4.3 api doc, would you be willing to generate them
again for 4.4 ?

There is also a bug:
https://issues.apache.org/jira/browse/CLOUDSTACK-4912

that you might be able to check at the same time

-sebastien

Re: [ACS44] RN

[Nguyen Anh Tu]

I didn't see the autoscaling feature, Sebastien.

--Tuna


On Thu, May 22, 2014 at 10:16 PM, sebgoa  wrote:

> Folks,
>
> Pierre-Luc has been working on the release notes for 4.4, it's here:
>
>
> http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/latest/
>
> We need to make sure all features are listed.
>
> We need to test the upgrade instructions.
>
> Please chime in, either as a reply to this or by sending a pr to the docs.
>
> thanks,
>
> -Sebastien

Review Request 21817: [UI] New Zones tab for Templates and ISOs

[Gabor Apati-Nagy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21817/
---

Review request for cloudstack and Jessica Wang.


Bugs: CLOUDSTACK-6565
https://issues.apache.org/jira/browse/CLOUDSTACK-6565


Repository: cloudstack-git


Description
---

New diff with improved ui layout


Diffs
-

  ui/css/cloudstack3.css cb9fa35 
  ui/dictionary.jsp 9cc030a 
  ui/scripts/templates.js 67cc2fb 

Diff: https://reviews.apache.org/r/21817/diff/


Testing
---


Thanks,

Gabor Apati-Nagy

Re: [ACS5.0] IAM feature postponed from 4.4 to 5.0?

[Min Chen]

Added API issues we found through IAM feature in the wiki page created by
Demetrius: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+changes

Thanks
-min

On 5/14/14 9:34 AM, "Min Chen"  wrote:

>Thanks Daan. Yes, I saw that there is another thread about putting an API
>request for 5.0 api. Once we are done with this disabling, we will put the
>issues we have found with current API in that wiki page to take into
>consideration when we design the new API.
>
>-min
>
>On 5/14/14 12:12 AM, "Daan Hoogland"  wrote:
>
>>Min,
>>
>>I think everybody knows I am all for less features per release. I
>>don't think you are making a bad call, per se. I do think we should
>>consider if we can come up with a total picture of what 5.x would
>>require af the api, though. Can you add to the discussion what it is
>>that is keeping you from implementing. And what requirements you have
>>for the 5.0 api so we can start devising the architectural guidelines
>>for the new api. more and more calls for a 5.0 are coming up lately so
>>let's move forward. (changing title)
>>
>>On Wed, May 14, 2014 at 1:53 AM, Min Chen  wrote:
>>> Hi All,
>>>
>>> In the past several weeks, QA has done some testing on IAM feature and
>>>found
>>> several backward-compatibility issues. Even though Prachi and I have
>>>tried
>>> our best to fix bugs to maintain backward compatibility, we realized
>>>that in
>>> order to support true IAM model documented in our FS
>>> 
>>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Identi
>>>t
>>>y+and+Access+Management+%28IAM%29+Plugin,
>>> we will have to make several API changes that will require us to
>>>increment
>>> CloudStack major version.
>>> Therefore we think that IAM feature is not ready for ACS 4.4 release,
>>>and we
>>> would like to propose to disable it in 4.4 branch and re-enable it
>>>later
>>> when community decides to go for 5.x.
>>>
>>> Thanks
>>> -min
>>
>>
>>
>>-- 
>>Daan
>

RE: Updating ACS 4.4 features list on release page?

[Demetrius Tsitrelis]

Thanks!

-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] 
Sent: Wednesday, May 21, 2014 3:29 PM
To: dev
Subject: Re: Updating ACS 4.4 features list on release page?

you can find those (it's not just one that is broken) at
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12323265

On Wed, May 21, 2014 at 11:34 PM, Demetrius Tsitrelis 
 wrote:
> In the "Features" section of the CloudStack 4.4 Release (Draft) page 
> (https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=39623192) 
> is a filter for a previous version of features 
> (https://issues.apache.org/jira/sr/jira.issueviews:searchrequest-xml/12323168/SearchRequest-12323168.xml?tempMax=1000)
>  which no longer works.
>
>
>
> What is the value of that filter for the 4.4 feature list?



--
Daan

awsapi POM war plugin attachClasses property

[Jeff Hair]

Hi,

I have a plugin that has a dependency on the awsapi, but it only produces a
WAR file. In the past I've patched true into
the awsapi POM, but now I'd like to do this without affecting any mainline
POM file. The plugin uses cloudstack as its parent, and it's unclear on how
to define the value in my child POM, since awsapi is a "sibling" POM. Is
this even possible?

Thanks

Re: Proxy Console (RealhostIP Retired) Question

[Amogh Vasekar]

Hi,
Does the DNS resolve from your local machine? Is the DNS publicly
resolvable, or is it local to your intranet?

Thanks,
Amogh

On 5/21/14 6:14 PM, "Mo"  wrote:

>but I am also still
>unable to proceed in getting console access as it states it's unable to
>resolve the DNS.
>
>All my other DNS resolves without issue, please note

[ACS4.4] Cherry pick request

[Amogh Vasekar]

Hi Daan,

Can you please cherry pick 7bbad0491f7ec087f693814caadbe6d648d2edf2
It resolves CLOUDSTACK-6671

Thanks,
Amogh

RE: [ACS44] 4.4 API doc

[Paul Angus]

I can do - I'll sort it out in the next couple of days.
I believe the bug was cleared when I did the last set.

Regards

Paul Angus
Cloud Architect
S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
paul.an...@shapeblue.com

-Original Message-
From: sebgoa [mailto:run...@gmail.com]
Sent: 22 May 2014 16:21
To: dev@cloudstack.apache.org
Cc: Paul Angus
Subject: [ACS44] 4.4 API doc

Hey Paul,

Since you generated the 4.3 api doc, would you be willing to generate them 
again for 4.4 ?

There is also a bug:
https://issues.apache.org/jira/browse/CLOUDSTACK-4912

that you might be able to check at the same time

-sebastien


Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: [ACS4.4] Cherry pick request

[Daan Hoogland]

On Thu, May 22, 2014 at 7:42 PM, Amogh Vasekar  wrote:
> 7bbad0491f7ec087f693814caadbe6d648d2edf2


is in

-- 
Daan

[DOCS] Git Flow

[Will Stevens]

Hey All,
In the the README.rst files in the documentation, it refers to this page if
you want to contribute: http://cloudstack.apache.org/developers.html

I am not sure those instructions are actually up-to-date or valid for
contributing to the documentation.

I originally tried to use this process (
https://help.github.com/articles/syncing-a-fork) to keep my documentation
fork up-to-date with the upstream/master, but after the first pull request
the commits have to be cherry-picked because the pull requests will always
take everything I have committed in my fork rather than the changes since
the last pull request.  This got annoying quickly.

When contributing to the actual CloudStack code I used a squashed patch
approach which worked very well.  I have written up that flow as well as a
similar flow for working with Github pull requests.

I would like you to review what I have written.  If you guys approve of the
flow, I would like to add it to the README.rst files in the different
documentation repositories to make it easier for people to contribute to
the documentation.  I know I found it really hard to figure out how to
contribute to the documentation initially.  We want to lower the bar a bit
on this so more people feel comfortable helping with the documentation.

Let me know what you think.

Cheers,

Will



Contributing to the documentation
=

Initial setup of your local fork


First, fork the original documentation repository to your Github account.
 Then on your computer, do the following...

.. code:: bash

$ git clone `url of your forked repo`
$ cd `git repo directory`
$ git remote add upstream `url of the original repo`
$ git checkout master
$ git fetch upstream
$ git merge upstream/master


Making changes
--

You will be making changes on a new `dev` branch which is only in your
local git repository.

.. code:: bash

$ git checkout -b dev
(make your changes)
$ git add .
$ git commit -a -m "commit message for your changes"

.. note::
The `-b` specifies that you want to create a new branch called `dev`.  You
only specify `-b` the first time because you are creating a new branch.
 Once the `dev` branch exists, you can later switch to it with `git
checkout dev`.


Merging `upstream/master` into your `dev` branch


.. code:: bash

$ git checkout master
$ git fetch upstream
$ git merge upstream/master
$ git checkout dev
$ git pull . master

.. note:: Now your `dev` branch is up-to-date with everything from
`upstream/master`.


Making a squashed patch for `upstream/master`
-

.. note:: Make sure you have merged `upstream/master` into your `dev`
branch before you do this.

.. code:: bash

$ git checkout master
$ git checkout -b squashed
$ git merge --squash dev
$ git commit -a -m "commit message for this squashed patch"
$ git format-patch master
$ git checkout master
$ git branch -D squashed

Upload the resulting patch file to a committer and move it out of your
working tree.

Continue working on the `dev` branch.  When your changes are committed to
the `upstream/master`, they will end up in your `master` branch when you
re-sync your local `master` with the `upstream/master`.  The next time you
create a squashed patch between the `dev` branch and `master`, it will only
include the changes that are not already in the `upstream/master` branch.


Making a squashed pull request for `upstream/master`


.. note:: Make sure you have merged `upstream/master` into your `dev`
branch before you do this.

.. code:: bash
$ git checkout master
$ git checkout -b squashed
$ git merge --squash dev
$ git commit -a -m "commit message for this squashed pull request"
$ git push origin master
$ git push origin squashed

Create a pull request on the `squashed` branch in your forked git repo on
github to contribute it back to `upstream/master`.

Continue working on the `dev` branch.  When your changes are committed to
the `upstream/master`, they will end up in your `master` branch when you
re-sync your local `master` with the `upstream/master`.  The next time you
create a squashed pull request between the `dev` branch and `master`, it
will only include the changes that are not already in the `upstream/master`
branch.

Once the `squashed` branch is committed into the `upstream/master` branch,
your local `squashed` branch and the `origin/squashed` branch are not
needed anymore (until you want to do the process again).  You can delete
them with the following...

.. code:: bash
$ git checkout master
$ git branch -D squashed
$ git push origin :squashed

Re: [ACS44] RN

[Amogh Vasekar]

http://bit.ly/1jZ7M3g is not mentioned.

Thanks,
Amogh

On 5/22/14 8:49 AM, "Nguyen Anh Tu"  wrote:

>I didn't see the autoscaling feature, Sebastien.
>
>--Tuna
>
>
>On Thu, May 22, 2014 at 10:16 PM, sebgoa  wrote:
>
>> Folks,
>>
>> Pierre-Luc has been working on the release notes for 4.4, it's here:
>>
>>
>> 
>>http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/la
>>test/
>>
>> We need to make sure all features are listed.
>>
>> We need to test the upgrade instructions.
>>
>> Please chime in, either as a reply to this or by sending a pr to the
>>docs.
>>
>> thanks,
>>
>> -Sebastien

Re: IRC and users@

[ilya musayev]

After we canceled IRC weekly meetings, folks stopped using it.

On 5/22/14, 4:57 AM, Mo wrote:

Agreed! I often find myself in IRC to ask a quick question, days gone by
that was the quickest way. Now, it seems, the mailing list & IRC are both
slightly delayed.

- Mo


On Thu, May 22, 2014 at 7:05 AM, sebgoa  wrote:


Hi folks,

#cloudstack has been deserted lately on IRC. It would be nice to see more
people in this channel, helping to answer questions from users.

also the mailing list users@ has lots of questions unanswered, a couple
day focus on this ML would help clear the backlog.

thanks,

-Sebastien

[ACS4.4] Cherry-pick 0d243ec7f2e1a0e3508d385f7b793b103c56ca07

[Min Chen]

Hi Daan,

Would you please cherry pick the following commit from 4.4-forward branch to 
4.4 branch?

Commit: 0d243ec7f2e1a0e3508d385f7b793b103c56ca07
CLOUDSTACK-6745:DomainAdmin is not able to deploy Vm for users in his 
domain/subdomain.

Thanks
-min

Re: [ACS44] RN

[Mike Tutkowski]

Is the web site updated nightly with the most recent info in Git? Just
curious when the changes I put into Git for the docs will be visible on
this site.

Thanks!


On Thu, May 22, 2014 at 3:23 PM, Amogh Vasekar wrote:

> http://bit.ly/1jZ7M3g is not mentioned.
>
> Thanks,
> Amogh
>
> On 5/22/14 8:49 AM, "Nguyen Anh Tu"  wrote:
>
> >I didn't see the autoscaling feature, Sebastien.
> >
> >--Tuna
> >
> >
> >On Thu, May 22, 2014 at 10:16 PM, sebgoa  wrote:
> >
> >> Folks,
> >>
> >> Pierre-Luc has been working on the release notes for 4.4, it's here:
> >>
> >>
> >>
> >>
> http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/la
> >>test/
> >>
> >> We need to make sure all features are listed.
> >>
> >> We need to test the upgrade instructions.
> >>
> >> Please chime in, either as a reply to this or by sending a pr to the
> >>docs.
> >>
> >> thanks,
> >>
> >> -Sebastien
>
>


-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*™*

Re: VPC Site to Site VPN CIDR RFC1918

[Chiradeep Vittal]

Seems reasonable to relax this constraint.

From: Erik Weber mailto:terbol...@gmail.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Thursday, May 22, 2014 at 1:40 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: Re: VPC Site to Site VPN CIDR RFC1918

We have no problem getting s2s to connect if the 'other end' from cs point
of view is within rfc1918.
Our problem is purely related to the limitation of only allowing rfc1918
networks on the other end.

Erik Weber


On Thu, May 22, 2014 at 10:21 AM, Daan Hoogland 
mailto:daan.hoogl...@gmail.com>>wrote:

I ran a test with a colleague this week connecting two cs vpcs. this works.

On Thu, May 22, 2014 at 6:05 AM, Sanjeev Neelarapu
mailto:sanjeev.neelar...@citrix.com>> wrote:
> In site-to-site vpn both sides need not to be under cloudstack control.
Only one site can be under cs control.
>
> -Original Message-
> From: Erik Weber [mailto:terbol...@gmail.com]
> Sent: Thursday, May 22, 2014 4:23 AM
> To: dev
> Subject: Re: VPC Site to Site VPN CIDR RFC1918
>
> The documentation says something else, excerpt:
> " The difference from Remote VPN is that Site-to-site VPNs connects
entire networks to each other, for example, connecting a branch office
network to a company headquarters network. In a site-to-site VPN, hosts do
not have VPN client software; they send and receive normal TCP/IP traffic
through a VPN gateway.".
>
> Assuming that both sides is under cloudstack control is just odd and
makes no sense.
>
> I'll file a ticket whenever I find the time, but still appreciate input
:-)
>
> Erik Weber
> 22. mai 2014 00:16 skrev "Daan Hoogland" 
> mailto:daan.hoogl...@gmail.com>>
følgende:
>
>> I guess you shouldn't use the site to site vpn but just a vpn. I am
>> not sure how to configure that but you should just create an active
>> (client side) vpn to the external network. I see no reason why it
>> should't work. the site to site assumes you have both sides in
>> cloudstack and thus with rfc1918 networks.
>>
>> On Wed, May 21, 2014 at 6:10 PM, Erik Weber 
>> mailto:terbol...@gmail.com>>
wrote:
>> > Site to site vpn.
>> >
>> > I'm not in control of the 50.0.1 network, but the client is.
>> >
>> > Basically the use case is that they want to secure the traffic to
>> > their cloud vms, and are fortunate enough to not have to use rfc1918
>> > on their network.
>> >
>> > I guess we could work around it by terminating the vpn on our
>> > equipment
>> and
>> > access it as a private gateway instead, but I'd prefer to use the
>> > technology that we so braverly tell our clients about.
>> >
>> > Erik
>> > 21. mai 2014 17:05 skrev "Daan Hoogland" 
>> > mailto:daan.hoogl...@gmail.com>>
>> følgende:
>> >
>> >> Are you creating a site to site vpn or connecting to an external
>> network?
>> >>
>> >> On Wed, May 21, 2014 at 5:02 PM, Daan Hoogland
>> >> mailto:daan.hoogl...@gmail.com>
>> >
>> >> wrote:
>> >> > Erik, If it doesn't work it is probably been blocked on purpose
>> >> > but I don't see why it is. I don't know your use case either and
>> >> > it seems an unlikely one. But if the 50.0.1 net is out of your
>> >> > control you maybe should be able to configure this. So I would
>> >> > say it is a bug/lack of feature. I'll look into the code for the
place the error is generated.
>> >> >
>> >> > in short: file a ticket
>> >> >
>> >> > On Wed, May 21, 2014 at 2:34 PM, Erik Weber 
>> >> > mailto:terbol...@gmail.com>>
>> wrote:
>> >> >> I understand that, but what my client wants is to connect public
>> >> >> ips instead of rfc1918 on one of the sides.
>> >> >>
>> >> >> e.g. one network has 10.0.1.0/24 and ip 1.2.3.4 the other has
>> >> >> 50.0.1.0/24 and ip 50.0.0.1
>> >> >>
>> >> >> but cloudstack currently does not let you do that, because it
>> >> >> expects
>> >> cidrs
>> >> >> to be rfc1918. see log excerpt:
>> >> >>
>> >> >> 2014-05-21 12:30:42,326 WARN  [c.c.u.n.NetUtils]
>> >> >> (API-Job-Executor-7:job-3072 ctx-bf3922b1) cidr 50.0.1.0/24 is
>> >> >> not
>> RFC
>> >> 1918
>> >> >> compliant
>> >> >> 2014-05-21 12:30:42,335 ERROR [c.c.a.ApiAsyncJobDispatcher]
>> >> >> (API-Job-Executor-7:job-3072) Unexpected exception while
>> >> >> executing
>> >> >>
>> org.apache.cloudstack.api.command.user.vpn.CreateVpnCustomerGatewayCmd
>> >> >> com.cloud.exception.InvalidParameterValueException: The customer
>> gateway
>> >> >> guest cidr list 50.0.1.0/24 is invalid guest cidr!
>> >> >> at
>> >> >>
>> >>
>> com.cloud.network.vpn.Site2SiteVpnManagerImpl.createCustomerGateway(Si
>> te2SiteVpnManagerImpl.java:176)
>> >> >>
>> >> >> I'm wondering if this is a bug/lacking feature, or intended.
>> >> >> As I initially said I'm not a network guy, so there might be
>> perfectly
>> >> good
>> >> >> reasons this shouldn't be allowed.
>> >> >>
>> >> >> But if it's a bug/lacking feature it would be great to know so
>> >> >> that I
>> >> could
>> >> >> file a

Re: VPC Site to Site VPN CIDR RFC1918

[Erik Weber]

Filed ticket https://issues.apache.org/jira/browse/CLOUDSTACK-6747 for it
:-)


-- 
Erik Weber


On Fri, May 23, 2014 at 12:24 AM, Chiradeep Vittal <
chiradeep.vit...@citrix.com> wrote:

> Seems reasonable to relax this constraint.
>
> From: Erik Weber mailto:terbol...@gmail.com>>
> Reply-To: "dev@cloudstack.apache.org" <
> dev@cloudstack.apache.org>
> Date: Thursday, May 22, 2014 at 1:40 AM
> To: "dev@cloudstack.apache.org" <
> dev@cloudstack.apache.org>
> Subject: Re: VPC Site to Site VPN CIDR RFC1918
>
> We have no problem getting s2s to connect if the 'other end' from cs point
> of view is within rfc1918.
> Our problem is purely related to the limitation of only allowing rfc1918
> networks on the other end.
>
> Erik Weber
>
>
> On Thu, May 22, 2014 at 10:21 AM, Daan Hoogland  >wrote:
>
> I ran a test with a colleague this week connecting two cs vpcs. this works.
>
> On Thu, May 22, 2014 at 6:05 AM, Sanjeev Neelarapu
> mailto:sanjeev.neelar...@citrix.com>> wrote:
> > In site-to-site vpn both sides need not to be under cloudstack control.
> Only one site can be under cs control.
> >
> > -Original Message-
> > From: Erik Weber [mailto:terbol...@gmail.com]
> > Sent: Thursday, May 22, 2014 4:23 AM
> > To: dev
> > Subject: Re: VPC Site to Site VPN CIDR RFC1918
> >
> > The documentation says something else, excerpt:
> > " The difference from Remote VPN is that Site-to-site VPNs connects
> entire networks to each other, for example, connecting a branch office
> network to a company headquarters network. In a site-to-site VPN, hosts do
> not have VPN client software; they send and receive normal TCP/IP traffic
> through a VPN gateway.".
> >
> > Assuming that both sides is under cloudstack control is just odd and
> makes no sense.
> >
> > I'll file a ticket whenever I find the time, but still appreciate input
> :-)
> >
> > Erik Weber
> > 22. mai 2014 00:16 skrev "Daan Hoogland"  >
> følgende:
> >
> >> I guess you shouldn't use the site to site vpn but just a vpn. I am
> >> not sure how to configure that but you should just create an active
> >> (client side) vpn to the external network. I see no reason why it
> >> should't work. the site to site assumes you have both sides in
> >> cloudstack and thus with rfc1918 networks.
> >>
> >> On Wed, May 21, 2014 at 6:10 PM, Erik Weber  >
> wrote:
> >> > Site to site vpn.
> >> >
> >> > I'm not in control of the 50.0.1 network, but the client is.
> >> >
> >> > Basically the use case is that they want to secure the traffic to
> >> > their cloud vms, and are fortunate enough to not have to use rfc1918
> >> > on their network.
> >> >
> >> > I guess we could work around it by terminating the vpn on our
> >> > equipment
> >> and
> >> > access it as a private gateway instead, but I'd prefer to use the
> >> > technology that we so braverly tell our clients about.
> >> >
> >> > Erik
> >> > 21. mai 2014 17:05 skrev "Daan Hoogland"  >
> >> følgende:
> >> >
> >> >> Are you creating a site to site vpn or connecting to an external
> >> network?
> >> >>
> >> >> On Wed, May 21, 2014 at 5:02 PM, Daan Hoogland
> >> >> mailto:daan.hoogl...@gmail.com>
> >> >
> >> >> wrote:
> >> >> > Erik, If it doesn't work it is probably been blocked on purpose
> >> >> > but I don't see why it is. I don't know your use case either and
> >> >> > it seems an unlikely one. But if the 50.0.1 net is out of your
> >> >> > control you maybe should be able to configure this. So I would
> >> >> > say it is a bug/lack of feature. I'll look into the code for the
> place the error is generated.
> >> >> >
> >> >> > in short: file a ticket
> >> >> >
> >> >> > On Wed, May 21, 2014 at 2:34 PM, Erik Weber  >
> >> wrote:
> >> >> >> I understand that, but what my client wants is to connect public
> >> >> >> ips instead of rfc1918 on one of the sides.
> >> >> >>
> >> >> >> e.g. one network has 10.0.1.0/24 and ip 1.2.3.4 the other has
> >> >> >> 50.0.1.0/24 and ip 50.0.0.1
> >> >> >>
> >> >> >> but cloudstack currently does not let you do that, because it
> >> >> >> expects
> >> >> cidrs
> >> >> >> to be rfc1918. see log excerpt:
> >> >> >>
> >> >> >> 2014-05-21 12:30:42,326 WARN  [c.c.u.n.NetUtils]
> >> >> >> (API-Job-Executor-7:job-3072 ctx-bf3922b1) cidr 50.0.1.0/24 is
> >> >> >> not
> >> RFC
> >> >> 1918
> >> >> >> compliant
> >> >> >> 2014-05-21 12:30:42,335 ERROR [c.c.a.ApiAsyncJobDispatcher]
> >> >> >> (API-Job-Executor-7:job-3072) Unexpected exception while
> >> >> >> executing
> >> >> >>
> >> org.apache.cloudstack.api.command.user.vpn.CreateVpnCustomerGatewayCmd
> >> >> >> com.cloud.exception.InvalidParameterValueException: The customer
> >> gateway
> >> >> >> guest cidr list 50.0.1.0/24 is invalid guest cidr!
> >> >> >> at
> >>

[ACS4.4] Cherry-pick da5ad74d5f4388c4aa1df2f2e5f9053bfb70d83d

[Min Chen]

Hi Daan,

Would you please cherry-pick the following commit from 4.4-forward to 
4.4?

Commit: da5ad74d5f4388c4aa1df2f2e5f9053bfb70d83d
CLOUDSTACK-6752: IAM command class separation caused ApiDoc warning of
duplicated cmd class for the same api name.

Thanks
-min

Question about Marvin's zone deployment feature

[Yoshikazu Nojima]

Hi all,

Does Marvin support creating storage network IP range while deploying a zone?
I couldn't find the place to configure it.

Thanks,
Noji

[ACS4.4] Cherry pick request : 12e552b06dfac5f19737f79aa0a8424b01b3197e

[Yoshikazu Nojima]

Hi Daan,

Could you cherry-pick the commit
12e552b06dfac5f19737f79aa0a8424b01b3197e to 4.4?

This commit fix the bug that make systemvm build stall.

Regards,
Noji

Build failed in Jenkins: build-master #846

[jenkins]

See 

Changes:

[min.chen] Disable IAM feature from 4.4 release.

--
[...truncated 1381 lines...]
[INFO] Copying 29 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-server ---
[INFO] Compiling 90 source files to 

[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ cloud-server ---
[INFO] Surefire report directory: 


---
 T E S T S
---
Running com.cloud.event.EventControlsUnitTest
log4j:WARN No appenders could be found for logger 
(com.cloud.event.EventControlsUnitTest).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
info.
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.584 sec
Running com.cloud.keystore.KeystoreTest
org.apache.cloudstack.api.response.UserVmResponse/null/{"id":"3","securitygroup":[],"nic":[],"tags":[],"affinitygroup":[]}
org.apache.cloudstack.api.response.AlertResponse/null/{"id":"100","description":"Hello"}
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.143 sec
Running com.cloud.alert.AlertControlsUnitTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec
Running com.cloud.capacity.CapacityManagerTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.135 sec
Running com.cloud.servlet.StaticResourceServletTest
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.143 sec
Running com.cloud.servlet.ConsoleProxyServletTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running com.cloud.resourcelimit.ResourceLimitManagerImplTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running com.cloud.network.firewall.FirewallManagerTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.002 sec
Running com.cloud.network.ExternalLoadBalancerDeviceManagerImplTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.543 sec
Running com.cloud.network.UpdatePhysicalNetworkTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.144 sec
Running com.cloud.network.CreatePrivateNetworkTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 sec
Running com.cloud.network.NetworkModelTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec
Running com.cloud.network.security.SecurityGroupManagerImplTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.752 sec
Running com.cloud.network.security.SecurityGroupQueueTest
Total jobs dequeued = 10, num queued=1001 queue current size=991
Num Vms= 50 Queue size = 50
Num Vms= 2 Queue size = 2 time=161 ms
Num Vms= 5000 Queue size = 5000 time=1122 ms
Num Vms= 1 Queue size = 1 time=1 ms
Num Vms= 100 Queue size = 100 time=444 ms
Num Vms= 1 Queue size = 1 time=266 ms
Total jobs dequeued = 10, num queued=1010 queue current size=1000
Total jobs dequeued = 1, num queued=1001 queue current size=1000
Total jobs dequeued = 10, num queued=1000 queue current size=990
Total jobs dequeued = 10, num queued=10 queue current size=0
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.073 sec
Running com.cloud.network.vpc.VpcManagerImplTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec
Running com.cloud.network.DedicateGuestVlanRangesTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.025 sec
Running com.cloud.network.lb.AssignLoadBalancerTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.071 sec
Running com.cloud.network.dao.NetworkDaoTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
Running com.cloud.vm.DeploymentPlanningManagerImplTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.831 sec
Running com.cloud.vm.snapshot.VMSnapshotManagerTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.125 sec
Running com.cloud.vm.UserVmManagerTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.188 sec
Running com.cloud.configuration.ValidateIpRangeTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec
Running com.cloud.configuration.ConfigurationManagerTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.053 sec
Running com.cloud.server.ConfigurationServerImplTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec
Running com.cloud.template.TemplateManagerImplTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec
Running com.cloud.vpc.Site2SiteVpnTest
Tests r

Build failed in Jenkins: build-master #847

[jenkins]

See 

Changes:

[min.chen] CLOUDSTACK-6742: listVolumes - As regularuser , able to list Vms and

[min.chen] CLOUDSTACK-6745:DomainAdmin is not able to deploy Vm for users in his

[min.chen] CLOUDSTACK-6752: IAM command class separation caused ApiDoc warning 
of

--
[...truncated 1381 lines...]
[INFO] Copying 29 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-server ---
[INFO] Compiling 90 source files to 

[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ cloud-server ---
[INFO] Surefire report directory: 


---
 T E S T S
---
Running com.cloud.event.EventControlsUnitTest
log4j:WARN No appenders could be found for logger 
(com.cloud.event.EventControlsUnitTest).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
info.
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.579 sec
Running com.cloud.keystore.KeystoreTest
org.apache.cloudstack.api.response.UserVmResponse/null/{"id":"3","securitygroup":[],"nic":[],"tags":[],"affinitygroup":[]}
org.apache.cloudstack.api.response.AlertResponse/null/{"id":"100","description":"Hello"}
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec
Running com.cloud.alert.AlertControlsUnitTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec
Running com.cloud.capacity.CapacityManagerTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.131 sec
Running com.cloud.servlet.StaticResourceServletTest
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.131 sec
Running com.cloud.servlet.ConsoleProxyServletTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running com.cloud.resourcelimit.ResourceLimitManagerImplTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running com.cloud.network.firewall.FirewallManagerTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.001 sec
Running com.cloud.network.ExternalLoadBalancerDeviceManagerImplTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.498 sec
Running com.cloud.network.UpdatePhysicalNetworkTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.139 sec
Running com.cloud.network.CreatePrivateNetworkTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec
Running com.cloud.network.NetworkModelTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec
Running com.cloud.network.security.SecurityGroupManagerImplTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.759 sec
Running com.cloud.network.security.SecurityGroupQueueTest
Total jobs dequeued = 10, num queued=1000 queue current size=990
Num Vms= 50 Queue size = 50
Num Vms= 2 Queue size = 2 time=199 ms
Num Vms= 5000 Queue size = 5000 time=1485 ms
Num Vms= 1 Queue size = 1 time=0 ms
Num Vms= 100 Queue size = 100 time=233 ms
Num Vms= 1 Queue size = 1 time=169 ms
Total jobs dequeued = 10, num queued=1010 queue current size=1000
Total jobs dequeued = 1, num queued=1001 queue current size=1000
Total jobs dequeued = 10, num queued=1000 queue current size=990
Total jobs dequeued = 10, num queued=10 queue current size=0
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.156 sec
Running com.cloud.network.vpc.VpcManagerImplTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec
Running com.cloud.network.DedicateGuestVlanRangesTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 sec
Running com.cloud.network.lb.AssignLoadBalancerTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.081 sec
Running com.cloud.network.dao.NetworkDaoTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running com.cloud.vm.DeploymentPlanningManagerImplTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.668 sec
Running com.cloud.vm.snapshot.VMSnapshotManagerTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.144 sec
Running com.cloud.vm.UserVmManagerTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.185 sec
Running com.cloud.configuration.ValidateIpRangeTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec
Running com.cloud.configuration.ConfigurationManagerTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.056 sec
Running com.cloud.server.ConfigurationServerImplTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0

VM's using custom offerings wont let us use the migrate host from UI (CS 4.3)!!!

[Amin Samir]

Hello,

 
We have cloud stack 4.3 over centos our hypervisors are xen server 6.2 SP1 with 
latest updates, the VM's that are created from custom offering don't let us use 
the migrate host icon from the UI, however you can move them from the xen 
center console.

 
Has anyone faced this issue before? 

 
Kind Regards

 

Jenkins build is back to normal : build-master #848

[jenkins]

See 

Re: Review Request 21628: CLOUDSTACK-6282: Automated network API Tests and uploaded patch

[Vinay Varma]

> On May 21, 2014, 6:30 a.m., Santhosh Edukulla wrote:
> > test/integration/component/test_escalations_networks.py, lines 434-435
> > 
> >
> > May be get the count as it is for before vpc list, need not be zero? 
> > Especially if multiple tests run in parallel, there could be a possibility 
> > we may get the count varying.

Here we are checking for Zero VPCs in that account and also kept asserts as 
such. This we have followed for all the automated tests. So we shall leave it 
as such for now


> On May 21, 2014, 6:30 a.m., Santhosh Edukulla wrote:
> > test/integration/component/test_escalations_networks.py, line 640
> > 
> >
> > Move this to above line after vpc creation.

Here we are creating VPC and then Network under VPC, so first we need to clean 
Network and then only VPC, if we are adding cleaning of VPC first and network 
later then during cleanup it was giving error saying "network exists in the vpc"


> On May 21, 2014, 6:30 a.m., Santhosh Edukulla wrote:
> > test/integration/component/test_escalations_networks.py, line 949
> > 
> >
> > Not clear with this check. Why cant we just append to cleanup?

We wanted this check as we need not add all the VM's created as we are deleting 
one VM in test itself.


> On May 21, 2014, 6:30 a.m., Santhosh Edukulla wrote:
> > test/integration/component/test_escalations_networks.py, line 1108
> > 
> >
> > Can this be moved after create?

Here we are creating VPC and then Network under VPC, so first we need to clean 
Network and then only VPC, if we are adding cleaning of VPC first and network 
later then during cleanup it was giving error saying "network exists in the vpc"


> On May 21, 2014, 6:30 a.m., Santhosh Edukulla wrote:
> > test/integration/component/test_escalations_networks.py, line 2091
> > 
> >
> > Do we require some time to check whether vpc started or failed?

We donot need any time, since it is async call framework is handling


> On May 21, 2014, 6:30 a.m., Santhosh Edukulla wrote:
> > test/integration/component/test_escalations_networks.py, line 2471
> > 
> >
> > For delete we require some time to wait?

We donot need any time, since it is async call framework is handling


- Vinay


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21628/#review43594
---


On May 19, 2014, 11:36 a.m., Monis Majeed wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21628/
> ---
> 
> (Updated May 19, 2014, 11:36 a.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-6282
> https://issues.apache.org/jira/browse/CLOUDSTACK-6282
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Automated network API Tests and uploaded patch
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_escalations_networks.py PRE-CREATION 
>   tools/marvin/marvin/config/test_data.py 5577ae1 
>   tools/marvin/marvin/lib/base.py 0a6405d 
> 
> Diff: https://reviews.apache.org/r/21628/diff/
> 
> 
> Testing
> ---
> 
> Executed all the Network tests and uploaded the results file
> 
> 
> File Attachments
> 
> 
> results.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/05/19/0574d454-3aae-4cf4-9c45-af8fc678b487__results.txt
> 
> 
> Thanks,
> 
> Monis Majeed
> 
>

Re: [ACS44] RN

[Sebastien Goasguen]

Within one hour of your push

-Sebastien

> On 22 May 2014, at 23:56, Mike Tutkowski  wrote:
> 
> Is the web site updated nightly with the most recent info in Git? Just
> curious when the changes I put into Git for the docs will be visible on
> this site.
> 
> Thanks!
> 
> 
> On Thu, May 22, 2014 at 3:23 PM, Amogh Vasekar 
> wrote:
> 
>> http://bit.ly/1jZ7M3g is not mentioned.
>> 
>> Thanks,
>> Amogh
>> 
>>> On 5/22/14 8:49 AM, "Nguyen Anh Tu"  wrote:
>>> 
>>> I didn't see the autoscaling feature, Sebastien.
>>> 
>>> --Tuna
>>> 
>>> 
 On Thu, May 22, 2014 at 10:16 PM, sebgoa  wrote:
 
 Folks,
 
 Pierre-Luc has been working on the release notes for 4.4, it's here:
>> http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/la
 test/
 
 We need to make sure all features are listed.
 
 We need to test the upgrade instructions.
 
 Please chime in, either as a reply to this or by sending a pr to the
 docs.
 
 thanks,
 
 -Sebastien
> 
> 
> -- 
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *™*