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

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
>>