@Legoktm do you still have a use case for this dump? If so, can this be resolved through doing T218592 or just using the API directly?

In T376726#10211294, @Dreamy_Jazz wrote:

@Legoktm do you still have a use case for this dump? If so, can this be resolved through doing T218592 or just using the API directly?

I was doing data analysis at the time (link) - I think it would be good if we could continue to keep dumping the table. But also I don't think there are any other table dumps that are partially redacted (e.g. T173237#3525344), and probably implementing this feature is more important than retaining the dumps unfortunately :(

In T376726#10211824, @Legoktm wrote:

In T376726#10211294, @Dreamy_Jazz wrote:

@Legoktm do you still have a use case for this dump? If so, can this be resolved through doing T218592 or just using the API directly?

I was doing data analysis at the time (link) - I think it would be good if we could continue to keep dumping the table. But also I don't think there are any other table dumps that are partially redacted (e.g. T173237#3525344), and probably implementing this feature is more important than retaining the dumps unfortunately :(

Thanks for the information. Users with a need for this data can query the wiki replicas (such as through quarry.wmcloud.org) even if we remove the database dump, but obviously having a local copy of the data would be more efficient and easier to automate.

Change #1078901 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[operations/puppet@production] dumps: Drop the globalblocks table dump

https://gerrit.wikimedia.org/r/1078901

Change #1078913 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[operations/puppet@production] dumps: stop running the dump_global_blocks job

https://gerrit.wikimedia.org/r/1078913

As per slack discussion, noting here that @Milimetric, @VirginiaPoundstone and I agree on moving forward with option 3: dropping this dump.

The rationale is low value from this dump, while also supporting moving the Temporary accounts work forward.

Change #1078913 merged by Ladsgroup:

[operations/puppet@production] dumps: Stop running the dump_global_blocks job

https://gerrit.wikimedia.org/r/1078913

Change #1080272 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[operations/puppet@production] dumps: Mark globalblocks dir and script as absent

https://gerrit.wikimedia.org/r/1080272

Change #1080272 merged by Ladsgroup:

[operations/puppet@production] dumps: Mark globalblocks dir and script as absent

https://gerrit.wikimedia.org/r/1080272

Change #1078901 merged by Ladsgroup:

[operations/puppet@production] dumps: Drop the globalblocks table dump

https://gerrit.wikimedia.org/r/1078901

Now that the patches are merged, I see that https://dumps.wikimedia.org/other/globalblocks/ is still present (not expected) and that the last run was on October 5 (expected). I think we can mark this task as resolved once https://dumps.wikimedia.org/other/globalblocks/ is no longer online.

In T376726#10233103, @kostajh wrote:

Now that the patches are merged, I see that https://dumps.wikimedia.org/other/globalblocks/ is still present (not expected) and that the last run was on October 5 (expected). I think we can mark this task as resolved once https://dumps.wikimedia.org/other/globalblocks/ is no longer online.

@Ladsgroup @Ahoelzl do you know why https://dumps.wikimedia.org/other/globalblocks/ is still available? Could someone from Data-Engineering or SRE have a look at this please?

In T376726#10267255, @kostajh wrote:

In T376726#10233103, @kostajh wrote:

Now that the patches are merged, I see that https://dumps.wikimedia.org/other/globalblocks/ is still present (not expected) and that the last run was on October 5 (expected). I think we can mark this task as resolved once https://dumps.wikimedia.org/other/globalblocks/ is no longer online.

@Ladsgroup @Ahoelzl do you know why https://dumps.wikimedia.org/other/globalblocks/ is still available? Could someone from Data-Engineering or SRE have a look at this please?

We may need to manually remove the globalblocks folder from cloudduumps* servers? I tried finding it myself but couldn't.

CC @BTullis

In T376726#10267915, @xcollazo wrote:

In T376726#10267255, @kostajh wrote:

In T376726#10233103, @kostajh wrote:

Now that the patches are merged, I see that https://dumps.wikimedia.org/other/globalblocks/ is still present (not expected) and that the last run was on October 5 (expected). I think we can mark this task as resolved once https://dumps.wikimedia.org/other/globalblocks/ is no longer online.

@Ladsgroup @Ahoelzl do you know why https://dumps.wikimedia.org/other/globalblocks/ is still available? Could someone from Data-Engineering or SRE have a look at this please?

We may need to manually remove the globalblocks folder from cloudduumps* servers? I tried finding it myself but couldn't.

CC @BTullis

Hi, bumping this thread, so we could close out this task. @BTullis, could you please take a look? Thanks!

There is nothing more for Trust and Safety Product Team to do here, so I'm untagging our sprint, and also unlinking Temporary accounts as the remaining work (making sure https://dumps.wikimedia.org/other/globalblocks/ is offline) is not relevant to that project.

In T376726#10383000, @kostajh wrote:

There is nothing more for Trust and Safety Product Team to do here, so I'm untagging our sprint, and also unlinking Temporary accounts as the remaining work (making sure https://dumps.wikimedia.org/other/globalblocks/ is offline) is not relevant to that project.

Thanks for the ping @kostajh and apologies for the delay in responding.

Your patches above removed the globalblocksdir from the dumpsdata100[3-7] servers, where dumps are initially written (by the snapshot servers).
However, the way that the dumps system currently works is that the dumpsdata servers regularly rsync the files to the dumps distribution servers, which are currently called clouddumps100[1-2].

When this sync occurs, existing files on the distribution servers are not deleted; new files are simply added to the colelction.
This setup has allowed us to have two servers with much larger storage (clouddumps) for holding many more copies of the dumps than the dumpsdata servers, which are more like a transient store.

This means that the previously dumped globalblocks files still exist on clouddumps100[1-2].

btullis@clouddumps1002:/srv/dumps/xmldatadumps/public/other$ tree globalblocks/
globalblocks/
├── 20240713
│   └── 20240713-globalblocks.gz
├── 20240720
│   └── 20240720-globalblocks.gz
├── 20240727
│   └── 20240727-globalblocks.gz
├── 20240803
│   └── 20240803-globalblocks.gz
├── 20240810
│   └── 20240810-globalblocks.gz
├── 20240817
│   └── 20240817-globalblocks.gz
├── 20240824
│   └── 20240824-globalblocks.gz
├── 20240831
│   └── 20240831-globalblocks.gz
├── 20240907
│   └── 20240907-globalblocks.gz
├── 20240914
│   └── 20240914-globalblocks.gz
├── 20240921
│   └── 20240921-globalblocks.gz
├── 20240928
│   └── 20240928-globalblocks.gz
└── 20241005
    └── 20241005-globalblocks.gz

13 directories, 13 files

The simplest option for taking them offline is simply for me to delete this directory and everything in it, from both servers.

Is that approach acceptable to you, or should I be looking to archive these files somewhere?

Are we confident that they are not being used internally by any data pipelines?

In T376726#10383137, @BTullis wrote:

In T376726#10383000, @kostajh wrote:

There is nothing more for Trust and Safety Product Team to do here, so I'm untagging our sprint, and also unlinking Temporary accounts as the remaining work (making sure https://dumps.wikimedia.org/other/globalblocks/ is offline) is not relevant to that project.

Thanks for the ping @kostajh and apologies for the delay in responding.

Your patches above removed the globalblocksdir from the dumpsdata100[3-7] servers, where dumps are initially written (by the snapshot servers).
However, the way that the dumps system currently works is that the dumpsdata servers regularly rsync the files to the dumps distribution servers, which are currently called clouddumps100[1-2].

When this sync occurs, existing files on the distribution servers are not deleted; new files are simply added to the colelction.
This setup has allowed us to have two servers with much larger storage (clouddumps) for holding many more copies of the dumps than the dumpsdata servers, which are more like a transient store.

This means that the previously dumped globalblocks files still exist on clouddumps100[1-2].

btullis@clouddumps1002:/srv/dumps/xmldatadumps/public/other$ tree globalblocks/
globalblocks/
├── 20240713
│   └── 20240713-globalblocks.gz
├── 20240720
│   └── 20240720-globalblocks.gz
├── 20240727
│   └── 20240727-globalblocks.gz
├── 20240803
│   └── 20240803-globalblocks.gz
├── 20240810
│   └── 20240810-globalblocks.gz
├── 20240817
│   └── 20240817-globalblocks.gz
├── 20240824
│   └── 20240824-globalblocks.gz
├── 20240831
│   └── 20240831-globalblocks.gz
├── 20240907
│   └── 20240907-globalblocks.gz
├── 20240914
│   └── 20240914-globalblocks.gz
├── 20240921
│   └── 20240921-globalblocks.gz
├── 20240928
│   └── 20240928-globalblocks.gz
└── 20241005
    └── 20241005-globalblocks.gz

13 directories, 13 files

The simplest option for taking them offline is simply for me to delete this directory and everything in it, from both servers.

Is that approach acceptable to you, or should I be looking to archive these files somewhere?

AFAIK, there's no need to archive these.

Are we confident that they are not being used internally by any data pipelines?

I don't find any usages via codesearch https://codesearch.wmcloud.org/search/?q=globalblocks&files=&excludeFiles=&repos=#operations/puppet

And also we haven't updated these files since early October. We could also do nothing, since these files don't have sensitive data, and we aren't writing any new files to this directory. But that might be confusing to someone who comes across that directory in the future.

In T376726#10383152, @kostajh wrote:

The simplest option for taking them offline is simply for me to delete this directory and everything in it, from both servers.

Is that approach acceptable to you, or should I be looking to archive these files somewhere?

AFAIK, there's no need to archive these.

Ack.

We could also do nothing, since these files don't have sensitive data, and we aren't writing any new files to this directory. But that might be confusing to someone who comes across that directory in the future.

I'm more than happy to delete on the grounds of being tidy. I just don't like making that decision myself, if it's not my data to begin with.

I'm more than happy to delete on the grounds of being tidy. I just don't like making that decision myself, if it's not my data to begin with.

I think on T376726#10211856 it was concluded that we can remove it all, and that although less convenient, the data can be fetched elsewhere.

From my side, +1 to delete for less confusion on what dumps are active or inactive.

Hmm. I'm not getting a 404 even when I disable cache.

In T376726#10387111, @Dreamy_Jazz wrote:

Hmm. I'm not getting a 404 even when I disable cache.

Oh, thanks for checking. You're right. There is a sync process that has re-already created some of these files.

btullis@clouddumps1002:/srv/dumps/xmldatadumps/public/other$ tree globalblocks/
globalblocks/
├── 20240921
│   └── 20240921-globalblocks.gz
├── 20240928
│   └── 20240928-globalblocks.gz
└── 20241005
    └── 20241005-globalblocks.gz

3 directories, 3 files

I will check all of the dumpsdata servers for stray copies and try again to delete them.

Maybe our rsync config attempts to honor last n dumps?