753577 - posting to autolog is broken....again.... :(

Status: RESOLVED WONTFIX

(Testing :: Talos, defect)

Description

[Jeff Hammel]

On production:

https://tbpl.mozilla.org/php/getParsedLog.php?id=11572779&tree=Firefox&full=1

Since its still green no one cares or notices.  Do we care about
posting to autolog?  If we do, we should care if its down.  If its
not, great, we can remove code.

This isn't the first time that this has happened.  It won't be the
last.

Comment 1

[Phil Ringnalda (:philor)]

There's a couple different ways you can go with "cares or notices":

* you can make it my responsibility, by turning the build colors when it doesn't post, but to do that you'll have to make it a tier 1 test, at the very least by running it on every (trunk, mozilla-central-related) branch. It was only visible on tbpl because I hadn't ever noticed it was there because it hasn't ever turned colors - you cannot have something visible on mozilla-central if you don't run it on everything that merges to mozilla-central

* you can make it your responsibility, by either alerting yourselves when you haven't heard about a run for 24 hours, or getting more fancy and using pulse to sometimes in a fallible way tell you or not tell you, whichever it feels like doing, every time a build that should trigger xperf happens

Comment 2

[Jeff Hammel]

I don't care enough about the xperf tests to make it my responsibility.  I am fine with deleting the code or fixing it.  If we do take the obvious fix -- changing the IP address when jgriffin provides a correct IP -- the same thing will happen again.  The IP will change.  It will fail on TBPL. It won't be noticed.  I will investigate something else and find out that it isn't reporting to autolog and write another bug.  My point is that changing the IP == not caring about the problem.

If we do care or hope to care someday about these autolog results, the first thing to do, IMHO, is to make the URL more configurable.  Not only is it hardcoded (for network topologies, AIUI, since the build machines cannot resolve the server by its FQDN), it is very difficult to find and not overrideable from either a .yml file or from the command line.  We should fix this first.  Additionally, we should actually depend on the mozautolog package unless there is a reason not to.  Instead we just copy the file.  If there are updates that we depend on (which has happened before) we are also broken.  xtalos is basically shoved in a little corner and not kept up, partially a symptom of being a subshell in a subshell which affects only one platform and isn't tier 1.

In any case, I would like to care about it or bury it.  It is another moving part that is going to require maintenance.  The question is, is it worth it?

Comment 3

[Joel Maher ( :jmaher ) (UTC -8)]

I think we should post to the new graph server.

Comment 4

[Jonathan Griffin (:jgriffin)]

The problem with posting to autolog is that port 80 on brasstack's internal IP is not open.  I can file a bug to open this if you want to continue posting to autolog, but it sounds like perhaps this will be moved to the new graph server.

If you'd like me to file that bug, let me know.

Comment 5

[Joel Maher ( :jmaher ) (UTC -8)]

we are reworking xperf to report 100% different numbers and this will be reported to graph server and datazilla.