The request is accepted for processing.
+``` + +------ + +## **Custom Object Metadata**: + +Swift allows end users the ability to tag Object metadata, this is extremely useful in identifying the source of data, notes about the object or the current processing state when the object is consumed by a data lake process. + +Using the swift CLI: + +``` +swift upload -m ``"X-Object-Meta-Security: TopSecret" HR_files payroll_information.txt +``` + +Using cURL: + +``` +curl -X POST -H "X-Auth-Token:$TOKEN" -H 'X-Object-Meta-Security: TopSecret' $STORAGE_URL/HR_files/payroll_information.txt +``` + +------ + +## **Static Web Hosting:** + +Using Swift Object you can serve static websites built in HTML to clients, this takes the need for any web servers out if your infrastructure and relies on Swift's robust infrastructure to serve web files out. + +1. Make container publicly readable: + +``` +# swift post -r '.r:*,.rlistings' web_container +``` + +2. Set site index file, in this case we will use *index.html* as the index file for our site: + +``` +# swift post -m 'web-index:index.html' web_container +``` + +3. Optional: Enable file listing, this allows the container to be browsed when an *index.html* file is not specified: + +``` +# swift post -m 'web-listings: true' web_container +``` + +4. Optional: Enable CSS for file listing when site index file is not specified: + +``` +# swift post -m 'web-listings-css:listings.css' web_container +``` + +5. Set custom error pages for any visitors accessing your static website, you may specify custom 401, 404 error pages or a catch all. + +``` +# swift post -m 'web-error:error.html' web_container +``` + +> [!NOTE] +> +> More information on static websites can be found here: +> +> [Swift Create static website](https://docs.openstack.org/ocata/user-guide/cli-swift-static-website.html) + +------ + +## **Lifecycle Management** + +In OpenStack Swift, the expiration of objects can be managed using a feature called **object expiration**. This allows you to automatically delete objects after a specified period, which is useful for managing storage costs and keeping your data organized and keep in compliance with our organization data retention requirements. + +There are two ways to set the object expiration, date and time based or after N seconds have passed. + +Set an object to expire at an absolute time (in Unix time): + +``` +# swift post CONTAINER OBJECT_FILENAME -H "X-Delete-At:UNIX_TIME" +``` + +Set an object to expire after N seconds have passed: + +``` +# swift post CONTAINER OBJECT_FILENAME -H "X-Delete-After:SECONDS" +``` + +To check on the X-Delete-At/X-Delete-After header: + +``` +# swift stat CONTAINER OBJECT_FILENAME +``` + +To clear any X-Remove flags from an object: + +``` +# swift post CONTAINER OBJECT_FILENAME -H "X-Remove-Delete-At:" +``` + +Benefits of Object Expiration + +- **Storage Management:** Helps in managing and reclaiming storage space by removing outdated or unnecessary objects. +- **Cost Efficiency:** Reduces storage costs by preventing accumulation of unneeded data. + +This feature is particularly useful in scenarios like managing temporary files, logs, or any other data that has a defined lifecycle. + +------ + +## Swift S3 REST API + +S3 is a product of Amazon and AWS, Swift's S3 RESTful API is a middleware component that allows verb compatibly between a native Swift deployment and applications that only speak S3 API. While most functionality is present in the Swift S3 middleware, some verbs are lacking or there is not a like for like feature within Swift. For the current state of Swift and S3 verb compatibility please refer to the following upstream documentation: + +[S3/Swift REST API Comparison Matrix](https://docs.openstack.org/swift/latest/s3_compat.html) + +------ + +# **Best Practices** + +## Performance: + +- Keep object count under 500k per container +- Multiplex over multiple container if possible +- To increase throughput scale out the amount of API worker threads you have interacting with Swift endpoint + +## Securing data: + +Swift supports the optional encryption of object data at rest on storage nodes. The encryption of object data is intended to mitigate the risk of users’ data being read if an unauthorized party were to gain physical access to a disk. + +> [!NOTE] +> +> Swift’s data-at-rest encryption accepts plaintext object data from the client, encrypts it in the cluster, and stores the encrypted data. This protects object data from inadvertently being exposed if a data drive leaves the Swift cluster. If a user wishes to ensure that the plaintext data is always encrypted while in transit and in storage, it is strongly recommended that the data be encrypted before sending it to the Swift cluster. Encrypting on the client side is the only way to ensure that the data is fully encrypted for its entire lifecycle. + +The following data are encrypted while at rest in Swift: + +- Object content i.e. the content of an object PUT request’s body +- The entity tag (ETag) of objects that have non-zero content +- All custom user object metadata values i.e. metadata sent using X-Object-Meta- prefixed headers with PUT or POST requests + +Any data or metadata not included in the list above are not encrypted, including: + +- Account, container and object names +- Account and container custom user metadata values +- All custom user metadata names +- Object Content-Type values +- Object size +- System metadata + +All in-flight operations are encrypted using HTTPS and TLS encryption. + +## **Cost Management** + +Managing cost in Openstack Swift can be accomplished using object lifecycle management, usage monitoring and storage classes. + +**Object Lifecycle Management:** Use expiration policies to automatically delete outdated or unnecessary objects, reducing the volume of stored data. + +**Usage Monitoring:** Keep tabs on your Object storage spend by looking at overall container sizes for your organization, using 'swift stat container' will show you the overall usage of each container being hosted on Swift. + +**Storage Classes:** Consider implementing different storage classes based on access frequency and performance needs. For example, frequently accessed data can be stored in faster, more expensive storage, while infrequently accessed data can be moved to slower, cheaper storage. Use Swift to store archival data at lower costs, particularly for data that needs to be retained but is rarely accessed, by locking into a longer commitment on storing archival data you will save money month over month.