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
Catalog zones #304
Catalog zones #304
Conversation
Also change ident to "load" when reloading and the backup main process to "old-main". When reload succeeds, "load" will become "main" and "old-main" will quit. Otherwise "load" will be exited (because of failure) and "old_main" will continue as "main".
A version of dname_to_string() that writes to a buffer instead of returning a static buffer. This is useful when you need to print two dnames in a log message.
TODO: Group property
+ marshalling of the catalog zone pattern options
Current version works fine for us 👍 (just replaced one of our test-installations of a previous catz-branch build) |
First issue encountered:
A manual |
Next issue I see then I restart
|
This seems to be related to configuration processing (like the previous catz work)
|
instead of struct domain
TODO: - Check all cases where zones are added, deleted or changed for status change of: producer zones and producer member zones. - A zone could be a consumer member zone, *and* a producer zone or a producer member.
and process more than one transfer file. TODO change processing after successful SOAINFO ... before xfrd_unlink_xfrfile().
... check zonefile when asked to check.
The function can still exit via apply_ixfr() -> addRR() or deleteRR() when out of memory, but in that case all bets are off anyway, right?
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.
This change looks okay to me, there are some issues in the list of suggestions. The consumer and producer parts look nice to have for catalog zones.
Thanks Wouter! I'll resolve the remaining reduce/reduce conflicts from command line. Co-authored-by: Wouter Wijngaards <wcawijngaards@users.noreply.github.com>
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.
Still looking into this, but thought I'd post one initial remark.
uint8_t catalog_role; | ||
uint8_t catalog_role_is_default; | ||
const char* catalog_member_pattern; | ||
const char* catalog_producer_zone; |
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.
Back when the first PR got made, we kind-of decided catalog properties must be set on a zone. A reason for that being so that you cannot all of a sudden break things simply by re-applying patterns. Why should this be part of a pattern?
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.
I evaluated this extensively. Have a look at the catzones.tdir and the text in the man page to see how this all works. The re-applying patterns issues are also covered in catzones.tdir.
Short summary: A catalog producer (catalog_role == CATALOG_ROLE_PRODUCER) is only functional when in a zone clause which is checked by evaluating the value for "catalog_producer_zone" (which only makes sense in a pattern and not in a zone; i.e. catalog member zones are always instantiated through patterns).
Currently only a single catalog consumer is allowed, but this may change in the future. In that future extension there is no reason why you would not have a catalog member zone which is a catalog consumer itself. But that's the future; we do it step by step. Currently it at least allows the user to configure a consumer zone in all the for nsd conventional manner.
Co-authored-by: Wouter Wijngaards <wcawijngaards@users.noreply.github.com>
Recover line to report an error Co-authored-by: Wouter Wijngaards <wcawijngaards@users.noreply.github.com>
... now used in a function prototype in dname.h + Some clarifying comments in the label_plus_dname() function
This version does the task from within the tranfer daemon (xfrd) which makes everything easier and more straight forward.