NFD

These slaves should not be deployed at Arizona, because it's going to cause IO capacity problems.
When UCLA's Ubuntu 14.04 slaves went offline, we deployed third and fourth Ubuntu 14.04 at Arizona, with the plan of deploying Ubuntu 16.10 at UCLA.

My proposal (and what I was trying to do with new OSX slave) is to add slaves to vagrant config. My current config is here: https://github.com/cawka/ndn-jenkins-slaves

Using this config, it is trivial to instantiate slave wherever we have available capacity.

https://github.com/cawka/ndn-jenkins-slaves

What's the rationale of adding multiple slaves into the same Vagrantfile, as opposed to keeping each slave separate?

One repository to manage all jenkins slaves. vagrant up [slave-name] to starts individual slaves. Multiple separate repositories or even vagrantfile complicates management and increases headaches.

I'm confused about your comment. Vagrantfile in ndn-jenkins-slaves does exactly the same: it defines multiple VMs with global defaults.

Has there been any progress on setting these up?

I thought you're working on this, but just noticed that we don't have any assignee...

I thought you were working on this as well... Junxiao said these would be hosted at UCLA, but I feel there was some miscommunication somewhere along the line.

I added 16.10 to ndn-cxx, ndn-tools, and NFD. I'll let new builds use them and see how they perform.

ndn-cxx seem to have an issue. Can you disable 16.10 and retrigger jobs?

16.10 was already disabled for ndn-cxx. I retriggered the only job I could find that had not already been retriggered and that had failed only on 16.10: http://jenkins.named-data.net/job/ndn-cxx/4626/

NFD appears to be building and testing correctly on 16.10. ndn-tools has not had a build submitted to it yet.

I'm currently building ndn-cxx to see if I can replicate the issue. I will update this issue with my results.

I encountered the same failure in util/time.t.cpp when I ran the test cases manually.

There several expected failures. Boost test doesn't clealry show them as expected. I found one bug with uninitialized variable that only expressed itself in 16.10. I suspect other failures are DNS related. Somehow they seem to disappear after I manually ran dig command. You probably saw that I re-enabled 16.10 for cxx and pushed a commit to build.

I disabled again for ndn-cxx until we can diagnose why IPv6 resolution fails or made those test cases non-fatal.

Alex Afanasyev wrote:

I disabled again for ndn-cxx until we can diagnose why IPv6 resolution fails or made those test cases non-fatal.

Any news?

Davide Pesavento wrote:

Nobody seems to be working on this so I'm clearing the "assignee" field.

Moreover, Ubuntu 17.04 will be released in about 3 weeks, so I don't think it makes sense to pursue this anymore.

Agreed. On that note, we need to decide who will host the 17.04 nodes.