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

[Alissa Cooper <[e-mail]>]

> On Feb 8, 2019, at 12:40 PM, Eric Rescorla <[e-mail]> wrote:
> 
> 
> 
> On Fri, Feb 8, 2019 at 9:29 AM Robert Sparks <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> On 2/8/19 11:20 AM, Eric Rescorla wrote:
>> 
>> 
>> On Fri, Feb 8, 2019 at 8:51 AM Robert Sparks <[e-mail] <mailto:[e-mail]>> 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.
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 <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
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/tools-development <https://www.ietf.org/mailman/listinfo/tools-development>
> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tools-development