Reference: onestack script
This article provides a summary of openstack learning in the last month, including the problem record during installation and deployment in a standalone environment and the source code learning process. It is suitable for beginners.
I. openstack installation and deployment
Currently, the official installation and deployment documents and the onestack script in Chinese are displayed.
According to the two documents, you can build an environment in the Ubuntu environment of the virtual machine, and some problems may occur in the middle. You can find and solve them.
Because onestack is Chinese, every sentence in the script has a detailed description, it will be much easier to learn.
You can directly change the IP address in the script to the IP address of your machine, and run the script to work normally.
/Etc/Network/interfaces can be changed or not, depending on the specific situation, for example, the virtual machine uses DHCP to automatically assign an IP address, it will change to an IP address after a certain period of time to access the network, anyway, as long as the IP address corresponds to the configuration, OK.
Generally, virtual machines cannot support KVM, so remember to change the cmd_type to qemu.
If you do not know the cause of the failure, you can manually install the module one by one based on the script to find the cause.
For example, if the installation starts from keystone and the test is complete, install glance, Nova, and dashbord in sequence.
If you build a source code debugging environment, you can use git clone or apt-Get source to obtain the source code. The ide I use is eclipse + pdev. I used to use eclipse.
You can use Pip install for source code installation.
If there are still problems that have not been solved, you can refer to the following, maybe it is a problem I have encountered.
1. compute and other services are blocked, causing failure to properly start the NOVA-compute service and then blocking the connection to libmongod. If the command virsh list is blocked, run the command killall-9 dmidecode and restart the NOVA-compute.
2. debug the eventlet when you start the NOVA-* service. change monkey_patch () to eventlet. monkey_patch (all = false, socket = true, select = true). Otherwise, an error occurs during thread switching.
3. It is blocked when the network service is started. If iptables is obtained in the log, files in lock/NOVA are deleted and restarted.
4. if the Volume XXX (for example, Nova-volumes) does not exist when the NOVA-volumes service is started, create a new partition and create a volume group named pvcreate/dev/sda6can't open/dev/sda6 exclusively. mounted filesystem? The above error occurs because the partition file is in use and umount is required. Pvcreate/dev/sda6physical volume "/dev/sda6" successfully created after creating a physical volume, you can run the "pvdisplay" command to view the physical volume information pvdisplay --- new physical volume --- PV name/dev/sda6vg namepv size 1.06 gballocatable Nope size (Kbyte) 0 total pe 0 free pe 0 allocated PE 0pv UUID N2LgeT-RB4Y-8YEP-lO2J-tDWu-UeCT-4Obl8p if you need to mount the volume at startup, modify/etc/fstab and add a row of the volume according to the rules
Create a logical volume group vgcreate Nova-volumes/dev/sda6
If you still have some questions, remember them first. If you have any questions, add them. Below is a brief introduction to the source code of several modules.
Ii. Read Source Code
Keystone, glance, and Nova have very similar structures. They use the wsgi protocol, webob, paste, and routes frameworks. People like me who have never touched Python before may have never touched these things, first, you can get a general idea of these frameworks, and then look at the source code to get a general idea of what is going on.
Let's talk about the keystone process first.Below is a record when I first learned it. I posted it directly. There may be errors. If you have any questions, please point out. Thank you.
When starting the keystone service, you need to find and parse the keystone. conf configuration file and parse the logging log configuration through the logging. conf configured in Keystone. conf.
Deploy. appconfig parses deploy. loadapp in create_server of the main section in paste. Deploy configuration. Load app context is the same as appconfig at the beginning. Then, use the Create method to parse the components of the paste configuration and perform initialization. Use = egg: paste # urlmap first gets the parsing execution, enters paste. urlmap # urlmap_factory, and passes in the config map obtained by loadcontext as the parameter. Here, urlmap will correspond to the app through the configured URI. For example, if it is the/2.0 Path in Composite: Admin, it will continue to find a pipeline: admin_api in each section pre. Find the configuration of the last application in pipeline and put it in context. app_context. Here is admin_service. The protocol of admin_service is paste. app_factory, And the execution method is keystone. Service: admin_app_factory. Find all filters in the same way and put them into context. filter_contexts. Then, use this pipeline context to call the create method. In pipeline, create app context is used first and then create filter context in sequence. (From here we will return to the keystone module from the deploy module) Create app context and execute admin_app_factory. Parsing directory template: catalog. regionone. identity. publicurlregion = regioneservice = identitykey = publicurl is combined into a JSON string {'regionone': {'Identity ': {'publicurl': 'http: // localhost: $ {public_port} s/V2.0 '} finally parses the entire directory Template into a dictionary object in JSON format. After the resolution is complete, get a version_controller with adminurl directory information, and then send it to routes. mapper adds route information, and finally returns the constructed router to urlmap, completing one-to-one correspondence between the request path and the route path. The route object stores the Request Path, controller information, and action information. So far, keystone-all is completed, and two servers are started waiting for the request. One is admin_port waiting, and the other is public_port waiting. When a request arrives at the service, it executes the filters according to the paste configuration, and then enters the module method for execution according to the route table configuration.
The above introduction mainly focuses on the paste and routes processes. Keystone uses these frameworks to provide rest APIs to reduce coupling and provide user authentication functions for each module.
The following describes the glance project.1. Registry provides HTTP Services for DB operations. glance API operates the image metadata stored in the database through HTTP requests to registry. Although the Registry API is accessible, users generally do not directly perform operations on the registry API.
2. after the glance-API and glance-registry start the service, find the paste configuration file based on the Application name and project name, and deploy the routing information to put the image metadata into the HTTP request header, request the glance-API address as the image file. Glance-API receives requests, parses request header information starting with X-image-Meta and X-image-meta-property-as image metadata, and then uses the registry client to request the registry service, store the image metadata in the database and obtain the id value as the name of the image file storage file. After the image file is stored or otherwise, request the registry service to update the image status and other metadata information again.
The Nova project is a little larger. The process of creating a virtual machine and releasing a snapshot is briefly described.1. Obtain the image from glance and create a virtual machine
1) the compute API obtains the request and determines whether the instance type meets the number of created instances.
2) When creating image_service, the system checks whether image_href is in the form of http: // myglanceserver: 9292/images/42. If yes, the system obtains the specified glance service, if it is an ID string, the default glance service is obtained.
3) Request glance to obtain image metadata
4) determine the access permission after obtaining metadata. The first is Auth-Token. If yes, return. If no, continue to judge whether the image is public or whether the current user is admin.
5) filter the obtained metadata
Only image_attributes = ['SIZE', 'disk _ format ',
'Container _ format', 'checksum', 'id ',
'Name', 'created _ at', 'updated _ ',
'Deleted_at', 'deleted', 'status ',
Attributes in 'min _ disk', 'min _ ram', 'is _ public ']
Convert timestamp to datetime
Convert 'block _ device_mapping ', and set the JSON string to map.
6) Make sure that the default security group exists.
7) Update dB data for new instances, add instance data and update associated data of instances and security groups, update block_device_mapping, update VM status to building, and update task status to scheduling.
8) send a request to start the instance to scheduler, and call run_instance by RPC remotely.
9) When compute-manager starts an instance, it first requests instance metadata
10) Assign the network, update the float IP address and associate the fixed IP address, and return the network information.
11) Create an instance maintenance directory (for example,/var/lib/NOVA/instances/instance-00000009 /)
12) Write instance information to libvirt. xml
13) Use image_id as the sha1 abstract as the image name
14) cache image. If a disk file exists, obtain the cached image in the _ base directory. If the cached image exists, it is used for the subsequent disk creation command, if the image does not exist, request the glance service to obtain the image metadata and image file data. If the image is of the qcow2 type, the libvirt command is used to create the image. The example is as follows:
Create cow image:
Qemu-IMG create-F qcow2-O cluster_size = 2 m, backing_file =
/Var/lib/NOVA/instances/_ base/80256f8ca341d522ac141d187481a03f5e61bce5/var/lib/NOVA/instances/instance-00000007/Disk
15) inject key, net, metadata and admin_password data to disk
16) Enable loopcaller to determine whether the virtual machine status is running.
2. Nova releases snapshots
1) Go to Nova. image. glance. image_service.create method-> glance client creates the image glance. client: add_image-> use rest API (lead information x-image-meta-property-image_type ': u'snapshot') request to create a metadata and get the ID of the current image as the snapshot type
2) Compute API uses RPC to call computemanager for Snapshot
3) computemanager obtains the region domain object, image metadata, and snapshot metadata of the instance.
4) Find the libvirt XML Description and parse the path of the disk.
5) if the VM is running, libvirt will suspend the VM and save the memory content to the file.
6) use the libvirt command to create a snapshot
Qemu-IMG snapshot-C $ {hexadecimal snapshot name }$ {disk-path}
7) extract the snapshot to the Temporary Folder
Qemu-IMG convert-F qcow2-O qcow2-S $ {hexadecimal snapshot name }$ {disk-path }$ {out-path}
8) delete a snapshot from disk
Qemu-IMG snapshot-d $ {hexadecimal snapshot name }$ {disk-path}
9) If the VM is running before the snapshot is created, the VM is switched from paused to running.
10) Use glance client to update snapshot metadata
11) Update instance metadata in the database (task_state = none)
