Re: VPC Firewall Rule Limitations

[Marcus]

It's possible to do, but there's some work involved. We'd have to modify
the table that stores the rules, then pass that in the ACL commands that
change the iptables rules.

It goes against the idea of tiers, though. A tier is supposed to represent
a given function, your mail server and web server should probably be in
separate tiers, or your mail sever should also be a web server, and your
web server also a mail server, if they are to be in the same tier.

On Wed, May 13, 2015 at 10:47 AM, Christopher Falk <
christopher.f...@reliablenetworks.com> wrote:

> Hi all,
>
> I've run into some limitations in the firewall rule capabilities in the
> VPC side that I'm hoping could be addressed in a future release. For VPC
> networks, when configuring ACL for tiers you can only manage tier-wide
> destinations for inbound or sources for outbound.
>
> What would it take to build in more granularity to these options?
>
> For example, in a tier with one web server and one mail server, I have to
> allow Inbound, from 0.0.0.0/0, on TCP 25, 80, 443 etc. This opens these
> ports to *all* instances in the tier, assuming they don't have their own
> OS-level firewalls running. Now of course only instances with Static NAT
> configured will pass traffic but that still permits port 25 to the web
> server and 80/443 to the FTP even if I don't want that.
>
> Typical firewall rule sets allow source/destination to be specified, so
> that we could open port 25 to the FTP server IP only, and port 80/443 to
> the web server only.
>
> The current rules are confusing for a new user with networking background.
> You have to understand that when selecting "Ingress" your specified CIDR is
> a *source* but when specifying "Egress" it is the destination CIDR.
>
> Thanks for the consideration,
>
> Christopher Falk
> Director, Technical Operations
> www.reliablenetworks.com
>

Preparing for 4.6

[Sebastien Goasguen]

Folks,

As we prepare to try a new process for 4.6 release it would be nice to start 
paying attention to master.

- Good commit messages
- Reference to a JIRA bug
- Squashing commits ( cc/ wilder :))

While you can apply patches directly, good practice is to apply the patch to a 
branch and then merge that branch into master. 

Before we start enforcing some of these things more strongly, please keep it in 
mind.

thanks,

-sebastien

Re: ACS 4.5.1 KVM live migration problem

[Andrei Mikhailovsky]

Hi Andrija, Marcus, 

Thanks for your comments and suggestions. I've checked the cloud.nics table 

mysql> select instance_id,isolation_uri,broadcast_uri from nics where 
instance_id=564 or instance_id=664 or instance_id=; 
+-+---+---+ 
| instance_id | isolation_uri | broadcast_uri | 
+-+---+---+ 
| 564 | vlan://96 | vlan://96 | 
| 664 | NULL | NULL | 
|  | vlan://1127 | vlan://1127 | 
+-+---+---+ 


>From my tests, instance_ids 564 and  are migrating correctly, but instance 
>664 is not ans showing the npe similar to the one i've given. 


Is this what is causing the migration issues? If so, should i change all 
isolation_uri and broadcast_uri to the corresponding network vlan ids? 

Thanks 

Andrei 

- Original Message -

From: "Andrija Panic"  
To: dev@cloudstack.apache.org 
Sent: Thursday, 14 May, 2015 4:00:07 PM 
Subject: Re: Fwd: ACS 4.5.1 KVM live migration problem 

That would probably be a bug that I had...but we updated main VLAN table 
with change URI or something... Marcus saved me that time :) 
Andrei, please provide more info and the info Marcus said, I will try to 
compare my values with yours if of any help. 

On 14 May 2015 at 16:56, Marcus  wrote: 

> So, I vaguely remember an issue introduced a little over a year ago where 
> the broadcast domain value of the nic was changed from a URI to just a vlan 
> ID, which worked for vlans but broke vxlan and some other things. If I 
> remember correctly, there would be a small set of installs during this 
> period that wouldn't have created their nics with the correct broadcast 
> domain value. I don't remember which versions were doing this but I do know 
> there's a JIRA ticket and a paper trail on how people were fixing it. The 
> code that broke the URI was backed out. VMs created with the bad code would 
> not be compatible with the new or the old versions of code. 
> 
> I was under the impression at the time that there was some SQL provided to 
> update the values during an upgrade, perhaps that never made it in, or 
> somehow got skipped during your upgrade process. At any rate, since there 
> is a null pointer on broadcast domain type, you may check your 
> nics/networks the MySQL db and verify that the broadcast/isolation types 
> are URI format and not just a number. Or try to find the bug I'm referring 
> to from around April last year. 
> On May 14, 2015 5:04 AM, "Andrei Mikhailovsky"  wrote: 
> 
> > Hi guys, 
> > 
> > Forwarding the message to the dev list as ive not had much reply in the 
> > users list. 
> > 
> > In summary. after upgrading from ASC4.4.2 ro 4.5.1 i started having 
> > migration issues with a lot of vms. some vms are successfully migrating 
> and 
> > others are not . 
> > 
> > The logs are shown below 
> > 
> > could someone help me to get to the bottom of this problem? 
> > 
> > Thanks 
> > 
> > Andrei 
> > 
> > 
> > 
> > - Forwarded Message - 
> > From: "Andrei Mikhailovsky"  
> > To: us...@cloudstack.apache.org 
> > Sent: Wednesday, 13 May, 2015 10:44:29 AM 
> > Subject: Re: ACS 4.5.1 KVM live migration problem 
> > 
> > Hi Rohit, 
> > 
> > forgot to answer you on the cloud.vlan table. 
> > 
> > That particular vm has a network with vlan id 1151 as shown when i look 
> at 
> > the network details in the acs gui. However, this vlan is not shown in 
> the 
> > cloud.vlan table. From what I can see the cloud.vlan table shows only the 
> > public and management network vlan interfaces and does not show the guest 
> > network vlans. 
> > 
> > In terms of the public network vlan which is used for routing traffic to 
> > the internet from this particular vm, it is: 
> > 
> > 
> > mysql> select * from vlan where id=12; 
> > 
> > 
> ++--+-+---+-+---++++-+-+--+---+-+-+
>  
> > | id | uuid | vlan_id | vlan_gateway | vlan_netmask | description | 
> > vlan_type | data_center_id | network_id | physical_network_id | 
> ip6_gateway 
> > | ip6_cidr | ip6_range | removed | created | 
> > 
> > 
> ++--+-+---+-+---++++-+-+--+---+-+-+
>  
> > | 12 | d13ea4b3-2087-4376-9d0a-f54efe2a55af | vlan://2030 | 178.XXX.XXX.1 
> > | 255.255.255.128 | 178.XXX.XXX.2-178.XXX.XXX.119 | VirtualNetwork | 1 | 
> > 200 | 200 | NULL | NULL | NULL | NULL | NULL | 
> > 
> > 
> ++--+-+---+-+---++++-+-+--+

Re: ACS 4.5.1 KVM live migration problem

[Andrija Panic]

Andrei,

 select instance_id,isolation_uri,broadcast_uri from nics where instance_id
in (select id from vm_instance where state='Running' and name not like
'r-%' and name not like 'v-%' and name not like 's-%') order by instance_id;

This gives me every niC, that does not belong to router or SSVm CPVMI
always have vlan values - since this is all Guest NICs - they must have
vlan ID...
NULL values are only present when VM is deleted/stoped in my case...

Can you check your VM 664 - what is so specific about it ?
all NICs (in my understanding, if this is advacned zone) must have some
vlan, can not be NULL or untagged ?

On 15 May 2015 at 12:58, Andrei Mikhailovsky  wrote:

>
>
> Hi Andrija, Marcus,
>
> Thanks for your comments and suggestions. I've checked the cloud.nics table
>
> mysql> select instance_id,isolation_uri,broadcast_uri from nics where
> instance_id=564 or instance_id=664 or instance_id=;
> +-+---+---+
> | instance_id | isolation_uri | broadcast_uri |
> +-+---+---+
> | 564 | vlan://96 | vlan://96 |
> | 664 | NULL | NULL |
> |  | vlan://1127 | vlan://1127 |
> +-+---+---+
>
>
> From my tests, instance_ids 564 and  are migrating correctly, but
> instance 664 is not ans showing the npe similar to the one i've given.
>
>
> Is this what is causing the migration issues? If so, should i change all
> isolation_uri and broadcast_uri to the corresponding network vlan ids?
>
> Thanks
>
> Andrei
>
> - Original Message -
>
> From: "Andrija Panic" 
> To: dev@cloudstack.apache.org
> Sent: Thursday, 14 May, 2015 4:00:07 PM
> Subject: Re: Fwd: ACS 4.5.1 KVM live migration problem
>
> That would probably be a bug that I had...but we updated main VLAN table
> with change URI or something... Marcus saved me that time :)
> Andrei, please provide more info and the info Marcus said, I will try to
> compare my values with yours if of any help.
>
> On 14 May 2015 at 16:56, Marcus  wrote:
>
> > So, I vaguely remember an issue introduced a little over a year ago where
> > the broadcast domain value of the nic was changed from a URI to just a
> vlan
> > ID, which worked for vlans but broke vxlan and some other things. If I
> > remember correctly, there would be a small set of installs during this
> > period that wouldn't have created their nics with the correct broadcast
> > domain value. I don't remember which versions were doing this but I do
> know
> > there's a JIRA ticket and a paper trail on how people were fixing it. The
> > code that broke the URI was backed out. VMs created with the bad code
> would
> > not be compatible with the new or the old versions of code.
> >
> > I was under the impression at the time that there was some SQL provided
> to
> > update the values during an upgrade, perhaps that never made it in, or
> > somehow got skipped during your upgrade process. At any rate, since there
> > is a null pointer on broadcast domain type, you may check your
> > nics/networks the MySQL db and verify that the broadcast/isolation types
> > are URI format and not just a number. Or try to find the bug I'm
> referring
> > to from around April last year.
> > On May 14, 2015 5:04 AM, "Andrei Mikhailovsky" 
> wrote:
> >
> > > Hi guys,
> > >
> > > Forwarding the message to the dev list as ive not had much reply in the
> > > users list.
> > >
> > > In summary. after upgrading from ASC4.4.2 ro 4.5.1 i started having
> > > migration issues with a lot of vms. some vms are successfully migrating
> > and
> > > others are not .
> > >
> > > The logs are shown below
> > >
> > > could someone help me to get to the bottom of this problem?
> > >
> > > Thanks
> > >
> > > Andrei
> > >
> > >
> > >
> > > - Forwarded Message -
> > > From: "Andrei Mikhailovsky" 
> > > To: us...@cloudstack.apache.org
> > > Sent: Wednesday, 13 May, 2015 10:44:29 AM
> > > Subject: Re: ACS 4.5.1 KVM live migration problem
> > >
> > > Hi Rohit,
> > >
> > > forgot to answer you on the cloud.vlan table.
> > >
> > > That particular vm has a network with vlan id 1151 as shown when i look
> > at
> > > the network details in the acs gui. However, this vlan is not shown in
> > the
> > > cloud.vlan table. From what I can see the cloud.vlan table shows only
> the
> > > public and management network vlan interfaces and does not show the
> guest
> > > network vlans.
> > >
> > > In terms of the public network vlan which is used for routing traffic
> to
> > > the internet from this particular vm, it is:
> > >
> > >
> > > mysql> select * from vlan where id=12;
> > >
> > >
> >
> ++--+-+---+-+---++++-+-+--+---+-+-+
> > > | id | uuid | vlan_id | vlan_gateway | vlan_netmask | description |
> > > vlan_type | data_center_id | netw

[GitHub] cloudstack-cloudmonkey pull request: In the specific case of a "cr...

[ntavares]

GitHub user ntavares opened a pull request:

https://github.com/apache/cloudstack-cloudmonkey/pull/4

In the specific case of a "create networkoffering" with no services, …

…the parameter 'supportedservices' gets stripped off because it's empty. 
However, the API requires it as mandatatory - and yes, the UI allows you to 
create a n.o. with no services.

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

$ git pull https://github.com/ntavares/cloudstack-cloudmonkey master

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

https://github.com/apache/cloudstack-cloudmonkey/pull/4.patch

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

This closes #4


commit 7a5052331a6ed40496995dcd43a82da2b86920d3
Author: Nuno Tavares 
Date:   2015-05-15T10:27:27Z

In the specific case of a "create networkoffering" with no services, the 
parameter 'supportedservices' gets stripped off because it's empty. However, 
the API requires it as mandatatory - and yes, the UI allows you to create a 
n.o. with no services.




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

Re: ACS 4.5.1 KVM live migration problem

[Andrei Mikhailovsky]

Andrija, 

I've ran the command and it showed me a bunch of running vms with NULLs. I 
would roughly say about 20% of my total running vms do have NULL under the 
isolation and broadcast URIs. 

All of these vms are working perfectly well (in terms of network connectivity) 
and there is nothing special about them. They all have at least one guest NIC. 

Andrei 
- Original Message -

From: "Andrija Panic"  
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Sent: Friday, 15 May, 2015 12:34:24 PM 
Subject: Re: ACS 4.5.1 KVM live migration problem 

Andrei, 

select instance_id,isolation_uri,broadcast_uri from nics where instance_id 
in (select id from vm_instance where state='Running' and name not like 
'r-%' and name not like 'v-%' and name not like 's-%') order by instance_id; 

This gives me every niC, that does not belong to router or SSVm CPVMI 
always have vlan values - since this is all Guest NICs - they must have 
vlan ID... 
NULL values are only present when VM is deleted/stoped in my case... 

Can you check your VM 664 - what is so specific about it ? 
all NICs (in my understanding, if this is advacned zone) must have some 
vlan, can not be NULL or untagged ? 

On 15 May 2015 at 12:58, Andrei Mikhailovsky  wrote: 

> 
> 
> Hi Andrija, Marcus, 
> 
> Thanks for your comments and suggestions. I've checked the cloud.nics table 
> 
> mysql> select instance_id,isolation_uri,broadcast_uri from nics where 
> instance_id=564 or instance_id=664 or instance_id=; 
> +-+---+---+ 
> | instance_id | isolation_uri | broadcast_uri | 
> +-+---+---+ 
> | 564 | vlan://96 | vlan://96 | 
> | 664 | NULL | NULL | 
> |  | vlan://1127 | vlan://1127 | 
> +-+---+---+ 
> 
> 
> From my tests, instance_ids 564 and  are migrating correctly, but 
> instance 664 is not ans showing the npe similar to the one i've given. 
> 
> 
> Is this what is causing the migration issues? If so, should i change all 
> isolation_uri and broadcast_uri to the corresponding network vlan ids? 
> 
> Thanks 
> 
> Andrei 
> 
> - Original Message - 
> 
> From: "Andrija Panic"  
> To: dev@cloudstack.apache.org 
> Sent: Thursday, 14 May, 2015 4:00:07 PM 
> Subject: Re: Fwd: ACS 4.5.1 KVM live migration problem 
> 
> That would probably be a bug that I had...but we updated main VLAN table 
> with change URI or something... Marcus saved me that time :) 
> Andrei, please provide more info and the info Marcus said, I will try to 
> compare my values with yours if of any help. 
> 
> On 14 May 2015 at 16:56, Marcus  wrote: 
> 
> > So, I vaguely remember an issue introduced a little over a year ago where 
> > the broadcast domain value of the nic was changed from a URI to just a 
> vlan 
> > ID, which worked for vlans but broke vxlan and some other things. If I 
> > remember correctly, there would be a small set of installs during this 
> > period that wouldn't have created their nics with the correct broadcast 
> > domain value. I don't remember which versions were doing this but I do 
> know 
> > there's a JIRA ticket and a paper trail on how people were fixing it. The 
> > code that broke the URI was backed out. VMs created with the bad code 
> would 
> > not be compatible with the new or the old versions of code. 
> > 
> > I was under the impression at the time that there was some SQL provided 
> to 
> > update the values during an upgrade, perhaps that never made it in, or 
> > somehow got skipped during your upgrade process. At any rate, since there 
> > is a null pointer on broadcast domain type, you may check your 
> > nics/networks the MySQL db and verify that the broadcast/isolation types 
> > are URI format and not just a number. Or try to find the bug I'm 
> referring 
> > to from around April last year. 
> > On May 14, 2015 5:04 AM, "Andrei Mikhailovsky"  
> wrote: 
> > 
> > > Hi guys, 
> > > 
> > > Forwarding the message to the dev list as ive not had much reply in the 
> > > users list. 
> > > 
> > > In summary. after upgrading from ASC4.4.2 ro 4.5.1 i started having 
> > > migration issues with a lot of vms. some vms are successfully migrating 
> > and 
> > > others are not . 
> > > 
> > > The logs are shown below 
> > > 
> > > could someone help me to get to the bottom of this problem? 
> > > 
> > > Thanks 
> > > 
> > > Andrei 
> > > 
> > > 
> > > 
> > > - Forwarded Message - 
> > > From: "Andrei Mikhailovsky"  
> > > To: us...@cloudstack.apache.org 
> > > Sent: Wednesday, 13 May, 2015 10:44:29 AM 
> > > Subject: Re: ACS 4.5.1 KVM live migration problem 
> > > 
> > > Hi Rohit, 
> > > 
> > > forgot to answer you on the cloud.vlan table. 
> > > 
> > > That particular vm has a network with vlan id 1151 as shown when i look 
> > at 
> > > the network details in the acs gui. However, this vlan is not shown in 
> > the 
> > > cloud.vlan table. From what I can see the cloud.vlan table shows only 

[GitHub] cloudstack-cloudmonkey pull request: In the specific case of a "cr...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack-cloudmonkey/pull/4


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

[GitHub] cloudstack-cloudmonkey pull request: In the specific case of a "cr...

[bhaisaab]

Github user bhaisaab commented on the pull request:


https://github.com/apache/cloudstack-cloudmonkey/pull/4#issuecomment-10238
  
@ntavares thanks for the fix, makes sense. Merging now.


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

Re: ACS 4.5.1 KVM live migration problem

[Andrija Panic]

Ok, but since they are guest, it confuses me - is this advanced zone with
vlan, right ? Then my understanding all NICs (of user VM) needs to have
some isolation method...

Anyway - I'm running advanced zone  + vlans, and all VMS (VMs behind VPC
and VMS on internet/public network - but still that's Guest network) -
still all of them have some vlan://x value.

For VR, SSVM, CPVM - there are NICs on "ACS public" network that doesnt use
vlan - they have "vlan://untagged", and "NULL" is only used for LinkLocal
(169.x) NICs, and for mgmt/sec-storage NIC for SSVM/CPVM in my case.



On 15 May 2015 at 13:47, Andrei Mikhailovsky  wrote:

> Andrija,
>
> I've ran the command and it showed me a bunch of running vms with NULLs. I
> would roughly say about 20% of my total running vms do have NULL under the
> isolation and broadcast URIs.
>
> All of these vms are working perfectly well (in terms of network
> connectivity) and there is nothing special about them. They all have at
> least one guest NIC.
>
> Andrei
> - Original Message -
>
> From: "Andrija Panic" 
> To: dev@cloudstack.apache.org
> Cc: us...@cloudstack.apache.org
> Sent: Friday, 15 May, 2015 12:34:24 PM
> Subject: Re: ACS 4.5.1 KVM live migration problem
>
> Andrei,
>
> select instance_id,isolation_uri,broadcast_uri from nics where instance_id
> in (select id from vm_instance where state='Running' and name not like
> 'r-%' and name not like 'v-%' and name not like 's-%') order by
> instance_id;
>
> This gives me every niC, that does not belong to router or SSVm CPVMI
> always have vlan values - since this is all Guest NICs - they must have
> vlan ID...
> NULL values are only present when VM is deleted/stoped in my case...
>
> Can you check your VM 664 - what is so specific about it ?
> all NICs (in my understanding, if this is advacned zone) must have some
> vlan, can not be NULL or untagged ?
>
> On 15 May 2015 at 12:58, Andrei Mikhailovsky  wrote:
>
> >
> >
> > Hi Andrija, Marcus,
> >
> > Thanks for your comments and suggestions. I've checked the cloud.nics
> table
> >
> > mysql> select instance_id,isolation_uri,broadcast_uri from nics where
> > instance_id=564 or instance_id=664 or instance_id=;
> > +-+---+---+
> > | instance_id | isolation_uri | broadcast_uri |
> > +-+---+---+
> > | 564 | vlan://96 | vlan://96 |
> > | 664 | NULL | NULL |
> > |  | vlan://1127 | vlan://1127 |
> > +-+---+---+
> >
> >
> > From my tests, instance_ids 564 and  are migrating correctly, but
> > instance 664 is not ans showing the npe similar to the one i've given.
> >
> >
> > Is this what is causing the migration issues? If so, should i change all
> > isolation_uri and broadcast_uri to the corresponding network vlan ids?
> >
> > Thanks
> >
> > Andrei
> >
> > - Original Message -
> >
> > From: "Andrija Panic" 
> > To: dev@cloudstack.apache.org
> > Sent: Thursday, 14 May, 2015 4:00:07 PM
> > Subject: Re: Fwd: ACS 4.5.1 KVM live migration problem
> >
> > That would probably be a bug that I had...but we updated main VLAN table
> > with change URI or something... Marcus saved me that time :)
> > Andrei, please provide more info and the info Marcus said, I will try to
> > compare my values with yours if of any help.
> >
> > On 14 May 2015 at 16:56, Marcus  wrote:
> >
> > > So, I vaguely remember an issue introduced a little over a year ago
> where
> > > the broadcast domain value of the nic was changed from a URI to just a
> > vlan
> > > ID, which worked for vlans but broke vxlan and some other things. If I
> > > remember correctly, there would be a small set of installs during this
> > > period that wouldn't have created their nics with the correct broadcast
> > > domain value. I don't remember which versions were doing this but I do
> > know
> > > there's a JIRA ticket and a paper trail on how people were fixing it.
> The
> > > code that broke the URI was backed out. VMs created with the bad code
> > would
> > > not be compatible with the new or the old versions of code.
> > >
> > > I was under the impression at the time that there was some SQL provided
> > to
> > > update the values during an upgrade, perhaps that never made it in, or
> > > somehow got skipped during your upgrade process. At any rate, since
> there
> > > is a null pointer on broadcast domain type, you may check your
> > > nics/networks the MySQL db and verify that the broadcast/isolation
> types
> > > are URI format and not just a number. Or try to find the bug I'm
> > referring
> > > to from around April last year.
> > > On May 14, 2015 5:04 AM, "Andrei Mikhailovsky" 
> > wrote:
> > >
> > > > Hi guys,
> > > >
> > > > Forwarding the message to the dev list as ive not had much reply in
> the
> > > > users list.
> > > >
> > > > In summary. after upgrading from ASC4.4.2 ro 4.5.1 i started having
> > > > migration issues with a lot of vms. some vms are successfully
> migrating

[GitHub] cloudstack pull request: ListFirewallEgressRulesCmd: extend from B...

[resmo]

GitHub user resmo reopened a pull request:

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

ListFirewallEgressRulesCmd: extend from BaseListTaggedResourcesCmd an…

…d cleanup

Fixes API duplicate parameter in docs and makes it more clear.
Fixes a bunch of typos.

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

$ git pull https://github.com/resmo/cloudstack 
fix/cleanup_egress_firewallrules_api

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

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

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

This closes #249


commit 7991dd015e9dae9df91b8b8bf7eab63b04b02370
Author: Rene Moser 
Date:   2015-05-13T08:12:30Z

ListFirewallEgressRulesCmd: extend from BaseListTaggedResourcesCmd and 
cleanup

Fixes API duplicate parameter in docs and makes it more clear.
Fixes a bunch of typos.




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

[GitHub] cloudstack pull request: ListFirewallEgressRulesCmd: extend from B...

[resmo]

Github user resmo closed the pull request at:

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


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

Re: ACS 4.5.1 KVM live migration problem

[Marcus]

Hmmm, this seems like an unrelated issue, though the culprits are the same
fields.  It has me wondering if there's a bug in the vm sync or network
persistence. It would be interesting to know if:

1) The null values are somehow reproduceable

2) If stopping a VM with null values is possible

3) If starting a vm with null values fixes them

Are the networks these belong to marked as persistent? Network ids can be
dynamic in certain situations, if a network is not used it gives back its
vlan id, then gets a new one when you spin up vms again. This means these
fields on the nic also need to be updated to reflect that, and I'm
wondering if there's some issue there.

On Fri, May 15, 2015 at 6:01 AM, Andrija Panic 
wrote:

> Ok, but since they are guest, it confuses me - is this advanced zone with
> vlan, right ? Then my understanding all NICs (of user VM) needs to have
> some isolation method...
>
> Anyway - I'm running advanced zone  + vlans, and all VMS (VMs behind VPC
> and VMS on internet/public network - but still that's Guest network) -
> still all of them have some vlan://x value.
>
> For VR, SSVM, CPVM - there are NICs on "ACS public" network that doesnt use
> vlan - they have "vlan://untagged", and "NULL" is only used for LinkLocal
> (169.x) NICs, and for mgmt/sec-storage NIC for SSVM/CPVM in my case.
>
>
>
> On 15 May 2015 at 13:47, Andrei Mikhailovsky  wrote:
>
> > Andrija,
> >
> > I've ran the command and it showed me a bunch of running vms with NULLs.
> I
> > would roughly say about 20% of my total running vms do have NULL under
> the
> > isolation and broadcast URIs.
> >
> > All of these vms are working perfectly well (in terms of network
> > connectivity) and there is nothing special about them. They all have at
> > least one guest NIC.
> >
> > Andrei
> > - Original Message -
> >
> > From: "Andrija Panic" 
> > To: dev@cloudstack.apache.org
> > Cc: us...@cloudstack.apache.org
> > Sent: Friday, 15 May, 2015 12:34:24 PM
> > Subject: Re: ACS 4.5.1 KVM live migration problem
> >
> > Andrei,
> >
> > select instance_id,isolation_uri,broadcast_uri from nics where
> instance_id
> > in (select id from vm_instance where state='Running' and name not like
> > 'r-%' and name not like 'v-%' and name not like 's-%') order by
> > instance_id;
> >
> > This gives me every niC, that does not belong to router or SSVm CPVMI
> > always have vlan values - since this is all Guest NICs - they must have
> > vlan ID...
> > NULL values are only present when VM is deleted/stoped in my case...
> >
> > Can you check your VM 664 - what is so specific about it ?
> > all NICs (in my understanding, if this is advacned zone) must have some
> > vlan, can not be NULL or untagged ?
> >
> > On 15 May 2015 at 12:58, Andrei Mikhailovsky  wrote:
> >
> > >
> > >
> > > Hi Andrija, Marcus,
> > >
> > > Thanks for your comments and suggestions. I've checked the cloud.nics
> > table
> > >
> > > mysql> select instance_id,isolation_uri,broadcast_uri from nics where
> > > instance_id=564 or instance_id=664 or instance_id=;
> > > +-+---+---+
> > > | instance_id | isolation_uri | broadcast_uri |
> > > +-+---+---+
> > > | 564 | vlan://96 | vlan://96 |
> > > | 664 | NULL | NULL |
> > > |  | vlan://1127 | vlan://1127 |
> > > +-+---+---+
> > >
> > >
> > > From my tests, instance_ids 564 and  are migrating correctly, but
> > > instance 664 is not ans showing the npe similar to the one i've given.
> > >
> > >
> > > Is this what is causing the migration issues? If so, should i change
> all
> > > isolation_uri and broadcast_uri to the corresponding network vlan ids?
> > >
> > > Thanks
> > >
> > > Andrei
> > >
> > > - Original Message -
> > >
> > > From: "Andrija Panic" 
> > > To: dev@cloudstack.apache.org
> > > Sent: Thursday, 14 May, 2015 4:00:07 PM
> > > Subject: Re: Fwd: ACS 4.5.1 KVM live migration problem
> > >
> > > That would probably be a bug that I had...but we updated main VLAN
> table
> > > with change URI or something... Marcus saved me that time :)
> > > Andrei, please provide more info and the info Marcus said, I will try
> to
> > > compare my values with yours if of any help.
> > >
> > > On 14 May 2015 at 16:56, Marcus  wrote:
> > >
> > > > So, I vaguely remember an issue introduced a little over a year ago
> > where
> > > > the broadcast domain value of the nic was changed from a URI to just
> a
> > > vlan
> > > > ID, which worked for vlans but broke vxlan and some other things. If
> I
> > > > remember correctly, there would be a small set of installs during
> this
> > > > period that wouldn't have created their nics with the correct
> broadcast
> > > > domain value. I don't remember which versions were doing this but I
> do
> > > know
> > > > there's a JIRA ticket and a paper trail on how people were fixing it.
> > The
> > > > code that broke the URI was backed out. VMs created with the bad code
> > 

Re: Preparing for 4.6

[Daan Hoogland]

Sebastien, I don't think commits in a big feature should be squashed. It
hinders review if to big chunks are submitted at once.

Op vr 15 mei 2015 om 11:27 schreef Sebastien Goasguen :

> Folks,
>
> As we prepare to try a new process for 4.6 release it would be nice to
> start paying attention to master.
>
> - Good commit messages
> - Reference to a JIRA bug
> - Squashing commits ( cc/ wilder :))
>
> While you can apply patches directly, good practice is to apply the patch
> to a branch and then merge that branch into master.
>
> Before we start enforcing some of these things more strongly, please keep
> it in mind.
>
> thanks,
>
> -sebastien

Re: Preparing for 4.6

[Marcus]

I'm not sure it is any different. Either you have a giant block of code
that represents a bunch of little commits, or a giant block that is one
commit. We don't want to merge little chunks to master that don't fully
implement the feature.

To the extent that features and goals can be split up, yes, we don't want
those features squashed together, or even submitted together, squashed or
not. An example of this is in combining formatting/syntax fixes with
functional changes, I have tried to review such pull requests and it is
very difficult to see what is going on in a 1k line request when 2/3 of the
changes are just reformatting noise.

Ideally the code is reviewed at the commit level as each small commit goes
from the developer's workstation to the dev branch, but I don't see a way
around reviewing the same amount of code in a pull request that represents
multiple small commits vs one squashed commit. You do get more visibility
into the comments, though.

I suppose a way to get both would be to branch master, do a pull request
from your dev branch to that branch, at which point it is reviewed, then
squash merge that back into master.
On May 15, 2015 8:55 AM, "Daan Hoogland"  wrote:

> Sebastien, I don't think commits in a big feature should be squashed. It
> hinders review if to big chunks are submitted at once.
>
> Op vr 15 mei 2015 om 11:27 schreef Sebastien Goasguen :
>
> > Folks,
> >
> > As we prepare to try a new process for 4.6 release it would be nice to
> > start paying attention to master.
> >
> > - Good commit messages
> > - Reference to a JIRA bug
> > - Squashing commits ( cc/ wilder :))
> >
> > While you can apply patches directly, good practice is to apply the patch
> > to a branch and then merge that branch into master.
> >
> > Before we start enforcing some of these things more strongly, please keep
> > it in mind.
> >
> > thanks,
> >
> > -sebastien
>

usage-server redudancy ?

[Andrija Panic]

Hi guys,

wondering, is it possible/good to have redudant cloudstack-usage running -
we have 2 acs mgmt nodes via LB, so can I run/install cloudstack-usage on
both nodes - does running 2 instances, makes problem  for usage data
agregation etc ?

THx

-- 

Andrija Panić

Re: Bug resolve for 4.5.2

[Daan Hoogland]

Sure, its what you say; a heads-up. if we find a fix let's remind ourselves
to check and/or enter a ticket for the same in 4.6

Op vr 15 mei 2015 om 03:52 schreef ilya :

> Daan,
>
> Thanks for heads up on 4.6 changes, nevertheless, quite of few folks
> will use 4.5 for at least a year before they upgrade to 4.6 or 4.7 by
> then, so we should still fix it in 4.5.
>
> Regards
> ilya
>
> On 5/14/15 5:26 AM, Daan Hoogland wrote:
> > Andrija, Marcus, Keep in mind that the vpc configuration scripts changed
> > drastically in 4.6/master. The ms-called scripts are replaced by a json
> > representation of the configuration that is processed on the VR. Any fix
> to
> > the present set of scripts will be short lived.
> >
> > Op do 14 mei 2015 om 06:01 schreef Marcus :
> >
> > This could be a good opportunity to get your hands dirty and submit a
> >> patch! These iptables rules are managed by a handful of shell scripts.
> >> There are some specific to VPC if I remember correctly, in
> /opt/cloud/bin
> >> on the virtual router. You can get a history of what script was run and
> >> with which parameters either I'm /var/log/cloud.out on the router or
> debug
> >> logs on the agent where the router runs.
> >> On May 13, 2015 2:57 PM, "Somesh Naidu" 
> wrote:
> >>
> >>> I believe the default network offering for Isolated Network
> >>> (DefaultIsolatedNetworkOfferingWithSourceNatService) does the same. So
> I
> >>> guess that may not be the problem.
> >>>
> >>> Regards,
> >>> Somesh
> >>>
> >>> -Original Message-
> >>> From: Andrija Panic [mailto:andrija.pa...@gmail.com]
> >>> Sent: Wednesday, May 13, 2015 12:14 PM
> >>> To: dev@cloudstack.apache.org
> >>> Subject: Re: Bug resolve for 4.5.2
> >>>
> >>> Is this maybe happening, because Im using everything of services on
> >> single
> >>> NEtwork offering : StaticNat, NetworkACL, PortForwarding, UserData,
> Vpn,
> >>> SourceNat, Dns, Lb, Dhcp ?
> >>> Maybe because of the design with some of the services ?
> >>>
> >>> Maybe I shouldnt use all stuff - although it doesnt make sense to me...
> >>>
> >>> On 12 May 2015 at 16:46, Andrija Panic 
> wrote:
> >>>
>  Hi Erik,
> 
>  Thanks for geting back to me.
> 
>  I have commented the issue and provided example from brand new ACS
>  installation, and new VPC, 1 network, 1 VM.
> 
> 
> >>
> http://secure-web.cisco.com/1WU4eQfmrJcfhnrBedw7AyAJbKlVUQJ5VhSpUxxbUMahg8oXbGqUkLA33un89ck8JZJHs78G4VumAGMsOQokXJ5RK2_C1-omDL66nAwlgG_yoJCZQeR79XNTfU-ql5XbKf2H05s7s4AvWrJ8ZId2r8sE7sqyx2ls3eI4vgRQgET6fU_cPtUbtUth_vZTSVzhCoq8agNngtqqw9uXXKzMXCQ/http%3A%2F%2Fpastebin.com%2FihjiDZ9h
> >>> - iptables-save from inside VR on pastebin -
>  this is brand new VPC (1 network, 1 VM in network) on 4.4.3 release.
>  http://snag.gy/V949g.jpg - ACS setup and "proof" :
>  XXX.39.228.155 - main VPC IP
>  XXX.39.228.156 - additional IP, configured Static NAT to private VM
>  10.10.10.10
>  Connected to XXX39.228.156:22 - and done "netstat -antup | grep 22" -
>  remote connection seems to come from XXX.39.228.155 - main VPC IP.
>  This is ACS 4.4.3, Advanced Zone, KVM.
> 
> 
>  Thanks
> 
>  On 12 May 2015 at 14:43, Erik Weber  wrote:
> 
> > On Tue, May 12, 2015 at 2:31 PM, Andrija Panic <
> >> andrija.pa...@gmail.com
> > wrote:
> >
> >> Hi dev team,
> >>
> >> I was wondering who would be willing to help with:
> >> https://issues.apache.org/jira/browse/CLOUDSTACK-8451
> >>
> >> remote IP not seen in VM behind VPC...
> >>
> > Could you get the relevant iptables rule with 'iptables-save'?
> >> obfuscate
> > addresses etc. if you feel like it
> >
> > --
> > Erik
> >
> 
> 
>  --
> 
>  Andrija Panić
> 
> >>>
> >>>
> >>> --
> >>>
> >>> Andrija Panić
> >>>
>
>

Re: Preparing for 4.6

[Daan Hoogland]

those comments will then have to be squashed s well, to this i put a -1. If
those comments where usefull at review-time they will be usefull in the
future as well.

Op vr 15 mei 2015 om 19:29 schreef Marcus :

> I'm not sure it is any different. Either you have a giant block of code
> that represents a bunch of little commits, or a giant block that is one
> commit. We don't want to merge little chunks to master that don't fully
> implement the feature.
>
> To the extent that features and goals can be split up, yes, we don't want
> those features squashed together, or even submitted together, squashed or
> not. An example of this is in combining formatting/syntax fixes with
> functional changes, I have tried to review such pull requests and it is
> very difficult to see what is going on in a 1k line request when 2/3 of the
> changes are just reformatting noise.
>
> Ideally the code is reviewed at the commit level as each small commit goes
> from the developer's workstation to the dev branch, but I don't see a way
> around reviewing the same amount of code in a pull request that represents
> multiple small commits vs one squashed commit. You do get more visibility
> into the comments, though.
>
> I suppose a way to get both would be to branch master, do a pull request
> from your dev branch to that branch, at which point it is reviewed, then
> squash merge that back into master.
> On May 15, 2015 8:55 AM, "Daan Hoogland"  wrote:
>
> > Sebastien, I don't think commits in a big feature should be squashed. It
> > hinders review if to big chunks are submitted at once.
> >
> > Op vr 15 mei 2015 om 11:27 schreef Sebastien Goasguen  >:
> >
> > > Folks,
> > >
> > > As we prepare to try a new process for 4.6 release it would be nice to
> > > start paying attention to master.
> > >
> > > - Good commit messages
> > > - Reference to a JIRA bug
> > > - Squashing commits ( cc/ wilder :))
> > >
> > > While you can apply patches directly, good practice is to apply the
> patch
> > > to a branch and then merge that branch into master.
> > >
> > > Before we start enforcing some of these things more strongly, please
> keep
> > > it in mind.
> > >
> > > thanks,
> > >
> > > -sebastien
> >
>

Re: Preparing for 4.6

[Mike Tutkowski]

Those comments may or may not be useful anymore. What they describe may
have been superseded by a subsequent commit.

On Fri, May 15, 2015 at 3:12 PM, Daan Hoogland 
wrote:

> those comments will then have to be squashed s well, to this i put a -1. If
> those comments where usefull at review-time they will be usefull in the
> future as well.
>
> Op vr 15 mei 2015 om 19:29 schreef Marcus :
>
> > I'm not sure it is any different. Either you have a giant block of code
> > that represents a bunch of little commits, or a giant block that is one
> > commit. We don't want to merge little chunks to master that don't fully
> > implement the feature.
> >
> > To the extent that features and goals can be split up, yes, we don't want
> > those features squashed together, or even submitted together, squashed or
> > not. An example of this is in combining formatting/syntax fixes with
> > functional changes, I have tried to review such pull requests and it is
> > very difficult to see what is going on in a 1k line request when 2/3 of
> the
> > changes are just reformatting noise.
> >
> > Ideally the code is reviewed at the commit level as each small commit
> goes
> > from the developer's workstation to the dev branch, but I don't see a way
> > around reviewing the same amount of code in a pull request that
> represents
> > multiple small commits vs one squashed commit. You do get more visibility
> > into the comments, though.
> >
> > I suppose a way to get both would be to branch master, do a pull request
> > from your dev branch to that branch, at which point it is reviewed, then
> > squash merge that back into master.
> > On May 15, 2015 8:55 AM, "Daan Hoogland" 
> wrote:
> >
> > > Sebastien, I don't think commits in a big feature should be squashed.
> It
> > > hinders review if to big chunks are submitted at once.
> > >
> > > Op vr 15 mei 2015 om 11:27 schreef Sebastien Goasguen <
> run...@gmail.com
> > >:
> > >
> > > > Folks,
> > > >
> > > > As we prepare to try a new process for 4.6 release it would be nice
> to
> > > > start paying attention to master.
> > > >
> > > > - Good commit messages
> > > > - Reference to a JIRA bug
> > > > - Squashing commits ( cc/ wilder :))
> > > >
> > > > While you can apply patches directly, good practice is to apply the
> > patch
> > > > to a branch and then merge that branch into master.
> > > >
> > > > Before we start enforcing some of these things more strongly, please
> > keep
> > > > it in mind.
> > > >
> > > > 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: Preparing for 4.6

[Rajani Karuturi]

-1 for squashed commits. I agree to what Daan said. Feature branch merge is
more convenient than squashed single commit.
If it was a small feature which involved single dev squashing is still ok.
But, a big no when it comes to big feature/refactoring involving effort
from multiple people and multiple reviews.


On Sat, May 16, 2015 at 3:21 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

Those comments may or may not be useful anymore. What they describe may
have been superseded by a subsequent commit.

On Fri, May 15, 2015 at 3:12 PM, Daan Hoogland >
wrote:

> those comments will then have to be squashed s well, to this i put a -1.
If
> those comments where usefull at review-time they will be usefull in the
> future as well.
>
> Op vr 15 mei 2015 om 19:29 schreef Marcus >:
>
> > I'm not sure it is any different. Either you have a giant block of code
> > that represents a bunch of little commits, or a giant block that is one
> > commit. We don't want to merge little chunks to master that don't fully
> > implement the feature.
> >
> > To the extent that features and goals can be split up, yes, we don't
want
> > those features squashed together, or even submitted together, squashed
or
> > not. An example of this is in combining formatting/syntax fixes with
> > functional changes, I have tried to review such pull requests and it is
> > very difficult to see what is going on in a 1k line request when 2/3 of
> the
> > changes are just reformatting noise.
> >
> > Ideally the code is reviewed at the commit level as each small commit
> goes
> > from the developer's workstation to the dev branch, but I don't see a
way
> > around reviewing the same amount of code in a pull request that
> represents
> > multiple small commits vs one squashed commit. You do get more
visibility
> > into the comments, though.
> >
> > I suppose a way to get both would be to branch master, do a pull request
> > from your dev branch to that branch, at which point it is reviewed, then
> > squash merge that back into master.
> > On May 15, 2015 8:55 AM, "Daan Hoogland" >
> wrote:
> >
> > > Sebastien, I don't think commits in a big feature should be squashed.
> It
> > > hinders review if to big chunks are submitted at once.
> > >
> > > Op vr 15 mei 2015 om 11:27 schreef Sebastien Goasguen <
> run...@gmail.com 
> > >:
> > >
> > > > Folks,
> > > >
> > > > As we prepare to try a new process for 4.6 release it would be nice
> to
> > > > start paying attention to master.
> > > >
> > > > - Good commit messages
> > > > - Reference to a JIRA bug
> > > > - Squashing commits ( cc/ wilder :))
> > > >
> > > > While you can apply patches directly, good practice is to apply the
> > patch
> > > > to a branch and then merge that branch into master.
> > > >
> > > > Before we start enforcing some of these things more strongly, please
> > keep
> > > > it in mind.
> > > >
> > > > 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
*™*



-- 
~Rajani
Sent from my Windows Phone

Re: usage-server redudancy ?

[Praveen B]

Hi Andrija,

Yes, it is always good to have redundant cloudstack-usage servers running
on both of your management nodes.
Also, this does not cause any problem for usage data aggregation.

Thanks,
Praveen

On Sat, May 16, 2015 at 2:11 AM, Andrija Panic 
wrote:

> Hi guys,
>
> wondering, is it possible/good to have redudant cloudstack-usage running -
> we have 2 acs mgmt nodes via LB, so can I run/install cloudstack-usage on
> both nodes - does running 2 instances, makes problem  for usage data
> agregation etc ?
>
> THx
>
> --
>
> Andrija Panić
>