-
Notifications
You must be signed in to change notification settings - Fork 61
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
Conversation
Never mind. Found my problem. |
dictionary describe
dictionary describe
I have plans to add functions for |
After some consideration, I decided |
954c37e
to
103e83e
Compare
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:
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 |
dictionary describe
Just checking if anyone has had a chance to look at this. @phamann ? |
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.
@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.
Thanks for the feedback. I'll get to work on that and I'll add an issue for the feature enhancement. |
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. |
556eeab
to
e6e7938
Compare
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 |
@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. |
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 Once thats out, I think this PR should be good to go. 😄 |
Not a problem. I'll pull those commits and start a new branch.
…On Thu, Oct 29, 2020, 09:16 Patrick Hamann ***@***.***> wrote:
Hey @benzvan <https://github.com/benzvan> apologies for the delay on this
PR. We were focused on getting the AssemblyScript support out first #160
<#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. 😄
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#159 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABWP6RYVTIEZBNA7HFGONPTSNF2MTANCNFSM4R4VLOQA>
.
|
OK. I force-pushed to my branch without the last two commits and it should be ready to merge. |
Oh...except I need to pull from master...1 sec. |
This is ready for another review. |
Just thought I'd bump this @phamann @Integralist |
👋🏻 @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.
Congrats on your new parentage @Integralist ! Thanks for the note. I just wanted to make sure it hadn't been forgotten. :-D |
Just a heads up that it seems the Windows test run has failed because of a difference in error message...
Which is interesting, as it's an OS specific error 🤔 Here is the full error:
|
re:
Thanks for notifying me of this! I've got a PR to correct that now 👍🏻 |
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.
@benzvan didn't want you to miss this comment: #159 (comment) |
@benzvan re:
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 |
OK, this makes sense. I didn't implement the |
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 @benzvan for your hard work. I've left a few more comments. But it looks like we're getting very close now 🤞🏻
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) |
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.
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.
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>
@Integralist I'm reasonably certain I addressed all your comments. |
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.
@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 🎉
Small text changes that would have bothered me for ages once I noticed them. Co-authored-by: Mark McDonnell <Integralist@users.noreply.github.com>
@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. |
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.
@benzvan I think we've made it over the finish line 🎉
Thank you for your patience and hard work on this PR Ben ❤️
I took back over review of this PR last week.
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. Theedgedictionary/describe.go
code is nearly identical to thehealthcheck/describe.go
code and theroot.go
files are also basically the same. But somehow the output of the help is different between the two.