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 <jaosor...@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 <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.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 >> >> > > > -- > 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 > >
__________________________________________________________________________ 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
