>I agree it makes sense to co-own statsv. I think it also needs to have a primary maintainer/point of contact if issues beside basic operational monitoring come up (e.g. general >maintenance and updates). What do you think? Sounds fine. Also, probably performance team doesn't mind to contribute to its maintenance as long as they are not in on the hook for ops.
I have created a page to ducument operational tasks, linked from : https://wikitech.wikimedia.org/wiki/Graphite#statsv https://wikitech.wikimedia.org/wiki/Analytics/statsv On Mon, Nov 14, 2016 at 11:57 AM, Filippo Giunchedi < [email protected]> wrote: > I agree it makes sense to co-own statsv. I think it also needs to have a > primary maintainer/point of contact if issues beside basic operational > monitoring come up (e.g. general maintenance and updates). What do you > think? > > thanks, > Filippo > > On Mon, Nov 14, 2016 at 8:21 AM, Andrew Otto <[email protected]> wrote: > >> +ops >> >> Analytics (Otto & Luca) probably have the most experience with python >> kafka clients, and also are the most likely to cause statsv problems, (due >> to analytics kafka broker restarts, etc.). So it makes sense for us to be >> at least partially responsible. >> >> On the other hand, statsv is for operational/performance metrics, so it’d >> be good if ops/performance folks had their eyes on it too. Can ops >> monitoring (Filippo?) and analytics co-own this service? I can do some >> work soon to update the Kafka client, but we should all know how it works >> and be ready and willing to modify or restart it. >> >> >> >> >> _______________________________________________ >> Ops mailing list >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/ops >> >> > > _______________________________________________ > Ops mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/ops > >
_______________________________________________ Analytics mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/analytics
