-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Role Broken, possible external package removed #24
Comments
+1 Same issue here. |
@vjpr, wanted to make sure you saw the submitted PR. Update defaults/main.yml to have 4.3 as the node version instead of 4.2 and you'll be back up and running If you're on Mac, ansible roles are stored in /usr/local/etc/ansible/roles |
@ryanlelek Thanks! I used your fix already :) |
Thanks @ryanlelek, patched this on my machine for now! |
@wolfeidau But what if you want to use version 4.2? The |
The issue is that when the 4.3 release was pushed out to the repo, it unregistered any earlier releases in the 4.x line. So if you do the standard The earlier versions are there, you'd just have to link directly to the URL IE:
assuming you are using Ubuntu Trusty. |
Thanks @chrislea. So this role should probably be updated to support linking directly to exact versions. I prefer to lock down exact Node.js versions, and upgrade all at once. And the fix of changing EDIT Seems there's some discussion about this in #5 already, so thats fine. |
Yeah I am guessing I will have to add some sort of escape hatch to work around this. @chrislea is there a reason it is setup this way? Cheers |
The reason it works this way is that the We're looking at changing our tooling so that the repo will show multiple versions, but that's fairly low on the priority list right now internally if I'm being honest. All that said, one of the major points of the 4.x release line is that being an LTS release, it's never going to break API compatibility when a new version comes out. So you should be totally safe updating to whatever the newest version is at any time without fear of it causing problems. Pinning to a specific version isn't necessary. And frankly, it could be a Bad Thing (tm) if you pinned a version like that. This most recent 4.3 release is a security release that you should definitely want to update to. |
Welp, looks like we hit it for 4.4:
|
Looks like the repo is updated so all I needed to do was to remove / reinstall the role. For some reason
|
Having the same issue installing default version(4.4) in a vagrant box. I had the same for a previous version of this same role, so I removed and reinstalled the newest version, still getting the same error with a different version number in the
|
same issue as @tsturzl. Any workarounds ? |
Workarounds set the nodejs_version for the role or patch the main.yml: |
@chrislea how is this acceptable? I'm testing playbooks to build a DR environment, and having the node version that currently running in production suddenly become available one day to the next is ridiculous. I know upgrading 'should' be safe, but that doesn't change that fact that the role breaks every time, and we don't just change production versions on a whim. If you compare the user experience to something like the AWS AMIs, where they register multiple packages. eg.
I'm completely fine with
which doesn't get unregistered each time? Maybe with a warning they are out of date now. |
@chrislea the biggest problem for me is that your role simply doesn't work and I'm unable to make it work. My work around has been to rip the source out of this repo and just removing passing a version number to apt, and then it will just install the latest version of It bothers me because version 4 is the LTS, it's probably what most people are going to use in a production environment, and Ubuntu is probably the most common distro to be running this against. So to say this issue isn't a priority is bothersome. |
@tsturzl it is frustrating, and with the release of 4.5 I had to make edits myself and was about to do something similar to what you did. Current solution is putting this in the groups (or hosts) that use the role. This might make a difference from using role variables depending on your version of Ansible, etc. Might be worth a shot as a short-term fix while we figure out a long-term.
|
Having read over this issue a few times I think we can all agree:
I am therefore proposing to remove the specific version number in favour of towing the party line and just installing what ever is latest in the 4.x or 6.x stream. This is in accordance with the existing packaging infra. This is as simple as:
Next phase will be to swap to specifying the 4.x or 6.x as a param, with the existing param retained for compatibility. |
Get rid of broken nodesource role nodesource/ansible-nodejs-role#24 nodesource/ansible-nodejs-role#33
Error:
TASK [nodesource.node : Install Node.js] ***************************************
fatal: [MYDOMAIN.COM]: FAILED! => {"cache_update_time": 1455109514, "cache_updated": true, "changed": false, "failed": true, "msg": "'/usr/bin/apt-get -y -o "Dpkg::Options::=--force-confdef" -o "Dpkg::Options::=--force-confold" install 'nodejs=4.2_'' failed: E: Version '4.2_' for 'nodejs' was not found\n", "stderr": "E: Version '4.2*' for 'nodejs' was not found\n", "stdout": "Reading package lists...\nBuilding dependency tree...\nReading state information...\n", "stdout_lines": ["Reading package lists...", "Building dependency tree...", "Reading state information..."]}
The text was updated successfully, but these errors were encountered: