On Wed, Apr 13, 2016 at 05:12:08PM -0500, Dolph Mathews wrote: > On Wed, Apr 13, 2016 at 2:37 PM, Emilien Macchi <emil...@redhat.com> wrote: > > > On Wed, Apr 13, 2016 at 12:13 PM, Matthew Treinish <mtrein...@kortar.org> > > wrote: > > > On Wed, Apr 13, 2016 at 10:59:10AM -0400, Emilien Macchi wrote: > > >> Hi, > > >> > > >> Current OpenStack Infra Periodic jobs do not send e-mails (only > > >> periodic-stable do), so I propose to create periodic-ci-reports > > >> mailing list [1] and to use it when our periodic jobs fail [2]. > > >> If accepted, people who care about periodic jobs would like to > > >> subscribe to this new ML so they can read quick feedback from > > >> failures, thanks to e-mail filters. > > > > > > So a big motivation behind openstack-health was to make doing this not > > > necessary. In practice the ML posts never get any real attention from > > people > > > and things just sit. [3] So, instead of trying to create another ML here > > > I think it would be better to figure out why openstack-health isn't > > working > > > for doing this and figure out how to improve it. > > > > I like openstack-health, I use it mostly every day. > > Though I miss notifications, like we have with emails. > > Something we could investigate is RSS support in openstack-health. > > > > I guess everyone is different. Outside of automated systems, I don't > interface with RSS/atom anymore myself (~since Google Reader was shutdown). > > I've investigated every mailing-list based notification I've ever received, > however I don't feel compelled to respond to the mailing list thread (if > that is a metric anyone is looking at here).
TBH, I don't think that's a metric that's relevant here. The argument that was being made earlier was that people want a ML to report results to because it acts as a notification system for periodic gate failures. The contention was that it enables people to respond quickly when things start to fail. But, what I was saying is that past experience has shown that in practice this is never the case. No one is actually on call for dealing with failures when they come in. So what ends up really happening is that failures just sit on the list and repeat every day. The ML is also pretty bad interface for dealing with this sort of thing over time. This problem was a big part of why openstack-health was developed. The RSS/atom idea is a compromise to provide an alternative for everyone who still says they want a notification on failures but would be more tightly integrated with the rest of the systems we're working on here. FWIW, I started doodling on doing this here: https://review.openstack.org/305496 it's still pretty far from complete, but it's a starting point. > > OpenStack Health is cool, but I certainly won't check it with any > regularity. This is actually the behavior I think we want to address. One of the goals for the project is to make it the go to spot for investigating anything related to the gate. Identifying the gaps that are preventing it from being a useful tool for you and other people is important for this goal. So I'm gonna put you on the spot, what do you think is missing from making this really useful for you today? -Matt Treinish > > >> > > >> The use-case is described in [2], please use Gerrit to give feedback. > > >> > > >> Thanks, > > >> > > >> [1] https://review.openstack.org/305326 > > >> [2] https://review.openstack.org/305278 > > > [3] > > http://lists.openstack.org/pipermail/openstack-dev/2016-February/086706.html
signature.asc
Description: PGP signature
__________________________________________________________________________ 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