status 14463; resolved fixed
moved all static (config related) variables to non-static in SRX server resource as we can have more than
one SRX device in a zone
reviewed-by: Chirag Jog
Each testCase class will use its own logger to distinguish log
messages when multiple suites are run. This will aid debugging
Every cloudstackTestCase will also contiain a class level attr of the
testClient which was previously available only to setUp/tearDown. Now
even setUpClass/tearDownClass can use this attribute.
Changes:
Fixed as described in the bug.
* CreateVlanIpRangeCmd still accept account/domainId info
* if account owns:
- one Isolated network with source nat service enabled, use this network
- more than one Isolated network with source nat service enabled - error out
- none Isolated networks with source nat service enabled, create it only in
case when there is an Isolated network offering with Availability=Required and
source nat service enabled.
Add VM details to name in PF/LB rule on click.
Note that the details panel now maximizes, to prevent additional panels
from accumulating by the user trying to click on multiple VMs when the
detail pane is present.
status 14240: resolved fixed
The routing table with two nics may be messed up, due to we sent same
router(gateway) information from different DHCP server, in order to specify
default gateway. E.g.
Network A: 192.168.1.0/24, gw 192.168.1.1
Network B: 192.168.2.0/24, gw 192.168.2.1
User VM: Nic 1 connect to network A, get ip 192.168.1.10; nic 2 connect to
network B, get ip 192.168.2.10.
Set network A as the default network of user VM.
Currently we would send this information to user VM through DHCP offer:
In network A: dhcp-option:router 192.168.1.1
In network B: dhcp-option:router 192.168.1.1
So both NIC in the guest VM would receive 192.168.1.1 as router(gateway).
But, in CentOS 5.6, dhclient-scripts try to tell if the gateway is reachable
for current subnet.
So when we try to enable nic 2(eth1) of user VM, dhclient would receive:
IP: 192.168.2.10
Mask: 255.255.255.0
Router: 192.168.1.1
Then it would found that the specified gateway(router) is not within its own
subnet(192.168.2.0/24). But since we send out this ip(192.168.1.1) as the
gateway for it, dhclient thought that it should got someway to access the
network through this IP. So it would execute:
ip route add 192.168.1.1 dev eth1
ip route replace default via 192.168.1.1 dev eth1
But it can never reach 192.168.1.1(which is in the eth0's subnet and the
gateway of eth0) by go through eth1 interface. So it is messed up.
We've tested Windows 2008 R2, CentOS 5.3, CentOS 5.6 and Ubuntu 10.04. Windows
and Ubuntu are fine with above policy.
To solve this, we send different dhcp:router option according to the guest OS
type now.
We may need expand this list later, but for now we only know that CentOS and
RHEL would behavior in this way.
status 14042: resolved fixed
Currently, the items listed under the load balancer always use .name as
the field to display for the VM name.
Since 'instancename' is now used for the user-friendly name field,
_itemName metadata attribute can be specified in the rule's data
provider to tell which field should be rendered as the name field in the
list.
Add UI support for associating IP ranges with specific account + domain;
this is accessible by going to the system network graph->public->IP
range edit, where clicking on 'Add user' button opens a dialog to
specify an account and domain.
Note that right now editing of existing IP ranges is not supported, so
in order to associate a range with another account, the IP range needs
to be dropped and re-created with the new account configuration.
status 14231: resolved fixed
Jessica Wang
Alena Prokharchyk
Murali reddy
Sanjay Tripathi
Nitin Mehta
Prasanna Santhanam
Edison Su
bfederle
Abhi
prachi
Kelven Yang
Sheng Yang
Sheng Yang
kishan