Open ryanlelek opened 8 years ago
+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 nodejs_version
seems broken, or should be documented better.
@vjpr I am hoping that @rvagg can shed some light on the removal of 4.2 from the repository.
I am not sure if it has been archived.
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 apt-get update
and then apt-cache search nodejs
now, you'll just see the 4.3 entry.
The earlier versions are there, you'd just have to link directly to the URL IE:
https://deb.nodesource.com/node_4.x/pool/main/n/nodejs/nodejs_4.2.6-1nodesource1~trusty1_amd64.deb
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 nodejs_version
to 4.3 will break when 4.4 is out...so lets keep this issue open @wolfeidau?
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 reprepro
command which manages the repo files for all of this and updates them when you add / remove packages doesn't support multiple versions. It will just use whatever the newest one is. Launchpad PPA repos work the same way.
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:
E: Version '4.3*' for 'nodejs' was not found
Looks like the repo is updated so all I needed to do was to remove / reinstall the role. For some reason ansible-galaxy remove
didn't work. Workaround was reinstalling with:
sudo -H ansible-galaxy install --force nodesource.node,master
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 stderr
output.
TASK [nodesource.node : Install Node.js] ***************************************
fatal: [testRedef]: FAILED! => {"cache_update_time": 1471545276, "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.4*'' failed: E: Version '4.4*' for 'nodejs' was not found\n", "stderr": "E: Version '4.4*' 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..."]}
same issue as @tsturzl. Any workarounds ?
Workarounds
set the nodejs_version for the role
- { role: 'nodesource.node', become: yes, nodejs_version: '4.5'}
or patch the main.yml:
on ubuntu this is the file to patch (4.4 -> 4.5):
/etc/ansible/roles/nodesource.node/defaults/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.
ruby
ruby-20
ruby-21
ruby-22
ruby-23
I'm completely fine with nodejs
moving to whatever is latest. If people want that, all good. Can't we also have
nodejs-44
nodejs-45
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 4.x
, which I'm honestly completely fine with. The thing that sucks is that this role is essentially useless at the moment because I have yet to find a workaround that actually works other than modifying the source code.
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.
nodejs_version: "4.5"
( I dont use a wildcard like "x" or "*" because it's already in the role)
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:
- name: Install Node.js
apt:
pkg:
- - nodejs={{ nodejs_version }}*
+ - nodejs
state: installed
update_cache: yes
Next phase will be to swap to specifying the 4.x or 6.x as a param, with the existing param retained for compatibility.
Error:
TASK [nodesource.node : Install Node.js] *** fatal: [MYDOMAIN.COM]: FAILED! => {"cache_update_time": 1455109514, "cacheupdated": 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..."]}