Openstack learning notes -grace component insight

Video understanding :
glance： A service that provides images for the creation of virtual machines
glance The function of ： Enables users to discover 、 register 、 Retrieve the image of the virtual machine , It provides a way to query the metadata of virtual machine image and retrieve the real image REST API
REST API The embodiment of is a URL, And in the glance Through one URL Address to identify a URL Address to uniquely identify a mirror image, such as :
<Glance Server Location>/v1/images/<ID>
<Glance Server Location>：glance The service is located according to
/v1： Use v1 edition , See IV for details
/images： The requested type is mirror
/<ID>： One uuid, stay glance Globally unique in

v1 Version of glance：
1、V1 Implementation of version , have glance-api and glance-registry Two WSGI service , Both REST API, But one thing to emphasize is ：glance-registry Provided REST API It's for glance-api The use of
2、Glance-API：1、 Accept api A request from , issue glance-registry.2、 Pull the image from the back-end storage device
3、Glance-Registry：1、 Connect to database , Find the image that conforms to the client standard from the database , Get the metadata of the image , Return the mirrored information to glance-api
v2 Version of glance：
1、v2 The realization of will be glance-registry Integrated into glance-api Inside , The advantage of this is that it reduces an intermediate processing link .
2、Glance-API： Accept api The incoming request directly accesses the database , After obtaining the metadata of the image, go to the storage device to pull the image .

Book notes ：
Glance Architecture （v1 edition ）：
1、Glance Mainly by glance-api And glance-registry Two services make up .
2、glance-api Is to enter Glance Entrance , Responsible for receiving the user's information RESTful request , Then through the backstage Swift Wait for the storage system to complete the storage and acquisition of images .
3、Glance Of Store Module implements a framework for storing the background , According to the interface provided by this framework , It supports different background storage systems .
4、 stay Juno Before the release ,Store The implementation of the module is located in glance/store Catalog ;Juno After the version ,Store Module as a separate project glance store Be stripped out , In order to serve more projects
5、glacne-registry Also a WSGI Server, The difference is ,glance-registry It deals with the metadata of the image （ The metadata here refers to some information about the image stored in the database ） dependent RESTful request .
6、glance-api Received from the user RESTful After the request , If the request is related to metadata , Then forward it to glance-registry service . then glance-registry The content of the request will be parsed , And interact with the database , Access or update the metadata of the image ,Glance Of DB Modules store only mirrored metadata .
v2 Version of Glance in ,glance-registry The content of the service is integrated into glance-api In .

Glance Source structure analysis ：
1、Glance The core code of is located in glance Catalog
2、 The execution scripts for all services and tools are located in glance/cmd
3、glance-api、glance/registry They correspond to each other GlanceAPI and Glance-registry
4、glance-api You can create a local cache for the image , Realization API The number of service nodes is expanded , Provide multiple API The efficiency of nodes serving the same image （ The local Image Cache Is a full copy of the image file , This caching mechanism is transparent to users ）.
5、 Users can use the configuration file /etc/glance/glance-cache.conf Appoint Cache Path of file storage 、 Can be used locally for Cache Storage space and other information .
6、 The implementation of the mirrored cache is located in glance/image_cache Catalog .
7、 in the light of import、export And so on ,Glance introduce Task The concept of （ Asynchronous operation for mirror ,glance/async That is, partial implementation ）
8、Glance The chain of responsibility is adopted (Chain of Responsibility) The design pattern implements the processing flow of user requests . This enables the system to dynamically reorganize the chain and assign responsibilities without affecting the client .
9、glance.domain Modules define some base classes or interfaces ,glance.gateway.Gateway The module realizes the establishment of responsibility chain .
10、Rally Is a project for performance testing ,glance/rally-jobs Directories are used for Rally File or plug-in .

setup.cfg：
entry_points, The namespace in “consolc_scripts” in , covers Glance All services and tools provided
Each of these represents an executable script , These scripts are installed at deployment time , They are also Glance Entrance to various works .
1、glance-cache-*： 4 Yes Image Cache Tools for management .
2、glance-manage： be used for Glance Database management .
3、glance-replicator： It is used to replicate the image .
4、glance-scrubber： Used to clean up deleted Image.
5、glance-control： Glance Provides glance-api and glance-registry Two WSGI Server. And one individual glance-scrubber Background service process , there glance-control Tools are used to control this 3 Service process .
6、glance-glare： Glare API service , Currently under development .

Glance API Detailed introduction ：
Glance API Mainly provides image management functions . such as Image Import of / export 、 Management of image metadata, etc .
at present Glance API share v1 and v2 Two versions ,v2 The version integrates glance-registry Functions of services , And the responsibility chain design pattern is used to realize API Process flow .
Image：
Image yes Glance Main resources managed . If from Image start-up VM, The VM After being deleted ,Image There is still a , however Image Does not include this time in this VM Modification on the instance （ because Image Just for VM Launched template ）
Yes Image Description of ：
1、id： A unique identifier Image Of UUID
2、name：Image Name
3、owner：Image The owner of the
4、size：Image Byte size of
5、created_at、updated_at： Express Image The birth time of 、 The last time it was modified
6、location：Image Storage location
7、disk_format：Image Its own format （ such as raw、qcow2（ be used for Qemu）、vdi（ be used for Virtual Box）、vmdk（ be used for Vmware） etc. ）
8、status： The state of the image .（Glance Responsible for managing the Image Life cycle of ）
Image The various states of ：
1、queued： Surface mirroring ID Has been reserved , But the image data has not been uploaded yet
2、saving： The surface image is now uploading
3、active： yes Image Status after successful uploading , At this point the Image Completely available
4、killed： An error occurred while uploading the surface , here Image Not at all .（ stay v2 Is abolished , If the upload fails , The status code changes to “queued” So that the upload can be retried ）
5、deleted： Although this time Glance Keep it Image Information about , But it's time to Image No longer available , Before Come to a certain time will be glance-scrubber Delete completely .
6、pending_delete： and deleted similar , But it doesn't delete Image, It can be recovered at this time .
Task：
Task Is aimed at Image The asynchronous （Async） operation , Some of the properties that it has are id、owner State, etc .Glance At the same time, a unified JSON Format API To operate these Task, Such as creating 、 Delete 、 Query status, etc .
In a Task In operation , We keep checking its status .
1、pending： Express Task Be created , But not implemented
2、processing： Express Task It's being executed .
3、success： Express Task It is implemented .
4、failure： Express Task Failed to finish successfully for some reason .
Task and Image The operation of is completely two concepts ：
1、 First of all, they are all different API resources ;
2、 secondly ,Task It's an asynchronous operation , It's right Image Encapsulation of operation , At present, only for clone、imports export 3 Operations are encapsulated ;
3、 Last ,Task Once created , You can constantly query its status , In an operation such as import after ,Task Can die , But at this point Image There is still a .