Add .deb support to puppet-opendaylight

[AkshitaJha]

Signed-off-by: Akshita Jha zenith158@gmail.com

[AkshitaJha]

This PR is basically a draft. I will be improving it.

[dfarrell07]

@AkshitaJha mentioned over email that she's seeing tests fail with strange error messages. I'm seeing the same, and +1 to them being strange/broken.

[~/puppet-opendaylight]$ bundle exec rake lint
%{path}:%{linenumber}:%{check}:%{KIND}:%{message}
%{path}:%{linenumber}:%{check}:%{KIND}:%{message}
%{path}:%{linenumber}:%{check}:%{KIND}:%{message}
[~/puppet-opendaylight]$ echo $?
1

[dfarrell07]

I'm seeing some SSH failures with the VM (which may be a problem with my dev system), so messing around with a container for beaker tests.

diff --git a/Rakefile b/Rakefile
index 5a5bd64..05075d2 100644
--- a/Rakefile
+++ b/Rakefile
@@ -89,6 +89,13 @@ task :ubuntu_5rel_vm do
   sh "RS_SET=ubuntu-16 INSTALL_METHOD=deb DEB_REPO='' bundle exec rake beaker"
 end

+# Deb Containers
+
+desc "Beaker tests against Ubuntu 16.04 Container with Boron release Deb"
+task :ubuntu_5rel_dock do
+  sh "RS_SET=ubuntu-16-docker INSTALL_METHOD=deb DEB_REPO='' bundle exec rake beaker"
+end
+
 # Multi-test helpers

 desc "Run syntax, lint, and spec tests."
diff --git a/spec/acceptance/nodesets/ubuntu-16-docker.yml b/spec/acceptance/nodesets/ubuntu-16-docker.yml
new file mode 100644
index 0000000..35b8725
--- /dev/null
+++ b/spec/acceptance/nodesets/ubuntu-16-docker.yml
@@ -0,0 +1,13 @@
+---
+HOSTS:
+  ubuntu-16-docker:
+    roles:
+      - master
+    platform: ubuntu-1604-x86_64
+    image: ubuntu:16.04
+    docker_cmd: '["/sbin/init"]'
+    hypervisor: docker
+
+CONFIG:
+  log_level: verbose
+  type: foss

I'm seeing this output/error (full log):

ubuntu-16-docker 11:51:02$ wget -O /tmp/puppet.deb http://apt.puppetlabs.com/puppetlabs-release-xenial.deb
  --2017-01-23 16:51:02--  http://apt.puppetlabs.com/puppetlabs-release-xenial.deb
  Resolving apt.puppetlabs.com (apt.puppetlabs.com)...   192.155.89.90, 2600:3c03::f03c:91ff:fedb:6b1d
  Connecting to apt.puppetlabs.com (apt.puppetlabs.com)|192.155.89.90|:80...   connected.
  HTTP request sent, awaiting response...   404 Not Found
  2017-01-23 16:51:02 ERROR 404: Not Found.

Checking the URL that's failing, it is indeed invalid. There isn't a puppetlabs-release-xenial.deb, but there is a puppetlabs-release-pc1-xenial.deb. The "pc1" bit is new to me, but figured out it's related to Puppet Collections. I'm not sure how to make Beaker install puppet from that deb.

[dfarrell07]

For ubuntu_5rel_vm, I'm seeing SSH auth working with username:ubuntu/pw, Vagrant attempting to fix some SSH stuff and then SSH failing to connect to the box ever again (full log). I'm guessing Vagrant's breaking things with that SSH step. I'm running Vagrant 1.9.1.

[dfarrell07]

For ubuntu_5rel_vm, I'm seeing SSH auth working with username:ubuntu/pw, Vagrant attempting to fix some SSH stuff and then SSH failing to connect to the box ever again

Interestingly, I'm not seeing the same problem with @AkshitaJha's 16.04 Vagrant box definition (full log of vagrant up ubuntu).

There was a problem that looks like this SSH problem in fairly recent versions of Vagrant. It had to do with the permissions of the ssh credentials not being right. It didn't happen with all OSs (I don't remember the details), which may be why we're just seeing this for Ubuntu. I was running a custom build of Vagrant until recently to get around this. I'm guessing that the vagrant gem still has this old version with the SSH bug, so we see it when Beaker does Vagrant stuff but not with my 1.9.1 system-wide install of Vagrant.

[dfarrell07]

For ubuntu_5rel_vm, I'm seeing SSH auth working with username:ubuntu/pw, Vagrant attempting to fix some SSH stuff and then SSH failing to connect to the box ever again

So maybe best just to focus on container-based Beaker for now. That's the priority anyway, since we use that in our Vagrant dev env and our new ODL CI job.

[dfarrell07]

I'm not sure how to make Beaker install puppet from that deb.

If we can't figure this out, we can use 14.04 for now. Would prefer 16.04, but not worth getting stuck on it.

[dfarrell07]

As the PR is nicely telling us, the Travis CI builds are failing too.

Bundler cannot continue installing faraday_middleware (0.11.0).

Seems to be a problem with gem version miss-match, I think not our fault. Can ignore it and I suspect it will magically start working later.

[AkshitaJha]

If we can't figure this out, we can use 14.04 for now. Would prefer 16.04, but not worth getting stuck on it.

To avoid the URL error, I tried using Ubuntu 14.04. I get the same SSH error that we get for ubuntu_5rel_vm (Full log). I too have Vagrant 1.9.1 installed in my system.

[dfarrell07]

To avoid the URL error, I tried using Ubuntu 14.04. I get the same SSH error that we get for ubuntu_5rel_vm (Full log). I too have Vagrant 1.9.1 installed in my system.

This log looks like you're using a container.

puppet-opendaylight$ sudo bundle exec rake ubuntu_5rel_dock RS_SET=ubuntu-16-docker INSTALL_METHOD=deb DEB_REPO='' bundle exec rake beaker

Creating container from image ef295ff2dc36

The failures at the end seem like the SSH server isn't up properly in the container. It could be many things, but you might be able to debug using docker ps to find the container and docker exec/run/attach to get a shell and look around. You should also of verify that normal docker stuff works (docker run hello-world).

/me makes a note: it would be nice if the puppet-test ODL job allowed you to pull an under-dev version of puppet-opendaylight like this pull request

[dfarrell07]

This is making good progress, getting fairly close. Maybe would be good to remove the tarball logic in this same PR, so we can verify the overall swap tarball->deb? Up to you.

[AkshitaJha]

This is making good progress, getting fairly close. Maybe would be good to remove the tarball logic in this same PR, so we can verify the overall swap tarball->deb? Up to you.

Will do. The beaker tests are failing for Ubuntu 14.04. I am yet to work on fixing the Ubuntu 16.04 issue.

[dfarrell07]

The beaker tests are failing for Ubuntu 14.04.

Yeah, that's what I'm seeing too. I noticed that if I run the beaker:ubuntu-14-docker rake task, things fail early with this error:

/home/daniel/puppet-opendaylight/spec/spec_helper_acceptance.rb:214:in `generic_validations': Unexpected RS_SET (host OS): (RuntimeError)

Which is caused by the enviroment var RS_SET (set in the rake task) not being set in the Beaker env at this check. I think that rake task is being automatically generated by the existence of our nodeset files and some puppet magic. As normal, puppet's magic is being a bit too smart, or not quite smart enough. We need to use the rake task you've defined, ubuntu14_5rel_dock, to get the env var set properly. We should likely raise a Trello card to remove these automated rake tasks (and others), to prevent confusion.

Using the correct rake task, the tests make it as far as applying the module, which is good. Eventually fails with (full log VM, almost same for container):

Error: Could not parse for environment production: Syntax error at ','; expected '}' at /tmp/apply_manifest.pp.jXuNrQ:3 on node ubuntu-14.rdu.redhat.com

Which typically means we are doing something wrong with params (ie empty param), causing the puppet manifest to be malformed.

Re-running with a flag to not destroy the VM after the test run so I can poke around

BEAKER_destroy=no bundle exec rake ubuntu14_5rel_vm &> ubuntu14_5rel_vm.log

Changing to the dir with the Vagrantfile for the box we just created:

$ cd .vagrant/beaker_vagrant_files/ubuntu-14.yml $ vagrant status ubuntu-14 running (virtualbox) $ vagrant ssh

Looking at the log to find the test manifest that failed and looking at it:

$ sudo cat /tmp/apply_manifest.pp.jXuNrQ
    class { 'opendaylight':
      install_method => deb,
      rpm_repo => ,
      default_features => ["config", "standard", "region", "package", "kar", "ssh", "management"],
      extra_features => [],
      odl_rest_port=> 8080,
      enable_ha=> false,
      ha_node_ips=> [],
      ha_node_index=> 0,
      log_levels=> {},
    }

Clearly the problem is the missing rpm_repo param.

[AkshitaJha]

Maybe would be good to remove the tarball logic in this same PR, so we can verify the overall swap tarball->deb?

Should I remove the tarball logic just for ubuntu or for Redhat based OS's too?

[dfarrell07]

Should I remove the tarball logic just for ubuntu or for Redhat based OS's too?

You can totally nuke everything related to tarballs. Hard to imagine that it's much more than bugs and a maintenance nightmare. They aren't really meant for use on RH OSs, hardly considered people using them over RPMs.

[AkshitaJha]

Clearly the problem is the missing rpm_repo param

I have changed the rpm_repo param to a more generic repo param. As you had mentioned earlier:

For the RPM, it's meant to be the param that determines which version of ODL to install

So, for Debs this value should logically be that of the PPA repo from which ODL will be installed.

There are some failures for bundle exec rake ubuntu14_5rel_vm . Out of these, Failure 1:

1) opendaylight class testing install methods Service "opendaylight" should be running
     Failure/Error: it { should be_running }
       expected Service "opendaylight" to be running

     # ./spec/spec_helper_acceptance.rb:108:in `block (2 levels) in generic_validations'

is expected as Ubuntu 14.04 uses Upstart, not systemd. There is a known issue with ODL's upstart file which results in ODL's status to be stop/waiting instead of start/running. Need to rectify this.

The internet connection here was really erratic today. Can you please confirm if you see the other failures (apart from the one about the opendaylight service) as well?

[AkshitaJha]

The latest PR allows using Ubuntu 16.04 with Beaker. However, some tests fail for both Ubuntu 14.04 and Ubuntu 16.04 docker containers.

Full logs for ubuntu16_5rel_dock and ubuntu14_5rel_dock. As far as I can tell, both the docker container test fails are the same. Ppa "ppa:odl-team/boron" fails for both whereas it is successful for ubuntu14_5rel_vm. Unable to figure out the issue here. :/ Can you confirm if you see the same failures?

[dfarrell07]

So, for Debs this value should logically be that of the PPA repo from which ODL will be installed.

Okay, awesome.

I have changed the rpm_repo param to a more generic repo param.

Humm, interesting/good thought. Now that you bring my attention to it, seems like we should remove the install_method param. Only reason it was needed was to toggle RPM/tarball on systems that support both. Now that we don't have tarball, can just look at OS/pkg manager to check if need deb/rpm vs having this param.

If we do that^^, I'd suggest leaving the rpm_repo param and adding a deb_repo param. We'd then be able to deploy in a fairly OS agnostic way to user - default params would give them a working deployment on whatever OS they point pup-odl at. Also, having both shows the user via the default what's expected. More clear to bump 5 to 6 (5-testing, 6-testing) vs having to figure out PPA vs RPM syntax.

The internet connection here was really erratic today

FYI the ODL deb download is really slow for me too, ~1Mbps. Also FYI I was seeing some failures regarding old/wrong IPs from apt early in docker beaker runs. Had to docker rmi some old cached image layers (see docker images).

I forgot about 14.04 not having systemd, good point. Maybe good reason not to support it?

For ubuntu14_5rel_dock (logs), I think all the errors are related to not having systemd. Error 3 (java not running) should be because ODL wasn't started, no sysd. You described 2 correctly. All the others are about /Stage[main]/Opendaylight::Service/Service[opendaylight] being nill, which again I think is because no sysd.

Full logs for ubuntu16_5rel_dock and ubuntu14_5rel_dock. As far as I can tell, both the docker container test fails are the same.

The difference I see is that 14 is failing with nill Service class (b/c no sysd, see above) where 16 is actually trying to use systemd, but then fails with missing init files. I think the bit about ppa:odl-team/boron failing is really because of the sysd failure a few lines above it.

Ubuntu 16 with Boron on Docker looks the same as your run, failures related to sysd init script error (logs). Not sure exactly what's going wrong there, maybe permissions/location of sysd file? Can compare to a deb-only install (permissions, location etc) and see what's different.

Ubuntu 16 in a VM still fails for me with early Vagrant SSH issues, same ones we talked about on this thread a while back.

[dfarrell07]

Both locally and in Travis I'm still seeing the %{path}:%{linenumber}:%{check}:%{KIND}:%{message} error. Again, not sure what's causing it.

[AkshitaJha]

Humm, interesting/good thought. Now that you bring my attention to it, seems like we should remove the install_method param. Only reason it was needed was to toggle RPM/tarball on systems that support both. Now that we don't have tarball, can just look at OS/pkg manager to check if need deb/rpm vs having this param.

This is a good idea. I have added both the params - rpm_repo and deb_repo.

I forgot about 14.04 not having systemd, good point. Maybe good reason not to support it?

Ubuntu 14.04 does not support systemd. It uses Upstart. Systemd is supported from Ubuntu 14.10 (Docs). I think I should write tests for Ubuntu 14.04 accordingly.

The difference I see is that 14 is failing with nill Service class (b/c no sysd, see above) where 16 is actually trying to use systemd, but then fails with missing init files. I think the bit about ppa:odl-team/boron failing is really because of the sysd failure a few lines above it.

Ubuntu 16 with Boron on Docker looks the same as your run, failures related to sysd init script error (logs). Not sure exactly what's going wrong there, maybe permissions/location of sysd file? Can compare to a deb-only install (permissions, location etc) and see what's different.

I checked the permissions/location of the sysd file. It's the same as the deb install. But, it seems systemd is not active in Ubuntu Docker images. Probably that's the reason for the error. However, Puppet provides a way in which we can use our service, if the init script is lacking(Docs). So, I added a binary attribute to manifests/service.pp file.

# == Class opendaylight::service
#
# Starts the OpenDaylight systemd or Upstart service.
#
class opendaylight::service {
  service { 'opendaylight':
    ensure     => running,
    enable     => true,
    hasstatus  => true,
    binary   => "/opt/opendaylight/bin/start",
    # TODO: Confirm this is actually supported by ODL service
    hasrestart => true,
  }
}

To check if the script - /opt/opendaylight/bin/start actually works, I SSH'ed into the centos/7 vagrant box of integration-packaging/rpm and observed the following:

[vagrant@localhost ~]$ systemctl status opendaylight
● opendaylight.service - OpenDaylight SDN Controller
   Loaded: loaded (/usr/lib/systemd/system/opendaylight.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: https://wiki.opendaylight.org/view/Main_Page
           http://www.opendaylight.org/
[vagrant@localhost ~]$ sudo systemctl start opendaylight
[vagrant@localhost ~]$ systemctl status opendaylight
● opendaylight.service - OpenDaylight SDN Controller
   Loaded: loaded (/usr/lib/systemd/system/opendaylight.service; disabled; vendor preset: disabled)
   Active: active (running) since Tue 2017-02-07 17:55:02 UTC; 6s ago
     Docs: https://wiki.opendaylight.org/view/Main_Page
           http://www.opendaylight.org/
  Process: 4239 ExecStart=/opt/opendaylight/bin/start (code=exited, status=0/SUCCESS)
 Main PID: 4254 (java)
   CGroup: /system.slice/opendaylight.service
           └─4254 /usr/bin/java -Djava.security.properties=/opt/opendaylight/etc/odl.java.security -server -Xms128M -Xmx2048m -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass -XX:+HeapDumpOnOutOfMemoryError -Dcom.sun.management.jmxre...
[vagrant@localhost ~]$ /opt/opendaylight/bin/stop
karaf: JAVA_HOME not set; results may vary
[vagrant@localhost ~]$ systemctl status opendaylight
● opendaylight.service - OpenDaylight SDN Controller
   Loaded: loaded (/usr/lib/systemd/system/opendaylight.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: https://wiki.opendaylight.org/view/Main_Page
           http://www.opendaylight.org/
[vagrant@localhost ~]$ /opt/opendaylight/bin/start
[vagrant@localhost ~]$ systemctl status opendaylight
● opendaylight.service - OpenDaylight SDN Controller
   Loaded: loaded (/usr/lib/systemd/system/opendaylight.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: https://wiki.opendaylight.org/view/Main_Page
           http://www.opendaylight.org/

/opt/opendaylight/bin/start does not seem to work, but opt/opendaylight/bin/stop and systemctl start opendaylight work correctly. Looks like a bug. I hope I am not missing something here?

Ubuntu 16 in a VM still fails for me with early Vagrant SSH issues, same ones we talked about on this thread a while back.

There seems to be some issue with the ubuntu/xenial64 vagarant box. Similar issue here. I tried using a different xenial64 base box, but there was an SSH timeout error. Working on it.

[AkshitaJha]

I added a binary attribute to manifests/service.pp file.

With just this, I received the error :

Error: Could not find init script for 'opendaylight'
Error: /Stage[main]/Opendaylight::Service/Service[opendaylight]/ensure: change from stopped to running failed: Could not find init script for 'opendaylight'

To rectify this error, I copied the start file from /opt/opendaylight/bin/start to /etc/init.d/opendaylight in install.pp.

file { '/etc/init.d/opendaylight' :
    ensure => file,
    source => "/opt/opendaylight/bin/start",
}

This gives me the error:

Error: Could not start Service[opendaylight]: Execution of '/etc/init.d/opendaylight start' returned 1: 
Error: /Stage[main]/Opendaylight::Service/Service[opendaylight]/ensure: change from stopped to running failed: Could not start Service[opendaylight]: Execution of '/etc/init.d/opendaylight start' returned 1:

I think this error is because /opt/opendaylight/bin/start does not work correctly. What do you think?

[dfarrell07]

I have added both the params - rpm_repo and deb_repo.

Awesome, great stuff, thanks. :)

But, it seems systemd is not active in Ubuntu Docker images.

Ah, yes, true. I should have thought of this and pointed it out. Docker containers are application containers, so they don't contain a service manager like systemd. They expect you to start the service as part of the container creation, running it as a service. Something like docker run -it opendaylight/odl:5.2.0 /opt/opendaylight/bin/karaf. There are other types of containers that do have systemd (LXC), but that's a different discussion (better to wait and move to OCI's stuff once ready imho).

This reminded me that our CentOS and Fedora containers also don't have systemd. I found this a bit confusing for a while, because looking at the logs of our test-puppet Jenkins job, Service stuff is clearly working. Thinking about it more, I guess Puppet's Service resource is doing some magic behind the scenes to start/stop/restart ODL's service w/o systemd (as you mentioned for Ubuntu).

I guess the problem is that Puppet's Service magic works for non-systemd Fedora/CentOS containers, but is failing on your Ubuntu container.

I checked the permissions/location of the sysd file

I guess we're not actually even using this? Config is happening via Service's params, not this file? Sorry for putting you on the wrong track there.

/opt/opendaylight/bin/start does not seem to work, but opt/opendaylight/bin/stop and systemctl start opendaylight work correctly.

This was confusing to me too. I think the problem is that you have to run start script as root for it to spawn a background daemon process for ODL. I see the same behavior, but it works with sudo (may need to check pgrep java and ssh -p 8101 karaf@localhost see ODL running, systemctl doesn't seem to see service if not started that way). Btw, I guess you know this but systemctl start backs up to bin/start, but it runs as root so np.

There seems to be some issue with the ubuntu/xenial64 vagarant box. Similar issue here. I tried using a different xenial64 base box, but there was an SSH timeout error. Working on it.

Ah, great job tracking that back to the root problems. You clearly seem to have found the relevant ones. Maybe we can work around it with the echo "ubuntu:ubuntu" | sudo chpasswd command someone mentioned? I guess in the nodeset file?

Could not find init script for 'opendaylight'

I'm starting to wonder if all of this init stuff is related to the "don't call /sbin/init in nodeset file" suggestion I made earlier. That command creates some init files, maybe those are what our errors are complaining about. Maybe Puppet's Service magic would handle managing ODL's service on Ubuntu if we had these init files.

I think this error is because /opt/opendaylight/bin/start does not work correctly.

I guess it's because that's not the type of script it expects to find. Expects a very special type of script, something like https://github.com/fhd/init-script-template/blob/master/template. For example, init scripts seem to expect first param $1 is start/stop/restart/status, whereas bin/start doesn't.

This is all very confusing, good job pushing through it. :+1:

[AkshitaJha]

There seems to be some issue with the ubuntu/xenial64 vagarant box. Similar issue here. I tried using a different xenial64 base box, but there was an SSH timeout error. Working on it.

I have changed the vagrant base box for Ubuntu 16.04. There are no SSH errors now.

I'm starting to wonder if all of this init stuff is related to the "don't call /sbin/init in nodeset file" suggestion I made earlier. That command creates some init files, maybe those are what our errors are complaining about. Maybe Puppet's Service magic would handle managing ODL's service on Ubuntu if we had these init files.

You were right! This was the command that was missing! All tests are successful now. :)

I see 93 examples, 0 failures for both Ubuntu 16.04 docker container and vagrant box. Finally!

[AkshitaJha]

Unable to figure out how to get upstart working in Ubuntu 14.04 for beaker tests. When I add [/sbin/init] to the nodeset docker file, I get SSH errors again :/ Without sysd, there are 93 examples 12 failures for the docker container. For the Ubuntu 14.04 VM, there are 93 examples 10 failures.

[dfarrell07]

This is really turning into a great PR, thanks @AkshitaJha!

All tests are successful now. :)

+1, I'm seeing Ubuntu 16.04 Beaker tests pass for both VMs and containers. Awesome!

Unable to figure out how to get upstart working in Ubuntu 14.04 for beaker tests.

Let's just not support Ubuntu 14.04. Clearly not worth the work imho.

Travis and I are still seeing that strange linter failure. If we can work that out and get 14.04 stuff removed, I think this is ready to merge.

[dfarrell07]

I have changed the vagrant base box for Ubuntu 16.04. There are no SSH errors now.

We should raise an Int/Pack Trello to track this imho. Would be good to eventually use the upstream Ubuntu box, but not worth blocking progress here. This kind of thing frequently works itself out in new box versions, may just need to revisit in a while and it will "magically" work. Can you verify what you're seeing, doc it and raise a card?

[dfarrell07]

Maybe we can work around it with the echo "ubuntu:ubuntu" | sudo chpasswd command someone mentioned? I guess in the nodeset file?

Did you try this with the upstream Ubuntu vagrant base box? As I review the past posts more, I guess you don't need to "verify what you're seeing" as I mentioned before, you clearly found the problem. Just extract the description from this wall of text and put it in a Trello card.

You were right! This was the command that was missing!

So it did turn out that my bad advice was the problem. ;)

[AkshitaJha]

Let's just not support Ubuntu 14.04. Clearly not worth the work imho.

Have removed support for Ubuntu 14.04.

Travis and I are still seeing that strange linter failure.

After removing support for Ubuntu 14.04, I no longer see the linter failures but all tests related to Deb installs are failing with the error:

Failure/Error: include apt

Puppet::PreformattedError:
    Evaluation Error: Unknown variable: '::puppetversion'. at /home/travis/build/dfarrell07/puppet-opendaylight/spec/fixtures/modules/apt/manifests/params.pp:9:6 on node testing-docker-b737b043-79c4-4bc4-a2f5-2e5b3e402ffd.ec2.internal

Maybe we can work around it with the echo "ubuntu:ubuntu" | sudo chpasswd command someone mentioned? I guess in the nodeset file?

I had tried adding

vagrant_image_commands:
      - 'echo "ubuntu:ubuntu" | sudo chpasswd'

to the nodeset file. I also tried this with vagrant_cmd. I get the same SSH errors with both. Is there any other way to execute this command from the nodeset file?

[AkshitaJha]

Failure/Error: include apt

Puppet::PreformattedError:
    Evaluation Error: Unknown variable: '::puppetversion'. at /home/travis/build/dfarrell07/puppet-opendaylight/spec/fixtures/modules/apt/manifests/params.pp:9:6 on node testing-docker-b737b043-79c4-4bc4-a2f5-2e5b3e402ffd.ec2.internal

Figured out what the problem was. Needed to set some facts puppetversion, lsbdistid, lsbdistrelease, ... etc. for Ubuntu tests.

[AkshitaJha]

I don't see the same travis errors in my local system (probably because of the difference in the puppet version).

Puppet version: 4.9.0 (Full Log) There are 7 failed examples (which I think are expected) for unsupported OSs.

[dfarrell07]

Awesome @AkshitaJha, thanks!

I don't see the same travis errors in my local system (probably because of the difference in the puppet version).

Ah, I see that we should add 4.9 to our Travis test matrix. I think the difference between the two is the code, not the Puppet version though. Travis is auto-merging your changes into master, I suspect you need to merge in the latest changes to get the same environment.

There are two types of rspec failures left. First is the typo I highlighted inline. Second is missing ::lsbdistid var.

I get the same SSH errors with both. Is there any other way to execute this command from the nodeset file?

I'm not sure, I haven't done much with custom commands in nodeset files. Let's just make sure it's doc'd on the Trello and do it in another patch/wait for upstream fix.

[dfarrell07]

Ah, I see that we should add 4.9 to our Travis test matrix.

Can you send a patch or raise a Trello to note this @AkshitaJha? Thanks for finding it :+1:

[dfarrell07]

Maybe you can squash these commits into one, @AkshitaJha? They do one logical thing, and I don't think we want the intermediary steps to be valid states of the codebase.

[AkshitaJha]

We should raise an Int/Pack Trello to track this imho. Would be good to eventually use the upstream Ubuntu box, but not worth blocking progress here. This kind of thing frequently works itself out in new box versions, may just need to revisit in a while and it will "magically" work. Can you verify what you're seeing, doc it and raise a card?

I created a trello card to update ubuntu box.

Ah, I see that we should add 4.9 to our Travis test matrix. Can you send a patch or raise a Trello to note this.

For now, raised a trello card for this as well.

Maybe you can squash these commits into one, @AkshitaJha? They do one logical thing, and I don't think we want the intermediary steps to be valid states of the codebase.

Done. But the travis checks are still failing for the missing ::lsbdistid var.

[dfarrell07]

I updated all the operatingsystem vars to lsbdistvars

You missed some in the newly-merged-in VPP code at the bottom of the file I mentioned

Thanks for explaination of var change

On Thu, Feb 23, 2017, 10:22 PM AkshitaJha notifications@github.com wrote:

Ah, I see that we should add 4.9 to our Travis test matrix. Can you send a patch or raise a Trello to note this.

Raised a PR https://github.com/dfarrell07/puppet-opendaylight/pull/131/commits/f29098afa597a667c32e0887bb0df0dc691b2a87 for this yesterday.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/dfarrell07/puppet-opendaylight/pull/131#issuecomment-282193535, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1ukYsghogxCRcsN7Q28ilm1GbWNKlmks5rfk0IgaJpZM4Lq2BX .

[AkshitaJha]

You missed some in the newly-merged-in VPP code

Thanks for being so patient @dfarrell07. I had not pulled these new changes!

As I already mentioned, I see no errors for Puppet 4.9.0. Maybe, the error is due to the caveat of lsbdistid: ... If that is not the case, then simply because of different puppet versions?

No wonder, I didn't see the same travis errors. Silly silly me! Running off in all directions!

All checks are successful now. Thanks again for being so kind and patient. :)

[dfarrell07]

Np @AkshitaJha. :) This looks great, very close.

All Ubuntu VM/container Beaker tests pass for me, as do the rspec and linting tests. However, the sanity rake job is failing in the CentOS 6-testing Beaker job.

http://pastebin.com/k6z95vsb

The first failure I'm seeing in the log is

Error: Unsupported OS:  at /etc/puppet/modules/opendaylight/manifests/init.pp:91 on node centos-7-docker.rdu.redhat.com

Which are related to the OS support checks in manifests/init.pp. I think the problem is related to the var changes we've been discussing, from operatingsystem to libdist.

[dfarrell07]

Great job digging to the root of it.

Is it better to have only operatingsystem vars for centos/redhat and both lsbdist and operatingsystem* vars for ubuntu?

Yeah, that sounds better to me. I'd rather have the minor confusion internal to puppet-opendaylight than force users to install redhat-lsb-core if we can avoid it.

[dfarrell07]

We're going to want to add your Ubuntu beaker tests to the acceptance rake tasks too FYI.

diff --git a/Rakefile b/Rakefile
index 7d62a15..3350bb5 100644
--- a/Rakefile
+++ b/Rakefile
@@ -118,6 +118,7 @@ desc "All tests, use VMs for Beaker tests"
 task :acceptance_vm => [
   :test,
   :cent_5rel_vm,
+  :ubuntu_5rel_vm,
   :cent_5test_vm,
   :cent_6test_vm,
 ]
@@ -126,6 +127,7 @@ desc "All tests, use containers for Beaker tests"
 task :acceptance_dock => [
   :test,
   :cent_5rel_dock,
+  :ubuntu_5rel_dock,
   :cent_5test_dock,
   :cent_6test_dock,
 ]

[AkshitaJha]

Tested it for cent_5rel_vm, cent_5rel_dock, ubuntu_5rel_vm and ubuntu_5rel_dock. Looks fine to me.

[dfarrell07]

All of acceptance_dock passes for me, so this is ready to merge. Great job on a very hard PR @AkshitaJha! Thank you from ODL and OPNFV for a major contribution!

[AkshitaJha]

All of acceptance_dock passes for me, so this is ready to merge. Great job on a very hard PR @AkshitaJha! Thank you from ODL and OPNFV for a major contribution!

Thanks @dfarrell07 for your patience and excellent guidance! Just wanted to add that puppet-opendaylight does not really seem hard anymore. ;)