Re: SUCCESS: Bulk deletion of /24 detail
[Input to DB-WG] Flagging this result as 'SUCCESS' is unhelpful. I regard this as a bug, and a silly one too. [Question to ripe-dbm] So how am I supposed to delete redundant objects and keep the DB clean ? Best Niall O'Reilly On Friday, Sep 12, 2003, at 08:26 Europe/Dublin, ripe-dbm@ripe.net wrote:
From: "Niall O'Reilly" <Niall.oReilly@ucd.ie> Subject: Bulk deletion of /24 detail Date: Fri, 12 Sep 2003 08:26:41 +0100 Reply-To: Niall.oReilly@ucd.ie Message-ID: <7484C0E0-E4F2-11D7-A9BD-000393DA759C@ucd.ie>
SUMMARY OF UPDATE:
Number of objects found: 0 Number of objects processed successfully: 0 Create: 0 Modify: 0 Delete: 0 No Operation: 0 Number of objects processed with errors: 0 Create: 0 Modify: 0 Delete: 0 Syntax Errors: 0
DETAILED EXPLANATION:
***Warning: Invalid keyword(s) found: Bulk, deletion, of, /24, detail ***Warning: All keywords were ignored
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following paragraph(s) do not look like objects and were NOT PROCESSED:
inetnum: 193.1.128.0 - 193.1.128.255 netname: UCD-193-1-128-19-128 delete: aggregated into UCD-193-1-128-19
inetnum: 193.1.129.0 - 193.1.129.255 netname: UCD-193-1-128-19-129 delete: aggregated into UCD-193-1-128-19
inetnum: 193.1.130.0 - 193.1.130.255 netname: UCD-193-1-128-19-130 delete: aggregated into UCD-193-1-128-19
inetnum: 193.1.131.0 - 193.1.131.255 netname: UCD-193-1-128-19-131 delete: aggregated into UCD-193-1-128-19
inetnum: 193.1.133.0 - 193.1.133.255 netname: UCD-193-1-128-19-133 delete: aggregated into UCD-193-1-128-19
inetnum: 193.1.137.0 - 193.1.137.255 netname: UCD-OLDBAR-LHS delete: aggregated into UCD-193-1-128-19
inetnum: 193.1.138.0 - 193.1.138.255 netname: UCD-OLDBAR-RHS delete: aggregated into UCD-193-1-128-19
inetnum: 193.1.139.0 - 193.1.139.255 netname: UCD-MICROSTORE delete: aggregated into UCD-193-1-128-19
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For assistance or clarification please contact: RIPE Database Administration <ripe-dbm@ripe.net>
Thanks to everyone on the db-wg list who sent me helpful answers. I know enough now. Let's close that thread. It's a curious social phenomenon that the question I put to the _ripe-dbm_ role was answered by _db-wg_ folks. Niall
Niall, Niall O'Reilly wrote:
Thanks to everyone on the db-wg list who sent me helpful answers. I know enough now. Let's close that thread.
It's a curious social phenomenon that the question I put to the _ripe-dbm_ role was answered by _db-wg_ folks.
The explanation is quite simple: the ripe-dbm is one person working through the ticket queue while there are many db-wg folks that have very good knowledge of the DB.
Niall
Andrei Robachevsky RIPE NCC P.S. The response time from the ripe-dbm is within one business day.
On Friday, Sep 12, 2003, at 10:03 Europe/Dublin, Andrei Robachevsky wrote:
P.S. The response time from the ripe-dbm is within one business day.
And sometimes, as in this case, much faster than that! Someone earned an extra stroopwafel today. Niall
On Fri, Sep 12, 2003 at 11:10:04AM +0100, Niall O'Reilly wrote:
On Friday, Sep 12, 2003, at 10:03 Europe/Dublin, Andrei Robachevsky wrote:
P.S. The response time from the ripe-dbm is within one business day.
And sometimes, as in this case, much faster than that! Someone earned an extra stroopwafel today.
Niall
The address of RIPE NCC is on there website :-) Back to the topic, I had a similair case this week, and it is very confusing to get a Succesfull back when no updates has been performed at all. So I also think the database shouldn't flag that succesfull in the reply. Maybe just flag it as a NOOP? Regards, Andre Koopal MCI
On Friday, Sep 12, 2003, at 12:36 Europe/Dublin, Andre Koopal wrote:
The address of RIPE NCC is on there website :-)
Yes. Musn't make a habit of public compliments! 8-) Niall
Dear Niall O'Reilly, I see from the log files that you have now deleted these objects. Regarding the SUCCESS reply it was a decision that we made when we re-structured dbupdate that we only reported FAILUE if we detected an error. If there is no error we report SUCCESS. This means that SUCCESS is now returned for a blank update message, a message where none of the objects are recognised (as in your case) and when no operation is performed because the submitted object is identical to the one currently in the database. It would not be difficult to change this behaviour if it is generally felt that the current scheme is mis-leading. Perhaps we can have some opinions about this from other users on the db-wg mailing list. Regards, Denis Walker -------------------------------- RIPE NCC Database Administration On Fri, 12 Sep 2003 08:47:49 +0100, Niall O'Reilly wrote: * [Input to DB-WG] * * Flagging this result as 'SUCCESS' is unhelpful. * I regard this as a bug, and a silly one too. * * [Question to ripe-dbm] * * So how am I supposed to delete redundant objects and keep the DB clean ? * * Best * * Niall O'Reilly * * On Friday, Sep 12, 2003, at 08:26 Europe/Dublin, ripe-dbm@ripe.net * wrote: * * > * > * >> From: "Niall O'Reilly" <Niall.oReilly@ucd.ie> * >> Subject: Bulk deletion of /24 detail * >> Date: Fri, 12 Sep 2003 08:26:41 +0100 * >> Reply-To: Niall.oReilly@ucd.ie * >> Message-ID: <7484C0E0-E4F2-11D7-A9BD-000393DA759C@ucd.ie> * > * > * > SUMMARY OF UPDATE: * > * > Number of objects found: 0 * > Number of objects processed successfully: 0 * > Create: 0 * > Modify: 0 * > Delete: 0 * > No Operation: 0 * > Number of objects processed with errors: 0 * > Create: 0 * > Modify: 0 * > Delete: 0 * > Syntax Errors: 0 * > * > * > DETAILED EXPLANATION: * > * > * > ***Warning: Invalid keyword(s) found: Bulk, deletion, of, /24, detail * > ***Warning: All keywords were ignored * > * > * > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * > The following paragraph(s) do not look like objects * > and were NOT PROCESSED: * > * > inetnum: 193.1.128.0 - 193.1.128.255 * > netname: UCD-193-1-128-19-128 * > delete: aggregated into UCD-193-1-128-19 * > * > inetnum: 193.1.129.0 - 193.1.129.255 * > netname: UCD-193-1-128-19-129 * > delete: aggregated into UCD-193-1-128-19 * > * > inetnum: 193.1.130.0 - 193.1.130.255 * > netname: UCD-193-1-128-19-130 * > delete: aggregated into UCD-193-1-128-19 * > * > inetnum: 193.1.131.0 - 193.1.131.255 * > netname: UCD-193-1-128-19-131 * > delete: aggregated into UCD-193-1-128-19 * > * > inetnum: 193.1.133.0 - 193.1.133.255 * > netname: UCD-193-1-128-19-133 * > delete: aggregated into UCD-193-1-128-19 * > * > inetnum: 193.1.137.0 - 193.1.137.255 * > netname: UCD-OLDBAR-LHS * > delete: aggregated into UCD-193-1-128-19 * > * > inetnum: 193.1.138.0 - 193.1.138.255 * > netname: UCD-OLDBAR-RHS * > delete: aggregated into UCD-193-1-128-19 * > * > inetnum: 193.1.139.0 - 193.1.139.255 * > netname: UCD-MICROSTORE * > delete: aggregated into UCD-193-1-128-19 * > * > * > * > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * > * > * > For assistance or clarification please contact: * > RIPE Database Administration <ripe-dbm@ripe.net> * > * > *
On Friday, Sep 12, 2003, at 10:14 Europe/Dublin, RIPE Database Manager wrote:
Regarding the SUCCESS reply ... Perhaps we can have some opinions about this from other users on the db-wg mailing list.
That's the discussion I wanted to open. Niall PS. Here's a curious _complementary_ social phenomenon. 8-)
participants (4)
-
Andre Koopal -
Andrei Robachevsky -
Niall O'Reilly -
RIPE Database Manager