https://github.com/vyos/build-iso/commit/180d2aab0156401f699025fa05451155389cf9ad
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 21 2017
Aug 20 2017
Aug 18 2017
Looks like phabricator hasn't picked up those commits for some reason...
Aug 17 2017
Aug 16 2017
Mar 4 2017
Feb 21 2017
Feb 17 2017
Feb 7 2017
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.
Jan 30 2017
What prevents you from adding it yourself by the way? The registration on wiki is open.
Jan 17 2017
I think we can just reference it directly.
I've just done a quick test of the BatString.numeric_compare, looks perfect.
Jan 16 2017
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
Jan 15 2017
Jan 14 2017
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.
Jan 13 2017
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.
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.
Jan 12 2017
Jan 11 2017
Jan 9 2017
Jan 8 2017
@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:
Jan 5 2017
@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.
Dec 31 2016
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.
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.
Dec 21 2016
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.
Dec 20 2016
Dec 17 2016
Does openfastpath really work? Have you tried it? It all looks great, and if it works reliably, we indeed should integrate it.
I moved the "task" part to T215.
Hi Carl,
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.
Dec 5 2016
@thomas.courbon I think we fixed a similar bug before, but it seems the fix wasn't quite complete...
Nov 23 2016
@hexes Could you update the task and specify which image you use and which error you get in it?
Looks like a bug indeed.
Nov 18 2016
Nov 10 2016
Hi Alex,
Nov 6 2016
@Alexis I wish, with this shortage of contributors, we were really in position to make specific plans regarding the timeframe. ;)
This also applies to the security updates issue. We really need a dedicated security watcher, but, sadly, no one wants to take up this role, so it's always done in a haphazard manner, which is a bad experience for both end users and developers, but that's what we've got.
In a few years of project life, the number of people committed to using VyOS in production grew, but the number of people committed to developing it almost did not, it's still just a few people who have to do everything, and, frankly, it's taxing. At this point, none of us can turn it into a full time job (the commercial support thing @syncer and I started may change it in the future and give some of the maintainers guaranteed N hours a week to spend on it, but it's still a very early stage).
Nov 5 2016
@Alexis By the way, if you are into the quagga source code, maybe you want to join the work on switching to the upstream or cumulus quagga and "forth-porting" vyatta changes to it?
@Alexis Please don't panic. This bug is only exploitable if RA handling is enabled in quagga, and by default it is not. Setting interface's IPv6 to autoconf doesn't enable it in zebra either.
I agree it should be included in 1.1.8, but it's not urgent. I suppose we'll build 1.1.8 some time next week anyway, there are other issues to be addressed.
Oct 21 2016
Sep 26 2016
Sep 14 2016
Maybe really generic one should not reference specific companies, not sure.
I've added the mirror to the load balancer. Please add it to the wiki page: http://wiki.vyos.net/wiki/Mirrors
Also, what's your update interval?
Sep 11 2016
Anything local should hardly be considered high priority, but the first one is remote. We definitely should include the fix in the 1.1.8
Sep 9 2016
Hey, could you rename the task to make it more obvious what it's about. The default meaning of GCC is GNU Compiler Collection. ;)
Sep 7 2016
Aug 31 2016
Looks like a worthy endeavor.