Skip to content
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

Adds support for managing edge dictionaries #159

Merged
merged 34 commits into from
Dec 14, 2020
Merged

Conversation

benzvan
Copy link
Contributor

@benzvan benzvan commented Sep 28, 2020

This is addressing issue #153

I'm hoping someone can take a look at this. The test will fail because the help function isn't printing what is expected. I still don't quite understand the code well enough to debug this. The edgedictionary/describe.go code is nearly identical to the healthcheck/describe.go code and the root.go files are also basically the same. But somehow the output of the help is different between the two.

@benzvan
Copy link
Contributor Author

benzvan commented Sep 28, 2020

Never mind. Found my problem.

@benzvan benzvan changed the title WIP: Adding support for dictionary describe Adding support for dictionary describe Sep 28, 2020
@benzvan
Copy link
Contributor Author

benzvan commented Sep 28, 2020

I have plans to add functions for create, update, and delete as well. I can either add them to this PR or I can wait until this is merged and add them individually, whichever makes sense for the flow of this project.

@benzvan
Copy link
Contributor Author

benzvan commented Sep 28, 2020

After some consideration, I decided describe wasn't complete enough for a version update and continued working. This is still work in progress and only has describe and create at this point.

@benzvan benzvan force-pushed the master branch 3 times, most recently from 954c37e to 103e83e Compare October 2, 2020 14:22
@benzvan
Copy link
Contributor Author

benzvan commented Oct 2, 2020

I believe this to be a releasable update with minimum viable features for dictionaries and dictionary items. I apologize for the size of this change, but each commit is relatively self-contained for easier reviewing.

My one concern is that if one wanted to create a new dictionary item one would need to do the following:

  • fastly service search --name <servicename>
  • get the service ID and service version from the above command
  • fastly service-version clone ...
  • get the service version from the above command
  • fastly dictionary create ...
  • get the dictionary ID from the above command
  • fastly service-version activate ...
  • fastly dictionaryitem create ...

Similarly updating an existing dictionary item will require describing the dictionary to get the dictionary id first.

I would propose SERVICE-ID be an optional flag provided SERVICE-NAME is present and can be used to query fastly for the service ID. Same with DICTIONARY-ID and DICTIONARY-NAME.

I would also propose a flag like clone-service=true for dictionary create that would combine the first 6 steps listed above so that dictionaries can be created and applied to a service in a single step.

@benzvan benzvan changed the title Adding support for dictionary describe Adds support for managing edge dictionaries Oct 6, 2020
@benzvan
Copy link
Contributor Author

benzvan commented Oct 13, 2020

Just checking if anyone has had a chance to look at this. @phamann ?

Copy link
Member

@phamann phamann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@benzvan apologies for the delay here, I appreciate both your effort for the contribution and the poke, so thank you.

Overall, this is looking good. A couple of small points around UX and consistency with the rest of the project. But nothing major.

imilarly updating an existing dictionary item will require describing the dictionary to get the dictionary id first.

I would propose SERVICE-ID be an optional flag provided SERVICE-NAME is present and can be used to query fastly for the service ID. Same with DICTIONARY-ID and DICTIONARY-NAME.

This is a good feature request. If you don't want to add the functionality for dictionaries in this PR please feel free to raise this as an issue on the repo and we'll try and get it added to the roadmap.

I would also propose a flag like clone-service=true for dictionary create that would combine the first 6 steps listed above so that dictionaries can be created and applied to a service in a single step.

Again this is a great feature request, so fell free to add an issue for tracking.

pkg/edgedictionaryitem/create.go Outdated Show resolved Hide resolved
pkg/edgedictionary/describe.go Outdated Show resolved Hide resolved
pkg/edgedictionaryitem/root.go Outdated Show resolved Hide resolved
pkg/edgedictionaryitem/create.go Outdated Show resolved Hide resolved
@benzvan
Copy link
Contributor Author

benzvan commented Oct 13, 2020

Thanks for the feedback. I'll get to work on that and I'll add an issue for the feature enhancement.

@benzvan
Copy link
Contributor Author

benzvan commented Oct 13, 2020

I've addressed your comments with new commits and one comment.

I'm willing to add both of the features I mention above within this PR but I'm having trouble figuring out if kingpin supports either/or required flags or if that's something I'll need to add to each file.

@benzvan benzvan force-pushed the master branch 2 times, most recently from 556eeab to e6e7938 Compare October 15, 2020 16:39
@benzvan
Copy link
Contributor Author

benzvan commented Oct 15, 2020

I'm going to pause for a moment (assuming tests pass) to allow you to look at my latest two commits. I'd like to make sure I'm matching your expectations from a project structure standpoint. I created a new service.go file that contains the GetIDFromName() function that is used by both the service describe and dictionary create commands.

@benzvan
Copy link
Contributor Author

benzvan commented Oct 21, 2020

@phamann just poking you for input again. I'm not sure I'll have time to do more on this for another week or so.

@phamann
Copy link
Member

phamann commented Oct 29, 2020

Hey @benzvan apologies for the delay on this PR. We were focused on getting the AssemblyScript support out first #160.

With regards two your last two commits, if not too much pain for you, I'd prefer it if you can move the --service-name work to its own PR, as its an important feature that warrants being in the change log, which is generated on a per PR basis as its automated. It will also allow us to review it in isolation. Hope thats ok? I should have said this earlier, apologies.

Once thats out, I think this PR should be good to go. 😄

@benzvan
Copy link
Contributor Author

benzvan commented Oct 29, 2020 via email

@benzvan
Copy link
Contributor Author

benzvan commented Nov 2, 2020

OK. I force-pushed to my branch without the last two commits and it should be ready to merge.

@benzvan
Copy link
Contributor Author

benzvan commented Nov 2, 2020

Oh...except I need to pull from master...1 sec.

@benzvan
Copy link
Contributor Author

benzvan commented Nov 27, 2020

This is ready for another review.

@benzvan
Copy link
Contributor Author

benzvan commented Dec 8, 2020

Just thought I'd bump this @phamann @Integralist

@Integralist
Copy link
Collaborator

👋🏻 @benzvan

I'm now back from paternity leave! 🥳

And yes, I've got this PR scheduled in my calendar to be re-reviewed and for which I aim to start tomorrow morning (UK time), so hopefully we can get this over the finish line very soon! 🙂

configure_test.go and edgedictionaryitem_test.go both had a need for a
tempfile, so I simplified the method from configure_test and added it to
the testutils where other common test utils go.
@benzvan
Copy link
Contributor Author

benzvan commented Dec 8, 2020

Congrats on your new parentage @Integralist !

Thanks for the note. I just wanted to make sure it hadn't been forgotten. :-D

@Integralist
Copy link
Collaborator

Just a heads up that it seems the Windows test run has failed because of a difference in error message...

want "open missingFile: no such file or directory",
have "open missingFile: The system cannot find the file specified."

Which is interesting, as it's an OS specific error 🤔

Here is the full error:

--- FAIL: TestDictionaryItemBatchModify (0.08s)
    --- FAIL: TestDictionaryItemBatchModify/dictionaryitem_batchmodify_--service-id_123_--dictionary-id_456_--file_missingFile (0.01s)
        edgedictionaryitem_test.go:299: want "open missingFile: no such file or directory", have "open missingFile: The system cannot find the file specified."

@Integralist
Copy link
Collaborator

re:

The example request json for the bulk update dictionary item endpoint is invalid.

Thanks for notifying me of this! I've got a PR to correct that now 👍🏻

@benzvan
Copy link
Contributor Author

benzvan commented Dec 9, 2020

That's really odd...I guess go is passing the system error back up as an error, which is going to be hard to test given the system error is different depending on the system. Maybe I can catch the error type and replace it with a consistent message.

Windows tests were failing due to a difference in the text content of
the missingFile error. I reduced the error expectation to the portion
that I know is not OS dependent.
@Integralist
Copy link
Collaborator

@benzvan didn't want you to miss this comment: #159 (comment)

@Integralist
Copy link
Collaborator

@benzvan re:

So I'm still using Flag.Required() to make sure the --new-name flag was passed but then also using the Action function to call c.newname.Set.

So this might just be a simple misunderstanding regarding the Dictionary update command. Let me try and explain...

If I look at the Go-Fastly code for updating a dictionary I see the following...

// UpdateDictionaryInput is used as input to the UpdateDictionary function.
type UpdateDictionaryInput struct {
	// ServiceID is the ID of the service (required).
	ServiceID string

	// ServiceVersion is the specific configuration version (required).
	ServiceVersion int

	// Name is the name of the dictionary to update.
	Name string

	NewName   *string      `form:"name,omitempty"`
	WriteOnly *Compatibool `form:"write_only,omitempty"`
}

This tells me that both the 'new name' and the 'write only' fields are optional and thus using Required() in the CLI for the --new-name flag isn't actually necessary in this case, because strictly speaking they should be able to specify a --write-only flag by itself (or both --write-only and --new-name together).

@benzvan
Copy link
Contributor Author

benzvan commented Dec 9, 2020

So this might just be a simple misunderstanding regarding the Dictionary update command. Let me try and explain...

OK, this makes sense. I didn't implement the --write-only option in the CLI, so --new-name is required for it to do anything.

Copy link
Collaborator

@Integralist Integralist left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @benzvan for your hard work. I've left a few more comments. But it looks like we're getting very close now 🤞🏻

pkg/edgedictionary/update.go Outdated Show resolved Hide resolved
pkg/edgedictionaryitem/batch.go Outdated Show resolved Hide resolved
pkg/edgedictionaryitem/create.go Outdated Show resolved Hide resolved
pkg/edgedictionaryitem/describe.go Outdated Show resolved Hide resolved
pkg/edgedictionaryitem/list.go Outdated Show resolved Hide resolved
pkg/edgedictionaryitem/describe.go Show resolved Hide resolved
pkg/edgedictionaryitem/describe.go Outdated Show resolved Hide resolved
pkg/edgedictionaryitem/update.go Show resolved Hide resolved
c.CmdClause.Flag("service-id", "Service ID").Short('s').StringVar(&c.manifest.Flag.ServiceID)
c.CmdClause.Flag("dictionary-id", "Dictionary ID").Required().StringVar(&c.Input.DictionaryID)
c.CmdClause.Flag("key", "Dictionary item key").Required().StringVar(&c.Input.ItemKey)
c.CmdClause.Flag("value", "Dictionary item value").Required().Action(c.itemvalue.Set).StringVar(&c.itemvalue.Value)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So annoyingly the Go-Fastly implementation has the item 'value' as an optional field although I believe that to be a mistake and in fact it should be a required field (because why bother calling the api without an updated value for the key -- I don't believe it's even possible to set an empty string as a value for an edge dict key either).

For now let's keep the .Required() as we want the command to be useful (i.e. don't allow someone to make request without a value) but we'll still need the common.OptionalString for now as the version of Go-Fastly we have is internally using a pointer. When I eventually cut a new Go-Fastly release I'll come back (as per the TODO(integralist) comment above) and fix up this section.

pkg/text/dictionaryitem_test.go Outdated Show resolved Hide resolved
benzvan and others added 7 commits December 9, 2020 12:07
The `dictionary describe --verbose` command makes additional calls to
the fastly api's GetDictionaryInfo and ListDictionaryItems endpoints.
The call to GetDictionaryInfo was using the serviceID value in place of
the dictionaryID, which would have resulted in a failed call at best and
values from the wrong dictionary at worst.

I added enforcement in the mock call to that endpoint to verify that the
dictionaryID in the input is the same as the dictionaryID in the output
from the original call to GetDictionary.
Add TODO for cleanup due to errors in the current go-fastly release.

Co-authored-by: Mark McDonnell <Integralist@users.noreply.github.com>
@benzvan
Copy link
Contributor Author

benzvan commented Dec 9, 2020

@Integralist I'm reasonably certain I addressed all your comments.

Copy link
Collaborator

@Integralist Integralist left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@benzvan please don't hate me 🙂 but there's three tiny textual tweaks I'd like to make.

Once you've got those made I'll be able to merge and then cut a new release 🎉

pkg/edgedictionaryitem/create.go Outdated Show resolved Hide resolved
pkg/edgedictionary/edgedictionary_test.go Outdated Show resolved Hide resolved
pkg/edgedictionary/update.go Outdated Show resolved Hide resolved
Small text changes that would have bothered me for ages once I noticed them.

Co-authored-by: Mark McDonnell <Integralist@users.noreply.github.com>
@benzvan
Copy link
Contributor Author

benzvan commented Dec 11, 2020

@Integralist Not at all. Except for the remediation message, which I wasn't sure how to word, the other two would have bugged me once I noticed them.

Copy link
Collaborator

@Integralist Integralist left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@benzvan I think we've made it over the finish line 🎉

Thank you for your patience and hard work on this PR Ben ❤️

@Integralist Integralist dismissed phamann’s stale review December 14, 2020 09:37

I took back over review of this PR last week.

@Integralist Integralist merged commit 0f4d27d into fastly:master Dec 14, 2020
@Integralist
Copy link
Collaborator

@benzvan v0.21.0 CLI release can be found here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants