Configuring FIWARE Lab Node

This section provides details about how to make the proper changes in the configuration of your node in order to join FIWARE Lab. Those changes are basically related to the proper configuration of flavours and quotas and more important, related to the common way to define the available networks in a FIWARE Lab node.

Configure Flavors and Quotas

The default flavors should be:

ID Name Memory (MB) Disk (Gb) Ephemeral Swap vCPUs RXTX Factor Public
1 m1.tiny 512 1 0 1 1.0 True
2 m1.small 2048 20 0 1 1.0 True
3 m1.medium 4096 40 0 2 1.0 True
4 m1.large 8192 80 0 4 1.0 True

For the nova service, the default quotas values that should be defined are the following:

Default defined quotas

Quota Limit
Instances 2
Cores 4
RAM 4096
Floating IPs 1
Fixed IPs -1
Metadata Items 1024
Injected files 5
Injected file content (bytes) 20240
Injected file path (bytes) 255
Key pairs 10
Security Groups 10
Security Group Rules 20

The neutron default quotas should be:

Default defined neutron quotas

Field Value
Floating IP 1
Network 5
Port 20
Router 1
Security Group -1
Security Group Rule -1
Subnet 5

Configure OpenStack Networks

FIWARE Lab has defined a predefined name of networks to be used by all the nodes. It helps to the different services deployed on top of OpenStack to work with the correct network without any special configuration on it.

  • public-ext-net-01. This is the Public External network, a non-shared network providing a floating IP pool (i.e. subnet) that provides public, routable IPv4 addresses. Additionally, nodes can configure IPv6 dual-stack on this network in order to provide IPv6 addresses. This network is not visible to attach directly OpenStack Instances on it. It is only visible to allocate public IPs to be used by tenants.

  • node-int-net-01. A shared tenant network providing DHCP IPv4 (and IPv6 in the future) addresses. This network is visible for all tenants and therefore anyone can attach OpenStack instances on it. Any node could choose its own network range since this should not collide with other node’s networks.

There is no limitation in the use of networks and every node can configure additional networks in its OpenStack configuration. If we test this information with the CLI tool we obtain the following result if we execute the following command:

$ neutron net-list

Or using the more recent version of the CLI, the following command:

$ openstack network list

The output of networks and subnets should be:

Example returned values of: openstack network list

Id Name subnets
3dccc622-7200-40be-b523-0f73674db0e7 public-ext-net-01 44c356e1-53ad-43ce-b3b7-816bbd1d9529 130.206.82.0/22
b99da016-cb02-4556-8d5f-2ce27a9a861d node-int-net-01 a250c7a4-4d23-4c9a-85be-3e9b367a00a1 172.16.0.0/20

And if we check the sub-network that we have associated to this network, through the following commands

$ neutron subnet-list

or

$ openstack subnet list

we will see something like this for the second network:

Example returned values of: openstack subnet list

Id Name CIDR Allocation pools
a250c7a4-4d23-4c9a-85be-3e9b367a00a1 node-int-subnet-01 172.16.0.0/20 {"start": "172.16.0.2", "end": "172.16.15.254"}