Open Stack

On Wed, Apr 13, 2016 at 05:12:08PM -0500, Dolph Mathews wrote:
> On Wed, Apr 13, 2016 at 2:37 PM, Emilien Macchi <emilien at redhat.com> wrote:
> 
> > On Wed, Apr 13, 2016 at 12:13 PM, Matthew Treinish <mtreinish at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160413/36e9572d/attachment.pgp>