Is there any reason for the choice of scraping compared to transferring the queues that havn't been over into phabricator to have a single location?

and some have not been imported.

Is that and T38#4840473 the reason this ticket was created, or are there additional reasons?

According to https://www.mediawiki.org/wiki/Phabricator/versus_RT , all queues except for access-requests@ and procurement@ were migrated to Phabricator in late 2014 so I'd expect those RT tickets to exist in Phabricator anyway. For procurement@, T93760 isn't clear to me if it's about migrating tickets or just moving the (future) workflow to Phab tooling. I don't know about access-requests@.

Tickets in the domains queue also weren't transferred

In T336320#8839975, @Peachey88 wrote:

Is there any reason for the choice of scraping compared to transferring the queues that havn't been over into phabricator to have a single location?

Basically that this option means we can finally shut down a Perl application and figure it out later while the other option means opening a pandora's box of uncertainties, discussion and unknown tools and the people who did it in the past aren't here anymore. It's just being pragmatic to avoid the "perfect is the enemy of good" and lack of resources that has led to the current situatiin.

An alternative proposal here is to create a static dump of the database only. As far as I'm aware there is no requirement for regular access to the information in RT and the purpose of this task is to have a data copy that can be accessed in an unlikely emergency. @wiki_willy do you have any thoughts on this?

Thanks for checking @LSobanski. It's definitely rare that we need to refer back to RT. In the last 5 years, the 2-3 cases that we've had to reference RT was typically due to tracking down information about core routers that we had purchased back then. In Netbox, we only have 24 active devices left that still reference RT tasks. As long as we're able to access these in someway (ideally quickly and easily) on the rare occasions that it's needed, you should be able to proceed with moving forward.

@wiki_willy thanks for the response, I have two more questions:

• What are the EOL dates for the remaining devices (or if you could share a way to locate them I can check myself)?
• Could you give me an example of information you would need from an RT ticket?

Sure, no prob @LSobanski. Here's the list of the 24 active devices that still reference RT tasks in Netbox, along with their purchase dates (network equipment usually EOLs every 8yrs):

The core/access switches are scheduled to be replaced in FY24-25, and we'll be upgrading the management switches with old Juniper switches for cost savings...so I doubt we'll need to reference their related RT tickets. However, the core routers (which is just the router chassis) and probably the KVM/LCD Consoles will never EOL, so every once in a while, we might to refer back their procurement RT tasks to find information about the type of line cards we had purchased, the type of optics, their costs, things like that. If we're able to just save all the information captured in RT #3069 and RT #552, I think we should be fine.

We could easily save the listed tickets above by just manually clicking "save as" in Firefox without having to fix the scraping problem.

We could proceed setting up the static RT service and just copy HTML files in place in chunks.

I have been thinking if we split up the work it may not be thaaaat much to just click through all tickets on the side over some time.

If its so few, perhaps pdf or copy and paste into new phab procurement tasks and then update the netbox refs?

In T336320#9686453, @Peachey88 wrote:

If its so few, perhaps pdf or copy and paste into new phab procurement tasks and then update the netbox refs?

This seems like the most reasonable approach to me and we can pair it with storing a db dump for any unexpected use cases showing up at a later stage.