From ssbarnea at redhat.com  Tue Jun  2 09:08:49 2020
From: ssbarnea at redhat.com (Sorin Sbarnea)
Date: Tue, 2 Jun 2020 10:08:49 +0100
Subject: [OpenStack-Infra] Can we use short domain names for build log
	servers?
Message-ID: <B77764CD-32D6-4758-9D23-B8AFFAC3A96D@redhat.com>

I would like to re-raise an older question: what can we do to avoid using human-unfriendly URLs for our build logs?

The current setup lead us to some URLs that seems more like a way to test client limitations.


I know that we use object storage from various providers but that should not be an excuse for having more human urls, maybe even using our own domains.
Using a CDN does not require ugly logs urls, that is for sure.


One random example (not even the worst):
https://27171abe9707251ada06-40d76dc3f646b86e4453b642950e6efd.ssl.cf2.rackcdn.com/729996/2/check/tox-py35/2c5d394/

Only the domain is >70 chars long, why not having something like logN.opendev.org instead?


Current URLs are backend urls, something that was not designed to be facing the consumer.


How does someone have to guess that this url is linked to openstack of opendev in any way? They would have to trust me that it does not include a magic blob that would highjack their browser. It is not uncommon for me to raise bugs to other opensource projects that never heard of zuul. Maybe if we start serving our logs in more friendly way, we can also market Zuul CI/CD better.



Why it matters:

- I often browse various log files, even on a hires desktop monitor I am unable to read the filename of the log because the window barely fits the domain name alone. Not even the changeset seems to fit the visible part of the url
- we need to share links to logs, long ones are impose additional problems, including splitting on irc.
- smaller screens


I will end with one of my favourite quotes: 

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

Lets take out a bit of this URL complexity.

Thanks
Sorin



From corvus at inaugust.com  Tue Jun  2 17:22:49 2020
From: corvus at inaugust.com (James E. Blair)
Date: Tue, 02 Jun 2020 10:22:49 -0700
Subject: [OpenStack-Infra] Can we use short domain names for build log
	servers?
In-Reply-To: <B77764CD-32D6-4758-9D23-B8AFFAC3A96D@redhat.com> (Sorin
 Sbarnea's message of "Tue, 2 Jun 2020 10:08:49 +0100")
References: <B77764CD-32D6-4758-9D23-B8AFFAC3A96D@redhat.com>
Message-ID: <87h7vtz8k6.fsf@meyer.lemoncheese.net>

Sorin Sbarnea <ssbarnea at redhat.com> writes:

> I would like to re-raise an older question: what can we do to avoid
> using human-unfriendly URLs for our build logs?

When was this question previously asked?

> The current setup lead us to some URLs that seems more like a way to
> test client limitations.

What limitations?

> I know that we use object storage from various providers but that
> should not be an excuse for having more human urls, maybe even using
> our own domains.
> Using a CDN does not require ugly logs urls, that is for sure.
>
>
> One random example (not even the worst):
> https://27171abe9707251ada06-40d76dc3f646b86e4453b642950e6efd.ssl.cf2.rackcdn.com/729996/2/check/tox-py35/2c5d394/
>
> Only the domain is >70 chars long, why not having something like logN.opendev.org instead?

Several of our storage providers have unique requirements, including one
which serves data from hundreds of unpredictable domains.

For a more complete understanding of the requirements leading to our
current system, you may want to read this message (and the message it
links to):

  http://lists.zuul-ci.org/pipermail/zuul-discuss/2018-July/000501.html

> Current URLs are backend urls, something that was not designed to be facing the consumer.

I agree.  The URLs that we report to the end user go to the Zuul
dashboard, and we encourage and expect users to browse logs via that
method.  It may then link to direct access to individual log files
(especially files it can't display), but that would only be after the
user has visited OpenDev Zuul's dashboard and will know they are at the
right place (to address your point below).

> How does someone have to guess that this url is linked to openstack of
> opendev in any way? They would have to trust me that it does not
> include a magic blob that would highjack their browser. It is not
> uncommon for me to raise bugs to other opensource projects that never
> heard of zuul. Maybe if we start serving our logs in more friendly
> way, we can also market Zuul CI/CD better.
>
> Why it matters:
>
> - I often browse various log files, even on a hires desktop monitor I
> am unable to read the filename of the log because the window barely
> fits the domain name alone. Not even the changeset seems to fit the
> visible part of the url
> - we need to share links to logs, long ones are impose additional
> problems, including splitting on irc.
> - smaller screens

I agree with all of those points, which is why we have focused on making
the log browser in the dashboard as pleasant and functional as possible.
If you're not being linked to it, or are not using it, I'd love to know
why.  Improving that is the best way to make Zuul more marketable as you
suggest (after all, if OpenDev sets up a complex system to mask the
domain names of log services, that's not necessarily something other
Zuul users can do).

-Jim


From fungi at yuggoth.org  Tue Jun  2 17:35:35 2020
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 2 Jun 2020 17:35:35 +0000
Subject: [OpenStack-Infra] Can we use short domain names for build log
 servers?
In-Reply-To: <B77764CD-32D6-4758-9D23-B8AFFAC3A96D@redhat.com>
References: <B77764CD-32D6-4758-9D23-B8AFFAC3A96D@redhat.com>
Message-ID: <20200602173535.nooumjwuxldcchmh@yuggoth.org>

On 2020-06-02 10:08:49 +0100 (+0100), Sorin Sbarnea wrote:
[...]
> Current URLs are backend urls, something that was not designed to
> be facing the consumer.
[...]

James addressed the other points pretty thoroughly, but I wanted to
raise a slight objection to this assertion. Public-facing object
storage is intended precisely for cases of serving various
files/media to browsers so as to offload the traffic from your
normal Web server. Maybe instead of backend you meant background? I
don't consider there to be anything wrong with sites telling
browsers to directly fetch some files from object storage rather
than proxying their requests (most frequent use of this is for
images and videos).
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20200602/6e7ee50e/attachment.sig>