Vagrant Up Fails with 'Undefined Local Variable Or Method' about icinga-vagrant HOT 15 CLOSED

Seems like a regression/change in Puppet 5.5.7.

https://gist.github.com/baurmatt/86ea02c0fd6dd173efab4a7bb7ddf23e

from icinga-vagrant.

One of the problems of relying on external tools.

from icinga-vagrant.

Seriously not helpful at all. Can you do better?

from icinga-vagrant.

That's not quite the reaction I was expecting. Nor was it my intention to suggest I could do better.

My thought on this were that as you're providing a Vagrant environment for people to spin up and use as a demo I expect it to be as self-contained as possible. You control it all. That way you also control, and have the ability to fix any issues. Demo environments are spun up on all sorts of kit so your environment needs to take care of that. So when it's built you know that no matter where it goes, it works. Minimising the dependencies you don't control, in my mind, is part of that. It means that you're not reliant on something that could stop you dead in your tracks, as this has done for me (I'm assuming at this point there is no workaround as there wasn't one offered).

When I saw the Vagrant environment my initial thoughts were 'why are they using Puppet when they know how it hangs together'. It just looks a little strange from an outsider to come along to your product and see you're using something else entirely to install it. Why not just script is yourselves that way you take that dependency away?

When I'm evaluating using a tool, and the demo doesn't work, and I take the time to report it, what I'm not expecting is somebody to complain and ask me if I can do better. What it says to me, and anybody else seeing this is that why would they bother reporting issues?

You can either take from that, that I'm having a go or you can take from that as honest feedback. That's entirely up to you. I know what my intention was and raising an issue is not something I do lightly. Unless there is a workaround for the issue I'll leave this as it is and move on.

from icinga-vagrant.

It is unfortunate that a Puppet minor version breaks this, but it is like anything else with open source - you're welcome to help resolve the issue, or have to wait until things are fixed. Thanks for raising the issue, I'll look into it when I get the time to.

Things I cannot stand are comments like yours, as it doesn't help with anything except for the feeling that one should not use Puppet. That doesn't help me nor you to get things working again. I hope you see my point here.

Meanwhile, you can try pinning the Puppet version in the provisioner scripts to 5.5.6.

diff --git a/.puppet/scripts/shell_provisioner_pre.sh b/.puppet/scripts/shell_provisioner_pre.sh
index d4acad5cf..226f5c9f2 100755
--- a/.puppet/scripts/shell_provisioner_pre.sh
+++ b/.puppet/scripts/shell_provisioner_pre.sh
@@ -37,7 +37,7 @@ fi

 if ! rpm -q "puppet-agent" &>/dev/null; then
     echo "Installing Puppet 5..."
-    yum install -y puppet-agent
+    yum install -y puppet-agent-5.5.6
 fi

 if [ `getenforce` = 'Enforcing' ]; then

from icinga-vagrant.

I'm feeling like I'm misunderstanding this repo. My understanding was that it's a demo environment to show off the product and what it can do? It's linked from the main Icinga website. I get that it's open source but when I come here from your website I'm expecting a certain level of functionality. So while I get it's open source, it should also work, in my opinion, without customers coming along to fix them. This is entirely different from the product itself. It's my expectation of the demo repo. It would not be my expectation of the repo for the product itself - been around open source a long time so I get it. Again, that's not me having a go.

Things I cannot stand are comments like yours, as it doesn't help with anything except for the feeling that one should not use Puppet. That doesn't help me nor you to get things working again. I hope you see my point here.

I absolutely do see your point here but it wasn't a comment aimed at not using Puppet (although I've made my feeling known on that). However what I hate is comments that are knee jerk reactions to other comments when there is nothing in the history to show what the meaning behind that comment was. Now that's a mouthful. Had there been a thread of 'nice' or 'not nice' comments, you'd have rightfully judged it one way or the other. But you didn't know what the intention was. Nor did you try and find out.

But that's done. We've both said our piece so let's leave that there.

Actually what my intention really was me sympathising with the issue of external dependencies screwing up your builds.

I will look at pinning the Puppet version in the diff but can I also suggest you do that for your environment? As this is a demo environment then the intention, I assume, is to just show off the product. So as an end user I only want to see what it can do. As a provider of that environment you want to provide a working environment. You know it works with that version of Puppet. Unless you want to test your environment every time Puppet releases a new version (or every time any other depending you use releases a new environment - you can only be sure it works if you do do that testing) then you need to pin it to a known working version. As I said, this is a demo environment so the latest functionality in Puppet is unnecessary.

from icinga-vagrant.

I wasn't aware that I would need to pin Puppet versions in the 5.x branch - this has worked for many years. As a quickfix, I will do so ... hopefully Icinga 2 compiles in that PR I am working on, so I may fire vagrant up myself meanwhile.

So, I guess I was wrong with my assumptions, sorry for the harsh reaction. We don't know each other in person, maybe never will, so always is hard to understand each other. Likewise, you're fluent in English, I am not.

Cheers,
Michael

from icinga-vagrant.

So, I guess I was wrong with my assumptions, sorry for the harsh reaction. We don't know each other in person, maybe never will, so always is hard to understand each other. Likewise, you're fluent in English, I am not.

That's something I wasn't aware of. Your written English certainly doesn't give that away!

I wasn't aware that I would need to pin Puppet versions in the 5.x branch - this has worked for many years.

I completely get that you've never had to do it. But this would help with what I said about minimising the need for dependencies. If you do continue to use Puppet then you have absolutely no idea if any future version of Puppet will break your build. This case it was a minor version but the build would have installed v6 when it comes along and that has a far higher chance of breaking things. You know it works with 5.5.6 so pin it to that and you don't have to worry about it. It's a known. v5.5.6.1 and newer are unknown.

It's a win for you as you know that version works so no issues like mine. It's a win for Icinga as you don't have another customer complaining about it not working, or jumping to Nagios (or whatever other solution) because your environment didn't work so "why should they bother trying it out when you can't get the basics right" (customers do think like this). It's a win for the techie who decides to show all this shiny stuff to their boss, and they build the Vagrant environment in front of them only to discover that Puppet has released another version that breaks everything between them trying it and demoing to the boss.

Pinning the version numbers takes your Vagrant environment from an unknown every time it's built to a known.

And this applies to any dependencies not just Puppet.

And finally I'm happy to report that the Vagrant build is continuing beyond where it failed last time after I made the change. So, thank you for that.

from icinga-vagrant.

Thanks for the help and testing :) I wasn't really aware that this environment is used by the many to evaluate Icinga ... feedback is received mostly when things don't work. One problem I do see with this environment: I did build and maintain it for many years now, and it more or less contains too many things to show and maintain. It doesn't break that often though.

Some versions are not pinned in there, like for Icinga itself where the Puppet module doesn't allow for it. For now, this environment also is used to generate feedback from users with using snapshots, but I tend to disable this in Hiera (the docs tell you how to use release packages with a short edit).

The Puppet modules themselves are safe, as they are a fixed Git subtree and not the usual way one would keep to install Puppet modules. Some don't like that, but it keeps this more safe than deprecated/removed modules from the forge.

Also, thanks for the kind feedback on my English :)

from icinga-vagrant.

Seems this change causes this: https://tickets.puppetlabs.com/browse/PUP-9137

from icinga-vagrant.

https://github.com/puppetlabs/puppetlabs-mysql/blob/master/CHANGELOG.md#added-2

Use puppet4 functions-api puppetlabs/puppetlabs-mysql#1044 (juliantodt)

I'm on 5.1.0, not 6.0.0.

from icinga-vagrant.

While testing, I've found Icinga/icinga2#6635 happening more visible.

from icinga-vagrant.

@dnsmichi I would be happy to help out if you were thinking of migrating this away from Puppet onto standard scripts (I know we've had that discussion and it's unlikely but I'm just letting you know).

from icinga-vagrant.

I'm fine with Puppet, thanks. I'm just looking to solve the real issue and learn from it. At some point, one likely wants to use new features from modules, and really needs Puppet 6 support. For myself, I've found the DSL easier than shell scripting or Ansible/Chef. It also keeps me in the loop with automation tools, things I would otherwise never learn.

from icinga-vagrant.

Plus, Puppet tends to speed up things in minor releases, so this is a good opportunity to update things too.

from icinga-vagrant.