[openstack-dev] [Zaqar] OpenStack Tokyo Summit Summary

Fei Long Wang feilong at catalyst.net.nz
Fri Nov 6 12:31:09 UTC 2015


Firstly, thank you for everyone joined Zaqar sessions at Tokyo summit. 
We definitely made some great progress for those working sessions. Here 
are the high level summary and those are basically our Mitaka 
priorities. I may miss something so please feel free to comment/reply 
this mail.

Sahara + Zaqar

We have a great discussion with Ethan Gafford from Sahara team. Sahara 
team is happy to use Zaqar to fix some potential security issues. The 
main user case will be covered in Mitaka is protecting tenant guest and 
data from administrative user. So what Zaqar team needs to do in Mitaka 
is completing the zaqar client function gaps for v2 to support signed 
URL, which will be used by Sahara guest agent. Ethan will create a spec 
in Sahara to track this work. This is a POC of what it'd look like to 
have a guest agent in Sahara on top of Zaqar. The Sahara team has not 
decided to use Zaqar yet but this would be the bases for that discussion.

Horizon + Zaqar

We used 1 horizon work session and 1 Zaqar work session to discuss this 
topic. The main user case we would like to address is the async 
notification so that Horizon won't have to poll the other OpenStack 
components(e.g. Nova, Glance or Cinder) per second to get the latest 
status. And I'm really happy to see we worked out a basic plan by 
leveraging Zaqar's notification and websocket.

1. Implement a basic filter for Zaqar subscription, so that Zaqar can 
decide if the message should be posted/forwarded to the subscriber when 
there is a new message posted the queue. With this feature, Horizon will 
only be notified by its interested notifications.


2. Listen OpenStack notifications

We may need more discussion about this to make sure if it should be in 
the scope of Zaqar's services. It could be separated process/service of 
Zaqar to listen/collect interested notifications/messages and post them 
in to particular Zaqar queues. It sounds very interesting and useful but 
we need to define the scope carefully for sure.

Pool Group and Flavor

Thanks MD MADEEM proposed this topic so that we have a chance to review 
the design of pool, pool group and flavor. Now the pool group and flavor 
has a 1:1 mapping relationship and the pool group and pool has a 1:n 
mapping relationship. But end user don't know the existence of pool, so 
flavor is the way for end user to select what kind of storage(based on 
capabilities) he want to use. Since pool group can't provide more 
information than flavor so it's not really necessary, so we decide to 
deprecate/remove it in Mitaka. Given this is hidden from users (done 
automatically by Zaqar), there won't be an impact on the end user and 
the API backwards compatibility will be kept.


Zaqar Client

Some function gaps need to be filled in Mitaka. Personally, I would rate 
the client work as the 1st priority of M since it's very key for the 
integration with other OpenStack components. For v1.1, the support for 
pool and flavor hasn't been completed. For v2, we're stilling missing 
the support for subscription and signed URL.


SqlAlchemy Migration

Now we're missing the db migration support for SqlAlchemy, the control 
plane driver. We will fix it in M as well.


Guys, please contribute this thread to fill the points/things I missed 
or pop up in #openstack-zaqar channel directly with questions and 

Cheers & Best regards,
Fei Long Wang (王飞龙)
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flwang at catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151107/c0e7812f/attachment.html>

More information about the OpenStack-dev mailing list