Regarding (1) which is about changing the default. No issues, I was trying to break any code until someone had more time than me to test it, as the devil is always in the details.

From John on github:

Yes the GCC preprocessors is limited (but works for the current use case) and m4 is indeed more powerful but not a user-friendly tool IMHO.

I will have a look as this was not supported by vyatta and therefore not added to the code when converted to python

Coming with a syntax which is not ultimately going to be as complex as the cli may be an impossible challenge. Changing the API to include in the XML what is path vs payload may indeed lead to indeed a better API tho. The example given use the word create in the path when REST would use POST.

I would have expected the output generated to be an OR of the validators or regexes and allow the output if any would have passed it

Thank you for writing some testing code using the smoketest repository. It may take a few working days for anyone to come back to you.

Thank you for the feedback, even if it was not what I was hoping for !

I would not use cpu<numbe> but just <number> like is used for taskset for example, but it would be a real improvement for users.
An op command should be provided giving the affinity of CPU ( from lscpu ) and the documentation should warn about interrupt crossing numa domains (for the case where a network card is providing multiple interfaces).

And there are some PR pending on that exact code ..

If anything this code could/should be extracted in an internal library and then a tool created to replace what we have so the behaviour is consistent in both cases.

There is now some python XML code to parse the XML. m4 is not a nice tool. If better pre-processing is required, which I would not argue for, please explain the issue you are trying to solve.

related to T1699

It may be a good idea to also have an option to hook debug logging to syslog.

Yes, it would solve the issue ... but ... currently, we re-apply the whole interface setting, so there is no change to have the vyos and live configuration not sync'ed.
This would be lost. It is a trade-off, but it could be done. It would be however the only sub-system working that way.

Ideally which interface is master/slave should be recorded and handled by VyOS so that users do not have to put some workaround like this one to know.

I do not have a lab to reproduce this ATM.

Sorry on behalf of the team. The process of PR review is not ideal. I appreciate that you have asked for merge, and would be probably expecting some feedback As it was not, and that you got neither yet. I know it can be a bit frustrating .. I also have PRs waiting! 🥱
Hopefully there will be more regular review going forward, in the meanwhile please be assured that your contribution is appreciated and again sorry for the wait.

@efficiosoft understood. We tend to all hangout there to help each other. If you have another way I/we can relate to you to support you (but here) let us know.

@efficiosoft are you on our slack channel ?

Well, it would be trivial to add an --auto-reload switch to the daemon for development purposes which could enable an inotify watcher over the XML files.

@efficiosoft asking users to fire a daemon is not really user-friendly :-) Once a daemon is loaded, whatever change is done to any initialisation data on the disk will not affect it. Should a tool exist loading the same data each time, then changes can be tested without affecting the running daemon.

Thank you for the offer, having read your patch it seems you are indeed fluent in Python and as there is lots to do so I am sure you will be able to help :-)
As @dmbaturin started this, I will let him come back to you about what could be done.

@SrividyaA the task is assigned to you, if you are going to fix it, all good, otherwise happy to do so.

https://lwn.net/Articles/822744/

As I click "sail", I just realise that as there is only one config per router, ConfigDict could be a subclass of Config which could be itself singleton. So even if it is subclassed, all instances could/would share the same underlying data and could be used inter-exchangeably for the content of the config.

@jestabro I would like to hear why you advocate this API and why you believe it is better than the one I have suggested.

Regarding the API proposed, most of these functions are also syntactic sugar for the same operations. Looking at the use cases, there is two: getting information about a leaf value, or getting information about tagNode changes.

Ok, I will look at how we can use the current configuration to insert the tagNode name when we generate the default configuration