Open Stack

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.openstack.org?subject:unsubscrib
>> e
>> 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
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosorior at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180316/0a740758/attachment-0001.html>