Open Stack

On 11/11/15 04:32, Ryan Brown wrote:
> 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.
>
I have contacted with jd and will see if we can use that to get the
notifications.
>>> 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)?
>
Basically, yes.
>>> 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
>>
>

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