Database release 1.79 deployed to RC environment
Dear colleagues, The RIPE NCC is pleased to announce the deployment of RIPE Database software release 1.79 to the Release Candidate (RC) environment: https://www.ripe.net/data-tools/db/release-notes/rc-release-candidate-enviro... <https://www.ripe.net/data-tools/db/release-notes/rc-release-candidate-environment> This release introduces the new attributes "created:" and "last-modified:" as part of the first phase of the deprecating the changed attribute in the RIPE Database. You can find more information about the three phases of this effort here: https://labs.ripe.net/Members/tim/deprecating-the-changed-attribute-in-the-r... <https://labs.ripe.net/Members/tim/deprecating-the-changed-attribute-in-the-ripe-database> It should be noted however that: = The new attributes will only be enabled in output this Thursday 2 April (because updating all objects with initial values takes a long time) = We have found that we needed to use the 1970-01-01T00:00:00Z instead of 0000-00-00T00:00:00Z (because it's invalid, and we observed inconsistencies in dealing with year 0 AD different libraries) We will update the referenced article shortly to reflect these changes. This release also changes attribute "referral-by" from mandatory to optional. This attribute is part of a mntner object for historical reasons and will be deprecated. Detailed release notes are published here: https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.79 <https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.79> Documentation for this release is published here: https://www.ripe.net/data-tools/support/documentation/ripe-database-document... <https://www.ripe.net/data-tools/support/documentation/ripe-database-documentation-1.79> Please let us know if you find any issues with this release. We plan to deploy this release to the production environment on Tuesday 28 April, and we plan to enable the new "created:" and "last-modified:" attributes the following Monday 4 May - after the initial values have been added for all objects. Please let us know if you have any questions or comments. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC
Dear colleagues, We have found two issues with the 1.79 in the Release Candidate environment: - Deletion of objects would not work until the new attributes are enabled - The publication of sponsoring org for legacy resources by the RIPE NCC (policy 2014-06) was not allowed by business rules For this reason we deployed a bug fix release 1.79.1 to the RC environment. Currently it is running in 'old' mode, i.e. the "last-modified:" and "created:" attributes are not visible in the output while we are updating all objects again. We chose to re-run this migration because we want to be sure that it will work on this exact release of whois when it is deployed to production. We expect the migration to finish later today, and will enable the new attributes tomorrow. Because no major changes were introduced with these fixes we plan to adhere to the original planning and deploy the 1.79.1 release of whois to the production environment on Tuesday 28 April (Monday is a public holiday here), and we plan to enable the new attributes in the output on Monday 4 May. Please let us know if you have any questions or comments. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC
On 31 Mar 2015, at 17:54, Tim Bruijnzeels <tim@ripe.net> wrote:
Dear colleagues,
The RIPE NCC is pleased to announce the deployment of RIPE Database software release 1.79 to the Release Candidate (RC) environment: https://www.ripe.net/data-tools/db/release-notes/rc-release-candidate-enviro... <https://www.ripe.net/data-tools/db/release-notes/rc-release-candidate-environment>
This release introduces the new attributes "created:" and "last-modified:" as part of the first phase of the deprecating the changed attribute in the RIPE Database. You can find more information about the three phases of this effort here: https://labs.ripe.net/Members/tim/deprecating-the-changed-attribute-in-the-r... <https://labs.ripe.net/Members/tim/deprecating-the-changed-attribute-in-the-ripe-database>
It should be noted however that:
= The new attributes will only be enabled in output this Thursday 2 April (because updating all objects with initial values takes a long time)
= We have found that we needed to use the 1970-01-01T00:00:00Z instead of 0000-00-00T00:00:00Z (because it's invalid, and we observed inconsistencies in dealing with year 0 AD different libraries)
We will update the referenced article shortly to reflect these changes.
This release also changes attribute "referral-by" from mandatory to optional. This attribute is part of a mntner object for historical reasons and will be deprecated.
Detailed release notes are published here: https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.79 <https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.79>
Documentation for this release is published here: https://www.ripe.net/data-tools/support/documentation/ripe-database-document... <https://www.ripe.net/data-tools/support/documentation/ripe-database-documentation-1.79>
Please let us know if you find any issues with this release. We plan to deploy this release to the production environment on Tuesday 28 April, and we plan to enable the new "created:" and "last-modified:" attributes the following Monday 4 May - after the initial values have been added for all objects.
Please let us know if you have any questions or comments.
Kind regards,
Tim Bruijnzeels
Assistant Manager Software Engineering RIPE NCC
Dear working group, On 22 Apr 2015, at 11:07, Tim Bruijnzeels <tim@ripe.net> wrote:
Because no major changes were introduced with these fixes we plan to adhere to the original planning and deploy the 1.79.1 release of whois to the production environment on Tuesday 28 April (Monday is a public holiday here), and we plan to enable the new attributes in the output on Monday 4 May.
We have deployed 1.79.1 to production today. We are currently running the updates to generate the values for 'last-modified:' and 'created:' in the background and plan to enable these new attributes in output Monday 4 May - because the background job needs some time to complete, and we prefer not make changes like this too close to the weekend. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC
Dear colleagues, The batch job to add the "created:" and "last-modified:" to all objects took longer to complete than we anticipated (due to the higher rate of updates in the production environment). The job was completed late afternoon today, but since tomorrow is a public holiday in Amsterdam we thought it better to postpone switching on the new attributes in output until this Wednesday to make sure we have all engineers on board when we do this. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC
On 28 Apr 2015, at 15:54, Tim Bruijnzeels <tim@ripe.net> wrote:
Dear working group,
On 22 Apr 2015, at 11:07, Tim Bruijnzeels <tim@ripe.net <mailto:tim@ripe.net>> wrote:
Because no major changes were introduced with these fixes we plan to adhere to the original planning and deploy the 1.79.1 release of whois to the production environment on Tuesday 28 April (Monday is a public holiday here), and we plan to enable the new attributes in the output on Monday 4 May.
We have deployed 1.79.1 to production today.
We are currently running the updates to generate the values for 'last-modified:' and 'created:' in the background and plan to enable these new attributes in output Monday 4 May - because the background job needs some time to complete, and we prefer not make changes like this too close to the weekend.
Kind regards,
Tim Bruijnzeels
Assistant Manager Software Engineering RIPE NCC
Dear colleagues The new attributes "created:" and "last-modified:" have now been enabled in output. However, we found a minor bug regarding no-op changes, that was not noticed in development or the RC environment. If an object is submitted without any changes it will always result in an update, because when we compare the object the "last-modified:" value will typically not match.(unless the update is done at sub-second speed) In other words what should be a "no-op" now results in a "touch" operation where only the "last-modified:" attribute is changed. While this is unfortunate we do not believe that this bug is severe enough to disable the new attributes. Instead, we are working on a fix for this and plan to deploy this, after thorough testing, as 1.79.2 at the end of the week. We will also work on a retro-active fix to the history of objects to remove those revisions of an object, where only "last-modified:" was updated. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC
On 04 May 2015, at 21:54, Tim Bruijnzeels <tim@ripe.net> wrote:
Dear colleagues,
The batch job to add the "created:" and "last-modified:" to all objects took longer to complete than we anticipated (due to the higher rate of updates in the production environment). The job was completed late afternoon today, but since tomorrow is a public holiday in Amsterdam we thought it better to postpone switching on the new attributes in output until this Wednesday to make sure we have all engineers on board when we do this.
Kind regards,
Tim Bruijnzeels
Assistant Manager Software Engineering RIPE NCC
On 28 Apr 2015, at 15:54, Tim Bruijnzeels <tim@ripe.net <mailto:tim@ripe.net>> wrote:
Dear working group,
On 22 Apr 2015, at 11:07, Tim Bruijnzeels <tim@ripe.net <mailto:tim@ripe.net>> wrote:
Because no major changes were introduced with these fixes we plan to adhere to the original planning and deploy the 1.79.1 release of whois to the production environment on Tuesday 28 April (Monday is a public holiday here), and we plan to enable the new attributes in the output on Monday 4 May.
We have deployed 1.79.1 to production today.
We are currently running the updates to generate the values for 'last-modified:' and 'created:' in the background and plan to enable these new attributes in output Monday 4 May - because the background job needs some time to complete, and we prefer not make changes like this too close to the weekend.
Kind regards,
Tim Bruijnzeels
Assistant Manager Software Engineering RIPE NCC
Dear working group,
On 06 May 2015, at 18:14, denis <ripedenis@yahoo.co.uk> wrote:
If an object is submitted without any changes it will always result in an update, because when we compare the object the "last-modified:" value will typically not match.(unless the update is done at sub-second speed) In other words what should be a "no-op" now results in a "touch" operation where only the "last-modified:" attribute is changed.
Just an observation. This might actually be a useful side effect. It allows maintainers of objects to 'touch' their objects and show they are alive and actively maintaining their data even when nothing needs to change. I am sure some people in the community who are going to start monitoring "last-changed:" attributes to argue that data is out of date would appreciate that, or even request it.
Sure, there is something to be said for this, but the downside of this is that the version history of the object becomes very large, which may not be desired. As far as I know this was not explicitly specified beforehand, so it would be good to have a clear WG consensus call on this now. For the moment we feel that it's probably best to apply the planned 'fix' because the behaviour will then be consistent with no-ops until now, but we can always revert this change when we get a clear direction from the WG. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC
Hi all, On Thu, May 07, 2015 at 09:55:25AM +0200, Tim Bruijnzeels wrote:
On 06 May 2015, at 18:14, denis <ripedenis@yahoo.co.uk> wrote:
If an object is submitted without any changes it will always result in an update,
I had a similar bug in one of our (AS8283) provisioning scripts :-)
Just an observation. This might actually be a useful side effect. It allows maintainers of objects to 'touch' their objects and show they are alive
Sure, there is something to be said for this, but the downside of this is that the version history of the object becomes very large, which may not be desired.
It would be a ton of signalling, but for what purpose? Some objects are perfectly fine for years on end without change. A better, less obtrusive, keepalive mechanism are the invoices that RIPE NCC sends to its members. At the moment there is no requirement to demonstrate to others you have a script running that can touch all objects.
As far as I know this was not explicitly specified beforehand, so it would be good to have a clear WG consensus call on this now.
When (if ever) such a request comes to the DBWG we will discuss it accordingly.
For the moment we feel that it's probably best to apply the planned 'fix' because the behaviour will then be consistent with no-ops until now, but we can always revert this change when we get a clear direction from the WG.
Implementing the bugfix is the correct course of action. At the moment the behaviour is not as expected and I appreciate the NCC taking action on such short notice. Kind regards, Job
On Thu, May 07, 2015 at 09:55:25AM +0200, Tim Bruijnzeels wrote: Dear WG Members
On 06 May 2015, at 18:14, denis <ripedenis@yahoo.co.uk> wrote:
If an object is submitted without any changes it will always result in an update, because when we compare the object the "last-modified:" value will typically not match.(unless the update is done at sub-second speed) In other words what should be a "no-op" now results in a "touch" operation where only the "last-modified:" attribute is changed.
Just an observation. This might actually be a useful side effect. It allows maintainers of objects to 'touch' their objects and show they are alive and actively maintaining their data even when nothing needs to change. I am sure some people in the community who are going to start monitoring "last-changed:" attributes to argue that data is out of date would appreciate that, or even request it.
Sure, there is something to be said for this, but the downside of this is that the version history of the object becomes very large, which may not be desired.
And the purpose of having such history is quite unclear.
As far as I know this was not explicitly specified beforehand, so it would be good to have a clear WG consensus call on this now.
+1
For the moment we feel that it's probably best to apply the planned 'fix' because the behaviour will then be consistent with no-ops until now, but we can always revert this change when we get a clear direction from the WG.
+1 Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
On Thu, May 07, 2015 at 10:31:23AM +0200, Piotr Strzyzewski wrote:
As far as I know this was not explicitly specified beforehand, so it would be good to have a clear WG consensus call on this now.
+1
ref ambiguity: OK for the consensus call or OK for the proposed behaviour? While I have been using the (older) timestamps as a hint for (potentially reduced) quality in the past, it is obvious that a more recent timestamp does not really provide as much confidence as an explicit data validation timestamp, so routine updates might actually be detrimental to the intented goal if too much is read into the last-modified timestamp. -Peter
On Thu, May 07, 2015 at 10:52:07AM +0200, Peter Koch wrote:
On Thu, May 07, 2015 at 10:31:23AM +0200, Piotr Strzyzewski wrote:
As far as I know this was not explicitly specified beforehand, so it would be good to have a clear WG consensus call on this now.
+1
ref ambiguity: OK for the consensus call or OK for the proposed behaviour?
I agree with Tim that this was nos explicitly specified beforehand, so OK for the consensus call. Sorry for being unclear. :) Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Dear working group,
we are working on a fix for this and plan to deploy this, after thorough testing, as 1.79.2 at the end of the week.
We have just deployed 1.79.2 with a fix for this issue.
We will also work on a retro-active fix to the history of objects to remove those revisions of an object, where only "last-modified:" was updated.
This is still open. But this is clean up that we can apply later. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC
participants (5)
-
denis -
Job Snijders -
Peter Koch -
Piotr Strzyzewski -
Tim Bruijnzeels