Difference between revisions of "HOWTO15 How to configure the Federated Cloud BDII"
Line 3: | Line 3: | ||
= Purpose = | = Purpose = | ||
This page provides instructions on how to configure the Federated Cloud Production BDII. | This page provides instructions on how to configure the Federated Cloud Production BDII. | ||
= Installation guide = | |||
== Pre-requisites == | |||
This guide has the following pre-requisites: | |||
* Site-BDII, with support to GLUE2 schema specifications. If you do not have already a site BDII installed from EMI or UMD you can follow the installation guide below | |||
* Python 2.2.x | |||
== Install Site-BDII == | |||
If you have already a production BDII (eg. for existing Grid or storage resources), you can skip this step. Otherwise, here is a quick guide on how to install and configure a site BDII: | |||
# Install UMD repository according to the instructions here: http://repository.egi.eu/category/umd_releases/distribution/umd-3/ | |||
# Install Site-BDII packages: <code>yum install bdii bdii-config-site</code> | |||
# Edit the file <code>/etc/glite-info-static/site/site.cfg</code> with your site information | |||
# Start the BDII service: <code>service bdii start; chkconfig bdii on</code> | |||
# Configure your GOCDB site information the 'GIIS URL' with the address of your site BDII and the base schema, (eg: ldap://prisma-cloud.ba.infn.it:2170/GLUE2DomainID=PRISMA-INFN-BARI,o=glue ) | |||
== Install the cloud resource provider script == | |||
For filling the BDII with the cloud resource information, you need to install the cloud resource provider script. | |||
=== For RHEL/CentOS/ScientifcLinux 6.x === | |||
#Install EPEL (follow instructions [https://fedoraproject.org/wiki/EPEL here]) | |||
#Install cloud provider script via RPM | |||
yum localinstall http://github.com/EGI-FCTF/BDIIscripts/raw/master/rpm/cloud-info-provider-service-0.2-1.el6.noarch.rpm | |||
=== For other OSes (Install from sources) === | |||
git clone http://github.com/EGI-FCTF/BDIIscripts/ | |||
cd BDIIscripts | |||
pip install -e . | |||
= Configuration guide = | = Configuration guide = | ||
== | == Configure middleware backend == | ||
The cloud provider script information is retrieved partially from a static configuration file and partially from the cloud middleware directly. Thus, the configuration depends on which middleware you have installed. | |||
=== OpenNebula === | |||
''NOTE:'' This is a pure OpenNebula installation. If you have installed OpenNebula via rOCCI, refer to the [[#OpenNebula via rOCCI|OpenNebula via rOCCI]] guide. | |||
* Copy the sample provider configuration file to the default software configuration file | |||
cp /opt/cloud-info-provider/etc/sample.opennebula.yaml /opt/cloud-info-provider/etc/bdii.yaml | |||
* Edit the <code>/opt/cloud-info-provider/etc/bdii.yaml</code> configuration, setting up the site permanent information and the OpenNebula connection information. Most of the information to be provider is self explanatory or specified in the comments. Below there is a set of notes who can be relevant during the configuration. | |||
''Configuration notes:'' | |||
* Keep always full_bdii_ldif set to False | |||
* You need to specify connection parameters to the OpenNebula XML-RPC interface. ''on_auth'' should contain the authorization parameters for an existing user with full read permissions on the image disks. If the user has been created with the ''core'' driver, this parameter shall be set to ''<username>:<password>''. ''on_rpcxml_endpoint'' shall contain the address of the RPCv2 endpoint. Usually it is ''http://myipaddress:2633/RPC2'' . If not on a secure network, it is suggested to provide this interface via https, since the on_auth parameter will be sent in clear text to the server. | |||
* ''site'' parameters can be left commented, since they will be automatically retreived from the ''/etc/glite-info-static/site/site.cfg'' configuration file | |||
* Compute templates can be ignored, since OpenNebula has no concept of resource flavours | |||
* Object storage services (STorage-as-a-service) can be set statically. As they are not provided by OpenNebula, they can be ignored or set to the ones provided by other middleware. | |||
== | === OpenNebula via rOCCI === | ||
* Copy the sample provider configuration file to the default software configuration file | |||
cp /opt/cloud-info-provider/etc/sample.opennebularocci.yaml /opt/cloud-info-provider/etc/bdii.yaml | |||
* Edit the ''/opt/cloud-info-provider/etc/bdii.yaml'' configuration, setting up the site permanent information and the OpenStack connection information. Most of the information to be provider is self explanatory or specified in the comments. Below there is a set of notes who can be relevant during the configuration. | |||
''Configuration notes:'' | |||
* Keep always full_bdii_ldif set to False | |||
* You need to specify connection parameters to the OpenStack interface. ''on_auth'' should contain the authorization parameters for an existing user with full read permissions on the image disks. If the user has been created with the ''core'' driver, this parameter shall be set to ''<username>:<password>''. ''on_rpcxml_endpoint'' shall contain the address of the RPCv2 endpoint. Usually it is ''http://myipaddress:2633/RPC2'' . If not on a secure network, it is suggested to provide this interface via https, since the on_auth parameter will be sent in clear text to the server. | |||
* ''site'' parameters can be left commented, since they will be automatically retreived from the ''/etc/glite-info-static/site/site.cfg'' configuration file | |||
* Compute templates can be gathered in two ways: directly from rOCCI configuration, by setting up the ''template_dir'' parameter to the rOCCI configuration folder or manually by placing them in the configuration file. One option does not preclude the other and the resulting templates will be the merge of the two. | |||
* Images are retrieved from the OpenNebula templates, to mimic the behavior of rOCCI. | |||
* Object storage services (STorage-as-a-service) can be set statically. As they are not provided by OpenNebula, they can be ignored or set to the ones provided by other middleware. | |||
= | === OpenStack === | ||
* Install the Nova Python SDK (needed by the OpenStack driver). You should have packages for that. In RHEL, they are provided by EPEL and you can install them via | |||
yum install -y python-novaclient | |||
* Copy the sample provider configuration file to the default software configuration file | |||
cp /opt/cloud-info-provider/etc/sample.openstack.yaml /opt/cloud-info-provider/etc/bdii.yaml | |||
* Edit the <code>/opt/cloud-info-provider/etc/bdii.yaml</code> configuration, setting up the site permanent information and the OpenStack connection information. Most of the information to be provider is self explanatory or specified in the file comments. Below there is a set of notes who can be relevant during the configuration. | |||
''Configuration notes:'' | |||
* Keep always full_bdii_ldif set to False | |||
* You need to specify connection parameters to the OpenStack Auth service (Keystone). OpenStack will then get the API endpoints from Keystone. | |||
* Be sure that keystone contains the OCCI endpoint, otherwise it will not be published by the BDII. You can check this via the command <code>keystone service-list</code>. To create a new service and endpoint, you can run <code>keystone service-create --name nova --type occi --description 'Nova OCCI Service'</code> and then <code>keystone endpoint-create --service_id 8e6de5d0d7624584bed6bec9bef7c9e0 --region RegionOne --publicurl http://$HOSTNAME:8787/ --internalurl http://$HOSTNAME:8787/ --adminurl http://$HOSTNAME:8787/</code> where the ''service_id'' is the one obtained from <code>keystone service-list</code> | |||
* In production environments, it is recommended to set the ''insecure'' parameter in the options to ''False'' and uncomment the ''os_cacert'' | |||
* ''site'' parameters can be left commented, since they will be automatically retreived from the ''/etc/glite-info-static/site/site.cfg'' configuration file | |||
=== Other === | |||
For all the other middleware, you can setup all the middleware information statically. To do so: | |||
* Copy the sample provider configuration file to the default software configuration file | |||
cp /opt/cloud-info-provider/etc/sample.static.yaml /opt/cloud-info-provider/etc/bdii.yaml | |||
* Edit the <code>/opt/cloud-info-provider/etc/bdii.yaml</code> configuration, setting up all the site compute and storage resource information. Most of the information to be provider is self explanatory or specified in the comments. Below there is a set of notes who can be relevant during the configuration. | |||
''Configuration notes:'' | |||
* Keep always full_bdii_ldif set to False | |||
* ''site'' parameters can be left commented, since they will be automatically retreived from the ''/etc/glite-info-static/site/site.cfg'' configuration file | |||
== Test configuration == | |||
Run manually the cloud-provider script and check that the output is correctly imported into the BDII. To do so, execute | |||
/usr/bin/cloud-info-provider-service > cloud-ldif.ldif | |||
Then open the cloud-ldif.ldif fiel and check that no error is present. Then, import the data into the LDAP via | |||
=== | ldapdelete -H ldap://full.hostname:2170 'GLUE2GroupID=cloud,GLUE2DomainID=<your site>,o=glue' -D 'your LDAP admin DN' -W | ||
ldapadd -f cloud-ldif.ldif -H ldap://full.hostname:2170 -D 'your LDAP admin DN' -W | |||
and check that the cloud data has been successfully added via | |||
ldapsearch -x -H ldap://full.hostname:2170 -b 'GLUE2GroupID=cloud,GLUE2DomainID=<your site>,o=glue' | |||
== Enable provider == | |||
To enable the provider, just link the executable to the BDII provider directory (as default: <code>/var/lib/bdii/gip/provider/</code> or the BDII_PROVIDER_DIR path set into <code>/etc/bdii/bdii.conf</code>) | |||
ln -fs /usr/bin/cloud-info-provider-service /var/lib/bdii/gip/provider/ | |||
Revision as of 18:34, 21 July 2014
Purpose
This page provides instructions on how to configure the Federated Cloud Production BDII.
Installation guide
Pre-requisites
This guide has the following pre-requisites:
- Site-BDII, with support to GLUE2 schema specifications. If you do not have already a site BDII installed from EMI or UMD you can follow the installation guide below
- Python 2.2.x
Install Site-BDII
If you have already a production BDII (eg. for existing Grid or storage resources), you can skip this step. Otherwise, here is a quick guide on how to install and configure a site BDII:
- Install UMD repository according to the instructions here: http://repository.egi.eu/category/umd_releases/distribution/umd-3/
- Install Site-BDII packages:
yum install bdii bdii-config-site
- Edit the file
/etc/glite-info-static/site/site.cfg
with your site information - Start the BDII service:
service bdii start; chkconfig bdii on
- Configure your GOCDB site information the 'GIIS URL' with the address of your site BDII and the base schema, (eg: ldap://prisma-cloud.ba.infn.it:2170/GLUE2DomainID=PRISMA-INFN-BARI,o=glue )
Install the cloud resource provider script
For filling the BDII with the cloud resource information, you need to install the cloud resource provider script.
For RHEL/CentOS/ScientifcLinux 6.x
- Install EPEL (follow instructions here)
- Install cloud provider script via RPM
yum localinstall http://github.com/EGI-FCTF/BDIIscripts/raw/master/rpm/cloud-info-provider-service-0.2-1.el6.noarch.rpm
For other OSes (Install from sources)
git clone http://github.com/EGI-FCTF/BDIIscripts/ cd BDIIscripts pip install -e .
Configuration guide
Configure middleware backend
The cloud provider script information is retrieved partially from a static configuration file and partially from the cloud middleware directly. Thus, the configuration depends on which middleware you have installed.
OpenNebula
NOTE: This is a pure OpenNebula installation. If you have installed OpenNebula via rOCCI, refer to the OpenNebula via rOCCI guide.
- Copy the sample provider configuration file to the default software configuration file
cp /opt/cloud-info-provider/etc/sample.opennebula.yaml /opt/cloud-info-provider/etc/bdii.yaml
- Edit the
/opt/cloud-info-provider/etc/bdii.yaml
configuration, setting up the site permanent information and the OpenNebula connection information. Most of the information to be provider is self explanatory or specified in the comments. Below there is a set of notes who can be relevant during the configuration.
Configuration notes:
- Keep always full_bdii_ldif set to False
- You need to specify connection parameters to the OpenNebula XML-RPC interface. on_auth should contain the authorization parameters for an existing user with full read permissions on the image disks. If the user has been created with the core driver, this parameter shall be set to <username>:<password>. on_rpcxml_endpoint shall contain the address of the RPCv2 endpoint. Usually it is http://myipaddress:2633/RPC2 . If not on a secure network, it is suggested to provide this interface via https, since the on_auth parameter will be sent in clear text to the server.
- site parameters can be left commented, since they will be automatically retreived from the /etc/glite-info-static/site/site.cfg configuration file
- Compute templates can be ignored, since OpenNebula has no concept of resource flavours
- Object storage services (STorage-as-a-service) can be set statically. As they are not provided by OpenNebula, they can be ignored or set to the ones provided by other middleware.
OpenNebula via rOCCI
- Copy the sample provider configuration file to the default software configuration file
cp /opt/cloud-info-provider/etc/sample.opennebularocci.yaml /opt/cloud-info-provider/etc/bdii.yaml
- Edit the /opt/cloud-info-provider/etc/bdii.yaml configuration, setting up the site permanent information and the OpenStack connection information. Most of the information to be provider is self explanatory or specified in the comments. Below there is a set of notes who can be relevant during the configuration.
Configuration notes:
- Keep always full_bdii_ldif set to False
- You need to specify connection parameters to the OpenStack interface. on_auth should contain the authorization parameters for an existing user with full read permissions on the image disks. If the user has been created with the core driver, this parameter shall be set to <username>:<password>. on_rpcxml_endpoint shall contain the address of the RPCv2 endpoint. Usually it is http://myipaddress:2633/RPC2 . If not on a secure network, it is suggested to provide this interface via https, since the on_auth parameter will be sent in clear text to the server.
- site parameters can be left commented, since they will be automatically retreived from the /etc/glite-info-static/site/site.cfg configuration file
- Compute templates can be gathered in two ways: directly from rOCCI configuration, by setting up the template_dir parameter to the rOCCI configuration folder or manually by placing them in the configuration file. One option does not preclude the other and the resulting templates will be the merge of the two.
- Images are retrieved from the OpenNebula templates, to mimic the behavior of rOCCI.
- Object storage services (STorage-as-a-service) can be set statically. As they are not provided by OpenNebula, they can be ignored or set to the ones provided by other middleware.
OpenStack
- Install the Nova Python SDK (needed by the OpenStack driver). You should have packages for that. In RHEL, they are provided by EPEL and you can install them via
yum install -y python-novaclient
- Copy the sample provider configuration file to the default software configuration file
cp /opt/cloud-info-provider/etc/sample.openstack.yaml /opt/cloud-info-provider/etc/bdii.yaml
- Edit the
/opt/cloud-info-provider/etc/bdii.yaml
configuration, setting up the site permanent information and the OpenStack connection information. Most of the information to be provider is self explanatory or specified in the file comments. Below there is a set of notes who can be relevant during the configuration.
Configuration notes:
- Keep always full_bdii_ldif set to False
- You need to specify connection parameters to the OpenStack Auth service (Keystone). OpenStack will then get the API endpoints from Keystone.
- Be sure that keystone contains the OCCI endpoint, otherwise it will not be published by the BDII. You can check this via the command
keystone service-list
. To create a new service and endpoint, you can runkeystone service-create --name nova --type occi --description 'Nova OCCI Service'
and thenkeystone endpoint-create --service_id 8e6de5d0d7624584bed6bec9bef7c9e0 --region RegionOne --publicurl http://$HOSTNAME:8787/ --internalurl http://$HOSTNAME:8787/ --adminurl http://$HOSTNAME:8787/
where the service_id is the one obtained fromkeystone service-list
- In production environments, it is recommended to set the insecure parameter in the options to False and uncomment the os_cacert
- site parameters can be left commented, since they will be automatically retreived from the /etc/glite-info-static/site/site.cfg configuration file
Other
For all the other middleware, you can setup all the middleware information statically. To do so:
- Copy the sample provider configuration file to the default software configuration file
cp /opt/cloud-info-provider/etc/sample.static.yaml /opt/cloud-info-provider/etc/bdii.yaml
- Edit the
/opt/cloud-info-provider/etc/bdii.yaml
configuration, setting up all the site compute and storage resource information. Most of the information to be provider is self explanatory or specified in the comments. Below there is a set of notes who can be relevant during the configuration.
Configuration notes:
- Keep always full_bdii_ldif set to False
- site parameters can be left commented, since they will be automatically retreived from the /etc/glite-info-static/site/site.cfg configuration file
Test configuration
Run manually the cloud-provider script and check that the output is correctly imported into the BDII. To do so, execute
/usr/bin/cloud-info-provider-service > cloud-ldif.ldif
Then open the cloud-ldif.ldif fiel and check that no error is present. Then, import the data into the LDAP via
ldapdelete -H ldap://full.hostname:2170 'GLUE2GroupID=cloud,GLUE2DomainID=<your site>,o=glue' -D 'your LDAP admin DN' -W ldapadd -f cloud-ldif.ldif -H ldap://full.hostname:2170 -D 'your LDAP admin DN' -W
and check that the cloud data has been successfully added via
ldapsearch -x -H ldap://full.hostname:2170 -b 'GLUE2GroupID=cloud,GLUE2DomainID=<your site>,o=glue'
Enable provider
To enable the provider, just link the executable to the BDII provider directory (as default: /var/lib/bdii/gip/provider/
or the BDII_PROVIDER_DIR path set into /etc/bdii/bdii.conf
)
ln -fs /usr/bin/cloud-info-provider-service /var/lib/bdii/gip/provider/