Open Stack

On 11/06/2015 01:36 PM, Doug Hellmann wrote:
> 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.

That would be great, I'm pretty strongly opposed to adding message 
filtering because that adds to the complexity of subscriptions pretty 
significantly.

>> 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

+1

>> 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>

Would this just be the addition of alembic (how heat and other projects 
handle it)?

>> Guys, please contribute this thread to fill the points/things I missed
>> or pop up in #openstack-zaqar channel directly with questions and
>> suggestions.
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-- 
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.