Deprecating old generic repos

[chb0github]

Hello community.

This is where we will hold a discussion about fully deprecating all non-repo specific resources.

previously, you had something like:

artifactory_local_repository 'foo' {
   type = 'npm'
}

There were several problems with the legacy model

1. It didn't allow for repo specific schema, so it was impossible to really know for sure what fields where necessary or not; both for us and our users. It was very easy to make mistakes
2. That resource contained a hodge-podge of features from various repo types that only really applied to their respective repos

That repo resource has been in deprecation for months and now there are replacements for local/remote/virtual for all repo types. Meaning: There is no need at all for the old repo resource.

We understand that totally removing this will effect our users. However, we can't just hang out forever and wait indefinitely. So, we do have to set a firm commit date. This is your opportunity to chime in, but total removal is already on the books and the code is ready

[tjstansell]

Personally, any timeline is fine with me, as long as it comes with a major version change. haha ;)

That said, there is currently no great migration path to move from the old style to the new. I seem to remember someone saying they tried it and ended up nuking a whole repo on accident because of lack of error checking in artifactory (or something like that). I wish I could find the issue I was reading on that. We've got >100 repos in this state that need to be migrated and our team will likely be writing a script that does refactoring/terraform state store surgery to do the migration. It will likely do the following:

• assume all terraform code changes have already been made (in a branch of our repo)
• copy the remote state locally as a precaution
• read the local state to determine the from -> to relationships looking for artifactory_{local,remote,virtual}_repository resources.
• terraform state rm $old (will this even work if there are depedencies/references?)
• terraform import $new ...

Then, assuming terraform plan looks pretty clean at that point, we'd do the same on the real state store.

At least, I think that's what needs to happen. We might end up doing something else entirely and just importing everything fresh, if that's possible. I don't know.

If there's a better way to migrate ... please help us out.

[tjstansell]

#290 (comment) is the comment I was thinking of.

[chb0github]

I spent a while trying to figure this out. The simplest i can think of is to create a new repo as a replication of the old until it's copied. You'd have better luck opening a support ticket and asking them how to rename or move a repo. I simply don't know

[chb0github]

Ok all, we are going to pin a date on the calendar:

APR-18-2022 This should see all immediate password changes released and a new major version bump
@danielmkn @alexhung