From nobody Tue Sep 1 05:11:40 2020
Return-Path:
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EA43A0FDE for ; Tue, 1 Sep 2020 05:11:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.847
X-Spam-Level:
X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGN4lbU8LgF6 for ; Tue, 1 Sep 2020 05:11:37 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497A03A0FDF for ; Tue, 1 Sep 2020 05:11:37 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:58337 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1kD58S-0008U0-7A; Tue, 01 Sep 2020 05:11:36 -0700
To: Robert Sparks , "tools-implementation@ietf.org"
References:
From: Henrik Levkowetz
Message-ID: <0447d10d-7846-60f2-ce4b-9acda26bd108@levkowetz.com>
Date: Tue, 1 Sep 2020 14:11:28 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To:
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Df4hFIpag4qnx2C5LTtNaacoxEmtJko7I"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: tools-implementation@ietf.org, rjsparks@nostrum.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At:
Subject: Re: [Tools-implementation] Why we're looking at the filesystem structure
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 01 Sep 2020 12:11:39 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Df4hFIpag4qnx2C5LTtNaacoxEmtJko7I
Content-Type: multipart/mixed; boundary="rWXWCN0jrkosMXMokcrBWxIhrHxpaaKQd";
protected-headers="v1"
From: Henrik Levkowetz
To: Robert Sparks ,
"tools-implementation@ietf.org"
Message-ID: <0447d10d-7846-60f2-ce4b-9acda26bd108@levkowetz.com>
Subject: Re: [Tools-implementation] Why we're looking at the filesystem
structure
References:
In-Reply-To:
--rWXWCN0jrkosMXMokcrBWxIhrHxpaaKQd
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
I think this is right. Good points.
Henrik
On 2020-09-01 05:09, Robert Sparks wrote:
> I've been thinking deeply about both Glen and Henrik's questions about =
> why we are looking at the filesystem structure and what our goals are=20
> when we talk about changing it.
>=20
> One insight that I think I've identified is that this activity is a=20
> means to an end, not an end in itself, and we are probably being=20
> distracted by focusing on what the filesystem structure should be.
>=20
> It's more important to understand what we really _have_ than it is to=20
> "fix" it (though I think we should keep the pressure up on making it=20
> better).
>=20
> The more important goals are being able to discuss doing something less=
=20
> painful to us (operators and coders) and more useful to the community=20
> than what we're doing now with providing services. When we've tried to =
> approach those in the past, we've felt that we need to do things like=20
> reduce confusion in the URL namespace at www.ietf.org and understand th=
e=20
> subtle requirements we currently have with services relying on files in=
=20
> the various places we have them. Talking about _those_ things, we've=20
> run quickly into the need to understand what the files we have are all =
> about, and then get lost focusing on changes rather than understanding =
> what's there.
>=20
> I think we're risking getting lost again. The apparent goal we're=20
> pushing towards (defining a better structure) is not really the what=20
> we're trying to achieve, though it is providing a good pressure for=20
> making progress towards those more important goals.
>=20
> We need to understand and document the things we have. The=20
> keep/archive/discard conversations are good ways to help us build that =
> understanding, but if we build a "perfect" structure in isolation of=20
> what we're going to do with it, the effort isn't going to pay back well=
=2E=20
> We need to make sure we understand what we're going to do with the resu=
lt.
>=20
> Reducing confusion in the www.ietf.org URL namespace is both a "make it=
=20
> easier for the user" and "make it simpler for the code and operations" =
> goal. Being able to _know_ whether we can pull a service off into the=20
> cloud without breaking other services (or at least really understanding=
=20
> how those other services will have to change) is a prerequisite for=20
> reducing our pain, and improving the experience for the community. Thos=
e=20
> are goals we should make sure we are moving towards.
>=20
> There are obvious things to change with where we're keeping things (and=
=20
> in some cases, what we're keeping), yes. Let's change them.
>=20
> But I think we should change the timbre of the conversation and make=20
> sure we're talking about "what is that" and "what/who uses that" at=20
> least as much as we're talking about "do we need to keep this". (But=20
> let's not ignore "should we keep this" and "what do we do with it if we=
=20
> _do_ keep it" as we're talking about it).
>=20
> RjS
>=20
>=20
--rWXWCN0jrkosMXMokcrBWxIhrHxpaaKQd--
--Df4hFIpag4qnx2C5LTtNaacoxEmtJko7I
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl9OOnAACgkQTptXS4+7
Fxr2FBAAkdDsQS3BOezpZix6jeGbbwhLKzGZgdghgj8s4bgGHrc+jRZDFf9IfH2c
hRICoiD1BimtoR3Z6JzCMFdEdQS+/MqqjTERF5Vw3S5FX/+5BDDZQ8w6Cb18hIEh
2ZZ6RJ5y4mbu4I7e7J8NVwAEqIe9HsPZIa2OL+YIrXRjlamM7OHbZnoVmJUfqA0F
2FL38akqDxD/es1TD7TwFnQKqLjA44ZclM0kQRcnScD6M0m1MvQdLemrd5uVf900
V2BvxqBYk23ORwFvd/6R5kSGp0pKUtK6ziwW8C6CgB3pKpD3XjBAvDKG2EUGnTyR
opwoXysuseqMXd1KvLsQp1s4hpljIkwNgDupm43qvxO7lNZ9DYlsV3q8onz3ucEp
8xMtAdBHVtlqMe64v1FusOoixk+SUIyZyuBSaHfJcogYvAXozaYtcX0FU8HYoCcN
jLCsf55vaVyBGliAt7sP8nMk8MkbD8v1ZhmGfiWKfq6d0UW+qF4hXFOXULx2X4Nj
9zgMj8VUF+62KG9Lvc0VVmNi5iOHWBc5BonGKlTH7+7fGlx9WBzWEaqiy/lQIC8r
eoC7eN5iR93GCnnBHBD7I5Wp8FDsb32Z38atbWae6xXo5hVWdGuJMVNl461Ua07x
QSty6nN7Fj1y42D+aZpfVWVrT8DCu3NdxceUAtYsgKcwNXUHhSk=
=Mbh+
-----END PGP SIGNATURE-----
--Df4hFIpag4qnx2C5LTtNaacoxEmtJko7I--
From nobody Tue Sep 1 09:33:16 2020
Return-Path:
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B21E3A08FB for ; Tue, 1 Sep 2020 09:33:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.079
X-Spam-Level:
X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pD9wx2hqSG2q for ; Tue, 1 Sep 2020 09:33:13 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9597B3A08F6 for ; Tue, 1 Sep 2020 09:33:13 -0700 (PDT)
Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 081GX8EC056382 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 1 Sep 2020 11:33:09 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1598977989; bh=DRPNvl4DbEsarZSrppJK6C9wufvfoBwoWFP+5BnjRVw=; h=To:Cc:From:Subject:Date; b=Ber/b1w9jXcbExaCfB/I/7Pb6LgeEDS4yiXm3+982fBvKtT7mkpIJtKiWkeJ4nzrI 4p6CGMdUpz6Q0sEnI3pdDctnVz6MbAOh+EY2CbTiSZ18+x5AXIR0Hr6tHnend0Gt4V qakTdih1Azbul1hSVEpeAS1t7BuLABMDpNPUPPm0=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local
To: "tools-implementation@ietf.org"
Cc: Ryan Cross
From: Robert Sparks
Message-ID: <04ca622f-002c-5157-827c-fb5090b2cf75@nostrum.com>
Date: Tue, 1 Sep 2020 11:33:08 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At:
Subject: [Tools-implementation] A usability anecdote on the mailarchive tool
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 01 Sep 2020 16:33:15 -0000
I was catching up on the gendispatch list today using thunderbird to
read the list through the IETF imap service.
I encountered a couple of days of messages that were not being served
correctly through that service (Ryan is looking at fixing that). They
were served through the http-based mailarchive service just fine,
however, so I shifted to those to complete my goal of catching up.
And I found that I was significantly more than twice as slow reading the
view via mailarchive than I was reading it through thunderbird. I
started poking at why, and a lot of it has to do with how the css at
mailarchive renders whitespace around quotations. Some has to do with
contrast, and some has to do with the need to scroll more.
I also lost time to learning to discard things that were in my face but
I didn't have to read. Those would eventually be trained into me, but
before accepting them I think perhaps I should push back about them.
(Like the thread index at the bottom of the message - that should
perhaps be collapsed or otherwise made very visually distinct).
So I wonder if we should look for outside help in assessing how the view
can be made more ergonomic (and also assess how the community is really
using the tool)?
RjS
From nobody Tue Sep 1 10:23:48 2020
Return-Path:
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C863A0BFD for ; Tue, 1 Sep 2020 10:23:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.848
X-Spam-Level:
X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZiXENrnxmuY for ; Tue, 1 Sep 2020 10:23:46 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 160DC3A0BDA for ; Tue, 1 Sep 2020 10:23:46 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:59541 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1kDA0X-0002q1-87; Tue, 01 Sep 2020 10:23:45 -0700
To: Robert Sparks , "tools-implementation@ietf.org"
References: <04ca622f-002c-5157-827c-fb5090b2cf75@nostrum.com>
Cc: Ryan Cross
From: Henrik Levkowetz
Message-ID: <845a2ad2-69ee-f282-7057-e241839480df@levkowetz.com>
Date: Tue, 1 Sep 2020 19:23:38 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <04ca622f-002c-5157-827c-fb5090b2cf75@nostrum.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LEUrkGwfsJegdPDmgnLQA8wUArtTqR0b9"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: rcross@amsl.com, tools-implementation@ietf.org, rjsparks@nostrum.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At:
Subject: Re: [Tools-implementation] A usability anecdote on the mailarchive tool
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 01 Sep 2020 17:23:48 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--LEUrkGwfsJegdPDmgnLQA8wUArtTqR0b9
Content-Type: multipart/mixed; boundary="caCoq2XDFvIFde6r5m1jt3iLI8KcFCj5U";
protected-headers="v1"
From: Henrik Levkowetz
To: Robert Sparks ,
"tools-implementation@ietf.org"
Cc: Ryan Cross
Message-ID: <845a2ad2-69ee-f282-7057-e241839480df@levkowetz.com>
Subject: Re: [Tools-implementation] A usability anecdote on the mailarchive
tool
References: <04ca622f-002c-5157-827c-fb5090b2cf75@nostrum.com>
In-Reply-To: <04ca622f-002c-5157-827c-fb5090b2cf75@nostrum.com>
--caCoq2XDFvIFde6r5m1jt3iLI8KcFCj5U
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
On 2020-09-01 18:33, Robert Sparks wrote:
> I was catching up on the gendispatch list today using thunderbird to=20
> read the list through the IETF imap service.
>=20
> I encountered a couple of days of messages that were not being served=20
> correctly through that service (Ryan is looking at fixing that). They=20
> were served through the http-based mailarchive service just fine,=20
> however, so I shifted to those to complete my goal of catching up.
>=20
> And I found that I was significantly more than twice as slow reading th=
e=20
> view via mailarchive than I was reading it through thunderbird. I=20
> started poking at why, and a lot of it has to do with how the css at=20
> mailarchive renders whitespace around quotations. Some has to do with=20
> contrast, and some has to do with the need to scroll more.
>=20
> I also lost time to learning to discard things that were in my face but=
=20
> I didn't have to read. Those would eventually be trained into me, but=20
> before accepting them I think perhaps I should push back about them.=20
> (Like the thread index at the bottom of the message - that should=20
> perhaps be collapsed or otherwise made very visually distinct).
+1
Collapse and greyed-out when collapsed, and not visually part of the
message pane.
> So I wonder if we should look for outside help in assessing how the vie=
w=20
> can be made more ergonomic (and also assess how the community is really=
=20
> using the tool)?
Ack.
--caCoq2XDFvIFde6r5m1jt3iLI8KcFCj5U--
--LEUrkGwfsJegdPDmgnLQA8wUArtTqR0b9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl9Og5oACgkQTptXS4+7
Fxr0yQ/+IBzDY942pmLB5BWVbQ8wPwKAldiu80tAHXZ9ZBRBk7pTyJnZtaei60cM
ic41qfoFbJciEZBd9/G18A7tOu3q4mK+r/zyCeiNjooXGx1bWpHWwnoVW00gWmWy
jWELjAMDrJRIc1yJID0w3dIvOzm78BuczoIoukHC1w0C/ImqIiagPSydiqEx0Ax5
akvAp0nLKOYoADalY/R3qyTrfesXtwM8uzw6QuLbBwIpqp64pBfKLwCpTvxal1G9
G/svCOrf2yZx2f5+rQSBZLHeCo5jAZKghb3oexwQJLUb7FSe77vcNhyKpgp8Fjlc
JX58K1yPyTQPH0xeRfPUAsLU7ou2TyidLdgGQFrjcjL4+nv504uPu8KYcVFnCjGT
BCTKABfIgI6zx59ZQlsXOvXXUy8n+reGCdyEU7FNDFFm3mJRzXxclYNLfplsJDJn
F/Fkx7zPIXSsB9CFf5uA+Y6mL0oqWIQ0lPZIX2diBKHdtOW9XPWnwsvvtDp9aWHF
Kz94814BKZct5KuQjQYYPNIYvPO75o9/NnMHDlV3Xppywx8LRK9QElPqWZsSn04S
je3TgXdXZAQJlNadBIVZcKqhpHGhv2ojLt2dF0mE2pquwuyhZYGipMXtczRX2m+0
YbFZlbHnXVJhUzXqU8iIOLUqw0/bq0BR+56ACTJlDp/MyFMY4oo=
=Sa8B
-----END PGP SIGNATURE-----
--LEUrkGwfsJegdPDmgnLQA8wUArtTqR0b9--
From nobody Tue Sep 1 10:31:07 2020
Return-Path:
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF903A0C45 for ; Tue, 1 Sep 2020 10:31:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.28
X-Spam-Level:
X-Spam-Status: No, score=-1.28 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQyzw-4ASrC4 for ; Tue, 1 Sep 2020 10:31:03 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C543A0C28 for ; Tue, 1 Sep 2020 10:31:01 -0700 (PDT)
Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 081HUuNE076901 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 1 Sep 2020 12:30:58 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1598981458; bh=8HhH07m7qStJ78Fi47Wlj7boR169H5E9P4kbVWLaKGg=; h=Subject:To:References:From:Date:In-Reply-To; b=YojBG8wvBttgiDaZpFIKyCDQ77cQGQ4DrFVkkgQETmdxTm29GSy5GBIkAfGgEJpv9 EM29UjSMCpnjV+N5LhK1lo81FybIh2MwCV5TGdFxqoW4PVZr9Dp15hl/qmt4FxP6iN oFGQC5C6CITLdY9pQyH1ApD+X21H8vUBBsqbRgTw=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local
To: Ryan Cross , "tools-implementation@ietf.org"
References: <751dc801-bd0a-ed46-e21e-c4ff5cecc8f2@nostrum.com> <590C0EF3-79A5-411F-B745-D8BAA085BEE6@amsl.com>
From: Robert Sparks
Message-ID: <8ec50ff6-471b-f698-5e61-b6034509e930@nostrum.com>
Date: Tue, 1 Sep 2020 12:30:56 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <590C0EF3-79A5-411F-B745-D8BAA085BEE6@amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At:
Subject: [Tools-implementation] Organization of the mail archives
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 01 Sep 2020 17:31:06 -0000
After consulting with Ryan, I propose this disposition for the following
email archive related directories:
>> Legacy Mailarchive /a/ietf A few very old mail archive scripts
This can simply be removed. The scripts are no longer used.
>> Email Mailarchive /a/isode ISODE IMAP server data store
>> Email Mailarchive /a/mailarch Mail Archive operations
These should stay where they are.
/a/mailarch/data/archive is the _authoritative_ store.
/a/mailarch/data/mbox_archive/public is an automatically generated set
of mbox files generated from the authoritative store. That should be
used to replace several things below.
>> Email Mailman /a/mailman Mailman operations
That has to remain (though we should consider what to do with it when we
bring in Mailman3
>> Email Mailman /a/mailman/archives Mailman Legacy Archives
This has to remain - it is where mailman's internal archiving takes
place - any lists using pipermail are kept here, so Legacy isn't really
accurate above
>>
>> Email Postfix /a/postfix Postfix operations
This remains
>> FTP FTP/Website combined /a/www/ietf-ftp/concluded-wg-ietf-mail-archive ftp, rsync none NOT exposed by http
>>
These have all been imported, and are served through the mailarchive.
These should be stashed. I personally don't think we should serve them
in any way since they are available through the mailarchive. If they are
served, they should clearly be in something I'd like to start calling
the "museum".
>
>> FTP FTP/Website combined /a/www/ietf-ftp/ietf-mail-archive Contains text versions of mail archive ftp, rsync night-runner All web access is to the /a/www/ietf-mail-archive tree, which this is a copy of
This should go away as soon as ftp stops depending on it (and we had
another conversation about removing it already).
>> Email Mailarchive /a/www/ietf-mail-archive Legacy mail archive
>> Email Mailarchive /a/www/ietf-mail-archive/text
>> Email Mailarchive /a/www/ietf-mail-archive/text-secure
>> Email Mailarchive /a/www/ietf-mail-archive/web
>> Email Mailarchive /a/www/ietf-mail-archive/web-old
>> Email Mailarchive /a/www/ietf-mail-archive/web-secure
>>
>> Again, has all of that been imported, and can all of this simply be removed (or stashed offline)?
All of this should be stashed. Everything here, with the possible
exception of things in web-old have been imported into mailarchive. Ryan
is looking at making sure those get imported. Once that's done, all of
these should either be taken offline or put in the museum.
Are there any other puddles of email-archive related things that aren't
in those directories?
From nobody Tue Sep 1 10:44:37 2020
Return-Path:
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF68A3A0C08 for ; Tue, 1 Sep 2020 10:44:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.909
X-Spam-Level:
X-Spam-Status: No, score=-101.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kosmVbcyk3kU for ; Tue, 1 Sep 2020 10:44:35 -0700 (PDT)
Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41A473A0C07 for ; Tue, 1 Sep 2020 10:44:35 -0700 (PDT)
Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 9B6D63C3C22 for ; Tue, 1 Sep 2020 10:44:23 -0700 (PDT)
Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) by c8a.amsl.com (Postfix) with ESMTPSA id 7A2113C3C21 for ; Tue, 1 Sep 2020 10:44:23 -0700 (PDT)
Received: by mail-yb1-f169.google.com with SMTP id x2so1268660ybf.12 for ; Tue, 01 Sep 2020 10:44:35 -0700 (PDT)
X-Gm-Message-State: AOAM533mmAD4NRJQg6taJCDMDEfnaZyPoklykex0nOieAtoGF0Mbd1GS QuSpKz2zs9PQh9/p9G53/WKAF/cHDPTHAAS5nO0=
X-Google-Smtp-Source: ABdhPJxR5YufDjw5yqw9LzwwH6o7Oquqsdzf5ZGG2qB5JrOq3qHi5GEpSfirQ1xaLmY7bTaz3v2i3pmjrpLHD8sMvRI=
X-Received: by 2002:a25:8b89:: with SMTP id j9mr4714283ybl.457.1598982274319; Tue, 01 Sep 2020 10:44:34 -0700 (PDT)
MIME-Version: 1.0
References: <751dc801-bd0a-ed46-e21e-c4ff5cecc8f2@nostrum.com> <590C0EF3-79A5-411F-B745-D8BAA085BEE6@amsl.com> <8ec50ff6-471b-f698-5e61-b6034509e930@nostrum.com>
In-Reply-To: <8ec50ff6-471b-f698-5e61-b6034509e930@nostrum.com>
From: Glen
Date: Tue, 1 Sep 2020 10:44:22 -0700
X-Gmail-Original-Message-ID:
Message-ID:
To: "tools-implementation@ietf.org"
Content-Type: text/plain; charset="UTF-8"
Archived-At:
Subject: Re: [Tools-implementation] Organization of the mail archives
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 01 Sep 2020 17:44:37 -0000
On Tue, Sep 1, 2020 at 10:31 AM Robert Sparks wrote:
> >> Email Mailarchive /a/isode ISODE IMAP server data store
> >> Email Mailarchive /a/mailarch Mail Archive operations
> These should stay where they are.
> >> Email Mailman /a/mailman Mailman operations
> That has to remain
> >> Email Postfix /a/postfix Postfix operations
> This remains
Right. Any package which can be deployed in a more-or-less isolated
tree should be in/remain in /a/(packagename)
> (though we should consider what to do with it when we bring in Mailman3
At the moment, we are investigating whether the two versions of
Mailman can be run in parallel in our environment. We do not yet
know, but initial indications are encouraging.
Mailman 3 will be deployed into /a/mailman3.
Glen
From nobody Tue Sep 1 10:51:46 2020
Return-Path:
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067703A0C88 for ; Tue, 1 Sep 2020 10:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.909
X-Spam-Level:
X-Spam-Status: No, score=-101.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ph2j1Dp2rd1l for ; Tue, 1 Sep 2020 10:51:41 -0700 (PDT)
Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9FD3A0C95 for ; Tue, 1 Sep 2020 10:51:41 -0700 (PDT)
Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id C5DB23C3C85 for ; Tue, 1 Sep 2020 10:51:29 -0700 (PDT)
Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by c8a.amsl.com (Postfix) with ESMTPSA id A331F3C3C83 for ; Tue, 1 Sep 2020 10:51:29 -0700 (PDT)
Received: by mail-yb1-f178.google.com with SMTP id 189so1297751ybw.3 for ; Tue, 01 Sep 2020 10:51:41 -0700 (PDT)
X-Gm-Message-State: AOAM530yMt7xFeNj2VLOOciBjsh0E+B9a+nxXu7EQwQPVeXrIdcIuiUV 7Sy+CmYyeRTpKsAMNaOb/FqJoIWgVzwstDVhm9k=
X-Google-Smtp-Source: ABdhPJyjdIQZD0+4dHEBK8uhN2hlpiClI/OER/7MfSHm/W9+FLErrrnnCpgPfTl5JTjI+uX1Uk51Sk9iGVRTIyUZnuE=
X-Received: by 2002:a25:5807:: with SMTP id m7mr4496631ybb.456.1598982700478; Tue, 01 Sep 2020 10:51:40 -0700 (PDT)
MIME-Version: 1.0
References: <751dc801-bd0a-ed46-e21e-c4ff5cecc8f2@nostrum.com> <590C0EF3-79A5-411F-B745-D8BAA085BEE6@amsl.com> <8ec50ff6-471b-f698-5e61-b6034509e930@nostrum.com>
In-Reply-To: <8ec50ff6-471b-f698-5e61-b6034509e930@nostrum.com>
From: Glen
Date: Tue, 1 Sep 2020 10:51:28 -0700
X-Gmail-Original-Message-ID:
Message-ID:
To: "tools-implementation@ietf.org"
Content-Type: text/plain; charset="UTF-8"
Archived-At:
Subject: Re: [Tools-implementation] Organization of the mail archives
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 01 Sep 2020 17:51:45 -0000
Separate subthread:
On Tue, Sep 1, 2020 at 10:31 AM Robert Sparks wrote:
> >> Email Mailman /a/mailman/archives Mailman Legacy Archives
> This has to remain - it is where mailman's internal archiving takes
> place - any lists using pipermail are kept here, so Legacy isn't really
> accurate above
Point of clarification:
*All lists use pipermail in that Ryan has said that Mailman2's
internal archiver cannot be shut off or replaced.
But
*No lists use pipermail in that /pipermail is not served from anywhere
in the Apache config, and all references to /pipermail are redirected
to the Mailarchive.
So we cannot move or remove, but can safely ignore, everything inside
/a/mailman it seems.
> >> FTP FTP/Website combined /a/www/ietf-ftp/concluded-wg-ietf-mail-archive ftp, rsync none NOT exposed by http
Forgive me, I might be misreading "NOT exposed by http," but:
https://www.ietf.org/ietf-ftp/concluded-wg-ietf-mail-archive/
> These have all been imported, and are served through the mailarchive.
> These should be stashed. I personally don't think we should serve them
> in any way since they are available through the mailarchive.
+1 I agree they should be removed from FTP, RSYNC, and HTTP, and not served.
> >> FTP FTP/Website combined /a/www/ietf-ftp/ietf-mail-archive Contains text versions of mail archive ftp, rsync night-runner All web access is to the /a/www/ietf-mail-archive tree, which this is a copy of
> This should go away as soon as ftp stops depending on it (and we had
> another conversation about removing it already).
> >> Email Mailarchive /a/www/ietf-mail-archive Legacy mail archive
> >> Email Mailarchive /a/www/ietf-mail-archive/text
> >> Email Mailarchive /a/www/ietf-mail-archive/text-secure
> >> Email Mailarchive /a/www/ietf-mail-archive/web
> >> Email Mailarchive /a/www/ietf-mail-archive/web-old
> >> Email Mailarchive /a/www/ietf-mail-archive/web-secure
> >> Again, has all of that been imported, and can all of this simply be removed (or stashed offline)?
> All of this should be stashed. Everything here, with the possible
> exception of things in web-old have been imported into mailarchive. Ryan
> is looking at making sure those get imported. Once that's done, all of
> these should either be taken offline or put in the museum.
+1.
I assume I should do the "taking offline". How will I know when to
proceed with that? Robert, I assume you will oversee that?
Glen
From nobody Tue Sep 1 11:39:33 2020
Return-Path:
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7553A0EE6 for ; Tue, 1 Sep 2020 11:39:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.078
X-Spam-Level:
X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo4qP112kkMo for ; Tue, 1 Sep 2020 11:39:29 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59EDB3A0EE5 for ; Tue, 1 Sep 2020 11:39:29 -0700 (PDT)
Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 081IdQrJ001228 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 1 Sep 2020 13:39:27 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1598985567; bh=ezEsL1HlvhHuPAAfTR1cn0I/PSA4jWoYyGnO3vVbD4E=; h=To:From:Subject:Date; b=Vqv6sFr1tAYDPLLF2X7/2+OHBA5AXBICYkhYEup5g0pvruqMzSpL+851DghIs+rHg 2aBFlSaV03u50XLwI7z4VBSAAus453YqcagD+vsvQIyOmh3RWSJI/81YBjBE0/ueVO LqIczAbsZeg/LAr6z5PsQVHz50D1+v9IgsO47b1Q=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local
To: "tools-implementation@ietf.org"
From: Robert Sparks
Message-ID:
Date: Tue, 1 Sep 2020 13:39:25 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------9BA3FF7F69BA1A24245FB172"
Content-Language: en-US
Archived-At:
Subject: [Tools-implementation] Building an understanding of the directories at ietf/YYmon
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 01 Sep 2020 18:39:31 -0000
This is a multi-part message in MIME format.
--------------9BA3FF7F69BA1A24245FB172
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Does anyone already understand what all the directories at
/a/www/ietf-ftp/ietf/YYmon (e.g 99nov) are all about?
I can make some guesses based on what I see there (I think they were an
early effort to organize meeting materials, but it would be better if
there were a definitive description of them already lying around.
rjsparks@ietfa:/a/www/ietf-ftp/ietf> ls -d [0-9][0-9][a-z][a-z][a-z]
00dec 01mar 03jul 04nov 90dec 92mar 94dec 95jul   97aug 99jul
00jul 02dec 03mar 05aug 91jul 92nov 94jul 96dec   97dec 99mar
00mar 02jul 03nov 05mar 91mar 93jul 94mar 96jun   98aug 99nov
01aug 02mar 04aug 05nov 91nov 93mar 95apr 96mar   98dec
01dec 02nov 04mar 06mar 92jul 93nov 95dec 97apr   98mar
The newest file there is:
-rw-rw-rw- 1 wwwrun www 279 Aug 1 2001 01aug/opsarea.txt
Looking through the http configs, they get served at
https://www.ietf.org/ietf/YYmon, and there are a smattering of hits for
them in the logs, all from spiders.
Some RFCs reference them:
rfc1719:
> 1. Introduction
>
> At the Amsterdam IETF meeting, we held a BOF, entitled the "IPDecide
> BOF", on the process and progress of the IPng activities.
>
> ("IPng" stands for "IP, the next generation". The IPDecide BOF was
> chaired by Brian Carpenter. Minutes are available in the IETF
> directories, with the file name 93jul.txt>.)
rfc1752:
> [Carpen93] Carpenter, B. and T. Dixon, "Minutes of the IPng Decision
> Process BOF (IPDECIDE)", /ietf/93jul/ipdecide-minutes-93jul.txt,
> August 1993.
rfc3238:
> [OPESBOF1] OPES BOF, 49th IETF, December 12, 2000. Agenda:
> "http://www.ietf.org/ietf/00dec/opes-agenda.txt".
> Minutes: "http://www.ietf.cnri.reston.va.us/
> proceedings/00dec/toc.htm#P25_256".
>
> IAB Informational [Page 14]
> RFC 3238 IAB Considerations for OPES January 2002
>
> [OPESBOF2] OPES BOF, 50th IETF, March 9, 2001. Minutes:
> "http://www.ietf.org/proceedings/01mar/ietf50-40.htm".
>
> [OPESBOF3] OPES BOF, 51st IETF, August 2001. Agenda:
> "http://www.ietf.org/ietf/01aug/opes.txt". Minutes:
> "http://www.ietf.org/proceedings/01aug/minutes/OPES.HTM".
I think these would go into a museum that gets served somewhere, but I
don't know if we should force that to continue to be a slice of the
www.ietf.org namespace.
Is it ok to break those few URLs and enter errata against the RFCs to
point to where we move them to?
There's no real win to slice parts of https://www.ietf.org/ietf/ out
with redirects - I'd like to return everything under that url to be
something the website (i.e. wagtail) can use. Otherwise we decide to
continue to live with having that chunk of the namespace dispatched to a
separate service than wagtail.
RjS
--------------9BA3FF7F69BA1A24245FB172
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
Does anyone already understand what all the directories at
/a/www/ietf-ftp/ietf/YYmon (e.g 99nov) are all about?
I can make some guesses based on what I see there (I think they
were an early effort to organize meeting materials, but it would
be better if there were a definitive description of them already
lying around.
rjsparks@ietfa:/a/www/ietf-ftp/ietf> ls -d
[0-9][0-9][a-z][a-z][a-z]
00dec 01mar 03jul 04nov 90dec 92mar 94dec 95jul   97augÂ
99jul
00jul 02dec 03mar 05aug 91jul 92nov 94jul 96dec   97decÂ
99mar
00mar 02jul 03nov 05mar 91mar 93jul 94mar 96jun   98augÂ
99nov
01aug 02mar 04aug 05nov 91nov 93mar 95apr 96mar   98dec
01dec 02nov 04mar 06mar 92jul 93nov 95dec 97apr   98mar
The newest file there is:
-rw-rw-rw- 1 wwwrun www 279 Aug 1 2001 01aug/opsarea.txt
Looking through the http configs, they get served at
https://www.ietf.org/ietf/YYmon, and there are a smattering of
hits for them in the logs, all from spiders.
Some RFCs reference them:
rfc1719:
1. Introduction
At the Amsterdam IETF meeting, we held a BOF, entitled the "IPDecide
BOF", on the process and progress of the IPng activities.
("IPng" stands for "IP, the next generation". The IPDecide BOF was
chaired by Brian Carpenter. Minutes are available in the IETF
directories, with the file name </ietf/93jul/ipdecide-minutes-
93jul.txt>.)
rfc1752:
[Carpen93] Carpenter, B. and T. Dixon, "Minutes of the IPng Decision
Process BOF (IPDECIDE)", /ietf/93jul/ipdecide-minutes-93jul.txt,
August 1993.
rfc3238:
[OPESBOF1] OPES BOF, 49th IETF, December 12, 2000. Agenda:
"http://www.ietf.org/ietf/00dec/opes-agenda.txt".
Minutes: "http://www.ietf.cnri.reston.va.us/
proceedings/00dec/toc.htm#P25_256".
IAB Informational [Page 14]
RFC 3238 IAB Considerations for OPES January 2002
[OPESBOF2] OPES BOF, 50th IETF, March 9, 2001. Minutes:
"http://www.ietf.org/proceedings/01mar/ietf50-40.htm".
[OPESBOF3] OPES BOF, 51st IETF, August 2001. Agenda:
"http://www.ietf.org/ietf/01aug/opes.txt". Minutes:
"http://www.ietf.org/proceedings/01aug/minutes/OPES.HTM".
I think these would go into a museum that gets served somewhere,
but I don't know if we should force that to continue to be a slice
of the www.ietf.org namespace.
Is it ok to break those few URLs and enter errata against the
RFCs to point to where we move them to?
There's no real win to slice parts of https://www.ietf.org/ietf/
out with redirects - I'd like to return everything under that url
to be something the website (i.e. wagtail) can use. Otherwise we
decide to continue to live with having that chunk of the namespace
dispatched to a separate service than wagtail.
RjS
--------------9BA3FF7F69BA1A24245FB172--
From nobody Tue Sep 1 11:59:10 2020
Return-Path:
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC043A0F48 for ; Tue, 1 Sep 2020 11:59:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44g8CAEz-BHw for ; Tue, 1 Sep 2020 11:59:06 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A6E33A0F3E for ; Tue, 1 Sep 2020 11:59:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5210A300B92 for ; Tue, 1 Sep 2020 14:59:03 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2WL20jxtWSiI for ; Tue, 1 Sep 2020 14:59:01 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id DD81A300AFF; Tue, 1 Sep 2020 14:59:00 -0400 (EDT)
From: Russ Housley
Message-Id:
Content-Type: multipart/alternative; boundary="Apple-Mail=_C20604A2-01BB-4BDF-A931-CABDD0DC3374"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\))
Date: Tue, 1 Sep 2020 14:59:01 -0400
In-Reply-To:
Cc: "tools-implementation@ietf.org"
To: Robert Sparks
References:
X-Mailer: Apple Mail (2.3445.104.15)
Archived-At:
Subject: Re: [Tools-implementation] Building an understanding of the directories at ietf/YYmon
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 01 Sep 2020 18:59:08 -0000
--Apple-Mail=_C20604A2-01BB-4BDF-A931-CABDD0DC3374
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
If memory serves, the proceedings used to include a snapshot of the I-Ds =
that were active at the time of the meeting. This is from a time when =
the proceedings were distributed as a CD-ROM.
Russ
> On Sep 1, 2020, at 2:39 PM, Robert Sparks =
wrote:
>=20
> Does anyone already understand what all the directories at =
/a/www/ietf-ftp/ietf/YYmon (e.g 99nov) are all about?
>=20
> I can make some guesses based on what I see there (I think they were =
an early effort to organize meeting materials, but it would be better if =
there were a definitive description of them already lying around.
>=20
> rjsparks@ietfa:/a/www/ietf-ftp/ietf> ls -d [0-9][0-9][a-z][a-z][a-z]
> 00dec 01mar 03jul 04nov 90dec 92mar 94dec 95jul 97aug 99jul
> 00jul 02dec 03mar 05aug 91jul 92nov 94jul 96dec 97dec 99mar
> 00mar 02jul 03nov 05mar 91mar 93jul 94mar 96jun 98aug 99nov
> 01aug 02mar 04aug 05nov 91nov 93mar 95apr 96mar 98dec
> 01dec 02nov 04mar 06mar 92jul 93nov 95dec 97apr 98mar
> The newest file there is:
>=20
> -rw-rw-rw- 1 wwwrun www 279 Aug 1 2001 01aug/opsarea.txt
>=20
> Looking through the http configs, they get served at =
https://www.ietf.org/ietf/YYmon , and =
there are a smattering of hits for them in the logs, all from spiders.
>=20
> Some RFCs reference them:
>=20
> rfc1719:
>=20
>=20
>> 1. Introduction
>>=20
>> At the Amsterdam IETF meeting, we held a BOF, entitled the =
"IPDecide
>> BOF", on the process and progress of the IPng activities.
>>=20
>> ("IPng" stands for "IP, the next generation". The IPDecide BOF =
was
>> chaired by Brian Carpenter. Minutes are available in the IETF
>> directories, with the file name > 93jul.txt>.)
>=20
>=20
> rfc1752:
>=20
>=20
>> [Carpen93] Carpenter, B. and T. Dixon, "Minutes of the IPng =
Decision
>> Process BOF (IPDECIDE)", =
/ietf/93jul/ipdecide-minutes-93jul.txt,
>> August 1993.
>=20
>=20
> rfc3238:
>=20
>=20
>> [OPESBOF1] OPES BOF, 49th IETF, December 12, 2000. Agenda:
>> "http://www.ietf.org/ietf/00dec/opes-agenda.txt" =
.
>> Minutes: "http://www.ietf.cnri.reston.va.us/
>> proceedings/00dec/toc.htm#P25_256" =
.
>>=20
>> IAB Informational [Page =
14]
>> RFC 3238 IAB Considerations for OPES January =
2002
>>=20
>> [OPESBOF2] OPES BOF, 50th IETF, March 9, 2001. Minutes:
>> "http://www.ietf.org/proceedings/01mar/ietf50-40.htm" =
.
>>=20
>> [OPESBOF3] OPES BOF, 51st IETF, August 2001. Agenda:
>> "http://www.ietf.org/ietf/01aug/opes.txt" =
. Minutes:
>> =
"http://www.ietf.org/proceedings/01aug/minutes/OPES.HTM" =
.
>=20
>=20
> I think these would go into a museum that gets served somewhere, but I =
don't know if we should force that to continue to be a slice of the =
www.ietf.org namespace.
>=20
> Is it ok to break those few URLs and enter errata against the RFCs to =
point to where we move them to?
>=20
> There's no real win to slice parts of https://www.ietf.org/ietf/ =
out with redirects - I'd like to return =
everything under that url to be something the website (i.e. wagtail) can =
use. Otherwise we decide to continue to live with having that chunk of =
the namespace dispatched to a separate service than wagtail.
>=20
> RjS
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> --=20
> Tools-implementation mailing list
> Tools-implementation@ietf.org
> https://www.ietf.org/mailman/listinfo/tools-implementation
--Apple-Mail=_C20604A2-01BB-4BDF-A931-CABDD0DC3374
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
charset=us-ascii
If memory serves, the proceedings used to include a snapshot of the I-Ds that were active at the time of the meeting. This is from a time when the proceedings were distributed as a CD-ROM.
Russ
Does anyone already understand what all the directories at
/a/www/ietf-ftp/ietf/YYmon (e.g 99nov) are all about?
I can make some guesses based on what I see there (I think they
were an early effort to organize meeting materials, but it would
be better if there were a definitive description of them already
lying around.
rjsparks@ietfa:/a/www/ietf-ftp/ietf> ls -d
[0-9][0-9][a-z][a-z][a-z]
00dec 01mar 03jul 04nov 90dec 92mar 94dec 95jul 97aug
99jul
00jul 02dec 03mar 05aug 91jul 92nov 94jul 96dec 97dec
99mar
00mar 02jul 03nov 05mar 91mar 93jul 94mar 96jun 98aug
99nov
01aug 02mar 04aug 05nov 91nov 93mar 95apr 96mar 98dec
01dec 02nov 04mar 06mar 92jul 93nov 95dec 97apr 98mar
The newest file there is:
-rw-rw-rw- 1 wwwrun www 279 Aug 1 2001 01aug/opsarea.txt
Looking through the http configs, they get served at
https://www.ietf.org/ietf/YYmon, and there are a smattering of
hits for them in the logs, all from spiders.
Some RFCs reference them:
rfc1719:
1. Introduction
At the Amsterdam IETF meeting, we held a BOF, entitled the "IPDecide
BOF", on the process and progress of the IPng activities.
("IPng" stands for "IP, the next generation". The IPDecide BOF was
chaired by Brian Carpenter. Minutes are available in the IETF
directories, with the file name </ietf/93jul/ipdecide-minutes-
93jul.txt>.)
rfc1752:
[Carpen93] Carpenter, B. and T. Dixon, "Minutes of the IPng Decision
Process BOF (IPDECIDE)", /ietf/93jul/ipdecide-minutes-93jul.txt,
August 1993.
rfc3238:
[OPESBOF1] OPES BOF, 49th IETF, December 12, 2000. Agenda:
"http://www.ietf.org/ietf/00dec/opes-agenda.txt".
Minutes: "http://www.ietf.cnri.reston.va.us/
proceedings/00dec/toc.htm#P25_256".
IAB Informational [Page 14]
RFC 3238 IAB Considerations for OPES January 2002
[OPESBOF2] OPES BOF, 50th IETF, March 9, 2001. Minutes:
"http://www.ietf.org/proceedings/01mar/ietf50-40.htm".
[OPESBOF3] OPES BOF, 51st IETF, August 2001. Agenda:
"http://www.ietf.org/ietf/01aug/opes.txt". Minutes:
"http://www.ietf.org/proceedings/01aug/minutes/OPES.HTM".
I think these would go into a museum that gets served somewhere,
but I don't know if we should force that to continue to be a slice
of the www.ietf.org namespace.
Is it ok to break those few URLs and enter errata against the
RFCs to point to where we move them to?
There's no real win to slice parts of https://www.ietf.org/ietf/
out with redirects - I'd like to return everything under that url
to be something the website (i.e. wagtail) can use. Otherwise we
decide to continue to live with having that chunk of the namespace
dispatched to a separate service than wagtail.
RjS
--
Tools-implementation mailing list
Tools-implementation@ietf.orghttps://www.ietf.org/mailman/listinfo/tools-implementation
--Apple-Mail=_C20604A2-01BB-4BDF-A931-CABDD0DC3374--
From nobody Tue Sep 1 12:04:03 2020
Return-Path:
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CE23A0F48 for ; Tue, 1 Sep 2020 12:04:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.027
X-Spam-Level:
X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.948, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMgYCgWhc0vO for ; Tue, 1 Sep 2020 12:04:00 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D3303A0F3E for ; Tue, 1 Sep 2020 12:04:00 -0700 (PDT)
Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 081J3wGV009918 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 1 Sep 2020 14:03:59 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1598987039; bh=r+RQ5ZTuggGlkuMZei6iDRt9nck59jFdiSCHvTcKmmQ=; h=Subject:To:References:From:Date:In-Reply-To; b=AvhjBqnqUwBy1HorXbLxRhe1+gC14Syp/pqRtnIGW127CSPj4zPvsT8d3cFepO2im CwdUnIkuI6I9qO1JCC70MIMK5tAQMtOBSWCAa7H3I5zd5KcxzC6GLsH0pxPDfXYC84 qIJ6MPgUWLYIpZecy0TL53U6V/tALjfyiyHkaEpE=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local
To: tools-implementation@ietf.org
References: <751dc801-bd0a-ed46-e21e-c4ff5cecc8f2@nostrum.com> <590C0EF3-79A5-411F-B745-D8BAA085BEE6@amsl.com> <8ec50ff6-471b-f698-5e61-b6034509e930@nostrum.com>
From: Robert Sparks
Message-ID:
Date: Tue, 1 Sep 2020 14:03:57 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To:
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At:
Subject: Re: [Tools-implementation] Organization of the mail archives
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 01 Sep 2020 19:04:02 -0000
On 9/1/20 12:51 PM, Glen wrote:
> Separate subthread:
>
> On Tue, Sep 1, 2020 at 10:31 AM Robert Sparks wrote:
>>>> Email Mailman /a/mailman/archives Mailman Legacy Archives
>> This has to remain - it is where mailman's internal archiving takes
>> place - any lists using pipermail are kept here, so Legacy isn't really
>> accurate above
> Point of clarification:
> *All lists use pipermail in that Ryan has said that Mailman2's
> internal archiver cannot be shut off or replaced.
> But
> *No lists use pipermail in that /pipermail is not served from anywhere
> in the Apache config, and all references to /pipermail are redirected
> to the Mailarchive.
>
> So we cannot move or remove, but can safely ignore, everything inside
> /a/mailman it seems.
Thank you!
But I'm still a bit concerned about one thing. I had it in my head that
there were still some active, or only recently (~5yrs) dormant lists
that only existed outside what mailarchive was ingesting. If that's not
true, I'll be relieved. Ryan (or anyone else) - do you remember any such
thing and can you point to it?
>
>>>> FTP FTP/Website combined /a/www/ietf-ftp/concluded-wg-ietf-mail-archive ftp, rsync none NOT exposed by http
> Forgive me, I might be misreading "NOT exposed by http," but:
> https://www.ietf.org/ietf-ftp/concluded-wg-ietf-mail-archive/
Old notes - clearly no longer correct. At the time, they said
"http://www.ietf.org/ietf-ftp goes to ietf-ftp/ietf".
>
>> These have all been imported, and are served through the mailarchive.
>> These should be stashed. I personally don't think we should serve them
>> in any way since they are available through the mailarchive.
> +1 I agree they should be removed from FTP, RSYNC, and HTTP, and not served.
>
>>>> FTP FTP/Website combined /a/www/ietf-ftp/ietf-mail-archive Contains text versions of mail archive ftp, rsync night-runner All web access is to the /a/www/ietf-mail-archive tree, which this is a copy of
>> This should go away as soon as ftp stops depending on it (and we had
>> another conversation about removing it already).
>>>> Email Mailarchive /a/www/ietf-mail-archive Legacy mail archive
>>>> Email Mailarchive /a/www/ietf-mail-archive/text
>>>> Email Mailarchive /a/www/ietf-mail-archive/text-secure
>>>> Email Mailarchive /a/www/ietf-mail-archive/web
>>>> Email Mailarchive /a/www/ietf-mail-archive/web-old
>>>> Email Mailarchive /a/www/ietf-mail-archive/web-secure
>>>> Again, has all of that been imported, and can all of this simply be removed (or stashed offline)?
>> All of this should be stashed. Everything here, with the possible
>> exception of things in web-old have been imported into mailarchive. Ryan
>> is looking at making sure those get imported. Once that's done, all of
>> these should either be taken offline or put in the museum.
> +1.
>
> I assume I should do the "taking offline". How will I know when to
> proceed with that? Robert, I assume you will oversee that?
Yes. Right now we are still trying to understand, and that understanding
will build a plan. I talk about what I think _should_ happen above as a
proposal to that plan, not as directives to take action now.
>
> Glen
>
From nobody Tue Sep 1 12:12:28 2020
Return-Path:
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926263A0F68 for ; Tue, 1 Sep 2020 12:12:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.026
X-Spam-Level:
X-Spam-Status: No, score=-3.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.948, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGDlkMBedIwP for ; Tue, 1 Sep 2020 12:12:24 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC4963A0F67 for ; Tue, 1 Sep 2020 12:12:24 -0700 (PDT)
Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 081JCMDS012966 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 1 Sep 2020 14:12:23 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1598987544; bh=VbzP4BZwQYmXi/FTHy+pzUdzspoAX82TKfGoNF1NMQQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=oMyaQSrbi35gWYn9g/52GAujiEsSM6sIiCAjULQsgNjuqWwUJifjucV7aroBmL0sa XoRm+/tFhl6GZ1TiICg/UKmbu9EBRZaPsE+5ycIvDc/NQWA+pQuS4Uv02N4lVG5ftu b3NKs5qRsSelDl4yiIEjrrKnzmTJKcU++cCnlMls=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local
To: Russ Housley
Cc: "tools-implementation@ietf.org"
References:
From: Robert Sparks
Message-ID:
Date: Tue, 1 Sep 2020 14:12:22 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To:
Content-Type: multipart/alternative; boundary="------------6AF24BE9A86468B320708AF5"
Content-Language: en-US
Archived-At:
Subject: Re: [Tools-implementation] Building an understanding of the directories at ietf/YYmon
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 01 Sep 2020 19:12:27 -0000
This is a multi-part message in MIME format.
--------------6AF24BE9A86468B320708AF5
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
On 9/1/20 1:59 PM, Russ Housley wrote:
> If memory serves, the proceedings used to include a snapshot of the
> I-Ds that were active at the time of the meeting. This is from a time
> when the proceedings were distributed as a CD-ROM.
Yes, but I don't think that's what these directories contain. There are
other directories that support the cd-rom images, and proceedings.
>
> Russ
>
>
>> On Sep 1, 2020, at 2:39 PM, Robert Sparks > > wrote:
>>
>> Does anyone already understand what all the directories at
>> /a/www/ietf-ftp/ietf/YYmon (e.g 99nov) are all about?
>>
>> I can make some guesses based on what I see there (I think they were
>> an early effort to organize meeting materials, but it would be better
>> if there were a definitive description of them already lying around.
>>
>> rjsparks@ietfa:/a/www/ietf-ftp/ietf> ls -d [0-9][0-9][a-z][a-z][a-z]
>> 00dec 01mar 03jul 04nov 90dec 92mar 94dec 95jul 97aug 99jul
>> 00jul 02dec 03mar 05aug 91jul 92nov 94jul 96dec 97dec 99mar
>> 00mar 02jul 03nov 05mar 91mar 93jul 94mar 96jun 98aug 99nov
>> 01aug 02mar 04aug 05nov 91nov 93mar 95apr 96mar 98dec
>> 01dec 02nov 04mar 06mar 92jul 93nov 95dec 97apr 98mar
>>
>> The newest file there is:
>>
>> -rw-rw-rw- 1 wwwrun www 279 Aug 1 2001 01aug/opsarea.txt
>>
>> Looking through the http configs, they get served at
>> https://www.ietf.org/ietf/YYmon, and there are a smattering of hits
>> for them in the logs, all from spiders.
>>
>> Some RFCs reference them:
>>
>> rfc1719:
>>
>>
>>> 1. Introduction
>>>
>>> At the Amsterdam IETF meeting, we held a BOF, entitled the "IPDecide
>>> BOF", on the process and progress of the IPng activities.
>>>
>>> ("IPng" stands for "IP, the next generation". The IPDecide BOF was
>>> chaired by Brian Carpenter. Minutes are available in the IETF
>>> directories, with the file name >> 93jul.txt>.)
>>
>>
>> rfc1752:
>>
>>
>>> [Carpen93] Carpenter, B. and T. Dixon, "Minutes of the IPng Decision
>>> Process BOF (IPDECIDE)", /ietf/93jul/ipdecide-minutes-93jul.txt,
>>> August 1993.
>>
>>
>> rfc3238:
>>
>>
>>> [OPESBOF1] OPES BOF, 49th IETF, December 12, 2000. Agenda:
>>> "http://www.ietf.org/ietf/00dec/opes-agenda.txt".
>>> Minutes:"http://www.ietf.cnri.reston.va.us/ proceedings/00dec/toc.htm#P25_256".
>>>
>>> IAB Informational [Page 14]
>>> RFC 3238 IAB Considerations for OPES January 2002
>>>
>>> [OPESBOF2] OPES BOF, 50th IETF, March 9, 2001. Minutes:
>>> "http://www.ietf.org/proceedings/01mar/ietf50-40.htm".
>>>
>>> [OPESBOF3] OPES BOF, 51st IETF, August 2001. Agenda:
>>> "http://www.ietf.org/ietf/01aug/opes.txt". Minutes:
>>> "http://www.ietf.org/proceedings/01aug/minutes/OPES.HTM".
>>
>>
>> I think these would go into a museum that gets served somewhere, but
>> I don't know if we should force that to continue to be a slice of the
>> www.ietf.org namespace.
>>
>> Is it ok to break those few URLs and enter errata against the RFCs to
>> point to where we move them to?
>>
>> There's no real win to slice parts of https://www.ietf.org/ietf/ out
>> with redirects - I'd like to return everything under that url to be
>> something the website (i.e. wagtail) can use. Otherwise we decide to
>> continue to live with having that chunk of the namespace dispatched
>> to a separate service than wagtail.
>>
>> RjS
>>
>>
>>
>>
>> --
>> Tools-implementation mailing list
>> Tools-implementation@ietf.org
>> https://www.ietf.org/mailman/listinfo/tools-implementation
>
--------------6AF24BE9A86468B320708AF5
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
On 9/1/20 1:59 PM, Russ Housley wrote:
If memory serves, the proceedings used to include a snapshot of
the I-Ds that were active at the time of the meeting. This is
from a time when the proceedings were distributed as a CD-ROM.
Yes, but I don't think that's what these directories contain. There
are other directories that support the cd-rom images, and
proceedings.
Russ
Does anyone already understand what all the
directories at /a/www/ietf-ftp/ietf/YYmon (e.g 99nov)
are all about?
I can make some guesses based on what I see
there (I think they were an early effort to organize
meeting materials, but it would be better if there
were a definitive description of them already lying
around.
rjsparks@ietfa:/a/www/ietf-ftp/ietf> ls -d
[0-9][0-9][a-z][a-z][a-z]
00dec 01mar 03jul 04nov 90dec 92mar 94dec
95jul 97aug 99jul
00jul 02dec 03mar 05aug 91jul 92nov 94jul
96dec 97dec 99mar
00mar 02jul 03nov 05mar 91mar 93jul 94mar
96jun 98aug 99nov
01aug 02mar 04aug 05nov 91nov 93mar 95apr
96mar 98dec
01dec 02nov 04mar 06mar 92jul 93nov 95dec
97apr 98mar
The newest file there is:
-rw-rw-rw- 1 wwwrun www 279 Aug 1 2001
01aug/opsarea.txt
Looking through the http configs, they get
served at https://www.ietf.org/ietf/YYmon,
and there are a smattering of hits for them in the
logs, all from spiders.
Some RFCs reference them:
rfc1719:
1. Introduction
At the Amsterdam IETF meeting, we held a BOF, entitled the "IPDecide
BOF", on the process and progress of the IPng activities.
("IPng" stands for "IP, the next generation". The IPDecide BOF was
chaired by Brian Carpenter. Minutes are available in the IETF
directories, with the file name </ietf/93jul/ipdecide-minutes-
93jul.txt>.)
rfc1752:
[Carpen93] Carpenter, B. and T. Dixon, "Minutes of the IPng Decision
Process BOF (IPDECIDE)", /ietf/93jul/ipdecide-minutes-93jul.txt,
August 1993.
rfc3238:
[OPESBOF1] OPES BOF, 49th IETF, December 12, 2000. Agenda:
"http://www.ietf.org/ietf/00dec/opes-agenda.txt".
Minutes: "http://www.ietf.cnri.reston.va.us/
proceedings/00dec/toc.htm#P25_256".
IAB Informational [Page 14]
RFC 3238 IAB Considerations for OPES January 2002
[OPESBOF2] OPES BOF, 50th IETF, March 9, 2001. Minutes:
"http://www.ietf.org/proceedings/01mar/ietf50-40.htm".
[OPESBOF3] OPES BOF, 51st IETF, August 2001. Agenda:
"http://www.ietf.org/ietf/01aug/opes.txt". Minutes:
"http://www.ietf.org/proceedings/01aug/minutes/OPES.HTM".
I think these would go into a museum that
gets served somewhere, but I don't know if we should
force that to continue to be a slice of the www.ietf.org
namespace.
Is it ok to break those few URLs and enter
errata against the RFCs to point to where we move them
to?
There's no real win to slice parts of https://www.ietf.org/ietf/
out with redirects - I'd like to return everything
under that url to be something the website (i.e.
wagtail) can use. Otherwise we decide to continue to
live with having that chunk of the namespace
dispatched to a separate service than wagtail.
RjS
--
Tools-implementation mailing list
Tools-implementation@ietf.org
https://www.ietf.org/mailman/listinfo/tools-implementation
--------------6AF24BE9A86468B320708AF5--
From nobody Tue Sep 1 12:29:31 2020
Return-Path:
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9102B3A1027 for ; Tue, 1 Sep 2020 12:29:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.909
X-Spam-Level:
X-Spam-Status: No, score=-101.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEm3wQb-UCnr for ; Tue, 1 Sep 2020 12:29:20 -0700 (PDT)
Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A4E13A0FA3 for ; Tue, 1 Sep 2020 12:29:18 -0700 (PDT)
Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id AF8233C2E08 for ; Tue, 1 Sep 2020 12:29:06 -0700 (PDT)
Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) by c8a.amsl.com (Postfix) with ESMTPSA id 89ED93C2E07 for ; Tue, 1 Sep 2020 12:29:06 -0700 (PDT)
Received: by mail-yb1-f177.google.com with SMTP id q16so1466618ybk.6 for ; Tue, 01 Sep 2020 12:29:18 -0700 (PDT)
X-Gm-Message-State: AOAM532Txqm09VoJbjL5nk086WZRVXguGGF5EV5IERdXBG44Lzbn6pjy 8gXlxpNp00s4FqTdQhKs5prlCYR3RUVZRyRzk/Y=
X-Google-Smtp-Source: ABdhPJx0hG1eYlvZj7Arcl0vuZcjpTfgZ3tTfbNikbLR+FP5xVVuzfwify4c/Woebn5HAG8JOSZfeTlDn0wB3wWWFBw=
X-Received: by 2002:a25:8b89:: with SMTP id j9mr5351276ybl.457.1598988557501; Tue, 01 Sep 2020 12:29:17 -0700 (PDT)
MIME-Version: 1.0
References: <751dc801-bd0a-ed46-e21e-c4ff5cecc8f2@nostrum.com> <590C0EF3-79A5-411F-B745-D8BAA085BEE6@amsl.com> <8ec50ff6-471b-f698-5e61-b6034509e930@nostrum.com>
In-Reply-To:
From: Glen
Date: Tue, 1 Sep 2020 12:29:05 -0700
X-Gmail-Original-Message-ID:
Message-ID:
To: tools-implementation@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At:
Subject: Re: [Tools-implementation] Organization of the mail archives
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 01 Sep 2020 19:29:30 -0000
On Tue, Sep 1, 2020 at 12:04 PM Robert Sparks wrote:
> > So we cannot move or remove, but can safely ignore, everything inside
> > /a/mailman it seems.
> Thank you!
Oh! Well... you're welcome!
> But I'm still a bit concerned about one thing. I had it in my head that
> there were still some active, or only recently (~5yrs) dormant lists
> that only existed outside what mailarchive was ingesting. If that's not
> true, I'll be relieved. Ryan (or anyone else) - do you remember any such
> thing and can you point to it?
Well, there is:
tail -35 /a/postfix/virtual
tail -36 /a/postfix/aliases
which are external feeder points for the mailarchive tool. All of
them are pointing to new new archive system (only), but I have no idea
which are still active/in use or not.
I'm not aware of anything pointing to MHonarc or any legacy archiving systems.
> Yes. Right now we are still trying to understand, and that understanding
> will build a plan. I talk about what I think _should_ happen above as a
> proposal to that plan, not as directives to take action now.
Okay, thank you. I have that September 4 removal directive I'll
proceed with, but everything else I'll just take as conversation
unless you tell me otherwise.
Glen
From nobody Thu Sep 3 06:35:39 2020
Return-Path:
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FD23A0BFC for ; Thu, 3 Sep 2020 06:35:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.847
X-Spam-Level:
X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZgvFdRnIRN9 for ; Thu, 3 Sep 2020 06:35:31 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC44C3A0BF2 for ; Thu, 3 Sep 2020 06:35:31 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:51306 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1kDpOg-0002hU-1o for tools-implementation@ietf.org; Thu, 03 Sep 2020 06:35:30 -0700
To: tools-implementation@ietf.org
References: <67be10c9-1958-4357-bb59-7fd2f845bd23@levkowetz.com>
From: Henrik Levkowetz
Message-ID:
Date: Thu, 3 Sep 2020 15:35:18 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <67be10c9-1958-4357-bb59-7fd2f845bd23@levkowetz.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MWHC9qVxL7IAG2afu6g10R9ACM4XKQemu"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: tools-implementation@ietf.org
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At:
Subject: Re: [Tools-implementation] https accesses to drafts and RFCs on tools.ietf.org
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 03 Sep 2020 13:35:37 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--MWHC9qVxL7IAG2afu6g10R9ACM4XKQemu
Content-Type: multipart/mixed; boundary="8EinoA1AVW74WXaIMKrfmbVgW7a2M4r7h";
protected-headers="v1"
From: Henrik Levkowetz
To: tools-implementation@ietf.org
Message-ID:
Subject: Re: https accesses to drafts and RFCs on tools.ietf.org
References: <67be10c9-1958-4357-bb59-7fd2f845bd23@levkowetz.com>
In-Reply-To: <67be10c9-1958-4357-bb59-7fd2f845bd23@levkowetz.com>
--8EinoA1AVW74WXaIMKrfmbVgW7a2M4r7h
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hi Roman
Here are the FTP figures from the IETF production server, based on the
available log data. The bargraphs are scaled to the same scale as the
equivalent tools figures. Since the production server doesn't serve
htmlized drafts and RFCs over FTP, there are no figures for those
categories:
Unprocessed Drafts:
506 2020-08-02 3%=20
180 2020-08-03 1%=20
196 2020-08-04 1%=20
128 2020-08-05 0%=20
127 2020-08-06 0%=20
211 2020-08-07 1%=20
189 2020-08-08 1%=20
199 2020-08-09 1%=20
215 2020-08-10 1%=20
193 2020-08-11 1%=20
1851 2020-08-12 12%=20
1280 2020-08-13 8%=20
174 2020-08-23 1%=20
156 2020-08-24 1%=20
193 2020-08-25 1%=20
111 2020-08-26 0%=20
1986 2020-08-27 13%=20
210 2020-08-28 1%=20
5355 2020-08-29 36% *
523 2020-08-30 3%=20
180 2020-08-31 1%=20
204 2020-09-01 1%=20
257 2020-09-02 1%=20
118 2020-09-03 0%=20
614.2 Average/Day 4%=20
14742 Total =20
111 Minimum/Day
5355 Maximum/Day
Unprocessed RFCs:
9 2020-08-02 0%=20
29 2020-08-03 0%=20
30 2020-08-04 0%=20
23 2020-08-05 0%=20
3376 2020-08-06 24% *********
637 2020-08-07 4% *
30 2020-08-08 0%=20
14 2020-08-09 0%=20
24 2020-08-10 0%=20
20 2020-08-11 0%=20
18 2020-08-12 0%=20
36 2020-08-13 0%=20
1 2020-08-22 0%=20
17 2020-08-23 0%=20
19 2020-08-24 0%=20
27 2020-08-25 0%=20
24 2020-08-26 0%=20
35 2020-08-27 0%=20
3549 2020-08-28 26% **********
3483 2020-08-29 25% **********
1802 2020-08-30 13% *****
38 2020-08-31 0%=20
330 2020-09-01 2%=20
59 2020-09-02 0%=20
20 2020-09-03 0%=20
546.0 Average/Day 4% =3D
13650 Total =20
1 Minimum/Day
3549 Maximum/Day
The figures above show only retrievals of the .txt version, which matches=
the tools.ietf.org figures; but there were also retrievals of derived .pd=
f,
=2Ehtml, .json (meta-information) and text versions without extension, wh=
ich
in particular gave a spike of 49855 retrievals on Aug. 28th. That spike
was essentially due to one actor. Grouping the Aug. 28 data above by cli=
ent:
1 1.241.44.96 0%=20
1 162.216.25.12 0%=20
7 172.83.168.131 0%=20
6 192.30.89.142 0%=20
4 2001:4898:80e8:a:9a8:247b:f8dc:e 0%=20
7 2a00:801:fd:800:250:56ff:fea5:ca 0%=20
5 alpha.harfa.net 0%=20
8 anubis.u-strasbg.fr 0%=20
3464 chekov.greenie.muc.de 97% ***************************=
*****
5 ftp.nluug.nl 0%=20
7 ftp2.ncnu.edu.tw 0%=20
8 pike-www.lysator.liu.se 0%=20
7 proxy3.nic.ad.jp 0%=20
5 quimby.gnus.org 0%=20
7 seymour23.snmp.com 0%=20
7 vlsi03.si.noda.tus.ac.jp 0%=20
or looking at the full RFC retrievals of that date, not just the .txt fil=
es:
1 1.241.44.96 0%=20
1 162.216.25.12 0%=20
29 172.83.168.131 0%=20
31 192.30.89.142 0%=20
4 2001:4898:80e8:a:9a8:247b:f8dc:e 0%=20
33 2a00:801:fd:800:250:56ff:fea5:ca 0%=20
26 alpha.harfa.net 0%=20
36 anubis.u-strasbg.fr 0%=20
31 chandelierly.boon.volia.net 0%=20
49482 chekov.greenie.muc.de 99% ***************************=
*****
27 ftp.nluug.nl 0%=20
34 ftp2.ncnu.edu.tw 0%=20
34 pike-www.lysator.liu.se 0%=20
36 proxy3.nic.ad.jp 0%=20
5 quimby.gnus.org 0%=20
12 seymour23.snmp.com 0%=20
33 vlsi03.si.noda.tus.ac.jp 0%=20
Best regards,
Henrik
On 2020-08-25 19:46, Henrik Levkowetz wrote:
> Hi Roman,
>=20
> I don't know how to best partition and select the data about https acce=
sses
> to drafts and RFCs on tools.ietf.org, but here's a first approach.
>=20
> I've split the data into accesses to htmlized documents and unprocessed=
> documents, and in turn split those into draft-* and rfc* accesses.
>=20
> All figures are for the last 73 days (since June 14th):
>=20
> Htmlized drafts:
> 97322 Average/Day
> 7104548 Total =20
> 29097 Minimum/Day
> 135658 Maximum/Day
>=20
> Htmlized RFCs:
> 306076 Average/Day
> 22343564 Total =20
> 126506 Minimum/Day
> 535266 Maximum/Day
>=20
> Unprocessed Drafts:
> 47976 Average/Day
> 3502257 Total =20
> 14070 Minimum/Day
> 169578 Maximum/Day
>=20
> Unprocessed RFCs:
> 8748 Average/Day
> 638645 Total =20
> 5289 Minimum/Day
> 18640 Maximum/Day
>=20
> In case it would be of any use (I don't think so, the figures above
> should contain the essence, but ...) I've also copied in the per-day
> counts with histogram below.
>=20
> Let me know if you need the data massaged differently.
>=20
>=20
> Best regards,
>=20
> Henrik
>=20
>=20
>=20
> -----------------------------------------------------------------------=
---------
>=20
>=20
>=20
> apache-html-draft.hits
> 81266 2020-06-14 1% ********************************
> 106428 2020-06-15 1% ******************************************
> 110841 2020-06-16 1% ********************************************
> 111007 2020-06-17 1% ********************************************
> 78600 2020-06-18 1% *******************************
> 72794 2020-06-19 1% ****************************
> 53766 2020-06-20 0% *********************
> 62376 2020-06-21 0% ************************
> 88540 2020-06-22 1% ***********************************
> 85501 2020-06-23 1% **********************************
> 81878 2020-06-24 1% ********************************
> 92900 2020-06-25 1% ************************************
> 87744 2020-06-26 1% **********************************
> 62831 2020-06-27 0% *************************
> 67390 2020-06-28 0% **************************
> 104369 2020-06-29 1% *****************************************
> 100735 2020-06-30 1% ****************************************
> 107741 2020-07-01 1% ******************************************
> 135658 2020-07-02 1% ***********************************************=
*******
> 89205 2020-07-03 1% ***********************************
> 74852 2020-07-04 1% *****************************
> 64488 2020-07-05 0% *************************
> 90414 2020-07-06 1% ***********************************
> 113455 2020-07-07 1% *********************************************
> 95969 2020-07-08 1% **************************************
> 104358 2020-07-09 1% *****************************************
> 95166 2020-07-10 1% *************************************
> 103439 2020-07-11 1% *****************************************
> 104289 2020-07-12 1% *****************************************
> 123107 2020-07-13 1% ***********************************************=
**
> 105469 2020-07-14 1% *****************************************
> 124455 2020-07-15 1% ***********************************************=
**
> 111573 2020-07-16 1% ********************************************
> 114783 2020-07-17 1% *********************************************
> 84040 2020-07-18 1% *********************************
> 91487 2020-07-19 1% ************************************
> 98138 2020-07-20 1% ***************************************
> 86829 2020-07-21 1% **********************************
> 89191 2020-07-22 1% ***********************************
> 92841 2020-07-23 1% ************************************
> 95828 2020-07-24 1% **************************************
> 78270 2020-07-25 1% *******************************
> 79919 2020-07-26 1% *******************************
> 89278 2020-07-27 1% ***********************************
> 105444 2020-07-28 1% *****************************************
> 115671 2020-07-29 1% **********************************************
> 107497 2020-07-30 1% ******************************************
> 91011 2020-07-31 1% ************************************
> 112594 2020-08-01 1% ********************************************
> 117895 2020-08-02 1% **********************************************
> 115567 2020-08-03 1% **********************************************
> 111839 2020-08-04 1% ********************************************
> 133018 2020-08-05 1% ***********************************************=
*****
> 129636 2020-08-06 1% ***********************************************=
****
> 92681 2020-08-07 1% ************************************
> 103041 2020-08-08 1% *****************************************
> 108460 2020-08-09 1% *******************************************
> 101429 2020-08-10 1% ****************************************
> 100971 2020-08-11 1% ****************************************
> 112109 2020-08-12 1% ********************************************
> 108633 2020-08-13 1% *******************************************
> 113473 2020-08-14 1% *********************************************
> 105689 2020-08-15 1% ******************************************
> 105464 2020-08-16 1% *****************************************
> 117522 2020-08-17 1% **********************************************
> 106793 2020-08-18 1% ******************************************
> 115426 2020-08-19 1% *********************************************
> 124808 2020-08-20 1% ***********************************************=
**
> 97833 2020-08-21 1% **************************************
> 80983 2020-08-22 1% ********************************
> 71943 2020-08-23 1% ****************************
> 74813 2020-08-24 1% *****************************
> 29097 2020-08-25 0% ***********
>=20
> 97322.6 Average 1% =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 7104548 Total =20
> 29097 Minimum =20
> 135658 Maximum =20
>=20
>=20
> apache-html-rfcs.hits
> 146316 2020-06-14 0% **************
> 291820 2020-06-15 1% *****************************
> 295920 2020-06-16 1% *****************************
> 338479 2020-06-17 1% **********************************
> 273364 2020-06-18 1% ***************************
> 222879 2020-06-19 0% **********************
> 141763 2020-06-20 0% **************
> 188444 2020-06-21 0% *******************
> 288590 2020-06-22 1% *****************************
> 270873 2020-06-23 1% ***************************
> 305401 2020-06-24 1% ******************************
> 333383 2020-06-25 1% *********************************
> 274105 2020-06-26 1% ***************************
> 241347 2020-06-27 1% ************************
> 188843 2020-06-28 0% *******************
> 348267 2020-06-29 1% ***********************************
> 325185 2020-06-30 1% ********************************
> 373970 2020-07-01 1% *************************************
> 352141 2020-07-02 1% ***********************************
> 321019 2020-07-03 1% ********************************
> 223567 2020-07-04 1% **********************
> 232055 2020-07-05 1% ***********************
> 368149 2020-07-06 1% *************************************
> 353699 2020-07-07 1% ***********************************
> 321830 2020-07-08 1% ********************************
> 394128 2020-07-09 1% ***************************************
> 361806 2020-07-10 1% ************************************
> 280085 2020-07-11 1% ****************************
> 286048 2020-07-12 1% ****************************
> 345781 2020-07-13 1% **********************************
> 288702 2020-07-14 1% *****************************
> 309233 2020-07-15 1% *******************************
> 535266 2020-07-16 2% ***********************************************=
*******
> 352427 2020-07-17 1% ***********************************
> 242841 2020-07-18 1% ************************
> 387772 2020-07-19 1% ***************************************
> 517604 2020-07-20 2% ***********************************************=
*****
> 488514 2020-07-21 2% ***********************************************=
**
> 388045 2020-07-22 1% ***************************************
> 311588 2020-07-23 1% *******************************
> 317076 2020-07-24 1% *******************************
> 211095 2020-07-25 0% *********************
> 283776 2020-07-26 1% ****************************
> 334426 2020-07-27 1% *********************************
> 328170 2020-07-28 1% *********************************
> 340508 2020-07-29 1% **********************************
> 315105 2020-07-30 1% *******************************
> 229031 2020-07-31 1% ***********************
> 159211 2020-08-01 0% ****************
> 220397 2020-08-02 0% **********************
> 316824 2020-08-03 1% *******************************
> 313566 2020-08-04 1% *******************************
> 310807 2020-08-05 1% *******************************
> 331097 2020-08-06 1% *********************************
> 279409 2020-08-07 1% ****************************
> 165472 2020-08-08 0% ****************
> 172664 2020-08-09 0% *****************
> 287621 2020-08-10 1% *****************************
> 295719 2020-08-11 1% *****************************
> 294523 2020-08-12 1% *****************************
> 307640 2020-08-13 1% *******************************
> 416059 2020-08-14 1% *****************************************
> 280695 2020-08-15 1% ****************************
> 263146 2020-08-16 1% **************************
> 333133 2020-08-17 1% *********************************
> 442889 2020-08-18 1% ********************************************
> 478904 2020-08-19 2% ***********************************************=
*
> 435493 2020-08-20 1% *******************************************
> 344104 2020-08-21 1% **********************************
> 280130 2020-08-22 1% ****************************
> 289216 2020-08-23 1% *****************************
> 327903 2020-08-24 1% *********************************
> 126506 2020-08-25 0% ************
>=20
> 306076.2 Average 1% =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 22343564 Total =20
> 126506 Minimum =20
> 535266 Maximum =20
>=20
>=20
> apache-id-draft.hits
> 49253 2020-06-14 1% ***************
> 55167 2020-06-15 1% *****************
> 50603 2020-06-16 1% ****************
> 46365 2020-06-17 1% **************
> 35022 2020-06-18 0% ***********
> 36849 2020-06-19 1% ***********
> 26434 2020-06-20 0% ********
> 50503 2020-06-21 1% ****************
> 39440 2020-06-22 1% ************
> 36768 2020-06-23 1% ***********
> 35647 2020-06-24 1% ***********
> 40646 2020-06-25 1% ************
> 38485 2020-06-26 1% ************
> 29214 2020-06-27 0% *********
> 39570 2020-06-28 1% ************
> 41089 2020-06-29 1% *************
> 33619 2020-06-30 0% **********
> 38919 2020-07-01 1% ************
> 65630 2020-07-02 1% ********************
> 54483 2020-07-03 1% *****************
> 39213 2020-07-04 1% ************
> 57434 2020-07-05 1% ******************
> 49707 2020-07-06 1% ***************
> 52609 2020-07-07 1% ****************
> 57386 2020-07-08 1% ******************
> 49086 2020-07-09 1% ***************
> 62601 2020-07-10 1% *******************
> 158713 2020-07-11 4% ***********************************************=
***
> 105169 2020-07-12 3% *********************************
> 169578 2020-07-13 4% ***********************************************=
*******
> 47409 2020-07-14 1% ***************
> 46682 2020-07-15 1% **************
> 49097 2020-07-16 1% ***************
> 47495 2020-07-17 1% ***************
> 32693 2020-07-18 0% **********
> 47718 2020-07-19 1% ***************
> 42470 2020-07-20 1% *************
> 36461 2020-07-21 1% ***********
> 37586 2020-07-22 1% ***********
> 34639 2020-07-23 0% ***********
> 31298 2020-07-24 0% *********
> 28626 2020-07-25 0% *********
> 47178 2020-07-26 1% ***************
> 37545 2020-07-27 1% ***********
> 36335 2020-07-28 1% ***********
> 43743 2020-07-29 1% *************
> 38596 2020-07-30 1% ************
> 35525 2020-07-31 1% ***********
> 36294 2020-08-01 1% ***********
> 68482 2020-08-02 1% *********************
> 53792 2020-08-03 1% *****************
> 52330 2020-08-04 1% ****************
> 50216 2020-08-05 1% ***************
> 53453 2020-08-06 1% *****************
> 43428 2020-08-07 1% *************
> 47594 2020-08-08 1% ***************
> 65591 2020-08-09 1% ********************
> 49202 2020-08-10 1% ***************
> 44368 2020-08-11 1% **************
> 43565 2020-08-12 1% *************
> 43954 2020-08-13 1% *************
> 42661 2020-08-14 1% *************
> 42860 2020-08-15 1% *************
> 63403 2020-08-16 1% ********************
> 49925 2020-08-17 1% ***************
> 41924 2020-08-18 1% *************
> 45676 2020-08-19 1% **************
> 42967 2020-08-20 1% *************
> 35859 2020-08-21 1% ***********
> 29273 2020-08-22 0% *********
> 41134 2020-08-23 1% *************
> 33938 2020-08-24 0% **********
> 14070 2020-08-25 0% ****
>=20
> 47976.1 Average 1% =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 3502257 Total =20
> 14070 Minimum =20
> 169578 Maximum =20
>=20
>=20
> apache-rfc-rfc.hits
> 5689 2020-06-14 0% ****************
> 7496 2020-06-15 1% *********************
> 6072 2020-06-16 0% *****************
> 7809 2020-06-17 1% **********************
> 8344 2020-06-18 1% ************************
> 5607 2020-06-19 0% ****************
> 6158 2020-06-20 0% *****************
> 8768 2020-06-21 1% *************************
> 6436 2020-06-22 1% ******************
> 10604 2020-06-23 1% ******************************
> 6253 2020-06-24 0% ******************
> 9404 2020-06-25 1% ***************************
> 7029 2020-06-26 1% ********************
> 6340 2020-06-27 0% ******************
> 6685 2020-06-28 1% *******************
> 18446 2020-06-29 2% ***********************************************=
******
> 6903 2020-06-30 1% *******************
> 7748 2020-07-01 1% **********************
> 9239 2020-07-02 1% **************************
> 10152 2020-07-03 1% *****************************
> 6783 2020-07-04 1% *******************
> 6220 2020-07-05 0% ******************
> 9874 2020-07-06 1% ****************************
> 15519 2020-07-07 2% ********************************************
> 8622 2020-07-08 1% ************************
> 9060 2020-07-09 1% **************************
> 9293 2020-07-10 1% **************************
> 9300 2020-07-11 1% **************************
> 7486 2020-07-12 1% *********************
> 9554 2020-07-13 1% ***************************
> 9725 2020-07-14 1% ****************************
> 7622 2020-07-15 1% **********************
> 7774 2020-07-16 1% **********************
> 7787 2020-07-17 1% **********************
> 6762 2020-07-18 1% *******************
> 7617 2020-07-19 1% **********************
> 8770 2020-07-20 1% *************************
> 11967 2020-07-21 1% **********************************
> 7177 2020-07-22 1% ********************
> 6735 2020-07-23 1% *******************
> 11814 2020-07-24 1% **********************************
> 5953 2020-07-25 0% *****************
> 9505 2020-07-26 1% ***************************
> 8357 2020-07-27 1% ************************
> 13692 2020-07-28 2% ***************************************
> 9109 2020-07-29 1% **************************
> 6942 2020-07-30 1% ********************
> 15018 2020-07-31 2% *******************************************
> 7288 2020-08-01 1% *********************
> 10365 2020-08-02 1% ******************************
> 11136 2020-08-03 1% ********************************
> 10579 2020-08-04 1% ******************************
> 11461 2020-08-05 1% *********************************
> 15231 2020-08-06 2% ********************************************
> 9138 2020-08-07 1% **************************
> 10778 2020-08-08 1% *******************************
> 6635 2020-08-09 1% *******************
> 7065 2020-08-10 1% ********************
> 7351 2020-08-11 1% *********************
> 18640 2020-08-12 2% ***********************************************=
*******
> 8030 2020-08-13 1% ***********************
> 7939 2020-08-14 1% **********************
> 7211 2020-08-15 1% ********************
> 6818 2020-08-16 1% *******************
> 7713 2020-08-17 1% **********************
> 8318 2020-08-18 1% ************************
> 9671 2020-08-19 1% ****************************
> 8971 2020-08-20 1% *************************
> 6335 2020-08-21 0% ******************
> 5289 2020-08-22 0% ***************
> 7672 2020-08-23 1% **********************
> 8450 2020-08-24 1% ************************
> 5342 2020-08-25 0% ***************
>=20
> 8748.6 Average 1% =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 638645 Total =20
> 5289 Minimum =20
> 18640 Maximum =20
>=20
--8EinoA1AVW74WXaIMKrfmbVgW7a2M4r7h--
--MWHC9qVxL7IAG2afu6g10R9ACM4XKQemu
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl9Q8RYACgkQTptXS4+7
Fxp2/RAAzSsAehZANBLM3Y4bJvOKUPHtXxEyWRRvSaB74JqdiL+9WvUiLx6wnv1q
luaHPrAM1Mvj5ipjXTlGeAgkpnwVDQsIuVjgmUQU80WNd7bCuKoDp1MhHW89zqdP
qRxWQyIvbTbn/wehu6MiIaI/mx0I71dzoTC6PgwJ8JuAS2s9eQNr9auBNbQS1c03
QhHchh17iWE6/332UrcvqZsCivPt8J4fsiKB8mD+VaOWHEwbyMnhHLVwaA0sC0Lq
qczPCCU45ZujZThBlwxxXRtR9efj9+Vj1bj5CJ+sXAL6G/uWyugkyzudHWc28sUH
J1Zxj2/bVa09AzYIqpFqhXq6xN8oNQSDna3+apI93gWMjRE/FlJY5mYTzSxTaq6K
3SrCpGW5uLJdnmAAbYTsJ9UPP1bl0A9jrbd5AwmOFwLxufyImJmpX5ed1aBeBbxA
ulSjQo0a5cJHFYxdPvhvuTouR5Z9lylAwKTjxF2pIkXGhfgizm7QPRFPBqwKgHH5
NM5aHc69XMpsUpzqA6pv7lQCjCvLCcZVupB1QciqnFzKlE02hVjYatC1lMEHjdyF
3Uh7fZhXjf6rA9pqPNE7tEz86Y/Llbjg/bhAVAlk/4H6VQ+p33cHAh4Uhiy44Sp1
G1Jsx7w7IpwvGOv8z+Pl6sAoiP5HzgkiWC1BqxDJrxcpTy1R+Mc=
=aqM6
-----END PGP SIGNATURE-----
--MWHC9qVxL7IAG2afu6g10R9ACM4XKQemu--
From nobody Wed Sep 9 08:37:38 2020
Return-Path:
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74AB3A0D3A for ; Wed, 9 Sep 2020 08:37:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.079
X-Spam-Level:
X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCJzKGfFMiV8 for ; Wed, 9 Sep 2020 08:37:33 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A62FE3A0E8E for ; Wed, 9 Sep 2020 08:37:33 -0700 (PDT)
Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 089FbVP8019258 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 9 Sep 2020 10:37:32 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1599665852; bh=72ukPnSvtz5Sbwz0KLeV4LROY/JNXc8BrFIs9oqU8ik=; h=To:From:Subject:Date; b=XQYtHn3MrL0P7J4Qoz20hmfdTzXNn+O3uCOKGjryMxW4EsrTSnrdxqQ9RKUR5KOjs SyUnZggdBqSbrc8dfZYZnfPPZovhEtJEVZoYxp8B6BAHf/noWYF0ootwQy+oikVreZ 93tzwZwX7afNuvluGTfVyU03xonyeVZnFItaXIBM=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local
To: "tools-implementation@ietf.org"
From: Robert Sparks
Message-ID: <7ac14729-a756-594e-6eb4-befef94223bc@nostrum.com>
Date: Wed, 9 Sep 2020 10:37:31 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At:
Subject: [Tools-implementation] Reminder: Call On Tue 15 Sep
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 09 Sep 2020 15:37:37 -0000
I will put together an agenda later today or during the day tomorrow,
but at a very high level, the focus will be continuing the conversation
about understanding the files needed by the services we provide. I'd
like to push further on the notion of what we can put into an "attic",
"museum" or other space that has the connotation that this is not
something a service is using and is not expected to change. Separately
we should talk about how that set of bits should be exposed.
From nobody Wed Sep 9 09:21:11 2020
Return-Path:
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8413A0522 for ; Wed, 9 Sep 2020 09:21:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.079
X-Spam-Level:
X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tT3emCnrDwv for ; Wed, 9 Sep 2020 09:21:05 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345A33A0476 for ; Wed, 9 Sep 2020 09:21:05 -0700 (PDT)
Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 089GL301034120 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 9 Sep 2020 11:21:04 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1599668464; bh=zO8vwNz5/Y4KgGYs12JcRF56/IH0YGxM7ywrSKOGiQI=; h=To:From:Subject:Date; b=mmfbPTjHv1XeS7E/xtFpQ2Bu15USzXjRfcEnzyT5gy6O1y+Ko3jkxcr9tVeSWKywz IfYXY//k0yUeaGnKJzcsbuFtAdNQlpDnkcIwKb9S9OS59JqD3WAUktAstDNhF4It9h O8qwYpYCSoPXrd7zXgc9RqkHmFJb7ZEtDRizkYOo=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local
To: "tools-implementation@ietf.org"
From: Robert Sparks
Message-ID: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com>
Date: Wed, 9 Sep 2020 11:21:03 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At:
Subject: [Tools-implementation] Revisiting whether we should continue using Docker as we currently do.
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 09 Sep 2020 16:21:09 -0000
A few weeks ago, shortly after the yc.o team's work managed to crash the
host they were working on through changing settings in a container, I
proposed that we unroll the things we currently have in containers on
production. At the time, Glen suggested we not do that. I'd like to ask
the question again - I think we may have more to consider.
1. I remain uneasy about docker's implementation on OpenSuse. The
container crash above, the issues we've run into with containers locking
(and sometimes causing processes talking to them like apache) to hang
are suspicious. That we've not been able to pin down what's really going
on suggests to me the issue is in a place we can't really look, inside
docker's interstitial networking or filesystem abstraction code perhaps.
2. Many of the containers we have (and in particular the one for the
website) really need to be designed differently if they are going to
remain deployed as containers. The amount of file-system mapping they do
is not what the docker architects expect as a normal use-case. Mapping
sockets in the way we do is also likely not something they focus on testing.
3. Docker is making Glen uncomfortable and the benefit for him
(operationally) of the containerization is not proportional to the extra
problems it is bringing.
So I again suggest that we unroll for the production deploys, at least
for now. I think we can unroll everything at this point, but there might
still be a hitch in unrolling the trac instances. Henrik - could you
remind me what our thinking was with respect to those?
I do plan to keep up the pressure to have containerized versions of
these services - this isn't a call to abandon Docker - but I suggest we
need to change how we're currently using it.
RjS
From nobody Wed Sep 9 10:52:00 2020
Return-Path:
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117B13A0BDC for ; Wed, 9 Sep 2020 10:51:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.858
X-Spam-Level:
X-Spam-Status: No, score=-102.858 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPEkiIQgR2Sd for ; Wed, 9 Sep 2020 10:51:49 -0700 (PDT)
Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50C6E3A0C47 for ; Wed, 9 Sep 2020 10:51:49 -0700 (PDT)
Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 23B7E3C13D4 for ; Wed, 9 Sep 2020 10:51:28 -0700 (PDT)
Received: from [192.168.86.10] (173-8-133-94-SFBA.hfc.comcastbusiness.net [173.8.133.94]) by c8a.amsl.com (Postfix) with ESMTPSA id EE2FF3C13D3 for ; Wed, 9 Sep 2020 10:51:27 -0700 (PDT)
To: tools-implementation@ietf.org
References: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com>
From: Glen
Organization: AMS
Message-ID: <49b0f12f-48a8-f810-2570-1d7f4c4b6342@amsl.com>
Date: Wed, 9 Sep 2020 10:51:47 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.1
MIME-Version: 1.0
In-Reply-To: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At:
Subject: Re: [Tools-implementation] Revisiting whether we should continue using Docker as we currently do.
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 09 Sep 2020 17:51:59 -0000
My full support and agreement here. To clarify: I suggested *not*
doing it only because I didn't want to be the cause of heartburn or the
loud voice whining. :-) But these arguments are persuasive, and I
agree with everything said here, both in terms of present *and* future
planning.
Glen
On 9/9/2020 09:21, Robert Sparks wrote:
> A few weeks ago, shortly after the yc.o team's work managed to crash the
> host they were working on through changing settings in a container, I
> proposed that we unroll the things we currently have in containers on
> production. At the time, Glen suggested we not do that. I'd like to ask
> the question again - I think we may have more to consider.
>
> 1. I remain uneasy about docker's implementation on OpenSuse. The
> container crash above, the issues we've run into with containers locking
> (and sometimes causing processes talking to them like apache) to hang
> are suspicious. That we've not been able to pin down what's really going
> on suggests to me the issue is in a place we can't really look, inside
> docker's interstitial networking or filesystem abstraction code perhaps.
>
> 2. Many of the containers we have (and in particular the one for the
> website) really need to be designed differently if they are going to
> remain deployed as containers. The amount of file-system mapping they do
> is not what the docker architects expect as a normal use-case. Mapping
> sockets in the way we do is also likely not something they focus on
> testing.
>
> 3. Docker is making Glen uncomfortable and the benefit for him
> (operationally) of the containerization is not proportional to the extra
> problems it is bringing.
>
> So I again suggest that we unroll for the production deploys, at least
> for now. I think we can unroll everything at this point, but there might
> still be a hitch in unrolling the trac instances. Henrik - could you
> remind me what our thinking was with respect to those?
>
> I do plan to keep up the pressure to have containerized versions of
> these services - this isn't a call to abandon Docker - but I suggest we
> need to change how we're currently using it.
>
> RjS
>
>
From nobody Wed Sep 9 10:56:09 2020
Return-Path:
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DA83A0BF3 for ; Wed, 9 Sep 2020 10:56:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.848
X-Spam-Level:
X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsnXukvMNf-o for ; Wed, 9 Sep 2020 10:56:06 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F6DA3A0BED for ; Wed, 9 Sep 2020 10:56:06 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:60882 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1kG4KD-0005uM-Bt; Wed, 09 Sep 2020 10:56:05 -0700
To: Robert Sparks , "tools-implementation@ietf.org"
References: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com>
From: Henrik Levkowetz
Message-ID: <55624944-8b1b-317b-94fe-3212d6ef60fe@levkowetz.com>
Date: Wed, 9 Sep 2020 19:55:58 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BKVq4CstLWpBSrgC41ef1WGSfnxKMrRNq"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: tools-implementation@ietf.org, rjsparks@nostrum.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At:
Subject: Re: [Tools-implementation] Revisiting whether we should continue using Docker as we currently do.
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 09 Sep 2020 17:56:08 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--BKVq4CstLWpBSrgC41ef1WGSfnxKMrRNq
Content-Type: multipart/mixed; boundary="kBLGjvumLIsBDXGlbeqCcmoncKVdj3DI6";
protected-headers="v1"
From: Henrik Levkowetz
To: Robert Sparks ,
"tools-implementation@ietf.org"
Message-ID: <55624944-8b1b-317b-94fe-3212d6ef60fe@levkowetz.com>
Subject: Re: [Tools-implementation] Revisiting whether we should continue
using Docker as we currently do.
References: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com>
In-Reply-To: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com>
--kBLGjvumLIsBDXGlbeqCcmoncKVdj3DI6
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hi Robert,
On 2020-09-09 18:21, Robert Sparks wrote:
> So I again suggest that we unroll for the production deploys, at least =
> for now. I think we can unroll everything at this point, but there migh=
t=20
> still be a hitch in unrolling the trac instances. Henrik - could you=20
> remind me what our thinking was with respect to those?
Since we're now running apache with a python 3.6 mod_wsgi, we cannot run
Trac under mod_wsgi until it's available for Python 3. (There's progress=
,
but it's not there yet). Which means moving it to nginx if we're not goi=
ng
to use Docker.
Henrik
--kBLGjvumLIsBDXGlbeqCcmoncKVdj3DI6--
--BKVq4CstLWpBSrgC41ef1WGSfnxKMrRNq
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl9ZFy4ACgkQTptXS4+7
Fxps0g/+PubovxO+fAAld+wmU78QBzYBU+fUMbtaiGghQ81dtNiHeQGFkRZCJV0K
q0lxIxg7OjVUsVX0+pK/TeRi92grLGmJFttxhkzl1X+GKUCRPITqr/OFJmSicrUh
LJtk5GfJCyaltocuErmYtYYrHBuLT/3ABvVTC+Fg1h4G5kzeLb1kzv4uQ1EKA1g+
lVG+ZOmQl9JLeldmow3KgWmaBBJwV+jpobLPNtGCCO7KD33UpRX+cfceO0osSFlB
RgzgT8PnIINxynhuNs73kavyrQJOOJ01CWG4CltSP6oUwz3uoW983lwBrVNtVofb
kwTKSYpT5N8RJ2o+BfEtgutjud/5jlI9czkjiawNUGb3bUPtUjyTtP/XN834FzYq
xiP8HD/Km40o74tKyAjOf4KsgHio8t8XrHxj5KXtjdwj1U0liFMCI3eXKv3G4qfH
+F2Bk6wguuYCDAFDy0NowmH99n5tnY5+ohq2i8Vyi1lHu2nA8ZIS3U3qyoYzYhQC
7Cw2TThb057q5SFbnUlzWutdH8bkLZRACyNgO1v64EzbyqfXr9EYVeoENATD5Db1
9g2rpCVu3mXF6/Dz3e3E8l4rwBsqUMlrOR9xVULpTQQNxSWH7Y996Sry9ky2UOCA
HcApe16fiCmTcd8GXZCrTT1WctS7iYMSOp3vHVs+b5/9h6l2vnE=
=KJ1Q
-----END PGP SIGNATURE-----
--BKVq4CstLWpBSrgC41ef1WGSfnxKMrRNq--
From nobody Wed Sep 9 11:08:09 2020
Return-Path:
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F623A0B85 for ; Wed, 9 Sep 2020 11:08:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.228
X-Spam-Level:
X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.948, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awmvlkXGVtKt for ; Wed, 9 Sep 2020 11:08:06 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FCC43A0AA7 for ; Wed, 9 Sep 2020 11:08:06 -0700 (PDT)
Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 089I83KV070584 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 9 Sep 2020 13:08:04 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1599674884; bh=gxZeyDLMdtwkHVCNDh1gizGMKf0ZwSNI9Dg1Et6TRTU=; h=Subject:To:References:From:Date:In-Reply-To; b=RPLM3JVl4R7GrhwL0dBPRa+eXAz19zPQZ1m2uV1Rdva/66/1ktrB4Dxp79p17jJXX lnGFVN2Rrthzh5Ck5meYY/fW8QK4Hw8Ubn1NwV+1cFDTD8LHU/3qhKIVshCjAvRpKg XCUcG9BWFgG0Qhe5/eWc0yVR7rugjdUfL9Qj18A0=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local
To: Henrik Levkowetz , "tools-implementation@ietf.org"
References: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com> <55624944-8b1b-317b-94fe-3212d6ef60fe@levkowetz.com>
From: Robert Sparks
Message-ID: <1c0ac174-c75d-4af5-f54a-3419b854d189@nostrum.com>
Date: Wed, 9 Sep 2020 13:08:02 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <55624944-8b1b-317b-94fe-3212d6ef60fe@levkowetz.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At:
Subject: Re: [Tools-implementation] Revisiting whether we should continue using Docker as we currently do.
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 09 Sep 2020 18:08:07 -0000
On 9/9/20 12:55 PM, Henrik Levkowetz wrote:
> Hi Robert,
>
> On 2020-09-09 18:21, Robert Sparks wrote:
>
>> So I again suggest that we unroll for the production deploys, at least
>> for now. I think we can unroll everything at this point, but there might
>> still be a hitch in unrolling the trac instances. Henrik - could you
>> remind me what our thinking was with respect to those?
> Since we're now running apache with a python 3.6 mod_wsgi, we cannot run
> Trac under mod_wsgi until it's available for Python 3. (There's progress,
> but it's not there yet). Which means moving it to nginx if we're not going
> to use Docker.
Glen mentioned possibly using mod_wsgi-express to run a separate apache
instance that loaded the 2.7 module rather than the 3.6 module?
>
>
> Henrik
>
From nobody Wed Sep 9 11:29:07 2020
Return-Path:
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CE83A0C30 for ; Wed, 9 Sep 2020 11:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.848
X-Spam-Level:
X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hc_9jhv9W-or for ; Wed, 9 Sep 2020 11:29:05 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31C883A0C28 for ; Wed, 9 Sep 2020 11:29:05 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:61221 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1kG4q8-0007sS-8P; Wed, 09 Sep 2020 11:29:04 -0700
To: Robert Sparks , "tools-implementation@ietf.org"
References: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com> <55624944-8b1b-317b-94fe-3212d6ef60fe@levkowetz.com> <1c0ac174-c75d-4af5-f54a-3419b854d189@nostrum.com>
From: Henrik Levkowetz
Message-ID: <972828d1-6a92-7217-b216-db52ec651bcb@levkowetz.com>
Date: Wed, 9 Sep 2020 20:28:56 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <1c0ac174-c75d-4af5-f54a-3419b854d189@nostrum.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GlMumqoI92bdPNL0wTQOjCNpTritjcsog"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: tools-implementation@ietf.org, rjsparks@nostrum.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At:
Subject: Re: [Tools-implementation] Revisiting whether we should continue using Docker as we currently do.
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 09 Sep 2020 18:29:06 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--GlMumqoI92bdPNL0wTQOjCNpTritjcsog
Content-Type: multipart/mixed; boundary="mkoFKssQFQmOuak95fwxM7pUT1tbcXwQ6";
protected-headers="v1"
From: Henrik Levkowetz
To: Robert Sparks ,
"tools-implementation@ietf.org"
Message-ID: <972828d1-6a92-7217-b216-db52ec651bcb@levkowetz.com>
Subject: Re: [Tools-implementation] Revisiting whether we should continue
using Docker as we currently do.
References: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com>
<55624944-8b1b-317b-94fe-3212d6ef60fe@levkowetz.com>
<1c0ac174-c75d-4af5-f54a-3419b854d189@nostrum.com>
In-Reply-To: <1c0ac174-c75d-4af5-f54a-3419b854d189@nostrum.com>
--mkoFKssQFQmOuak95fwxM7pUT1tbcXwQ6
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
On 2020-09-09 20:08, Robert Sparks wrote:
>=20
> On 9/9/20 12:55 PM, Henrik Levkowetz wrote:
>> Hi Robert,
>>
>> On 2020-09-09 18:21, Robert Sparks wrote:
>>
>>> So I again suggest that we unroll for the production deploys, at leas=
t
>>> for now. I think we can unroll everything at this point, but there mi=
ght
>>> still be a hitch in unrolling the trac instances. Henrik - could you
>>> remind me what our thinking was with respect to those?
>> Since we're now running apache with a python 3.6 mod_wsgi, we cannot r=
un
>> Trac under mod_wsgi until it's available for Python 3. (There's progr=
ess,
>> but it's not there yet). Which means moving it to nginx if we're not =
going
>> to use Docker.
> Glen mentioned possibly using mod_wsgi-express to run a separate apache=
=20
> instance that loaded the 2.7 module rather than the 3.6 module?
I don't think you can run 2 Apache instances with different mod_wsgi modu=
les
without containerizing one of them?
Henrik
--mkoFKssQFQmOuak95fwxM7pUT1tbcXwQ6--
--GlMumqoI92bdPNL0wTQOjCNpTritjcsog
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl9ZHukACgkQTptXS4+7
FxpGaQ/5AZGhYiGADu70BlQtArvbbnqEJgSmI65Ad1rQBQ3TzPZfWCN4BD9/I5Kx
pKSyQhEtdqSiozlZOlinpktKun06ilVtYEfX6r6J/PmLh5HGpfc3qWsk9WcDSg31
LSAZcvJqJLH3N6e9IVELNydzj+8Sk5m/gyd1nBONZXuP4xHMQ/YHiXn2xwJ2pdnr
2YgIudob1HWtrDifuzfqbOZT/cF5qtDETnIeMcr554Aj15vjiVdeP+zF520q9Dog
dfnJ06drVABNqf5JzcU6FNGJiruBdGIxwaKpxeo7D/0HeBI2bH9mUhAPe7600a0X
W1a5yslXhacFfVgyyJQHlngoE0KNjy5E/e/cRsaRzlLVYJTZ8ZjhFkzHo9RzH/V6
GdOYx6Zx8N022ZIe71E1vtdrbYEXYWOLXtKsMY/CNOoZ/PXQTp2D4khW5xluXrtw
eAmeI0aKJ14pZXK9DkkA1G2X4LlPnURUlpb25J8Hc0OhyRJcBM1oSJ9c8i6Azdlo
M+Bw10rHPZQX/RirIsc5OQQHMMGRSRjTFv+L/VJ6n2IKLCuqOuBSN5IjgbZKmSwv
Po5SeAfqPbOrm+3s9wLRn4dHtO5Ix41HtX5CfZNm3YiW52IdN6hcDCiLRqoSU2FJ
fSUmDpBZNE1dzEfbqk4qeQesj3NjIYZTz2PO0KX04K6b4wOTRww=
=+kUv
-----END PGP SIGNATURE-----
--GlMumqoI92bdPNL0wTQOjCNpTritjcsog--
From nobody Wed Sep 9 13:02:25 2020
Return-Path:
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CF13A0D54 for ; Wed, 9 Sep 2020 13:02:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCiA77N5AmYx for ; Wed, 9 Sep 2020 13:02:20 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43383A0B41 for ; Wed, 9 Sep 2020 13:02:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6D7C6300B70 for ; Wed, 9 Sep 2020 16:02:18 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AO-IjC7ZtYpb for ; Wed, 9 Sep 2020 16:02:16 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 557A9300435; Wed, 9 Sep 2020 16:02:16 -0400 (EDT)
From: Russ Housley
Message-Id:
Content-Type: multipart/alternative; boundary="Apple-Mail=_EFDD6B93-6631-4491-9656-824ECF59CC91"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\))
Date: Wed, 9 Sep 2020 16:02:17 -0400
In-Reply-To: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com>
Cc: "tools-implementation@ietf.org"
To: Robert Sparks
References: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com>
X-Mailer: Apple Mail (2.3445.104.15)
Archived-At:
Subject: Re: [Tools-implementation] Revisiting whether we should continue using Docker as we currently do.
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 09 Sep 2020 20:02:23 -0000
--Apple-Mail=_EFDD6B93-6631-4491-9656-824ECF59CC91
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
One of the reasons that we went to containers was to isolate some =
python2 from python3. Will we just use virtual environment for that?
Russ
> On Sep 9, 2020, at 12:21 PM, Robert Sparks =
wrote:
>=20
> A few weeks ago, shortly after the yc.o team's work managed to crash =
the host they were working on through changing settings in a container, =
I proposed that we unroll the things we currently have in containers on =
production. At the time, Glen suggested we not do that. I'd like to ask =
the question again - I think we may have more to consider.
>=20
> 1. I remain uneasy about docker's implementation on OpenSuse. The =
container crash above, the issues we've run into with containers locking =
(and sometimes causing processes talking to them like apache) to hang =
are suspicious. That we've not been able to pin down what's really going =
on suggests to me the issue is in a place we can't really look, inside =
docker's interstitial networking or filesystem abstraction code perhaps.
>=20
> 2. Many of the containers we have (and in particular the one for the =
website) really need to be designed differently if they are going to =
remain deployed as containers. The amount of file-system mapping they do =
is not what the docker architects expect as a normal use-case. Mapping =
sockets in the way we do is also likely not something they focus on =
testing.
>=20
> 3. Docker is making Glen uncomfortable and the benefit for him =
(operationally) of the containerization is not proportional to the extra =
problems it is bringing.
>=20
> So I again suggest that we unroll for the production deploys, at least =
for now. I think we can unroll everything at this point, but there might =
still be a hitch in unrolling the trac instances. Henrik - could you =
remind me what our thinking was with respect to those?
>=20
> I do plan to keep up the pressure to have containerized versions of =
these services - this isn't a call to abandon Docker - but I suggest we =
need to change how we're currently using it.
>=20
> RjS
>=20
>=20
> --=20
> Tools-implementation mailing list
> Tools-implementation@ietf.org
> https://www.ietf.org/mailman/listinfo/tools-implementation
--Apple-Mail=_EFDD6B93-6631-4491-9656-824ECF59CC91
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
One of the reasons that =
we went to containers was to isolate some python2 from python3. =
Will we just use virtual environment for =
that?
Russ
A =
few weeks ago, shortly after the yc.o team's work managed to crash the =
host they were working on through changing settings in a container, I =
proposed that we unroll the things we currently have in containers on =
production. At the time, Glen suggested we not do that. I'd like to ask =
the question again - I think we may have more to consider.
1. I remain uneasy about docker's =
implementation on OpenSuse. The container crash above, the issues we've =
run into with containers locking (and sometimes causing processes =
talking to them like apache) to hang are suspicious. That we've not been =
able to pin down what's really going on suggests to me the issue is in a =
place we can't really look, inside docker's interstitial networking or =
filesystem abstraction code perhaps.
2. =
Many of the containers we have (and in particular the one for the =
website) really need to be designed differently if they are going to =
remain deployed as containers. The amount of file-system mapping they do =
is not what the docker architects expect as a normal use-case. Mapping =
sockets in the way we do is also likely not something they focus on =
testing.
3. Docker is making Glen =
uncomfortable and the benefit for him (operationally) of the =
containerization is not proportional to the extra problems it is =
bringing.
So I again suggest that we unroll =
for the production deploys, at least for now. I think we can unroll =
everything at this point, but there might still be a hitch in unrolling =
the trac instances. Henrik - could you remind me what our thinking was =
with respect to those?
I do plan to keep up =
the pressure to have containerized versions of these services - this =
isn't a call to abandon Docker - but I suggest we need to change how =
we're currently using it.
RjS
--
Tools-implementation mailing list
Tools-implementation@ietf.orghttps://www.ietf.org/mailman/listinfo/tools-implementation
=
--Apple-Mail=_EFDD6B93-6631-4491-9656-824ECF59CC91--
From nobody Wed Sep 9 13:04:25 2020
Return-Path:
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBEC3A0D58 for ; Wed, 9 Sep 2020 13:04:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.026
X-Spam-Level:
X-Spam-Status: No, score=-3.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.948, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfWjOD5mVXVX for ; Wed, 9 Sep 2020 13:04:22 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9A13A0B15 for ; Wed, 9 Sep 2020 13:04:22 -0700 (PDT)
Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 089K4KQW010282 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 9 Sep 2020 15:04:21 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1599681861; bh=drl+fQqJ/PhdriTc3sL9BY1dCqhrHnVFg22hSiLobVo=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=aiajo5AGaRHwONOoujd6r96Yab5r0ME21wZw1IHUlQblXpbwN9levRTB/Dp1XX5w8 B2oIck2MzvBSnskkGGhKhzxxZ2tIpYYIPvcXoniLfGwqvjO1w9OpzaOZP7wt0thrAF DK+CpW8RipKkiNYGtXZZA/bj91CHL+thiTlO2n+E=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local
To: Russ Housley
Cc: "tools-implementation@ietf.org"
References: <3ae28788-898a-de72-22b6-b0f036d1b23a@nostrum.com>
From: Robert Sparks
Message-ID: <280055fe-c8e4-669f-9df1-22ab032d828d@nostrum.com>
Date: Wed, 9 Sep 2020 15:04:20 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To:
Content-Type: multipart/alternative; boundary="------------10D8EF02AF537B53B264FF10"
Content-Language: en-US
Archived-At:
Subject: Re: [Tools-implementation] Revisiting whether we should continue using Docker as we currently do.
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 09 Sep 2020 20:04:24 -0000
This is a multi-part message in MIME format.
--------------10D8EF02AF537B53B264FF10
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
On 9/9/20 3:02 PM, Russ Housley wrote:
> One of the reasons that we went to containers was to isolate some
> python2 from python3. Will we just use virtual environment for that?
That's the essence of the question below about trac. Trac may need to
remain in a container, or move to a separate vm, or something, though
we're continuing looking closely at whether we can avoid either.
>
> Russ
>
>> On Sep 9, 2020, at 12:21 PM, Robert Sparks > > wrote:
>>
>> A few weeks ago, shortly after the yc.o team's work managed to crash
>> the host they were working on through changing settings in a
>> container, I proposed that we unroll the things we currently have in
>> containers on production. At the time, Glen suggested we not do that.
>> I'd like to ask the question again - I think we may have more to
>> consider.
>>
>> 1. I remain uneasy about docker's implementation on OpenSuse. The
>> container crash above, the issues we've run into with containers
>> locking (and sometimes causing processes talking to them like apache)
>> to hang are suspicious. That we've not been able to pin down what's
>> really going on suggests to me the issue is in a place we can't
>> really look, inside docker's interstitial networking or filesystem
>> abstraction code perhaps.
>>
>> 2. Many of the containers we have (and in particular the one for the
>> website) really need to be designed differently if they are going to
>> remain deployed as containers. The amount of file-system mapping they
>> do is not what the docker architects expect as a normal use-case.
>> Mapping sockets in the way we do is also likely not something they
>> focus on testing.
>>
>> 3. Docker is making Glen uncomfortable and the benefit for him
>> (operationally) of the containerization is not proportional to the
>> extra problems it is bringing.
>>
>> So I again suggest that we unroll for the production deploys, at
>> least for now. I think we can unroll everything at this point, but
>> there might still be a hitch in unrolling the trac instances. Henrik
>> - could you remind me what our thinking was with respect to those?
>>
>> I do plan to keep up the pressure to have containerized versions of
>> these services - this isn't a call to abandon Docker - but I suggest
>> we need to change how we're currently using it.
>>
>> RjS
>>
>>
>> --
>> Tools-implementation mailing list
>> Tools-implementation@ietf.org
>> https://www.ietf.org/mailman/listinfo/tools-implementation
>
--------------10D8EF02AF537B53B264FF10
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
On 9/9/20 3:02 PM, Russ Housley wrote:
One of the
reasons that we went to containers was to isolate some
python2 from python3. Will we just use virtual
environment for that?
That's the essence of the question below about trac. Trac may
need to remain in a container, or move to a separate vm, or
something, though we're continuing looking closely at whether we
can avoid either.
A few weeks ago, shortly after the yc.o team's
work managed to crash the host they were working on
through changing settings in a container, I proposed that
we unroll the things we currently have in containers on
production. At the time, Glen suggested we not do that.
I'd like to ask the question again - I think we may have
more to consider.
1. I remain uneasy about docker's implementation on
OpenSuse. The container crash above, the issues we've run
into with containers locking (and sometimes causing
processes talking to them like apache) to hang are
suspicious. That we've not been able to pin down what's
really going on suggests to me the issue is in a place we
can't really look, inside docker's interstitial networking
or filesystem abstraction code perhaps.
2. Many of the containers we have (and in particular the
one for the website) really need to be designed
differently if they are going to remain deployed as
containers. The amount of file-system mapping they do is
not what the docker architects expect as a normal
use-case. Mapping sockets in the way we do is also likely
not something they focus on testing.
3. Docker is making Glen uncomfortable and the benefit for
him (operationally) of the containerization is not
proportional to the extra problems it is bringing.
So I again suggest that we unroll for the production
deploys, at least for now. I think we can unroll
everything at this point, but there might still be a hitch
in unrolling the trac instances. Henrik - could you remind
me what our thinking was with respect to those?
I do plan to keep up the pressure to have containerized
versions of these services - this isn't a call to abandon
Docker - but I suggest we need to change how we're
currently using it.
RjS
--
Tools-implementation mailing list
Tools-implementation@ietf.org
https://www.ietf.org/mailman/listinfo/tools-implementation
--------------10D8EF02AF537B53B264FF10--
From nobody Thu Sep 10 11:52:03 2020
Return-Path:
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1233A0CE6 for ; Thu, 10 Sep 2020 11:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.079
X-Spam-Level:
X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbB7nwmujvzb for ; Thu, 10 Sep 2020 11:52:00 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA3D13A0C3D for ; Thu, 10 Sep 2020 11:52:00 -0700 (PDT)
Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 08AIpwQk004232 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 10 Sep 2020 13:52:00 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1599763920; bh=lkbgWECUU3Q1A3baTl3gLECKPAm6FE00CDqiZE9JxSs=; h=To:From:Subject:Date; b=UDzVCHZzL5mf87gm4RpAS5HVEusiH97WFZrhPS0ZPlLySE7TAMknmmOWHMdhoottE bGb3oqwHmrVasYdKDhkqwRImQ1Oi7W6fBCKCnhxeOSzZLO2kGhzBI2lxxbQcyK3OJj dIIYaFUjH+dJ/6R1y4wpMVyGo5+TtG+8JsZ9ku7U=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local
To: "tools-implementation@ietf.org"
From: Robert Sparks
Message-ID:
Date: Thu, 10 Sep 2020 13:51:58 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At:
Subject: [Tools-implementation] Agenda for next week
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation
List-Unsubscribe: