Openstack configuration (Release THREE) - Revision history

Tierno at 11:21, 25 September 2018

2018-09-25T11:21:00Z

← Older revision		Revision as of 11:21, 25 September 2018
Line 81:		Line 81:
	* '''keypair''': To be added in addition to the keypair allocated on the VNF descriptor. Provide the name of an openstack keypair		* '''keypair''': To be added in addition to the keypair allocated on the VNF descriptor. Provide the name of an openstack keypair
	* '''dataplane_physical_net''': The physical network label used in Openstack both to identify SRIOV and passthrough interfaces (nova configuration) and also to specify the VLAN ranges used by SR-IOV interfaces (neutron configuration). In case of VMware Integrated Openstack (VIO) provide moref ID of distributed virtual switch.		* '''dataplane_physical_net''': The physical network label used in Openstack both to identify SRIOV and passthrough interfaces (nova configuration) and also to specify the VLAN ranges used by SR-IOV interfaces (neutron configuration). In case of VMware Integrated Openstack (VIO) provide moref ID of distributed virtual switch.
	* '''use_floating_ip''': (By default false). ~~When true~~ a management interface of a VNFD is automatically assigned a floating_ip -if possible-. The prefered method is to use a provider network		* '''use_floating_ip''': (By default false). If boolean True (note: not string 'True') a management interface of a VNFD is automatically assigned a floating_ip -if possible-. If a string is suplied instead of a boolean, it indicates the network/floating ip pool to use. The prefered method is to use a provider network
	* '''dataplane_net_vlan_range''': In case of VMware Integrated Openstack (VIO) provide vlan ranges for the SRIOV (binding direct) networks in format ['start_ID - end_ID']		* '''dataplane_net_vlan_range''': In case of VMware Integrated Openstack (VIO) provide vlan ranges for the SRIOV (binding direct) networks in format ['start_ID - end_ID']
	* '''microversion''': This is an Openstack-only parameter that allows to specify a specific microversion to be used in nova. When using 'microversion: 2.32', it enables the use of Virtual Device Role Tagging, which allows to identify each VM interface with a tag (the tag will be the name of the interface in the VNFD) and convey that information to the VM as metadata. This implementation approach is due to the warning message in https://developer.openstack.org/api-guide/compute/microversions.html where it is stated that microversion backwards compatibility is not guaranteed and clients should always require a specific microversion. This functionality was introduced would not work with Openstack versions previous to Newton.		* '''microversion''': This is an Openstack-only parameter that allows to specify a specific microversion to be used in nova. When using 'microversion: 2.32', it enables the use of Virtual Device Role Tagging, which allows to identify each VM interface with a tag (the tag will be the name of the interface in the VNFD) and convey that information to the VM as metadata. This implementation approach is due to the warning message in https://developer.openstack.org/api-guide/compute/microversions.html where it is stated that microversion backwards compatibility is not guaranteed and clients should always require a specific microversion. This functionality was introduced would not work with Openstack versions previous to Newton.

Ramonsalguer: /* Configure Openstack for OSM (EPA) */

2018-05-22T10:28:44Z

Configure Openstack for OSM (EPA)

← Older revision		Revision as of 10:28, 22 May 2018
Line 25:		Line 25:
	By default openstack apply the "default" security group that blocks any incoming traffic to the VM. However ssh access might be needed by VCA. You must modify the default security group to allow TCP port 22, or create a new security group and configure RO to use this security group when datacenter is addeed (see [[Openstack_configuration_(Release_TWO)#Add_openstack_to_OSM\|Add openstack to OSM]] )		By default openstack apply the "default" security group that blocks any incoming traffic to the VM. However ssh access might be needed by VCA. You must modify the default security group to allow TCP port 22, or create a new security group and configure RO to use this security group when datacenter is addeed (see [[Openstack_configuration_(Release_TWO)#Add_openstack_to_OSM\|Add openstack to OSM]] )

	=Configure Openstack for OSM ~~(EPA)~~=		=Configure Openstack for full EPA support in OSM =

	Besides the instructions above for any Openstack, you should do extra configuration to configure Openstack for running VNFs which use SRIOV interfaces.		Besides the instructions above for any Openstack, you should do extra configuration to configure Openstack for running VNFs which use SRIOV interfaces.

Garciadeblas: /* Add openstack to OSM */

2018-01-23T11:07:08Z

Add openstack to OSM

← Older revision		Revision as of 11:07, 23 January 2018
Line 80:		Line 80:

	* '''keypair''': To be added in addition to the keypair allocated on the VNF descriptor. Provide the name of an openstack keypair		* '''keypair''': To be added in addition to the keypair allocated on the VNF descriptor. Provide the name of an openstack keypair
	* '''dataplane_physical_net''': The ~~configured network_vlan_ranges at neutron for the~~ SRIOV ~~(binding direct)~~ and passthrough (~~binding direct-physical~~) ~~networks, e.g. 'physnet_sriov' in~~ the ~~above~~ configuration. In case of VMware Integrated Openstack (VIO) provide moref ID of distributed virtual switch		* '''dataplane_physical_net''': The physical network label used in Openstack both to identify SRIOV and passthrough interfaces (nova configuration) and also to specify the VLAN ranges used by SR-IOV interfaces (neutron configuration). In case of VMware Integrated Openstack (VIO) provide moref ID of distributed virtual switch.
	* '''use_floating_ip''': (By default false). When true a management interface of a VNFD is automatically assigned a floating_ip -if possible-. The prefered method is to use a provider network		* '''use_floating_ip''': (By default false). When true a management interface of a VNFD is automatically assigned a floating_ip -if possible-. The prefered method is to use a provider network
	* '''dataplane_net_vlan_range''': In case of VMware Integrated Openstack (VIO) provide vlan ranges for the SRIOV (binding direct) networks in format ['start_ID - end_ID']		* '''dataplane_net_vlan_range''': In case of VMware Integrated Openstack (VIO) provide vlan ranges for the SRIOV (binding direct) networks in format ['start_ID - end_ID']

Garciadeblas: /* Add openstack to OSM */

2017-12-19T09:26:01Z

Add openstack to OSM

Garciadeblas: /* Configure Openstack for OSM (EPA) */

2017-12-19T09:04:25Z

Configure Openstack for OSM (EPA)

← Older revision		Revision as of 09:04, 19 December 2017
Line 29:		Line 29:
	Besides the instructions above for any Openstack, you should do extra configuration to configure Openstack for running VNFs which use SRIOV interfaces.		Besides the instructions above for any Openstack, you should do extra configuration to configure Openstack for running VNFs which use SRIOV interfaces.

	'''DO NOT consider this as the final configuration guide for Openstack with EPA. Please check Openstack docs and Openstack downstream distros' docs to get a further understanding'''		'''DO NOT consider this as the final configuration guide for Openstack with EPA. Please check Openstack docs and Openstack downstream distros' docs to get a further understanding and the up-to-date required configuration.'''

	'''Note: The configuration shown below works with Openstack Newton, and might ~~change in the future~~.'''		'''Note: The configuration shown below works with Openstack Newton, and it might not work with later versions.'''

	* The compute nodes need to have a whitelist for the interfaces with SRIOV and passthrough enabled, and those interface need to be associated to a physical network label e.g. “physnet”. This can be done in the file /etc/nova/nova.conf :		* The compute nodes need to have a whitelist for the interfaces with SRIOV and passthrough enabled, and those interface need to be associated to a physical network label e.g. “physnet”. This can be done in the file /etc/nova/nova.conf :

Garciadeblas: /* Configure Openstack for OSM (EPA) */

2017-12-19T09:03:00Z

Configure Openstack for OSM (EPA)

← Older revision		Revision as of 09:03, 19 December 2017
Line 39:		Line 39:
	mechanism_drivers =openvswitch,sriovnicswitch		mechanism_drivers =openvswitch,sriovnicswitch

	3. The neutron controller needs to be updated to set the vlans to be used for the defined physical network label. This can be done in the file “/etc/neutron/plugins/ml2/ml2_conf.ini”. For instance, to set the vlans from 2000 to 3000:		* The neutron controller needs to be updated to set the vlans to be used for the defined physical network label. This can be done in the file “/etc/neutron/plugins/ml2/ml2_conf.ini”. For instance, to set the vlans from 2000 to 3000:
	network_vlan_ranges =physnet:2000:3000		network_vlan_ranges =physnet:2000:3000

	4. The neutron controller needs to be updated to allow the supported NIC vendor’s product ID. This can be done in the file “/etc/neutron/plugins/ml2/ml2_conf.ini” to		* The neutron controller needs to be updated to allow the supported NIC vendor’s product ID. This can be done in the file “/etc/neutron/plugins/ml2/ml2_conf.ini” to
	[ml2_sriov]		[ml2_sriov]
	supported_pci_vendor_devs = 8086:10ed		supported_pci_vendor_devs = 8086:10ed

	5. The nova controller needs to be updated to allow proper scheduling of SR-IOV and Passthrough devices, by adding the PciPassthroughFilter filter to the list of filters. This can be done in the file “/etc/nova/nova.conf”:		* The nova controller needs to be updated to allow proper scheduling of SR-IOV and Passthrough devices, by adding the PciPassthroughFilter filter to the list of filters. This can be done in the file “/etc/nova/nova.conf”:
	scheduler_available_filters=nova.scheduler.filters.all_filters		scheduler_available_filters=nova.scheduler.filters.all_filters
	scheduler_default_filters=RetryFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,CoreFilter, PciPassthroughFilter		scheduler_default_filters=RetryFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,CoreFilter, PciPassthroughFilter

Garciadeblas: /* Configure openstack for OSM (EPA) */

2017-12-19T09:02:36Z

Configure openstack for OSM (EPA)

← Older revision		Revision as of 09:02, 19 December 2017
Line 25:		Line 25:
	By default openstack apply the "default" security group that blocks any incoming traffic to the VM. However ssh access might be needed by VCA. You must modify the default security group to allow TCP port 22, or create a new security group and configure RO to use this security group when datacenter is addeed (see [[Openstack_configuration_(Release_TWO)#Add_openstack_to_OSM\|Add openstack to OSM]] )		By default openstack apply the "default" security group that blocks any incoming traffic to the VM. However ssh access might be needed by VCA. You must modify the default security group to allow TCP port 22, or create a new security group and configure RO to use this security group when datacenter is addeed (see [[Openstack_configuration_(Release_TWO)#Add_openstack_to_OSM\|Add openstack to OSM]] )

	=Configure ~~openstack~~ for OSM (EPA)=		=Configure Openstack for OSM (EPA)=

	Besides the instructions above for any Openstack, you should do extra configuration to configure ~~openstack~~ for running VNFs which use SRIOV interfaces.		Besides the instructions above for any Openstack, you should do extra configuration to configure Openstack for running VNFs which use SRIOV interfaces.

	'''1. ~~Provide~~ a ~~mechanism to connect the SR-IOV interfaces~~'''. As they are physical ports connected to an external switch, Neutron will not be able to connect them. You can use a physical switch programmed to interconnect the vlan tags among them (not recommened for security reasons). Another solution is to use a ML2 plugin that programs the external switch.		'''DO NOT consider this as the final configuration guide for Openstack with EPA. Please check Openstack docs and Openstack downstream distros' docs to get a further understanding'''

	'''2. ~~Configure the Neutron controller for using SR-IOV ports~~'''		'''Note: The configuration shown below works with Openstack Newton, and might change in the future.'''
	~~<p>Edit /etc/neutron/plugins/ml2/ml2_conf.ini with the tag and vlan ranges used by the dataplane network</p>~~

	[~~ml2_type_vlan]~~		* The compute nodes need to have a whitelist for the interfaces with SRIOV and passthrough enabled, and those interface need to be associated to a physical network label e.g. “physnet”. This can be done in the file /etc/nova/nova.conf :
	~~network_vlan_ranges = physnet_sriov~~:~~3000~~:~~3100~~		pci_passthrough_whitelist=[{"devname": "p3p1", "physical_network": "physnet"}, {"devname": "p3p2", "physical_network": "physnet"}]

	~~'''3~~. ~~Configure~~ the ~~compute nodes for using SR-IOV'''~~		* The neutron controller needs to be updated to add “sriovnicswitch” to the mechanism_drivers. This can be done in the file “/etc/neutron/plugins/ml2/ml2_conf.ini”
			mechanism_drivers =openvswitch,sriovnicswitch

	~~On each compute node you have~~ to ~~associate~~ the ~~VFs available~~ to ~~each~~ physical network. ~~That is performed by configuring pci_passthrough_whitelist~~ in /etc/~~nova~~/~~nova~~.~~conf~~. So, ~~for example~~:		3. The neutron controller needs to be updated to set the vlans to be used for the defined physical network label. This can be done in the file “/etc/neutron/plugins/ml2/ml2_conf.ini”. For instance, to set the vlans from 2000 to 3000:
			network_vlan_ranges =physnet:2000:3000

	~~pci_passthrough_whitelist~~ = ~~{"vendor_id"~~:~~"8086"~~, ~~"product_id"~~:~~"10ed"~~,~~"physical_network"~~:~~"physnet_sriov"}~~		4. The neutron controller needs to be updated to allow the supported NIC vendor’s product ID. This can be done in the file “/etc/neutron/plugins/ml2/ml2_conf.ini” to
			[ml2_sriov]
			supported_pci_vendor_devs = 8086:10ed

			5. The nova controller needs to be updated to allow proper scheduling of SR-IOV and Passthrough devices, by adding the PciPassthroughFilter filter to the list of filters. This can be done in the file “/etc/nova/nova.conf”:
			scheduler_available_filters=nova.scheduler.filters.all_filters
			scheduler_default_filters=RetryFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,CoreFilter, PciPassthroughFilter

			The previous configuration has been collected from the links below. Please check them to get more details:
			* https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html-single/network_functions_virtualization_product_guide/
			* https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html-single/network_functions_virtualization_planning_guide/
			* https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html-single/network_functions_virtualization_configuration_guide/
			* https://docs.openstack.org/newton/networking-guide/config-sriov.html

	=Add openstack to OSM=		=Add openstack to OSM=

Tierno: /* Add openstack to OSM */

2017-12-19T08:46:53Z

Add openstack to OSM

← Older revision		Revision as of 08:46, 19 December 2017
Line 55:		Line 55:
	* '''use_existing_flavors''': (By default false). Set to "True" to use the closer flavor with enough resources instead of creating a new flavor with the exact requirements. This option does not work for EPA (cpu pinning, huge pages, ...) where openmano still tries to create a flavor with the needed extra expects. Use this options when you do not have admin credentials (Available from future v2.0.2 version)		* '''use_existing_flavors''': (By default false). Set to "True" to use the closer flavor with enough resources instead of creating a new flavor with the exact requirements. This option does not work for EPA (cpu pinning, huge pages, ...) where openmano still tries to create a flavor with the needed extra expects. Use this options when you do not have admin credentials (Available from future v2.0.2 version)
	* '''vim_type''': Set to "VIO" to use VMware Integrated openstack as VIM		* '''vim_type''': Set to "VIO" to use VMware Integrated openstack as VIM
			* '''use_internal_endpoint''': Set to True to force using internal endpoints
	For openstack API v3. (It is needed to provide domain variables)		For openstack API v3. (It is needed to provide domain variables)

Garciadeblas: /* Configure openstack for OSM (basic) */

2017-12-12T15:53:45Z

Configure openstack for OSM (basic)

← Older revision		Revision as of 15:53, 12 December 2017
Line 23:		Line 23:
	'''5. Modify default security group or create a new one'''		'''5. Modify default security group or create a new one'''

	By default openstack apply the "default" security group that blocks any incoming traffic to the VM. However ssh access is needed by VCA. You must modify the default security group to allow TCP port 22 or; create a new security group and configure RO to use this security group when datacenter is addeed (see [[Openstack_configuration_(Release_TWO)#Add_openstack_to_OSM\|Add openstack to OSM]] )		By default openstack apply the "default" security group that blocks any incoming traffic to the VM. However ssh access might be needed by VCA. You must modify the default security group to allow TCP port 22, or create a new security group and configure RO to use this security group when datacenter is addeed (see [[Openstack_configuration_(Release_TWO)#Add_openstack_to_OSM\|Add openstack to OSM]] )

	=Configure openstack for OSM (EPA)=		=Configure openstack for OSM (EPA)=

Tierno: /* Add openstack to OSM */

2017-10-26T11:14:37Z

Add openstack to OSM

← Older revision		Revision as of 11:14, 26 October 2017
Line 54:		Line 54:
	* '''insecure''': (By default false). When true it allows authorization over a non trusted certificate over https		* '''insecure''': (By default false). When true it allows authorization over a non trusted certificate over https
	* '''use_existing_flavors''': (By default false). Set to "True" to use the closer flavor with enough resources instead of creating a new flavor with the exact requirements. This option does not work for EPA (cpu pinning, huge pages, ...) where openmano still tries to create a flavor with the needed extra expects. Use this options when you do not have admin credentials (Available from future v2.0.2 version)		* '''use_existing_flavors''': (By default false). Set to "True" to use the closer flavor with enough resources instead of creating a new flavor with the exact requirements. This option does not work for EPA (cpu pinning, huge pages, ...) where openmano still tries to create a flavor with the needed extra expects. Use this options when you do not have admin credentials (Available from future v2.0.2 version)
	* '''APIversion''': (By default v2.0). Set to "v3.3" to use this openstack API version (experimental)
	* '''vim_type''': Set to "VIO" to use VMware Integrated openstack as VIM		* '''vim_type''': Set to "VIO" to use VMware Integrated openstack as VIM
	* '''~~use_internal_endpoint~~''': ~~When true~~ it ~~allows~~ use of ~~private API endpoints~~
			For openstack API v3. (It is needed to provide domain variables)

			* '''APIversion''': (By default it used v3 if the keystone auth-url ends with "v3"). Set to "v3.3" or "3" to use this openstack API version
			* '''project_domain_id''', '''project_domain_name''': If non of them are provided "default" is used for project_domain_id
			* '''user_domain_id''', '''user_domain_name''': If non of them are provided "default" is used for user_domain_id


	ADVANCED configuration:		ADVANCED configuration:

← Older revision		Revision as of 09:26, 19 December 2017
Line 58:		Line 58:
	=Add openstack to OSM=		=Add openstack to OSM=

	There is a parameter called '''--config''' used to supply general configuration options ~~both at datacenter creation and datacenter attachment to openmano tenant (the latter prevails)~~. This paremeter can be used when creating the datacenter using the OSM ~~cli~~ or adding the datacenter directly to the RO.		There is a parameter called '''--config''' used to supply general configuration options. This paremeter can be used when creating the datacenter using the OSM client or when adding the datacenter directly to the RO (both at datacenter creation and datacenter attachment to openmano tenant -the latter prevails-).

	The following configuration can be added:		The following configuration can be added:

	* '''security_groups''': To be used for the deployment		* '''security_groups''': To be used for the deployment
	* '''availability_zone''': To be used for the deployment		* '''availability_zone''': To be used for the deployment. It can be:
			** a single availability zone (all deployments will land in that zone), e.g. 'availability_zone: controller'
			** several availability zones, which enables affinity and anti-affinity deployments, e.g. 'availability_zone: [zone1, zone2]'
	* '''region_name''': The region where the VM must be deployed.		* '''region_name''': The region where the VM must be deployed.
	* '''insecure''': (By default false). When true it allows authorization over a non trusted certificate over https		* '''insecure''': (By default false). When true it allows authorization over a non trusted certificate over https
Line 74:		Line 76:
	* '''project_domain_id''', '''project_domain_name''': If non of them are provided "default" is used for project_domain_id		* '''project_domain_id''', '''project_domain_name''': If non of them are provided "default" is used for project_domain_id
	* '''user_domain_id''', '''user_domain_name''': If non of them are provided "default" is used for user_domain_id		* '''user_domain_id''', '''user_domain_name''': If non of them are provided "default" is used for user_domain_id


	ADVANCED configuration:		ADVANCED configuration:

	* '''keypair''': To be added in addition to the keypair allocated on the VNF descriptor. Provide the name of a openstack keypair		* '''keypair''': To be added in addition to the keypair allocated on the VNF descriptor. Provide the name of an openstack keypair
	* '''dataplane_physical_net''': The configured network_vlan_ranges at neutron for the SRIOV (binding direct) and passthrough (binding direct-physical) networks, e.g. 'physnet_sriov' in the above configuration. In case of VMware Integrated Openstack (VIO) provide moref ID of distributed virtual switch		* '''dataplane_physical_net''': The configured network_vlan_ranges at neutron for the SRIOV (binding direct) and passthrough (binding direct-physical) networks, e.g. 'physnet_sriov' in the above configuration. In case of VMware Integrated Openstack (VIO) provide moref ID of distributed virtual switch
	* '''use_floating_ip''': (By default false). When true a management interface of a VNFD is automatically assigned a floating_ip -if possible-. The prefered method is to use a provider network		* '''use_floating_ip''': (By default false). When true a management interface of a VNFD is automatically assigned a floating_ip -if possible-. The prefered method is to use a provider network
	* '''dataplane_net_vlan_range''': In case of VMware Integrated Openstack (VIO) provide vlan ranges for the SRIOV (binding direct) networks in format ['start_ID - end_ID']		* '''dataplane_net_vlan_range''': In case of VMware Integrated Openstack (VIO) provide vlan ranges for the SRIOV (binding direct) networks in format ['start_ID - end_ID']
			* '''microversion''': This is an Openstack-only parameter that allows to specify a specific microversion to be used in nova. When using 'microversion: 2.32', it enables the use of Virtual Device Role Tagging, which allows to identify each VM interface with a tag (the tag will be the name of the interface in the VNFD) and convey that information to the VM as metadata. This implementation approach is due to the warning message in https://developer.openstack.org/api-guide/compute/microversions.html where it is stated that microversion backwards compatibility is not guaranteed and clients should always require a specific microversion. This functionality was introduced would not work with Openstack versions previous to Newton.

	The content of config is a yaml format text. The recomendation is to use a comma separated list between curly brackets {} and quotes, ~~e.g.~~:		The content of config is a yaml format text. The recomendation is to use a comma separated list between curly brackets {} and quotes. For instance, the following config is used to add a VMware Integrated Openstack where floating IP addresses will be assigned to VNF mgmt interfaces, all deployments must land in the availability_zone "controller", and the vlan ranges for the SRIOV networks will be 1-5 and 7-10:
	--config='{use_floating_ip: True, availability_zone: ~~controller~~, dataplane_net_vlan_range: ["1-5" , "7-10"]}}'		--config='{use_floating_ip: True, availability_zone: zone1, dataplane_net_vlan_range: ["1-5" , "7-10"]}}'

	==Using the ~~osm cli~~==		==Using the OSM client==
	osm vim-create --name openstack-site --user admin --password userpwd --auth_url http://10.10.10.11:5000/v2.0 --tenant admin --account_type openstack --config='{security_groups: default, keypair: mykey}'		osm vim-create --name openstack-site --user admin --password userpwd --auth_url http://10.10.10.11:5000/v2.0 --tenant admin --account_type openstack --config='{security_groups: default, keypair: mykey}'