feat: Enabled virtual-circuit sub commands in metal-cli#369
feat: Enabled virtual-circuit sub commands in metal-cli#369ctreatma merged 1 commit intoequinix:mainfrom
Conversation
1e23c8e to
018cc34
Compare
018cc34 to
dfc8b69
Compare
dfc8b69 to
2f0f46f
Compare
749fee1 to
d37183a
Compare
d37183a to
12a370d
Compare
12a370d to
d4b5946
Compare
|
d4b5946 to
382bb97
Compare
|
The commands in your example output look like a good basis for e2e tests on the new subcommands. Could you add those? |
382bb97 to
8786b6b
Compare
e1671b7 to
4bcc34c
Compare
|
@codinja1188 this looks good from a testing perspective but I see a bunch of un-addressed review comments from @aayushrangwala. |
4bcc34c to
21b35c8
Compare
|
|
||
| inc := []string{} | ||
| header := []string{"ID", "Name", "Speed", "Created"} | ||
| if vcID == "" { |
There was a problem hiding this comment.
I think @aayushrangwala is suggesting that the param should be marked required using MarkFlagRequired as done in other cases in this PR, rather than with an explicit check for an empty string.
| }, | ||
| } | ||
|
|
||
| deleteVirtualcircuitCmd.Flags().StringVarP(&vcID, "id", "i", "", "The UUID of the virtual-circuit.") |
There was a problem hiding this comment.
Within the virtual-circuit subcommand, the id string should refer to the same ID. It is confusing if metal vc create -i <id> expects a connection ID and metal vc update -i <id> expects a vc ID. The create command should use a different flag for the connection ID.
21b35c8 to
839138b
Compare
839138b to
76a3546
Compare
76a3546 to
6727012
Compare
6727012 to
7a95050
Compare
7a95050 to
6239e8c
Compare
6239e8c to
1b14125
Compare
|
|
The latest test run failed during cleanup for a test: A 422 on delete usually indicates that the code is doing something wrong (as opposed to an intermittent platform issue). Do these failures not happen when you run the tests locally? |
A re-run of the tests passed, so the failures do not happen consistently. I'm doing a 3rd run now to get a feel for the failure rate. I'm guessing this is some kind of timing issue: the tests pass if the platform happens to handle the cleanup requests quickly enough, but if there's a delay somewhere in the deletion process, the tests fail. If that's the case we can merge as-is and shore up the tests in a separate PR. Ideally that separate PR wouldn't come in until after all the other in-flight PRs are merged, but if the intermittent failures are causing too many problems for review we may need to fix them sooner. |
Not observed in local run |
ctreatma
left a comment
There was a problem hiding this comment.
Tests added in this PR passed 2 out of 3 times in CI, so this can go in as-is and we can improve the resilience of the tests later.
Part of #307