Re: [TOOLS-DEVELOPMENT] Notes for 12Feb tools call
Robert Sparks <rjsparks@nostrum.com> Tue, 12 February 2019 14:44 UTC
Return-Path: <rjsparks@nostrum.com>
X-Original-To: tools-development@ietfa.amsl.com
Delivered-To: tools-development@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F721200B3 for <tools-development@ietfa.amsl.com>; Tue, 12 Feb 2019 06:44:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.719
X-Spam-Level:
X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 C4IBPeF9YeWy for <tools-development@ietfa.amsl.com>; Tue, 12 Feb 2019 06:44:14 -0800 (PST)
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 5AC491200ED for <tools-development@ietf.org>; Tue, 12 Feb 2019 06:44:14 -0800 (PST)
Received: from unescapeable.local ([47.186.39.7]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x1CEi5ot020652 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 12 Feb 2019 08:44:06 -0600 (CST) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1549982647; bh=ME0wftI19qg38sNR2wgTo17OkmTx9v8ZJx657CsCGXU=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=isgr+XzWC+5LipTKcItXgrEcGR9kNwzjxyC1y/Ve091n2FZIX4iC0Gut+wFusy4xj j5B5gZnWbE3atiWyMSccO3qFl3Qwk1eE8pcNtSaa2kBLwkZhCpVtdRS2qFRaDeA634 6dWAET588BZRw2qXCkpKEbyR7NCM7odV7Ap+tC0c=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.39.7] claimed to be unescapeable.local
To: Alissa Cooper <alissa@cooperw.in>, Eric Rescorla <ekr@rtfm.com>
Cc: IETF Tools Development <tools-development@ietf.org>
References: <6f07a810-b829-9f8c-32be-edc0db92a016@nostrum.com> <CABcZeBN15BBYv9vhN4cJp1QyLVV6DNRf74718k592ucCTwfd-A@mail.gmail.com> <5e4296d8-6e6d-d023-639e-c10baeac4fec@nostrum.com> <CABcZeBM9uAGNHqyWPa1Mz810oD83D1pRNMn_TA+ZAzFKZuadYw@mail.gmail.com> <90C96271-23D0-4784-8043-D99CD08FFF80@cooperw.in>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <de769cd4-c55c-102e-f9b1-c175db589f66@nostrum.com>
Date: Tue, 12 Feb 2019 08:44:04 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <90C96271-23D0-4784-8043-D99CD08FFF80@cooperw.in>
Content-Type: multipart/alternative; boundary="------------4ACFD8FF5308A1AA095A0198"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-development/U5nwYri5ReF8zINgv2iHNNGqDEw>
Subject: Re: [TOOLS-DEVELOPMENT] Notes for 12Feb tools call
X-BeenThere: tools-development@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Development list server <tools-development.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-development>, <mailto:tools-development-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-development/>
List-Post: <mailto:tools-development@ietf.org>
List-Help: <mailto:tools-development-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-development>, <mailto:tools-development-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Feb 2019 14:44:19 -0000
On 2/12/19 8:19 AM, Alissa Cooper wrote: > > >> On Feb 8, 2019, at 12:40 PM, Eric Rescorla <ekr@rtfm.com >> <mailto:ekr@rtfm.com>> wrote: >> >> >> >> On Fri, Feb 8, 2019 at 9:29 AM Robert Sparks <rjsparks@nostrum.com >> <mailto:rjsparks@nostrum.com>> wrote: >> >> >> On 2/8/19 11:20 AM, Eric Rescorla wrote: >>> >>> >>> On Fri, Feb 8, 2019 at 8:51 AM Robert Sparks >>> <rjsparks@nostrum.com <mailto:rjsparks@nostrum.com>> wrote: >>> >>> # IETF Website # >>> >>> Torchbox has completed their last major deliverable >>> (upgrading the >>> website to a more modern version of wagtail). There are a >>> small number >>> of tickets related to documentation and requests for >>> information we >>> should have before shifting the code into our own public code >>> repository. Note that the wagtail project continues to issue new >>> releases. The project with torchbox brought us to wagtail >>> 2.2.2. The >>> current release now is 2.4. >>> >>> However, we are blocked on deploying this latest >>> deliverable. The way we >>> are serving python applications via Apache right now >>> (mod_wsgi) only >>> allows the use of one version of python. Many of our >>> applications are on >>> Python 2.7 right now. This includes the datatracker and the >>> mailarchive. >>> Wagtail, on the other hand, dropped support for python 2.7 >>> at Wagtail >>> 2.0. Waiting until we have all exisiting deployed >>> applications ported to >>> python 3 to deploy the deliverable from Torchbox is exceedingly >>> suboptimal. It will delay the current plan for the >>> tools-team to take >>> over maintenance of the website code and start adding >>> features the >>> secretariat has asked for. We've started conversations about >>> what other >>> options we have besides waiting for everything to be ported >>> to python 3. >>> >>> >>> Why does the version of datatracker impact the version of >>> Wagtail we run? They seem to be on different hosts, so can't >>> they run different versions of Python? >> They are currently served from the same machine, even if they >> have different hostnames. >> >> >> This seems like a good opportunity to move one to a different >> machine, or better yet, to some system (containers?) where hardware >> assignment doesn't matter. >> >>> # Yangcatalog # >>> >>> We've shifted the plan for short-term deployment and >>> development to >>> occur using the existing externally hosted server. >>> >>> >>> Can you provide some more background for this? Why can't this be >>> moved to an IETF server (or IETF-managed cloud) >> There were some difficulties trying to move this to an IETF >> server given the current level of access to internals (shell >> access to the machine) required by the application. Eric and the >> developers were experiencing connectivity problems that couldn't >> be reproduced from other locations, and it appears some trouble >> with outbound connections that Glen's team couldn't isolate. The >> goal is _definitely_ to be where we could deploy anywhere. The >> first task in the outstanding SoW includes the work needed to get >> the project to the point that shell access isn't required by the >> developers or application expert. It will also improve release >> packaging to make deploying wherever more feasible.'' >> >> >> Hmm.... So my instinct here would be to hold off on doing anything >> else until that's happened. Alissa, WDYT? > > I think that sounds like what the SOW calls for. That's what I'm expecting of it too. > Alissa > >> >> -Ekr >> >>> >>> -Ekr >>> >>> The meeting application improvement SoW is essentially ready >>> to issue. >>> >>> I have text from Ekr to work into the RPC security code >>> review SoW. The >>> RPC has asked that we hold off issuing that RFP until some >>> changes >>> related to the new format are better integrated into their >>> repository so >>> that the review focuses more on the code that will actually >>> be used. >>> >>> The Inline-Errata SoW is still under review and has several >>> unresolved >>> comments. The lastest version is at >>> <https://docs.google.com/document/d/1T-6eBrNPC7aIxOTChdIZE7fecbxUJ7kq-F6RhyCNUGI/edit>. >>> One of the major observations in the comments is that this >>> project is >>> focusing on the existing (old-format) publication format, >>> and is not >>> targetting or taking advantage of the new format in any way. >>> That's >>> intentional. We need to have some run-time experience with >>> the new >>> format before we can sensibly ask a contractor to work on >>> inlining >>> errata into it. We plan to learn from this project, and >>> apply what we >>> learn into the new format with a future project. >>> >>> The next SoW to be developed is for IANA expert review tracking. >>> >>> >>> >>> _______________________________________________ >>> TOOLS-DEVELOPMENT mailing list >>> TOOLS-DEVELOPMENT@ietf.org <mailto:TOOLS-DEVELOPMENT@ietf.org> >>> https://www.ietf.org/mailman/listinfo/tools-development >>> >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org <mailto:TOOLS-DEVELOPMENT@ietf.org> >> https://www.ietf.org/mailman/listinfo/tools-development >
- [TOOLS-DEVELOPMENT] Notes for 12Feb tools call Robert Sparks
- Re: [TOOLS-DEVELOPMENT] Notes for 12Feb tools call Eric Rescorla
- Re: [TOOLS-DEVELOPMENT] Notes for 12Feb tools call Robert Sparks
- Re: [TOOLS-DEVELOPMENT] Notes for 12Feb tools call Eric Rescorla
- Re: [TOOLS-DEVELOPMENT] Notes for 12Feb tools call Robert Sparks
- Re: [TOOLS-DEVELOPMENT] Notes for 12Feb tools call Alissa Cooper
- Re: [TOOLS-DEVELOPMENT] Notes for 12Feb tools call Alissa Cooper
- Re: [TOOLS-DEVELOPMENT] Notes for 12Feb tools call Robert Sparks
- Re: [TOOLS-DEVELOPMENT] Notes for 12Feb tools call Robert Sparks
- Re: [TOOLS-DEVELOPMENT] Notes for 12Feb tools call Alissa Cooper
- Re: [TOOLS-DEVELOPMENT] Notes for 12Feb tools call Alexa Morris
- Re: [TOOLS-DEVELOPMENT] Notes for 12Feb tools call Robert Sparks
- Re: [TOOLS-DEVELOPMENT] Notes for 12Feb tools call Alexa Morris
- Re: [TOOLS-DEVELOPMENT] Notes for 12Feb tools call Alexa Morris