Vagrant Up Fails with 'Undefined Local Variable Or Method' #166
Comments
|
Seems like a regression/change in Puppet 5.5.7. https://gist.github.com/baurmatt/86ea02c0fd6dd173efab4a7bb7ddf23e |
|
One of the problems of relying on external tools. |
|
Seriously not helpful at all. Can you do better? |
|
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. |
|
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. |
|
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.
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. |
|
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, |
That's something I wasn't aware of. Your written English certainly doesn't give that away!
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. |
|
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 :) |
|
Seems this change causes this: https://tickets.puppetlabs.com/browse/PUP-9137 |
|
https://github.com/puppetlabs/puppetlabs-mysql/blob/master/CHANGELOG.md#added-2
I'm on 5.1.0, not 6.0.0. |
|
While testing, I've found Icinga/icinga2#6635 happening more visible. |
|
@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). |
|
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. |
|
Plus, Puppet tends to speed up things in minor releases, so this is a good opportunity to update things too. |
e0bf8cfe Merge pull request #179 from olevole/master 8cd1f6e0 fix spec: proper data_dir value for FreeBSD 4333ff9e properly aligned b37bdb0d repo and package method are the same for FreeBSD e1aeca52 fix typo e4aa1eff repo: added case for FreeBSD OS family d661e22c fix typo b9e566ad Merge branch 'master' of github.com:olevole/puppet-grafana 4277076e Merge branch 'master' of github.com:olevole/puppet-grafana b299a124 Merge pull request #180 from voxpupuli/modulesync e6a50cc9 modulesync 2.8.0 e66e9999 Merge branch 'master' of github.com:olevole/puppet-grafana cad5c06e Add FreeBSD platform support b2c5b7e2 Add FreeBSD platform support 69d9cae6 Merge pull request #176 from voxpupuli/afisher_update_dependencies 8c752fee allow puppetlabs/apt 7.x 01eb3f57 Allow puppet/archive 4.x and puppetlabs/stdlib 6.x fa9bce3d Merge pull request #172 from alexconrey/master 5c47fe5d Fix rubocop issues (#9) ee7252df fix issue with grafana_folder idempotency apply (#8) 5f08df2f Merge pull request #171 from voxpupuli/modulesync 3011aba0 Update README.md (#7) f7580a3b fix rubocop warnings (#6) f86d7c30 Update grafana dashboard resource (#5) d6a938a4 Rewrite grafana_cli unit test cd52596e modulesync 2.7.0 d5067d36 Merge pull request #170 from alexconrey/master 2adb0966 update acceptance tests for grafana_folder (#4) 3f6d08c5 Update README.md/create acceptance tests (#3) e1817961 rubocop fixes (#2) 29c1bfa4 Corrected invalid database config example (#169) 99254e3a Implement grafana folder resource (#1) ab1c6f58 Use data in modules instead of params.pp (#167) 4c57681f Merge pull request #166 from dhoppe/puppet3_syntax 822a6fd5 Remove Puppet 3 specific syntax 78c361bc Mark passwords as sensitive (#165) f4c4d9ba Merge pull request #161 from dhoppe/base_url 1b093c7a Merge pull request #164 from voxpupuli/modulesync 411ab48a Merge branch 'master' into base_url 3f98b51c Merge pull request #160 from dhoppe/real_package_source 20c26773 Update to latest available version and make sure the repo configs are unique (#163) 0a84497f modulesync 2.6.0 d5a535ef Fix value of variables base_url and real_archive_source 72ba05ae Fix value of variable real_package_source git-subtree-dir: .puppet/modules/grafana git-subtree-split: e0bf8cfe9ac06852fbb423e247e18e765d9d4a8b
Not much to say. Tried running a
vagrant upand get the error.Expected Behavior
It should just work.
Current Behavior
Vagrant up produces the error above.
Steps to Reproduce (for bugs)
Run a
vagrant upContext
Your Environment
vagrant -v): 2.1.5The text was updated successfully, but these errors were encountered: