Fixed 1, 2, and 3.

Yes, @Tania and I are working on the rewrite.

Create a new repo (dev.packages.vyos.net/debian) and moved hvinfo to there.

https://github.com/vyos/vyos-1x/commit/ecdbe7b6fb64ae7d27d9147aa2c4a55b3a491735
https://github.com/vyos/vyos-1x/commit/5404d4108b510765150c2ac54098cd26ec18a683

The current implementation with postfix aliases is/was a bit problematic because all spam sent to it is forwarded to all members, and the mail servers where member addresses are get upset with mine and report me to spam lists.

I've merged the quagga pull request. Do you have implementation of the CLI for it, or shall I add it?

@c-po The post I made yesterday (http://blog.vyos.net/vyos-development-digest-number-10), the vyos-1x package is pretty much that, the future single package for all config scripts and data. I would be reluctant to put things that are not VyOS-specific into it though. With small things such as the mDNS repeater things get shaky of course. Something like PMACCT is a clear case, merging it into another package would be insanity. Those relays are small enough to make one wonder if they really need their own packages.

@JulesT I'm afraid Perl code is going to be around for quite a while, as many things need to be fixed before any rewrite of them can take place.
It's the code for new features that concerns me, not as much in the language as in the old approach that is not conductive to either automated testing or future implementation of transactional commit.

@JulesT 99% of new EdgeOS code is proprietary. I see no reason to stick with it for the tiny open source bits they may release once in a while. EdgeOS could use their departure from Vyatta Core as a chance to rethink those decisions, but apparently due to time pressure they didn't... Now they are stuck with backporting UnionFS forever and never getting e.g. fully transactional commits or

And now that I've actually looked into it... ;)

I think before we call it finished, we should move those repos under vyos organization and give @c-po access to them (frankly, I also propose to add him to maintainers).

We should, but somehow I don't have write access to this task. We should find a way to change the default permissions so that all maintainers can do that.

@sebastianm In VyConf it's going to be fairly easy (ok, possible at least) to implement different input and output formats, so chances are we can add | display json or | display yaml filters if there's demand for it.

https://github.com/vyos/build-iso/commit/180d2aab0156401f699025fa05451155389cf9ad

https://github.com/vyos/vyos-1x/commit/8cc396c20398e01f4af76d386d87a38811cead06
https://github.com/vyos/vyatta-cfg/commit/e55d9affac8159b09b503fca4a364192a24eb52e
https://github.com/vyos/vyatta-cfg/commit/be1dfd64f53776d299651d5347041f17a805aba1

Looks like phabricator hasn't picked up those commits for some reason...

Trying to use Debian Jessie fails because it doesn't have 3.18 kernel which is required for OverlayFS support.

I have no idea what you are doing, but: 1) overlayfs is used for the livecd union mount and NOT for config sessions 2) for config sessions, a userspace implementation of unionfs (unionfs-fuse) is used.

What prevents you from adding it yourself by the way? The registration on wiki is open.

I think we can just reference it directly.

I've just done a quick test of the BatString.numeric_compare, looks perfect.

Already implemented in Config_tree.

This has nothing to do with vyconf. Please move it out of the project, and to vyos 1.2.0

Protobuf schema has been written.

@jpbostic My idea for interacting with vyconf from outside the interactive shell is a bit different. The issue with 'vyshell -c "set interfaces ethernet eth0 disable' is that it needs to setup a session first, and store the session ID between commands, so either it will be limited to 'vyshell -c "configure; set interfaces ethernet eth0 address 192.0.2.1/24; set interfaces ethernet eth0 mtu 1400"' (i.e. long command strings in single call), or it will be dependent on specific environment setup, and from VyOS 1.x we already know how problematic it will be.

Worse, such config can be saved, but cannot be loaded afterwards because the formatter doesn't bother to quote such strings and you end up with a syntactically invalid config.

@jpbostic I think @mickvav has a point here, making it configurable is relatively cheap (it's just a field in /etc/passwd after all, or a call to chsh). People who don't want it to be the deault like myself and service accounts for ansible etc. can just change the default.

Once @tmartinson setups a physical server for us (I'd like to say thanks to him, by the way!), it will become a permanent place for the jenkins VM and build hosts where we can give access all maintainers without worrying about mixing Sentrium corporate stuff with it.

@tmartinson Well, you should change your vote then (votes are not final here, for the better I guess).

@systo Just to make sure you are looking at it the right way, in the large it's actually less verbose than old syntax. The vif may not be the best example but firewall would make it apparent:

@rps An serious issue with "interfaces { eth0" is that when there is no parent subtree of all ethernet interfaces specifically, we don't know which script to call when something in "eth0" changes. We'd have to have one big script that handles the whole "interfaces" subtree, which is very problematic when it comes to adding new interface types. If eth* interfaces are children of the "ethernet" node and tun* interfaces are children of the "tunnel" node, it's easy to attach ethernet script to the "ethernet" node and "tunnel" script to the "tunnel" node, if we want to add "openvpn" later, we won't have to modify that large script to accomodate it

@rps No, that's not the biggest challenge. Semicolon at the end of leaf nodes makes them unambiguous enough and easy to tell from tag nodes (this is especially bad with valueless nodes by the way, think "disable", colon wouldn't help there, but semicolon at the end does the job). The biggest challenge is that with "ethernet eth0" the parser must be fully stateful and capable of tracking which parent nodes it's already seen. "eth0", "eth1" etc. are really children of the same node called "ethernet", but in the config they appear separately. Consider this unusual but logically valid config:

@Merijn I'm still not sure why JunOS has that "unit" thing. To me it looks redundant, redundant ©. Though what we are discussing is "unit 0" vs "unit { 0" grammatic distinction, rather than specific syntax of ethernet interfaces.

@tmartinson No, "vlan-id 99" is the old style. And, at that stage we don't know if it's ethernet or not.

@Merijn Now that you remind me of it, I think "edit interfaces tunnel; copy tun10 to tun11" or similar should be possible regardless of the config syntax. No matter how it looks in the config, internally "tunnel" is a node with children "tun0", "tun1" and so on, and there's no reason why it shouldn't be possible to use it as edit level.

@dsteinkopf Not sure, we'll have to devise some rules regarding line breaks, and past some number of leaf nodes inside we are back to the original aesthetic issue (and then there can be non-leaf nodes inside too!
On a fresh look today, I'm convinced that the old tag node formatting is aesthetically superior, so myself as a user of my own project I'm probably voting no, though as a developer I want to see how many people also think it's worth it.

Yes, related. I was just talking to myself really, we get the CI back first, and then we can look into adding vyconf to it.

Our gateway is bad and we should feel bad. When jenkins migration to the new site is complete (we are migrating build hosts too), this should work again.

Thanks! Unit tests pass.

Unit tests pass for me too.

I made it return Unknown if the file in question doesn't exist, hope this fixed the issue.

Seems to work. @hexes, please test and tell me if for you it doesn't.

Duplicate indeed.