Dear Ruediger, Thanks you for your observations and comments. I have answered your questions inline below:
> Op 29 aug. 2018, om 16:18 heeft Ruediger Volk, Deutsche Telekom Technik - > FMED-41.. <r...@nic.dtag.de> het volgende geschreven: > > Dear Nathalie, and colleagues, > > some observations/questions/comments on the database 1.92[.x?] > preparation/testing and planned deployment. > Please watch out for the "PLEASE" marker for action items. > >> Dear Colleagues, >> >> Following the implementation plan for NWI-5 (Out-of-region ROUTE(6) >> objects and removal of ASN authorisation for ROUTE(6) object creation) >> we have now deployed the NWI-5 changes to the RC (Release Candidate) >> environment. >> The RC environment allows you to test the impact of the changes before >> we will go to production on 4 September 2018. > >> We encourage you to test the impact of the NWI-5 changes on your scripts >> and tools and report any issues you may find to ripe-...@ripe.net >> <mailto:ripe-...@ripe.net> > our ops team reported that during their first test runs they saw 1.92.2 > in the RC environment, and later queries were answered by 1.92.3 - > without any explanation available it looked like they had to redo the testing. > While no unexpected behaviour was identified so far the value of testing > is somewhat questionable if the "system under test" is being changed > in unknown ways without notification or explanation - specifically > with the open question whether/when/what further changes may occur > before moving to production. > The web pages for the Release Candidate environment and the Release Notes > only talk about 1.92 and do NOT claim to have been updated after 2018-08-03. > I only see two update messages on the wg mailing list (both 2018-08-14) > which are NOT reporting different versions of the RC environment. > > PLEASE PROVIDE information on what/why happened, and what to expect. Actually, there were 3 RC releases since the announcement. The first version after the announcement(1.92.1) added separate sources for NRTM. The next release (1.92.2) added the RIPE-NONAUTH source to database dump and split files and the final version (1.92.3) fixed a redirect bug in the API. We should have stated that more explicitly in the release notes. We will take this lesson on board for the next time, to make sure we have complete and correct release notes and numbers. > > PLEASE PUBLISH now the time window during which the production system > will be converted. Production users ought to be able to schedule > important runs to avoid that conversion window, and decide what > better is run before, and potentially final tests on the production > system before continuing routine production - currently available > information means during the whole Sep. 4th (and potentially late Sep. 3rd) > the status of the database is unknown. > > I understand that the split of sources RIPE ./. RIPE-NONAUTH will be > handled so that queries using the "default source selection" > (i.e. traditional whois queries WITHOUT -s parameter) will > return the same results before and after the conversion - > aside of changes due to users changing their data in the database. > (PLEASE confirm - I did not find this explicitly stated in a prominent place, > and only figured out this detail from the impact analysis.) > Inconsistencies during the conversion window would seem > somewhat acceptable - the STRONG requirement for the conversion window > is to KNOW (in advance!) WHEN the system is in a less trustworthy > transitional state. I will send a separate e-mail to the working group in a moment, with the time lines and order of events, but for sake of completeness (I’m replying to you already), This is how it is scheduled: We will implement all the changes between 09:00 CET and 15:00 UTC+2 in the following order: Remove mnt-routes attribute from aut-num objects Remove RPSL maintainer Deploy the Whois NWI-5 release to production Update source to RIPE-NONAUTH Update Pending route(6) objects The FTP files will be generated as usual around midnight UTC+2, after all the changes have been implemented. > > Operators usually prefer to transition using the "make before break" paradigm. > I note that the production system currently returns an error condition > when queried with explicitly specified sources including the new > RIPE-NONAUTH; this means explicit query for the new default > ("-s RIPE,RIPE-NONAUTH") fails. > Those who have queries that currently specify e.g. -s RIPE,APNIC-GRS > cannot upgrade their tools to the equivalent future form > -s RIPE,RIPE-NONAUTH,APNIC-GRS so far without "breaking". > To support "make before break" and allow users to prepare for > smooth transition the production database actually SHOULD already accept > queries for the new source without returning "unknown source" failure. > For MY environment this is NOT critical. > PLEASE consider quickly improving support for this and report to users. While Job also urged for the “make before break” option, we will not accept queries for the new source before the 4rd of September, as we don’t want to impact production before the 4rd of September. We will of course first create the source RIPE-NONAUTH and then move all impacted objects immediately to this new source. This should not take more than 4 hours. Of course we will send an update to the DB-WG mailing list once all changes have been implemented. With kind regards, Nathalie Trenaman Product Manager RIPE NCC
