Ip-profile is used in NSD to create subnet in VIM. What about if the network already exists in VIM and if I want to teach OSM how to generate and increment IPs within existing subnet when scaling VDU?
Ip-profile for existing network in VIM
Proposers
Tolga Gölelcin (Telenity)
Type
Feature
Target MDG/TF
IM, LCM, RO
Description
Ip-profile is used in NSD to create subnet in VIM. What about if the network already exists in VIM and if I want to teach OSM how to generate and increment IPs within existing subnet when scaling VDU?
Ip-profile only works when OSM is creating a subnet, for scaled VDUs there’s no current way to influence which IP the CP is going to get. But there may be.
My proposal is to add a boolean type property named "exists" under ip-profiles. If it is "false" it works as it is currently. But if it is "true" then no subnet will be created. Only the VDUs spwaned will be assigned IP as it is defined in ip-profile definition.
+--rw ip-profiles* [name]
| +--rw exists boolean
| +--rw name string
| +--rw description? string
| +--rw ip-profile-params
| +--rw ip-version? inet:ip-version
| +--rw subnet-address? inet:ip-prefix
| +--rw gateway-address? inet:ip-address
| +--rw security-group? string
| +--rw dns-server* [address]
| | +--rw address inet:ip-address
| +--rw dhcp-params
| | +--rw enabled? boolean
| | +--rw start-address? inet:ip-address
| | +--rw count? uint32
| +--rw subnet-prefix-pool? stringDemo or definition of done
There is a production site where many applications are already deployed as Openstack VMs. The task is to convert some applications to VNFs such that they can be manually scaled via OSM. So there are some Networks and Subnets already created. The first step is to convert uscVM. Below you can see two application servers and the subnets:
$ openstack server list -c Name -c Networks +----------------+-----------------------------------------------------------------------------------------------------------------------------+ | Name | Networks | +----------------+-----------------------------------------------------------------------------------------------------------------------------+ | usc-1-uscVM2-1 | RY_EXT_LAN=192.173.204.47; RY_TENANT_DMI=192.168.3.47; RY_TENANT_RMI=192.168.4.47; RY_TENANT_LAN=192.168.7.47 | | usc-1-uscVM1-1 | RY_EXT_LAN=192.173.204.46, 10.35.42.167; RY_TENANT_DMI=192.168.3.46; RY_TENANT_RMI=192.168.4.46; RY_TENANT_LAN=192.168.7.46 | +----------------+-----------------------------------------------------------------------------------------------------------------------------+
$ openstack subnet list -c Name -c Subnet +-------------------------+--------------------+ | Name | Subnet | +-------------------------+--------------------+ | RY_TENANT_RMI_sub | 192.168.4.0/24 | | RY_TENANT_DMI_sub | 192.168.3.0/24 | | RY_TENANT_LAN_sub | 192.168.7.0/24 | | RY_EXT_LAN_sub | 192.173.204.0/24 | | public-subnet | 10.35.42.0/24 | +-------------------------+--------------------+
Here are the NSD and VNFD: https://drive.google.com/open?id=1ZHysc7Se5rIs1qq0nRBX2TM3RrQc0_kk https://drive.google.com/open?id=1_z6sJP9Wjyk6O-EeQuo0jm5iJcyf_Ca_
Those NSD and VNFD only mimic the existing situation. The aim is infact to design the VNFD and NSD such that the scaled uscVM should be spwaned with IPs RY_EXT_LAN=192.173.204.48; RY_TENANT_DMI=192.168.3.48; RY_TENANT_RMI=192.168.4.48; RY_TENANT_LAN=192.168.7.48 But for the time being it is not possible to say that "Hey OSM the spwaned VDU should get 192.173.204.48 on RY_EXT_LAN, 192.168.3.48 on RY_TENANT_DMI and so on.