After an OpenStack installation, has been successfully created, it shall be configured in order to be used. Although there are many tutorials online presenting these steps, we have collected the steps that are needed in order to connect an OpenStack of a public organization on STRATEGIC Service Store.

Creating Users and Projects

At first, appropriate users and projects should be created. A project is created by the Admin menu of OpenStack, as shown in Figure below.

image015

Figure : Create a new project

If users exist already they can be added directly to the project and if a new user is created, the main project of the user can be assigned. The newly added users can use their credentials in order to authenticate though the STRATEGIC Service Store.

  Creating OpenStack Flavors

On OpenStack IaaS, these templates are called flavors[1] and the specific flavors reflecting the needs of a specific organization can be created. These flavors will be available in the STRATEGIC Service Store as option for the deployment of the service.

 Creating OpenStack networks

In order to deploy an application on OpenStack the creation of appropriate networks is needed. The networks can be internal or external and for privacy issues a network should be assigned to a single project. After their creation, networks of the project/tenant are displayed along with their status  .

 Verification of OpenStack API endpoints

When installing OpenStack, it should be noted that the API endpoints should be exposed to STRATEGIC Service Store. OpenStack installer (FUEL) usually deploys both public and internal API endpoints within the system – as demonstrated below.

STRATEGIC Service Store should be seeing a localized IP (in the network of STRATEGIC Service Store) for the primary API. However, since the primary API provides the IP addresses of the other APIs the API endpoint should be accessible with domain URL. Even a private DNS name is possible to be used.

  Integration Points

In order for the STRATEGIC Service Store to be integrated on behalf of a user, all the API endpoints presented above should be accessible.

Also, there are different ports for different OpenStack components. In order support the particular functionalities offered by each component, remote OpenStack site need to open the ports presented in the following table:

OpenStack service Default ports Port type
Block Storage(cinder) 8776
Compute(nova) endpoints 8774
Compute API(nova-api) 8773,8775
Compute ports for access to virtual machine consoles 5900-5999
Compute VNC proxy for browsers( OpenStack-nova-novncproxy) 6080
Compute VNC proxy for traditional VNC clients (OpenStack-nova-xvpvncproxy) 6081
Proxy port for HTML5 console used by Compute service 6082
Identity service (keystone) administrative endpoint 355357 adminurl
identity service public endpoint 5000 publicurl
Image Service (glance) API 9292 publicurl and adminurl
Image Service registry 9191
Networking(neutron) 9696 publicUrl and adminurl
Object Storage(swift) 6001-6002
Orchestration(heat)endpoint 8004 publicurl and admin url
Orchestration AWS CloudFormation-compatible API (OpenStack-heat-api-cfn) 8000
Orchestration(heat)endpoint 8004 publicurl and admin url
Orchestration(heat)endpoint 8004 publicurl and admin url

Table: OpenStack services and default ports

 

[1] http://docs.openstack.org/openstack-ops/content/flavors.html