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.
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
Changes done:
- Provide UUID for userid and domainid only while constructing the login response. Session will hold the DB id's as before, to ensure other parts keep working.
- This reverts commit de28aa3ddde5b601f2f234f2eccef871fbaf1a06.
Description:
Incorrectly removed part of the XML serializer that serialized
the IdentityProxy object in normal responses, when putting in
support for serialization of lists of IdentityProxy objects in
exception responses as part of the code changes put in for bug
13217, resulting in this bug. Putting it back in place.
Description:
Adding overloaded addProxyObject() function to CloudException
and RuntimeCloudException classes and using this function
to stuff exceptions with IDs, to reduce code footprint.
Description:
Modifying the API functions' exception handling to call
addProxyObject() wherever applicable, and removing some
wrong calls to addProxyObject() that were put in in an
earlier commit for this bug.
With this commit, we cover many API functions to use the
new exception handling code, but some pieces may still be
left out. These will be covered as work in progress, when
making changes to the CS API code.
Description:
Removed some wrong invocations to addProxyObject() when
throwing exceptions in NetworkManagerImpl.java.
Replaced db ids with uuids in various points in the code
of NetworkManagerImpl.java, where exceptions are thrown.
Description:
Replacing placement of db ids in exception messages to uuids
in the file ManagementServerImpl.java.
Since there are a large number of files that throw exceptions
with db ids in them and they need to be changed, we will make
the changes in multiple commits.
Description:
Adding a new class AnnotationHelper, that provides routines
to read annotations from a VO class.
Cloudstack does the mapping between cloudstack java VO objects
and the database tables using cglib. cglib creates proxy objects
as the maps between VO objects and the database. A VO (value
object) class is populated after querying from the MYSQL database.
Ideally, a getAnnotation() issued on a cglib proxy object should
get a list of all the annotations in all classes in the inheritence
chain. However, this functionality seems to be currently broken
in cglib. Hence, when querying for annotations given the object
of a VO class, we need to get to the corresponding VO class of that
cglib proxy class and issue a getAnnotation() on that class. To get
the VO class, we simply need to get the super class of the proxy
object. Also, we need to recurse to the root VO class in case the
VO class extends another VO class.
Note that the cache used by CS is ehcache.
