Zed Series Release Notes

14.0.0

Upgrade Notes

  • Upgrade one of the storage drivers, the Mongo driver with new version of PyMongo. PyMongo has been updated to 4.0.0, there are some changes which are not supported in the new version: 1. Collection.count and Cursor.count is removed. 2. Collection.ensure_index is removed. 3. Collection.__bool__ raises NotImplementedError. 4. Should use Binary.from_uuid to handle the UUID object. Those changes need to upgrade the mongo driver’s code to work well.

13.0.0

New Features

  • Introduce a new request header called “EXTRA-SPEC” and driver mechanism with stevedore to let developers implement the task about how to deal with this information. In Wallaby, there’s just an empty handler by default.

12.0.0

Prelude

Welcome to the Victoria release of the OpenStack Message service (Zaqar). In this cycle, the Zaqar team would like to bring the following points to your attention. Details may be found below.

  • Support encrypted messages in queue.

  • Fixed bugs for stable and security.

New Features

Upgrade Notes

  • The default value of [oslo_policy] policy_file config option has been changed from policy.json to policy.yaml. Operators utilising customised or previously generated static policy JSON files (which are not needed by default), should generate new policy files or convert them into YAML format. Use the oslopolicy-convert-json-to-yaml tool to convert a JSON to YAML formatted policy file in a backward compatible way.

Deprecation Notes

  • The JSON policy files were deprecated by the oslo.policy library during the Victoria development cycle. As a result, this deprecation is being noted in the Wallaby cycle with an anticipated future removal of support by oslo.policy. As such operators will need to convert to YAML policy files. Please see the upgrade notes for details on the migration of any custom policy files.

Bug Fixes

11.0.0

New Features

  • To enhance the security of messaging service, the queue in Zaqar supports to encrypt messages before storing them into storage backends, also could support to decrypt messages when those are claimed by consumer. To enable this feature, user just need to take “_enable_encrypt_messages=True” when creating queue. AES-256 is used as the default of encryption algorithm and encryption key is configurable in the zaqar.conf.

10.0.0

New Features

  • Support query queues with filter ‘with_count=true’ to return the amount of the queues. This will help users to quickly get the exact total number of queues which they own.

Upgrade Notes

  • Python 2.7 support has been dropped. Last release of Zaqar to support py2.7 is OpenStack Train. The minimum version of Python now supported by Zaqar is Python 3.6.

8.0.0

Prelude

Added new tool zaqar-status upgrade check.

New Features

  • Add an new option named ‘message_delete_with_claim_id’, when it is True, delete messages must need claim_ids and message_ids both in request parameters. This will improve the security of the message.

  • Currently the email subscriptions in Zaqar rely on the third part tools, such as “sendmail”. It means that deployer should install it out of Zaqar. If he forgets, Zaqar will raise internal error. This work let Zaqar support email subscription by itself using the smtp python library.

  • Introduce a new resource called Topic into Zaqar. Topic is a concept from AWS Simple Notification Service (SNS), it will has relevance with subscriptions. User can send message to a topic, and then the subscribers will get the message according to different protocols, like http, email, SMS, etc. This feature will help Zaqar to split Messaging Queue Service and Notification Service clearly.

  • In Queens, we support the old way to use pool_group and the new way without it in Flavour both. In Stein, we will remove the pool_group totally and only keep the new way in Flavour and Pool.

  • New framework for zaqar-status upgrade check command is added. This framework allows adding various checks which can be run before a Zaqar upgrade to ensure if the upgrade can be performed safely.

Upgrade Notes

  • Operator can now use new CLI tool zaqar-status upgrade check to check if Zaqar deployment can be safely upgraded from N-1 to N release.

7.0.0

New Features

  • Support for queue filter when queue listing. With this feature, users can add filter of name or metadata in query string parameters in queue list to filter queues.

  • Since some clients use different format of client id not only UUID, like user id of LDAP, so Zaqar will remove the format contraint of the client id. Add one option ‘client_id_uuid_safe’ to allow user to control the validation of client id. Add two options ‘min_length_client_id’ and ‘max_length_client_id’ to allow user to control the length of client id if not using UUID. This also requires user to ensure the client id is immutable.

  • Since we have introduced the ‘pool_list’ instead of pool_group in Queens, Now we will update the APIs to suggest users use new argument.

  • Add three new reserved metdata in response body of querying queue. “_dead_letter_queue”, “_dead_letter_queue_messages_ttl” and “_max_claim_count”. Those metadata will help user to know better about dead letter queue.

Other Notes

  • The code structure for configuration files are changed. This is transparent for end users, but the persons who work for downstream changes should pay attention. Please refactor your private configurations to zaqar/conf/ folder as well.

6.0.0

New Features

  • Zaqar supports a new way to directly use a pool resource without pool_group when creating a Flavour. The old way will be kept in Queens and be marked deprecated. Zaqar will remove the pool_group totally in Rocky.

  • Support more retry back-off function in webhook type. It will work when Zaqar failed to send the notification to the subscriber. Users can define the retry back-off function in metadata of queue. There are four retry back-off functions including ‘linear’, ‘arithmetic’, ‘geometric’ and ‘exponential’.

  • Support Redis as the management storage backend to improve the performance and ease of deployment. For the management driver, user needs to enable the Redis storage options in redis.conf to persist data.

  • Support for delayed queues is added for MongoDB, Redis and Swift. With this feature, if the queue is a delayed queue, its message will be delayed some time to be claimed. New reserved metadata key of queue is added: _default_message_delay.

  • Support non-URL encoded message body checksum function, the default algorithm is MD5. Back-end support for MongoDB, Redis and Swift. With this feature, when a user sends a message to the queue, Zaqar calculates a “checksum” value for the body of the non-URL encoded message, which the user can then get after the message is got or claimed. Finally, the user can use it to verify that the body of the newly obtained message is correct.

  • Redis connection doesn’t support password configuration in Zaqar, so Redis-server can not set a password. If Redis service doesn’t set a password, it will suffer a large number of attacks. The patch will support password configuration for a Redis connection in Zaqar.

5.0.0

New Features

  • The new Swift storage backend is added to Zaqar in Ocata. It’s experimental currently. To use this backend, you should modify the “drivers” section in the config file. [Blueprint swift-storage-driver]

  • Introduce Guru to Zaqar. Guru is a mechanism whereby developers and system administrators can generate a report about the state of a running Zaqar executable. This report is called a Guru Meditation Report. Now Guru can support wsgi, websocket and uwsgi modes all.

  • This feature is the third part of subscription confirmation feature. Support to send email to subscriber if confirmation is needed. To use this feature, user need to set the config option “external_confirmation_url”, “subscription_confirmation_email_template” and “unsubscribe_confirmation_email_template”. The confirmation page URL that will be used in email subscription confirmation before notification, this page is not hosted in Zaqar server, user should build their own web service to provide this web page. The subscription_confirmation_email_template let user to customize the subscription confirmation email content, including topic, body and sender. The unsubscribe_confirmation_email_template let user to customise the unsubscribe confirmation email content, including topic, body and sender too.

  • Zaqar now supports Cross-Origin Resource Sharing (CORS).

  • Support dot character in queue’s name, like ‘service.test_queue’.

  • Support notification delivery policy in webhook type. It will work when the notification is sent from Zaqar to the subscriber failed. User can define the retry policy in the options of subscription or metadata of queue.

  • Support for dead letter queue is added for MongoDB, Redis and Swift. With this feature, message will be moved to the specified dead letter queue if it’s claimed many times but still can’t successfully processed by a client. New reserved metadata keys of queue are added: _max_claim_count, _dead_letter_queue and _dead_letter_queue_messages_ttl.

Critical Issues

  • When using the sqlalchemy driver, operators now are required to run “zaqar-sql-db-manage upgrade” before making the service available. The service previously tried to create the database on the first request, but it was bound to race conditions.

Bug Fixes

  • Add two configurations for the notification endpoint of the websocket server, instead of a random port and local address. One is ‘notification-bind’, address on which the notification server will listen. Another is ‘notification-port’, port on which the notification server will listen.

  • Zaqar didn’t return the reserved metadata when listing detailed queue. After this fix, Zaqar will return reserved metadata ‘_default_message_ttl’ and ‘_max_messages_post_size’ in response of listing detailed queue.

4.0.0.0rc1

New Features

  • The OSprofiler is integrated to Zaqar in Ocata. It is a library from Oslo. It aims to analyse the performance bottleneck issue by making possible to generate one trace per request affecting all involved services and build a tree of calls.

4.0.0.0b2

New Features

  • A new queue action is added so that users can purge a queue quickly. That means all the messages and subscriptions will be deleted automatically but the metadata of the queue will be kept.

  • Add migration support for Zaqar’s sqlalchemy storage driver.

3.0.0.0rc1

New Features

  • Currently, the v1 API is still accessible though it has been deprecated for a while. And we’re going to deprecate v1.1 soon. To keep the backward compatibility, a new config option - enable_deprecated_api_versions is added so that operator can totally turn off an API version or still support it by adding the API version to the list of the new config option.

Deprecation Notes

  • Zaqar API v2 has been released for several cycles and it is integrated as the default API version by most of the OpenStack services. So it is time to deprecated v1.1 in favour of v2. Now in Newton cycle, Zaqar API v1.1 is officially deprecated.

3.0.0.0b3

New Features

  • Now before users send messages to subscribers through a queue, the subscribers should be confirmed first. Zaqar only sends messages to the confirmed subscribers. This feature supports “webhook” and “mailto” subscribers with MongoDB or Redis backend. The “mailto” part will be done in O cycle. Set “require_confirmation = True” to enable this feature. The default value is “False” now and we will enable it by default after one or two cycles.

3.0.0.0b2

New Features

  • Add a new webhook notifier using trust authentication. When using the ‘trust+’ URL prefix, Zaqar will create a Keystone trust for the user, and then use it when a notification happens to authenticate against Keystone and send the token to the endpoint.

  • Support ‘post_data’ and ‘post_headers’ options on subscribers, allowing customisation of the payload when having a webhook subscriber. The ‘post_data’ option supports the ‘$zaqar_message$’ string template, which will be replaced by the serialised JSON message if specified.

  • Queues now behave lazy in subscriptions also. So there is no need for the user to pre-create a queue before creating a subscription for this queue. Zaqar will create the queue automatically on the subscription creation request. As before, all subscriptions will continue to stay active even if the corresponding queue was deleted.

  • Currently Zaqar can support more built-in/reserved attributes in queue. For now there are two important attributes ‘max_messages_post_size’ and ‘max_message_ttl’. With this feature, when user query queues Zaqar will show those two attributes (read from config file if there is no customised value from user) in queue metadata so that user can know what value it is.

Bug Fixes

  • When access the root path of Zaqar service, for example: curl GET http://127.0.0.1:8888/, user will see 401 error. Which will cause some front end proxy (like HAProxy) to complain. Now this issue has been fixed.

  • Query for all subscriptions on a given queue by taking into account the returned marker, if any. Without this fix, only 10 subscriptions can be extracted from database to send notification.

  • In IPv6 management network environment, starting Zaqar server will run into ‘Address family for hostname not support’ error when use WSGI simple server. The root cause is that Python’s TCPServer implementation is hard-coded to use IPv4, even in IPv6 environments. Now this issue has been fixed.