only owner of the network can access it; if it's domain - all accounts in the domain and domain children can have an access.
* aclType replaces 2 old fields: isShared and isDomainSpecific.
* All 2.2.x account specific networks will have aclType=Account; 2.2.x Domain specific networks - aclType=domain; 2.2.x Zone level networks - aclType=Domain with domainId = Root domain id
- ListSupportedNetworkServiceProvidersCmd will now return Providers along with its element's services and boolean 'canEnableIndividualServices' that indicates if for this Provider services can be enabled/disabled
- add & update NetworkServiceProvider changed to take in the list of services to enable. While adding a provider, if list is null then all services supported by the element are enabled by default.
- ListNetworkServices enhanced to take in a provider name and returns services of that specific provider.
* can be specified for Shared network only
* if not specified for the Shared networks, try to locate it based on the zoneId and tags. If tags is not null, pick up first physicalNetwork from the zone that has matching tags. If tags is null, and there are none/more than 1 physical netwroks in the zone, error out.
Added PortForwardingServiceProvider, StaticNatServiceProvider, rename
PasswordServiceProvider to UserDataServiceProvider(may rename to a better name
later).
Add related function for service providers.
2)Re-apply all existing firewall rules as a part of implement call. TODO: Cleanup all existing rules from the backend (leave them in the DB) as a part of shutdown call
TODO:
- Still leaving the provider columns in data_center schema as-is for CloudKit and BareMetal
- ExternalNetworkDeviceMgrImpl still needs to fix the dataCenter.setProviders calls and externalNetworkApplicance usage checks to see if zone has external networking.
Limitations:
* can't upgrade to the network offering with lesser number of services
* can upgrade only when the service provider of the original offering is not external (domR, dhcp, elb) to the external type of the provider
In the past, the NetworkElement would cover almost all the functionality that
e.g. virtual router can cover: firewall, source NAT, static NAT, password,
VPN... So anyone want to implement the NetworkElement would have to implement
these service's specific methods, even it wouldn't support it. Also, if we want
to find a e.g. FirewallServiceProvider, we have to proceed all the current
network service providers, to call a method to know if it support such service.
That's neither elegant nor scaling way to do it.
As the first step, this patch separates each ServiceProvider from NetworkElement
(there are some interface already out of NetworkElement, so this patch slightly
modifies them too), and only the class would implement the correlated interface, would
have the ability to do these services.
1) Introduce new managers - ProjectManager and DomainManager. Moved all domain related code from AccountManager to DomainManager.
2) Moved some code from ManagementServerImpl to the correct managers.
3) New resource limit for Domain - Project
1) On enableStaticNat command we actually send the command to the backend (we used to just upgrade the DB in the past). The backend command carries sourceIp and destIp, and creates IP to IP mapping on the domR.
2) On disableStaticNat for the Ip address in addition to cleaning up port ranges, we also delete IP to IP mapping on the domR.
status 10869: resolved fixed
Here is the flow (design is approved by Will Chan):
1) If user specifies custom ip address, and this ip is not the first ip in the range, the dhcp server gets the ip.
2) If user specifies custom ip address, and this ip is the first ip in the range, the dhcp server will get the random ip address from the range.
2) If user doesn't specify custom ip address, we always try to allocate first ip address from the range for the dhcp server; if this ip is already allocated, the dhcp server will get the random ip from the range.
This will work for:
* domR's Guest network
* dhcp's Direct network
status 10869: resolved fixed
Here is the flow (design is approved by Will Chan):
1) If user specifies custom ip address, and this ip is not the first ip in the range, the dhcp server gets the ip.
2) If user specifies custom ip address, and this ip is the first ip in the range, the dhcp server will get the random ip address from the range.
2) If user doesn't specify custom ip address, we always try to allocate first ip address from the range for the dhcp server; if this ip is already allocated, the dhcp server will get the random ip from the range.
This will work for:
* domR's Guest network
* dhcp's Direct network
Block update only in these cases:
* when DNS capability AllowDnsSuffixModification is false for the network
* when target network has running network elements (dhcps or domRs)
Conflicts:
server/src/com/cloud/vm/dao/DomainRouterDao.java
server/src/com/cloud/vm/dao/DomainRouterDaoImpl.java
Block update only in these cases:
* when DNS capability AllowDnsSuffixModification is false for the network
* when target network has running network elements (dhcps or domRs)
Alena Prokharchyk
Sheng Yang
Alex Huang
alena
prachi
Edison Su