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: >> [email protected]?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: [email protected] Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington -------------------------------------------------------------------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
