Difference between revisions of "HOWTO15 How to configure the Federated Cloud BDII"
Line 40: | Line 40: | ||
= Generate the cloud information = | = Generate the cloud information = | ||
Cloud information can be generated using the following Python script ([https://raw.githubusercontent.com/EGI-FCTF/BDIIscripts/master/old/cloud-info-provider-site-entry-glue2 (cloud-info-provider-site-entry-glue2 | Cloud information can be generated using the following Python script ([https://raw.githubusercontent.com/EGI-FCTF/BDIIscripts/master/old/cloud-info-provider-site-entry-glue2 (cloud-info-provider-site-entry-glue2) Download here]) | ||
The script must be edited with your site and cloud services information before its execution, as described in the following tables. To run the script, just execute: | The script must be edited with your site and cloud services information before its execution, as described in the following tables. To run the script, just execute: | ||
$ chmod +x cloud-info-provider-site-entry-glue2 | $ chmod +x cloud-info-provider-site-entry-glue2 | ||
$ ./cloud-info-provider-site-entry-glue2 | $ ./cloud-info-provider-site-entry-glue2 > cloud-ldif.ldif | ||
===General interface information=== | ===General interface information=== |
Revision as of 10:08, 10 June 2014
Purpose
This page provides instructions on how to configure the Federated Cloud Production BDII.
Configuration guide
For sites with existing production BDII
If your site has already a production BDII (eg. for existing Grid resources), you need to add to this production BDII the cloud information. This information is in a separated dedicated three, so it will not interfere with your existing data. The production BDII at your site may be implemented using the site BDII software package released via UMD/EMI or with a bare OpenLDAP server. To add the production cloud information, you need to:
If your site has a BDII from EMI/UMD
- Be sure that your site BDII supports GLUE2.0 schema and publish all the user relevant information on GLUE2.0 . Be sure also that the GOCDB GIIS entry of your production site points to the GLUE2.0 schema, (eg:
ldap://prisma-cloud.ba.infn.it:2170/GLUE2DomainID=PRISMA-INFN-BARI,o=glue
). If that is not the case, update your BDII to GLUE2.0 and update the GIIS URL accordingly. - Download and configure the Python script in a directory of your choice, as described into the following chapter. Set the
provider['full_bdii_schema']
variable to 'false' . - Run the Python script to produce the cloud LDIF
- Delete old cloud data (if any)(eg.
ldapdelete -H ldap://full.hostname:2170 'GLUE2GroupID=cloud,GLUE2DomainID=SZTAKI,o=glue' -D 'your LDAP admin DN' -W
) - Add new cloud data (eg.
ldapadd -f cloud-ldif.ldif -H ldap://full.hostname:2170 -D 'your LDAP admin DN' -W
) - Check that the cloud data has been successfully added without errors (eg.
ldapsearch -x -H ldap://full.hostname:2170 -b 'GLUE2GroupID=cloud,GLUE2DomainID=SZTAKI,o=glue'
) - Move the cloud generation script or link it into the local BDII_PROVIDER_DIR (as default:
/var/lib/bdii/gip/provider/
. The BDII_PROVIDER_DIR folder path is set into/etc/bdii/bdii.conf
)
If you site has a bare OpenLDAP server
- Be sure that your LDAP supports GLUE2.0 schema and publish all the user relevant information on GLUE2.0 . Be sure also that the GOCDB GIIS entry of your production site points to the GLUE2.0 schema, (eg:
ldap://prisma-cloud.ba.infn.it:2170/GLUE2DomainID=PRISMA-INFN-BARI,o=glue
). If that is not the case, update your BDII to GLUE2.0 and update the GIIS URL accordingly. - Run the Python script to produce the cloud LDIF, setting the
provider['full_bdii_schema']
variable to 'false' . More information on how to run the schema is in the following chapter. - Delete old cloud data (if any)(eg.
$ ldapdelete -H ldap://full.hostname:2170 'GLUE2GroupID=cloud,GLUE2DomainID=SZTAKI,o=glue' -D 'your LDAP admin DN' -W
) - Add new cloud data (eg.
ldapadd -f cloud-ldif.ldif -H ldap://full.hostname:2170 -D 'your LDAP admin DN' -W
)
For sites without existing production BDII
If your site does not have a site BDII, you can setup a new one simply by setting up a new LDAP server. To do so:
- Install OpenLDAP packages (or any LDAP server you like) and configure it using the following configuration files:
- Configuration file for the LDAP server. (slapd.conf) Download here.
- GLUE20.schema file, containing the GLUE20 LDAP definitions. (GLUE20.schema) download here.
- Follow the Generate the cloud information section to produce the cloud LDIF, setting the
provider['full_bdii_schema']
variable to 'true' . More information on how to run the schema is in the following chapter - Delete existing LDAP database directory, as specified in the slapd.conf file (if not already empty) (eg:
rm -rf /var/db/openldap/openldap-data/
) and create a new empty one (eg:mkdir /var/db/openldap/openldap-data/; chown ldap:ldap -R /var/db/openldap/openldap-data/
) - Load the ldap data (eg:
$ slapadd -f /etc/openldap/slapd.conf -l cloud-ldif.ldif
) - Start the LDAP server (eg:
$ slapd -f /etc/openldap/slapd.conf -h ldap://full.hostname:2170 -d 0 > file-name 2>&1 &
orservice slapd start
) - 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
)
Refresh the data
Data contained in the LDAP server is static, thus refresh or update need to be performed by hand. If you need to perform major updates, you can re-generate the entire cloud schema (using the Data publish script, as reported in the chapter below) and then re-import it. To do it, you can follow again the instruction in the Configuration Guide above.
Generate the cloud information
Cloud information can be generated using the following Python script ((cloud-info-provider-site-entry-glue2) Download here)
The script must be edited with your site and cloud services information before its execution, as described in the following tables. To run the script, just execute:
$ chmod +x cloud-info-provider-site-entry-glue2 $ ./cloud-info-provider-site-entry-glue2 > cloud-ldif.ldif
General interface information
Variable name | Description | Examples |
---|---|---|
interface['IaaS_api'] | API standard for the IaaS management interface | OCCI |
interface['IaaS_api_version'] | API standard version for the IaaS management interface | 1.1 |
interface['IaaS_api_endpoint_technology'] | API endpoint technology for the IaaS management interface | REST |
interface['IaaS_api_authorization_method'] | API AAI for the IaaS management interface | X509-VOMS |
interface['STaaS_api'] | API standard for the STaaS management interface | CDMI |
interface['STaaS_api_version'] | API standard version for the STaaS management interface | 1.0.1 |
interface['STaaS_api_endpoint_technolog'] | API endpoint technology for the STaaS management interface | REST |
interface['STaaS_api_authorization_method'] | API AAI for the STaaS management interface | X509-VOMS |
General cloud site information
Variable name | Description | Examples |
---|---|---|
provider['site_name'] | This is the name of the cloud site, if it was a Grid site it would have been the GOCDB name. | Self explanatory |
provider['production_level'] | State of the site certification (production level) | production |
provider['full_bdii_schema'] | Flag for production full BDII schema (set to true, for new BDII) or only cloud resources (set to false, for existing BDII) | true |
provider['www'] | Address of the information web site of the resource provider, or the cloud service. It should contain a full URL (eg. with http:// prefix) | http://recas-pon.ba.infn.it/ |
provider['Country'] | Country where the cloud infrastructure is located (in ISO 3166-1 Alpha2 standard) | IT |
provider['site_longitude'] | The longitude of the main site location (in the XX.XXXX format) | 16.8891 |
provider['site_latitude'] | The latitude of the main site location | 41.1123 |
provider['affiliated_ngi'] | The name of the affiliated NGI | NGI_IT |
provider['user_support_contact'] | Site user support contact mail address | admin@cloudsite.org |
provider['general_contact'] | Site general contact mail address | admin@cloudsite.org |
provider['sysadmin_contact'] | Site system administration main contact mail address | admin@cloudsite.org |
provider['security_contact'] | Site security contact mail address | admin@cloudsite.org |
provider['sysadmin_contact'] | Site user support contact mail address | admin@cloudsite.org |
provider['site_bdii_host'] | Local site BDII host | site-bdii.mysite.it |
provider['site_bdii_port'] | Local site BDII port | 2170 |
provider['site_total_cpu_cores'] | The total number of CPU cores provided by the site | 300 |
provider['site_total_ram_gb'] | The total RAM provided by the site (in GB) | 600 |
provider['site_total_storage_gb'] | The total number of storage provided by the site (in GB) | 1024 |
provider['iaas_middleware'] | The name of the IaaS middleware | OpenStack Nova |
provider['iaas_middleware_version'] | The version of the IaaS middleware deployed | havana |
provider['iaas_middleware_developer'] | The developer of the IaaS middleware deployed | OpenStack |
provider['iaas_hypervisor'] | The hypervisor deployed in the IaaS middleware | KVM |
provider['iaas_hypervisor_version'] | The version of the hypervisor deployed in the IaaS middleware | 1.5.0 |
provider['iaas_capabilities'] | This variable contains a list of strings "('string1','string2','string3,..)", those strings describe the capabilities provided by the cloud IaaS service. Please note that the strings are not formalized anywhere, new labels should be agreed within the Task Force, for the moment. | ('cloud.managementSystem','cloud.vm.uploadImage') |
provider['iaas_endpoints'] | List of the endpoints to reach the IaaS service. This is a list of python dictionaries. Basically the format is "({endpoint1},{endpoint2},{endpoint3}...). the structure of the single {endpoint} bits will be described in an additional table. If no IaaS service is provided, please leave this array empty. | |
provider['os_tpl'] | List of the OS templates available in the cloud IaaS service, that is the different virtual machines images available to be instantiated by the user. It is a list of python dictionaries. Basically the format is "({os_tpl1},{os_tpl2},{os_tpl3}...). the structure of the single {os_tpl} bits will be described in an additional table. | |
provider['resource_tpl'] | List of the Resource templates (flavors) available in the cloud IaaS service, that is the different virtual machines virtual hardware resources (RAM, CPU, etc...) available to be instantiated by the user. It is a list of python dictionaries. Basically the format is "({resource_tpl1},{resource_tpl2},{resource_tpl3}...). the structure of the single {resource_tpl} bits will be described in an additional table. | |
provider['staas_middleware'] | The name of the STaaS middleware | OpenStack Swift |
provider['staas_middleware_version'] | The version of the STaaS middleware deployed | havana |
provider['staas_middleware_developer'] | The developer of the STaaS middleware deployed | OpenStack |
provider['staas_capabilities'] | This variable contains a list of strings "('string1','string2','string3,..)", those strings describe the capabilities provided by the cloud STaaS service. Please note that the strings are not formalized anywhere, new labels should be agreed within the Task Force, for the moment. | ('cloud.data.upload') |
provider['staas_endpoints'] | List of the endpoints to reach the STaaS service. This is a list of python dictionaries. Basically the format is "({endpoint1},{endpoint2},{endpoint3}...). the structure of the single {endpoint} bits will be described in an additional table. If no STaaS service is provided, please leave this array empty. |
IaaS Endpoint instance
It is a python dictionary, the format is: {'label1':'value1' , 'label2':'value2'....}.
If a cloud IaaS service provide different interfaces, such as OCCI and EC2, it should publish different endpoints with different implementation.
Label | Description | Examples |
---|---|---|
endpoint_url | The URL to reach the service endpoint, it should contain the protocol (e.g. https://) and the port, if it is not the standard port for the protocol. | https://one.cloud.gwdg.de:8443 |
endpoint_interface | The interface implemented by the endpoint. | OCCI |
service_type_name/version/developer | The scripts fills this with the 'iaas_middleware_name/version/developer' variables described above | |
interface_version | The version of the specification of the interface implemented. The script fills this with interface['IaaS_api_version'] described above. | interface['IaaS_api_version'] |
endpoint_technology | This is the architecture implemented by the web service. The script fills this with interface['IaaS_api_endpoint_technology'] described above. | interface['IaaS_api_endpoint_technology'] |
auth_method | This is the AAI implemented by the web service. The script fills this with interface['IaaS_api_authorization_method'] described above. | interface['IaaS_api_authorization_method'] |
OS_Tpl instance
If a cloud service provide a list of default virtual images that can be instantiate by the user, they should be advertised with a list of execution environment. It is a python dictionary, the format is: {'label1':'value1' , 'label2':'value2'....}.
Label | Description | Examples |
---|---|---|
image_name | name of the OS image. It should be self-explanatory and directly presentable to the user | Scientific Linux 6.4 (x86_64) |
image_version | version of the OS image. Note that this is not the version of the OS, but the version of the virtual image | 1.0 |
marketplace_id | URL of the image into the reference marketplace. For the Federated Cloud, this should point to the AppDB. To obtain this value from AppDB, go into the Virtual Machine image version page (eg. http://appdb.egi.eu/store/vm/image/2c24de6c-e385-49f1-b64f-f9ff35e70f43:9/ and copy the XML link provided by the interface) | http://appdb.egi.eu/store/vm/image/2c24de6c-e385-49f1-b64f-f9ff35e70f43:9/xml |
occi_id | OCCI ID of the image on the site. It shall contain the full mixin to be used in the OCCI create compute API call. | http://fedcloud.egi.eu/occi/infrastructure/os_tpl#ef13c0be-4de6-428f-ad5b-8f32b31a54a1 |
os_family | This is the operating system type provided in the virtual image, the currently formalized families are: linux, windows, macosx, solaris | linux |
os_name | The name of the operating system. | suse |
os_version | The version of the operating system | 6.0.4 |
platform | The processor architecture (i386,amd64,itanium, sparc, powerpc) | amd64 |
Resource_Tpl instance
If a cloud service provide a list of pre-defined virtual hardware resource templates (flavors) that can be instantiate by the user, they should be advertised with a list of resource templates. It is a python dictionary, the format is: {'label1':'value1' , 'label2':'value2'....}.
Label | Description | Examples |
---|---|---|
occi_id | OCCI ID of the resource template on the site. It shall contain the full mixin to be used in the OCCI create compute API call. | http://fedcloud.egi.eu/occi/infrastructure/resource_tpl#tiny-with-disk |
memory | The amount of RAM memory associated to the VM instance (MB) | 512 |
cpu | The number of virtual CPU associated to the VM instance | 2 |
platform | The virtual processor architecture (i386,amd64,itanium, sparc, powerpc) | amd64 |
network | The type of IP provided to the VM (public,private) | public |
STaaS Endpoint instance
It is a python dictionary, the format is: {'label1':'value1' , 'label2':'value2'....}.
If a cloud IaaS service provide different interfaces, such as CDMI and S3, it should publish different endpoints with different implementation.
Label | Description | Examples |
---|---|---|
endpoint_url | The URL to reach the service endpoint, it should contain the protocol (e.g. https://) and the port, if it is not the standard port for the protocol. | https://one.cloud.gwdg.de:8443 |
endpoint_interface | The interface implemented by the endpoint. | OCCI |
service_type_name/version/developer | The scripts fills this with the 'iaas_middleware_name/version/developer' variables described above | |
interface_version | The version of the specification of the interface implemented. The script fills this with interface['staas_api_version'] described above. | interface['staas_api_version'] |
endpoint_technology | This is the architecture implemented by the web service. The script fills this with interface['STaaS_api_endpoint_technology'] described above. | interface['STaaS_api_endpoint_technology'] |
auth_method | This is the AAI implemented by the web service. The script fills this with interface['STaaS_api_authorization_method'] described above. | interface['STaaS_api_authorization_method'] |