-
Notifications
You must be signed in to change notification settings - Fork 9.6k
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
provider/clc: CenturyLink Cloud Provider #4893
Conversation
log.Printf("[INFO] Using EXISTING group: %v => %v", name, m[name]) | ||
d.SetId(m[name]) | ||
return nil | ||
} |
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.
A bit more Go-style way to do this would be:
if id, ok := m[name]; ok {
log.Printf("...")
d.SetId(id)
return nil
}
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.
Ah and actually we shouldn't have this "use existing group" behavior in Create - it's inconsistent with the way resource creates generally work in Terraform. We'll implement import functionality as a first class feature. Attempting to create a resource that already exists should result in an 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.
Part of the intent behind this is the relative inconvenience of working with server groups on clc. In particular, I was trying to allow the user to refer to a group by name rather than the clunkier guid. If instead the code errors on existing group in create, that would more or less require the user to either a) manage groups explicitly or b) book-keep guids. Not sure if the intention comes across through this description. But in the end, if it runs against convention, I'll remove it.
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.
Thanks for the extra context here.
If you want to enable users who are not managing server groups in Terraform to be able to reference them from Terraform, it seems to me that the name
vs guid
question is more of an issue in the referencing resources rather than this group resource itself.
The behavior you get by rescuing this error is a "poor man's terraform import
". If you assume at some future date that a user will be able to do something like terraform import clc_group.mygroup "groupfoo"
- this "pull group under management on collision error during create" behavior ends up creating confusion.
Does that make sense?
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.
yes. i'll have it error and await the import directive. thanks for clarifying.
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.
hmm, so I revisited this problem and it's a bit thorny. here are the details:
- there's no way to create a new toplevel group and every group needs a parent
- parent_group_id is required on create
- groups don't have any uniqueness by attribute. eg. you can have multiple groups named foo (under the same parent). so it's not possible to create a resource (with some name) that already exists, a duplicate will always be created.
- the tests may need a hard-coded guid
- import is not yet available
putting this altogether, it seems to me that having a poor man's import would be ideal. it's entirely possible I'm not understanding the intended pattern in the conventional way. would it be so horrible to break the rules here?
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.
Ah yes - thorny indeed!
I do see the merits in argument you're making, but the fact that groups don't have any uniqueness constraint makes me worry. What would the behavior be when there are two groups named "foo"?
Anyways, all this said - I'm willing to let this behavior stand for the initial implementation. We can let the implementation evolve with more usage.
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.
Ya, there would be 2 groups with the same name and different IDs. Kinda
silly but that's how it works. I'll tidy up the rest of the group bits and
we can revisit later.
On Mar 2, 2016 3:58 PM, "Paul Hinze" [email protected] wrote:
In builtin/providers/clc/resource_clc_group.go
#4893 (comment):+}
+
+func resourceCLCGroupCreate(d *schema.ResourceData, meta interface{}) error {
- client := meta.(*clc.Client)
- dc := d.Get("location_id").(string)
- m, err := dcGroups(dc, meta)
- if err != nil {
return fmt.Errorf("Failed pulling groups in location %v - %v", dc, err)
- }
- name := d.Get("name").(string)
- // use an existing group if we have one
- if m[name] != "" {
log.Printf("[INFO] Using EXISTING group: %v => %v", name, m[name])
d.SetId(m[name])
return nil
- }
Ah yes - thorny indeed!
I do see the merits in argument you're making, but the fact that groups
don't have any uniqueness constraint makes me worry. What would the
behavior be when there are two groups named "foo"?Anyways, all this said - I'm willing to let this behavior stand for the
initial implementation. We can let the implementation evolve with more
usage.—
Reply to this email directly or view it on GitHub
https://github.com/hashicorp/terraform/pull/4893/files#r54814841.
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.
it might not be optimal, but I worked around this by using the top-level DC group…
So parent = "GB3 Hardware”
.
Could that be a sensible fall back?
Cheers
Gav
On 2 Mar 2016, at 23:35, albert [email protected] wrote:
In builtin/providers/clc/resource_clc_group.go #4893 (comment):
+}
+
+func resourceCLCGroupCreate(d *schema.ResourceData, meta interface{}) error {
- client := meta.(*clc.Client)
- dc := d.Get("location_id").(string)
- m, err := dcGroups(dc, meta)
- if err != nil {
return fmt.Errorf("Failed pulling groups in location %v - %v", dc, err)
- }
- name := d.Get("name").(string)
- // use an existing group if we have one
- if m[name] != "" {
log.Printf("[INFO] Using EXISTING group: %v => %v", name, m[name])
d.SetId(m[name])
return nil
- }
hmm, so I revisited this problem and it's a bit thorny. here are the details:there's no way to create a new toplevel group and every group needs a parent
parent_group_id is required on create
groups don't have any uniqueness by attribute. eg. you can have multiple groups named foo (under the same parent). so it's not possible to create a resource (with some name) that already exists, a duplicate will always be created.
the tests may need a hard-coded guid
import is not yet available
putting this altogether, it seems to me that having a poor man's import would be ideal. it's entirely possible I'm not understanding the intended pattern in the conventional way. would it be so horrible to break the rules here?—
Reply to this email directly or view it on GitHub https://github.com/hashicorp/terraform/pull/4893/files#r54812368.
Hello hello! I began a detailed code review - have to step AFK for now, but I shall return to complete it! Feel free to follow up on any questions or concerns. 👍 |
Thanks for following through and the detailed feedback! Will hop on these
|
Again, thanks for the extra set of eyes, style pointers and feedback. There are some pending bits I need to provide and I'd like your thoughts on a few minor points. Re: err-in-create-on-existing as some help with one of the tests. |
This test has a step that is repeatedly failing. It is testing an update operation and after the update, re-reading my resource fails with a "Not found" (in the resource tree) The test errors (I think) here: Any clue what I'm doing wrong here or pointers to debugging it? |
@ack Would be great to get the CLC provider into Terraform core... Could you take a look at CenturyLinkCloud/terraform-provider-clc#4 and CenturyLinkCloud/terraform-provider-clc#5 with the associated PR's before this gets merged though? |
default = "achoi" | ||
} | ||
variable "clc_password" { | ||
default = "T*5upfac" |
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.
@ack Are these "valid" credentials?
@ack Trying to help out with that test question but I can't seem to get the base test to pass. I think I've got the authentication sorted out, but I can't seem to figure out how to get around this 500 that the API is throwing:
Any clues? My test account is |
@phinze there were some set up steps to take on the account (create a network and a server) before the LB could be created. The complete message visible in our control portal was "Group could not be created: No private IP addresses." Also created an account for myself under ZZ9F to duplicate failed tests in the future. Apologies for the hiccup, please pull latest and give it a go now. |
Thanks @ack! Will give it another go.
Can we document whatever the required steps are to get from a fresh account to being able to run acceptance tests on the provider page? |
Looks like the load balancer "not found" message was just a typo: Easy fix! 😀 |
ecdf6d2
to
f75710e
Compare
added an update and some cleanup on groups. thx for the typo catch btw. ready for another pass. have you been able to run the full suite yet? |
Been working on getting this merge-able, and I believe I'm nearly there. Here's my branch: https://github.com/hashicorp/terraform/tree/phinze/clc In the latest commit on that branch I:
But now I can't seem to get the load balancer tests to pass:
@ack Any idea what might be going on here? |
Ya, it's a known bug. The workaround was the mysterious ADMIN server that was in your account that I think you tore down. Basically, a server is required in the DC before a LB can be provisioned. I neglected to mention that the last time. If an operation failed w/ no helpful error message, you're likely to get a better one in the UI if you try the same operation.There's a system VPN server in IL1 that we can use permanently. I've pulled your changes, updated the tests to point to IL1, merged the latest sdk changes, and rebased the branch down to a few commits. |
Cool thanks for the extra context there - that makes sense. This looks good to go! 🚀
Can we follow up with a modification to the LB tests so they just create their own servers? |
( Going to land this as-is though so it makes it in .14 👍 - great work on this! 😀 ) |
provider/clc: CenturyLink Cloud Provider
awesome! thanks so much for all your support getting this in. |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
initial PR for provider integration, ready for feedback.