Open Stack

On 31/05/15 18:12 +0000, Ildikó Váncsa wrote:
>Hi All,
>
>I would like to ask about the user-facing notifications part of the list. Do you have a roadmap for this? Is this driven by the Zaqar team? What are the next steps?

Hey,

This will require cross-project efforts and we (the Zaqar team) would
love to get some help here. If anyone is willing to drive the spec and
sync, the Zaqar team would be happy to help with other tasks.

I think it'd be really beneficial to start doing it in one of the
services (Heat?) as a PoC, while we discuss the cross-project spec and
feed it with the things we'll learn from the PoC.

Would you like to help with this?

Cheers,
Flavio

>
>Thanks and Best Regards,
>Ildikó
>
>-----Original Message-----
>From: Clint Byrum [mailto:clint at fewbar.com]
>Sent: May 27, 2015 18:42
>To: openstack-dev
>Subject: Re: [openstack-dev] [Zaqar][all] Zaqar will stay... Lots of work ahead
>
>Excerpts from Flavio Percoco's message of 2015-05-26 01:28:06 -0700:
>> Greetings,
>>
>> TL;DR: Thanks everyone for your feedback. Based on the discussed plans
>> at the summit - I'll be writing more about these later - Zaqar will
>> stick around and play its role in the community.
>>
>> Summit Summary
>> ==============
>>
>> I'm happy to say that several use cases were discussed at the summit
>> and the difference from previous summits is that we left the room with
>> some action items to make them happen.
>>
>> Cross-project user-facing notifications
>> =======================================
>>
>> https://etherpad.openstack.org/p/liberty-cross-project-user-notificati
>> ons
>>
>> Besides brainstorming a bit on what things should/should not be
>> notified and what format should be used, we also talked a bit about
>> the available technologies that could be used for this tasks. Zaqar
>> was among those and, AFAICT, at the end of the session we agreed on
>> giving this a try. It'll likely not happen as fast as we want but the
>> action item out of this session was to write a cross-project spec
>> describing the things discussed and the technology that will be
>> adopted.
>>
>
>My takeaway from that session was that there's need for something like yagi to filter the backend notifications into user-consumable tenant-scoped messages, and that Zaqar would be an interesting target for those messages along with Atom feeds or perhaps other pub/sub oriented things that deployers would be comfortable hosting for their users.
>
>> Heat + Zaqar
>> ============
>>
>> The 2 main areas where Zaqar will be used in Heat are Software Config
>> and Hooks. The minimum requirements (server side) for this are in
>> place already. There's some work to do on the client side that the
>> team will get to asap.
>>
>
>The bigger one to me is just user-notificiation which I think is covered in the cross project session, but it's worth noting that Heat is one of the projects that already does some user notification and suffers problems because of it (the events API is what I mean here).
>
>> Next Steps
>> ==========
>>
>> In light of the above, and as mentioned in the TL;DR, Zaqar will stick
>> around and the team, as promised, will focus on making those
>> integrations happen. The team is small, which means we'll carefully
>> pick the tasks we'll be spending time on.
>>
>> As a first step, we should restore our meetings and get to work right
>> away. To favor our contributors in NZ, next week's meeting will be at
>> 21:00 UTC and we'll keep it at that time for 2 weeks.
>>
>> For the Zaqar team (and folks interested), I'll be sending out further
>> emails to sync on the work to do.
>>
>> Special thanks for all the folks that showed interest, participated in
>> sessions and that are committed on making this happen.
>>
>
>Thanks for setting things up for success before the summit. I think we all went into the discussions with an open mind because we knew where the team stood.
>
>
>== Crazy idea section ==
>
>One thing I never had a chance to discuss with any of the Zaqar devs that I would find interesting is an email-only backend for Zaqar. Basically make Zaqar an HTTP-to-email gateway. There are quite a few hyper-scale options for SMTP and IMAP, and they're inherently multi-tenant, so I'd find it interesting to see if the full Zaqar API could be mapped onto that. This would probably be more comfortable to scale for some deployers than Redis or MongoDB, and might have the nice side-effect that a deployer could expose IMAP IDLE for efficient end-user subscription, and it could also allow Zaqar to serve as email-as-a-service for senders too (to prevent getting all your vms' IPs added to spam lists overnight. ;)
>
>__________________________________________________________________________
>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
>
>__________________________________________________________________________
>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

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150601/0589faa0/attachment.pgp>