Skip to content

Feature: Added RRSet comments support #87

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

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

PetrusHahol
Copy link

Solves #62.

@PetrusHahol PetrusHahol changed the title Feature: Added RRSet comments support WIP: Feature: Added RRSet comments support Jun 4, 2021
@PetrusHahol
Copy link
Author

Import support will be added soon.

@PetrusHahol PetrusHahol changed the title WIP: Feature: Added RRSet comments support Feature: Added RRSet comments support Jun 7, 2021
@@ -491,26 +517,13 @@ func (client *Client) ListRecords(zone string) ([]Record, error) {

err = client.Cache.Set([]byte(zone), cacheValue, client.CacheTTL)
if err != nil {
return nil, fmt.Errorf("The cache for REST API requests is enabled but the size isn't enough: cacheSize: %db \n %s",
DefaultCacheSize, err)
fmt.Printf("[WARN] The cache for REST API requests is enabled but"+
Copy link
Author

Choose a reason for hiding this comment

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

@mbag
Have a look at this change. I think it's better to through not an error but a warning message here.
If it needed, I can create it as a separate MR.

Copy link
Collaborator

Choose a reason for hiding this comment

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

@PetrusHahol I think it should return error (for example JSON marshaling above returns error), because user enables caching and expects objects to be cached. But if there is error and they are not cached, however, the execution continues with only warning. This might not be something they want to pass.

Also, I'm wondering now if the error described is only possible error, i.e. if it wouldn't be better to just do return nil, err as in other error checks. Because, if in fact, the client.Cache.Set fails for some other reason, it might get obscured by our custom error message. But this was my error, that I haven't spotted before merging.

Copy link
Collaborator

Choose a reason for hiding this comment

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

oh, I forgot to ask. Why do you think it's better to just log warning, and continue with the execution?

Copy link
Author

@PetrusHahol PetrusHahol Jun 18, 2021

Choose a reason for hiding this comment

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

Hmm.. Actually I also think it may lead to some different error. I will change it.
I have just totally otherwise picture of it. In case users use cache and something went wrong with it, we can still continue execution and in a meanwhile let them know that something crashed. User can immediately stop execution. But maybe you're right, it might lead to DDoS of PowerDNS API, like if it would be without caches enabled.

Choose a reason for hiding this comment

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

Hello guys, any update with the "comment" paramenter ?

@providus-sys
Copy link

bump!

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

Successfully merging this pull request may close these issues.

4 participants