Open Stack

I think it would simplify deployment a fair bit too -- a single API to
provide instead of also having to setup a notification listener. I shall
ponder and perhaps implement once I've finished the privsep stuff.

Michael

On Fri, Mar 16, 2018 at 5:49 PM, Juan Antonio Osorio <jaosorior at gmail.com>
wrote:

> Having an interface for vendordata that gets deletes would be quite nice.
> Right now for novajoin we listen to the nova notifications for updates and
> deletes; if this could be handled natively by vendordata, it would simplify
> our codebase.
>
> BR
>
> On Fri, Mar 16, 2018 at 7:34 AM, Michael Still <mikal at stillhq.com> wrote:
>
>> Thanks for this. I read the README for the project after this and I do
>> now realise you're using notifications for some of these events.
>>
>> I guess I'm still pondering if its reasonable to have everyone listen to
>> notifications to build systems like these, or if we should messages to
>> vendordata to handle these actions. Vendordata is intended at deployers, so
>> having a simple and complete interface seems important.
>>
>> There were also comments in the README about wanting to change the data
>> that appears in the metadata server over time. I'm wondering how that maps
>> into the configdrive universe. Could you explain those comments a bit more
>> please?
>>
>> Thanks for your quick reply,
>> Michael
>>
>>
>>
>>
>> On Fri, Mar 16, 2018 at 2:18 PM, Pino de Candia <
>> giuseppe.decandia at gmail.com> wrote:
>>
>>> Hi Michael,
>>>
>>> Thanks for your message... and thanks for your vendordata work!
>>>
>>> About your question, Tatu listens to events on the oslo message bus.
>>> Specifically, it reacts to compute.instance.delete.end by cleaning up
>>> per-instance resources. It also listens to project creation and user role
>>> assignment changes. The code is at:
>>> https://github.com/openstack/tatu/blob/master/tatu/notifications.py
>>>
>>> best,
>>> Pino
>>>
>>>
>>> On Thu, Mar 15, 2018 at 3:42 PM, Michael Still <mikal at stillhq.com>
>>> wrote:
>>>
>>>> Heya,
>>>>
>>>> I've just stumbled across Tatu and the design presentation [1], and I
>>>> am wondering how you handle cleaning up instances when they are deleted
>>>> given that nova vendordata doesn't expose a "delete event".
>>>>
>>>> Specifically I'm wondering if we should add support for such an event
>>>> to vendordata somehow, given I can now think of a couple of use cases for
>>>> it.
>>>>
>>>> Thanks,
>>>> Michael
>>>>
>>>> 1: https://docs.google.com/presentation/d/1HI5RR3SNUu1If-A5Z
>>>> i4EMvjl-3TKsBW20xEUyYHapfM/edit#slide=id.p
>>>>
>>>> ____________________________________________________________
>>>> ______________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: OpenStack-dev-request at lists.op
>>>> enstack.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.op
>>> enstack.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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Juan Antonio Osorio R.
> e-mail: jaosorior at gmail.com
>
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180319/4f604ec5/attachment.html>