November 2017 Achieving Zen-like Bliss with Glance Brian Rosmaita, irc: rosmaita Erno Kuvaja, irc: jokke_
Brian Rosmaita Distinguished Member of the Technical Staff Verizon Wireless
Erno Kuvaja Senior Software Engineer
The OpenStack Image Service The OpenStack Image Service (codenamed “Glance”) is developed and maintained by the Glance project . Glance allows you to to store, browse, share, distribute, and manage bootable disk images. The glance software provides the Image Service APIs. ● Version 2 is under active development ● Version 1 is DEPRECATED and scheduled to be removed in the Queens release developer.openstack.org/api-ref/image
More Glance at the Summit ● Operators’ Feedback Session ○ Tuesday, 4:10-4:50pm ○ Level 4 - C4.11 ● Glance Project Update ○ Wednesday, 11:25-11:45am ○ Level 3 Convention Center - C3.2 ● Glance Image Import is here ... now it's time to start using it! ○ Wednesday, 4:30-5:10pm ○ Level 3 Convention Center - Cockle Bay Room 2
Questions 1. How do I discover images ? 2. How do I share images effectively with my organization? 3. How can I make better use of my image metadata using property protections? 4. How do I ensure the authenticity of image data using digital signature? 5. What are image locations? Are they appropriate for my cloud? 6. What is the new image import workflow, and what does it do for me?
November 2017 How Do I Discover Images?
How do I discover images? ➡ The Glance image-list call ➡ GET /v2/images • Things to know about the default image-list response Operator configuration options: • limit_param_default = 25 • api_limit_max = 1000 • End-user supplied parameters: • limit • The default response does not contain all images • available to the end user This is an anti-spam feature •
How do I discover images? ➡ The Glance image-list call ➡ GET /v2/images • Things to know about the default image-list response Default content (no query parameters other than limit or sorting) • All public images (regardless of owner) • All private images owned by the end user • All community images owned by the end user • All shared images that the end user owns • All shared images that the end user has accepted • What’s missing • Community images provided by other owners • Shared images that haven’t been accepted •
How do I discover images? ➡ The Glance image-list call ➡ GET /v2/images • Use the ‘visibility’ filter to discover the “missing” images GET /v2/images?visibility=community • All community images (including the ones you own) • GET /v2/images?visibility=community&owner=be2565a54dad45 • All community images owned by that particular producer • Use your owner identifier to see only your community images •
How do I discover images? ➡ The Glance image-list call ➡ GET /v2/images • Use the ‘visibility’ filter to discover the “missing” images GET /v2/images?visibility=shared • All shared images that the end user owns • All shared images that the end user has accepted • (so, basically, only the shared images that show up in the default list) • GET /v2/images?visibility=shared&member_status=all • All shared images that the end user may use • Can also use ‘accepted’, ‘pending’, or ‘rejected’ for the member status • filter
How do I discover images? ➡ The Glance image-list call ➡ GET /v2/images • You can filter on any image property Image properties (“metadata”) tend to be subject to local practices • • Glance “common image properties” are an attempt to provide some common properties with standardized values across OpenStack clouds • Limitations The API pretty much only allows conjunctions in query strings, and no • negations You can form disjunctions (but only on some fields) using the ‘in’ operator • (introduced in Mitaka) The ‘name’ filter specifies an exact match • • To allow users to do complex searches, we suggest you deploy Searchlight (the OpenStack front end to ElasticSearch)
How do I discover images? ➡ The Glance image-list call ➡ GET /v2/images • Size comparison filters size_min - only return images larger than the specified size (in bytes) • size_max - only return images smaller than the specified size (in bytes) • • Time comparison filters Can be applied to created_at and updated_at • Introduced in Mitaka •
November 2017 How Do I Share Images Effectively With My Organization?
How do I share images effectively? ➡ Well, it depends on who you are and what you want to accomplish! ➡ We’ll consider “sharing” to mean “make an image available to someone other than the image owner” ➡ In Glance, who has access to an image is tied to the image’s ‘visibility’ property • public • community • shared • private ➡ You change an image’s visibility by using the image-update (PATCH) call • Can also specify visibility at the time of image creation Default is ‘shared’ • • The ability to share is governed by policies
How do I share images effectively? ➡ Public images • The image is available to all users Only the owner (or an admin) can update or delete the image • • Policy target: “publicize_image”: “role:admin” • These are a cloud’s “base images” • The basic idea of a public image is that there is some kind of support relationship between the operator and end users Because most clouds treat them this way, there’s an expectation on the part • of end users The ability to publicize an image can be extended to whoever you like, but it’s • best to keep this expectation in mind
How do I share images effectively? ➡ Community images • The image is available to all users Only the owner (or an admin) can update or delete the image • • Policy target: “communitize_image”: “” • These are images made available to the entire community of users in a cloud • Original use case was open-source projects who wanted to make make an image available to all users, and were willing to maintain the image and support it themselves • Useful if you just want an image to be available, but you have no need to know who exactly has access to it
How do I share images effectively? ➡ Shared images • The image is available only to specific users who must be made “members” of the image Only the owner (or an admin) can update or delete the image • Only the owner (or admin) can add or delete image members • Only a member (or admin) can modify that member’s member_status • • Policy targets: "add_member": "" • "delete_member": "" • "get_member": "" • "get_members": "" • "modify_member": "" •
How do I share images effectively? ➡ Shared images • The image must have ‘shared’ visibility in order for members to be added (since Ocata) • Simply having ‘shared’ visibility does not imply that anyone other than the owner has access to the image Must also have a non-empty member list • • Shared images are useful if you only want specific other projects* to have access to the image The member_status of an image member does not affect access to the image • It affects whether the image will appear in a member’s default image list • The image is available to a member as soon as that member is added to the • image
November 2017 How can I make better use of my image metadata using property protections?
How can I make better use of my image metadata using property protections? ➡ Property protections were introduced in Havana ➡ Allow an operator to specify CRUD on custom image properties (“image metadata”) ➡ Called “property protections” instead of “protected properties” because they’re not a particular kind of image property • They provide an authorization layer around all the custom image properties ➡ Can be configured to use roles or policy rules to describe the permissions ➡ Left to the operator to document how the protections are set in a particular cloud • (This is mentioned several places in the Image Service API reference)
How can I make better use of my image metadata using property protections? ➡ Configuring • Related options allow_additional_image_properties (default is True) • When False, only properties specified in the image schema are allowed • image_property_quota (default is 128) • • Primary options property_protection_file (default is empty string) • Activate property protections by specifying a file • property_protection_rule_format (default is ‘roles’) • Tells Glance what to expect in the property_protection_file • ‘roles’ or ‘policies’ •
How can I make better use of my image metadata using property protections? ➡ The property_protection_file • If you specify one, it covers all your custom image properties • The feature is very conservative If the file can’t be found, the API service won’t start • If there’s a problem with the file content, the API service won’t start • If a property is not mentioned in the file, the permissions are deny-all for that • property You probably want a catch-all clause at the bottom of the file •
Recommend
More recommend
