@dmbaturin I understand that the discussion is "unit 0" vs "unit { 0", what i meant was that i could be an option to keep following the JunOS style as much as possible to maybe enable more interoperability.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 5 2017
Well plain JSON would also be an option then :-)
@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.
The XORP configuration syntax (which Vyatta initially built upon) solves the parsing issue with the simple introduction of a ":" as a delimiter between keys and values.
In the blog post #7 i liked the address [ 192.168.2.1/24 10.10.10.1/30 ]; part. But since i work most of the time with mixed JunOS and Vyos environments a mostly the same syntax would be very nice :-)
However JunOS would be:
I was thinking that the variable would actually be "vlan-id 99". That was written simply to make it easier to read. But if it will be the top of a node, then we end up with vif, vlan-id. Which is redundant, redundant. In that case I would drop the "vlan-id" portion all together. It is only there for esthetics.
@tmartinson No, "vlan-id 99" is the old style. And, at that stage we don't know if it's ethernet or not.
Maybe something like this? We already know that it is an ethernet interface by the fact that it is eth0. And by adding the "vlan-id" portion we get a newer style of configuration but keep the read-ability of the configuration stanza.
@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.
A pro for me would be that i can do 'edit interfaces ethernet eth0 vif' and work with all virtual interfaces.
@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.
Maybe it's a good idea to 1. use the new syntax but 2. generate less line breaks. e.g.
interfaces { ethernet { eth0 { vif { 99 { address 192.0.2.1/24; } 101 { address 203.0.113.1/24; } } } } }
In this case the new syntax would be fine for me. (Details open for discussion.)
Jan 1 2017
Dec 23 2016
Dec 22 2016
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.
I get a 502 Bad Gateway too.
Is this related? https://phabricator.vyos.net/T222
Awesome. I don't know if it's just me but I get a 502 Bad Gateway when accessing https://ci.vyos.net/
Thanks! Unit tests pass.
Dec 21 2016
Unit tests pass for me too.
Dec 20 2016
Dec 17 2016
Dec 14 2016
Someone please remove the vyconf tag from this task, it has nothing to do with it. It can be added to 1.2.0 in fact!
Looks like it works, and the tests pass.