It's not a elegant fix. The status for firewall rules should remain unchanged
before/after ip association/disassociation. But the related change is tricky
than this fix, may not get enough test for 3.0.1. So we would apply existed
firewall rules again, which would work, just result in some unnecessary
commands.
status 14484: resolved fixed
Reviewed-by: Edison Su
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.
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.
Bug 13127: API error text refer to database ids instead of uuids
Code-Reviewers: Ewan Mellor, Kelven Yang
Description:
1. A new class CSExceptionErrorCode has been added to utils.
It contains a list of error codes for each type of
Exception class. Use fully qualified package paths for
Exceptions in CSExceptionErrorCode. We log any exception
name not found in the list of error codes for exceptions.
2. Whenever we throw an exception exobj anywhere in the
CS code, the CSErrorCode is set in the base class
constructor.
3. We add a new field csErrorCode in classes CloudException,
RuntimeCloudException, ExecutionException and
ExceptionResponse.
4. Two places in ApiServer.java were wrongly modified when
putting in changes for bug 13127 to not throw an exception.
This has been corrected in this commit.
Description:
Modify Exception handling to enable addition of multiple
uuids in a single exception thrown by API functions. Both
XML and JSON outputs will store all uuids and Fieldnames.
This will make it easier to provide more information when
an exception occurs - for example, a zone id, a cluster id,
host id, and then a specific property id.
Description:
Added a field name for the db id in the IdentityProxy class, and
modified setProxyObject() to take an additional id name parameter.
This will let us know the name of the uuid that we are returning.
E.g.- domainId, zoneId, etc. The client can view this field in
the json/xml output. Modified the JSON/XML serialization routines
to append this new parameter to the serialized output for Exception
Responses.
Description:
1) Added a setProxyObject() method to CloudException and RuntimeCloudException
2) Modified a bunch of throw exceptions in NetworkManagerImpl.java to call setProxyObject() before throwing an exception.
3) Changed scope of ProxyIdentity attribute to protected.
4) Added routines to ServerApiException to get/set IdentityProxy object, and
routine in RuntimeCloudException to get the Idproxy object.
5) Modified the exception handling around the dispatcher and handlerequest()
to copy over the IdentityProxy information before rethrowing an exception
eventually back to handle().
6) Removed duplicate IdentityProxy object in ServerApiException.
It was extending RuntimeCloudException which already had an
IdentityProxy object.
We expect user to use following sequence when update virtual router provided
network offering to external firewall devices offering:
1. Shutdown all the user VMs.
2. Modify network to new offering.
3. Click "Allow CIDR change" in the pop-up dialog, which would pass
changeCidr=true to the updateNetwork API.
We would shutdown guest network before we update the network for new
offering(with changeCidr = true), in order to re-implement the network.
status 13715: resolved fixed
Reviewed-by: Alex
CIDR may be different after update to a service offering contained external
network element, user is required to acknowledge this, otherwise the update
won't process
Changes:
- We do not need these global setting anymore. These will be hidden since 3.0
- The default traffic label will be picked from the global setting which is null by default. When traffic label is null it means the resource uses tag on the default gateway
- Changes to invoke discoverer to reload the resource object on host connection
- Since a zone can have many physical networks, there can be multiple guest, public networks. Only the zone wide storage and management traffic label will be stored in host_details henceforth.
- If traffic labels are updated, discoverer should update the host_details
Summary of Changes:
- created a generic way for LB rule validations, so as LB device(like Haproxy) specific validations can be done syncronously.
- Removed asyncronous validations from Haproxy and done syncronously.
