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 <mi...@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.decan...@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 <mi...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Juan Antonio Osorio R. e-mail: jaosor...@gmail.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev