Re: [TOOLS-DEVELOPMENT] Notes for 12Feb tools call

Robert Sparks <rjsparks@nostrum.com> Fri, 08 February 2019 17:54 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 218091294FA for <tools-development@ietfa.amsl.com>; Fri, 8 Feb 2019 09:54:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 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, 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 zWjbabawo27X for <tools-development@ietfa.amsl.com>; Fri, 8 Feb 2019 09:54:16 -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 1C450124BF6 for <tools-development@ietf.org>; Fri, 8 Feb 2019 09:54:15 -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 x18HsDYY008189 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 8 Feb 2019 11:54:14 -0600 (CST) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1549648455; bh=0iTbi1aclKwSFIRGTMTWC3bpW8C6H1UeuepJKO2Cspo=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=GJrE8ZK9kSWjhp+9k/3dBUrytykPWUWhhenASMnmxbpBUHbndWiVRvRIdD3/vuDQp EyjONyBTa6LwfolPRdzd9B/1qALf8VHrWHcRFeJXPgMkj3Sum3WgMy4fgOO2s9CbIk m0aN2YvldzO2jnLzgCKthJNHEvWpXcuiIaa8RuTw=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.39.7] claimed to be unescapeable.local
To: 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>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <243b50bb-6f2b-fd01-99eb-b515b5b4e453@nostrum.com>
Date: Fri, 8 Feb 2019 11:54:13 -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: <CABcZeBM9uAGNHqyWPa1Mz810oD83D1pRNMn_TA+ZAzFKZuadYw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------461C8754F62F8A54247FA59D"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-development/F1bNv2n8scB3Cvuik3EMWu_Ouh8>
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: Fri, 08 Feb 2019 17:54:19 -0000

On 2/8/19 11:40 AM, Eric Rescorla 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.
Agreed - that one of the options we're talking about.
>
>>         # 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?
>
> -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
>>