-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: First draft of changes to separate 2 basic resources away from equinix/ #479
Conversation
I had to move both The I also added a Makefile target to run tests from |
@ctreatma @displague What do you think? |
internal/config/envvars.go
Outdated
package config | ||
|
||
|
||
const ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This (and the related changes) could be broken out to a separate PR, and IMO the constants could be added to config.go
rather than going in their own file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not have the envvars defined in a separate file? They are used by provider and sweeper code; and are obviously unreleated to code in config.go. I would consider a separate package (internal/envvars
) but since it's configuration related, I dropped it here.
The envvars were moved to internal
because sweeping in the acceptance tests for the ssh_key uses them, and can't use them from equinix/
because of import cycyle. If I wouldn't actually try to make acceptance tests of moved metal_ssh_key work, I wouldn't know that they need to be moved. I just spend 15 minutes researching on how to justify this :(.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If they're going to the config
package (which is IMO reasonable since they are used as configuration), then there's not really a compelling reason to add them to a separate file that only defines the constants: it's still in the config
package and it still gets imported along with all of the code in config.go
. Moving the constants to a different file in the same package shouldn't lead to an import cycle.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I moved the const block to config.go and removed envvars.go.
} | ||
} | ||
|
||
func resourceMetalSSHKeyCreate(d *schema.ResourceData, meta interface{}) error { | ||
func ResourceMetalSSHKeyCreate(d *schema.ResourceData, meta interface{}) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: We shouldn't need to export the CRUD functions, just the Resource or DataSource itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And since we are sharing CRUD and Schema between the project ssh key and user ssh keys, we could still use the exported Resource as the base and then give it a Project variation of Schema. The shared schema (MetalSSHKeyCommonFields
) could be exported.
@@ -13,7 +13,7 @@ import ( | |||
"github.com/packethost/packngo" | |||
) | |||
|
|||
func metalSSHKeyCommonFields() map[string]*schema.Schema { | |||
func MetalSSHKeyCommonFields() map[string]*schema.Schema { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should avoid repeating the package name in the function names. For example, this would be metal_ssh_key.CommonFields()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same for the CRUD functions. (ResourceMetalSSHKeyCreate -> Create, and perhaps create
or resourceCreate
since we don't need to export these functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed the CRUD callbacks to private and renamed them. I also made the schema easier to share between metal_ssh_key and metal_project_ssh_key.
"github.com/packethost/packngo" | ||
) | ||
|
||
func TestAccCheckMetalSSHKeyExists(n string, key *packngo.SSHKey) resource.TestCheckFunc { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect this file should be named ..._test.go
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not a test, just a helper function, and we've got one like this for most of the resource types. I'm not sure why.
I would name the file resource_checkers.go
and put there all the other test helpers which check if resource exists remotely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@displague What about this?
GNUmakefile
Outdated
testacc: | ||
testaccmoved: | ||
# go through all the directories in internal/resources and run tests | ||
for d in $$(find ./internal/resources -maxdepth 2 -mindepth 2 -type d); do \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These packages should already be covered by $(TEST)
. The for loop over directories in internal/ doesn't seem necessary and I suspect we are retesting packages.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right. I thought make testacc
was only going through tests in equnix/
. I will remove changes in the Makefile.
a30aee9
to
f9f13e0
Compare
f9f13e0
to
9293144
Compare
@@ -0,0 +1,119 @@ | |||
package acceptance |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not requesting any changes, just commenting:
These helpers may turn out to all be "metal" related. In the future we may want to consider moving such service-shared testing / utility code to a service specific home.
internal/services/metal/{resourcename}
internal/services/metal/testing
More likely, and for more gain, I think we would want to move towards a testing pattern like the one in the Linode provider:
https://github.com/linode/terraform-provider-linode/tree/dev/linode/instance/tmpl
We have a few string building helpers and the go template approach is better suited for that.
9293144
to
e9d9e2e
Compare
e9d9e2e
to
a706f2b
Compare
a706f2b
to
2dfde31
Compare
Codecov ReportAttention:
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #479 +/- ##
==========================================
- Coverage 60.11% 59.43% -0.69%
==========================================
Files 99 96 -3
Lines 20045 19745 -300
==========================================
- Hits 12051 11736 -315
- Misses 7691 7714 +23
+ Partials 303 295 -8 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO this is good as-is; I see the relevant tests passing in CI, and the failed tests are all platform issues. If there are things we want to adjust we can do that in follow-up PRs.
This PR is an attempt to move two basic resources away from the equinix namespace. Once this is in, it should be easier to start working on the framework plugin migration.
Part of #106 towards #365