Open Stack

Excerpts from Fei Long Wang's message of 2015-11-07 01:31:09 +1300:
> Greetings,
> 
> 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.
> 
> https://blueprints.launchpad.net/zaqar/+spec/suport-filter-for-subscription
> 
> 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.

The Telemetry team discussed splitting out the code in Ceilometer that
listens for notifications to make it a more generic service that accepts
plugins to process events. One such plugin might be an interface to
filter events and republish them to Zaqar, so if you're interested in
working on that you might want to coordinate with the Telemetry team to
avoid duplicating effort.

> 
> 
> 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.
> 
> https://blueprints.launchpad.net/zaqar/+spec/deprecate-pool-group
> 
> 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.
> 
> https://blueprints.launchpad.net/zaqar/+spec/finish-client-support-for-v1.1-features
> 
> SqlAlchemy Migration
> -----------------------------
> 
> Now we're missing the db migration support for SqlAlchemy, the control 
> plane driver. We will fix it in M as well.
> 
> https://blueprints.launchpad.net/zaqar/+spec/sqlalchemy-migration 
> <https://blueprints.launchpad.net/zaqar/+spec/sqlalchemy-migration>
> 
> 
> Guys, please contribute this thread to fill the points/things I missed 
> or pop up in #openstack-zaqar channel directly with questions and 
> suggestions.
>