nodesource / ansible-nodejs-role

Ansible Role for Node.js Binary Install
MIT License
131 stars 47 forks source link

Role Broken, possible external package removed #24

Open ryanlelek opened 8 years ago

ryanlelek commented 8 years ago

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..."]}

vjpr commented 8 years ago

+1 Same issue here.

ryanlelek commented 8 years ago

@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

vjpr commented 8 years ago

@ryanlelek Thanks! I used your fix already :)

gillesdemey commented 8 years ago

Thanks @ryanlelek, patched this on my machine for now!

vjpr commented 8 years ago

@wolfeidau But what if you want to use version 4.2? The nodejs_version seems broken, or should be documented better.

wolfeidau commented 8 years ago

@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.

chrislea commented 8 years ago

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.

vjpr commented 8 years ago

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.

wolfeidau commented 8 years ago

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

chrislea commented 8 years ago

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.

makmanalp commented 8 years ago

Welp, looks like we hit it for 4.4:

E: Version '4.3*' for 'nodejs' was not found

makmanalp commented 8 years ago

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

tsturzl commented 7 years ago

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..."]}
pankajlal commented 7 years ago

same issue as @tsturzl. Any workarounds ?

francisdb commented 7 years ago

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

wyaeld commented 7 years ago

@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.

tsturzl commented 7 years ago

@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.

ryanlelek commented 7 years ago

@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)

wolfeidau commented 7 years ago

Having read over this issue a few times I think we can all agree:

  1. Pinning a specific version using this role is not working reliably for the reasons which @chrislea outlined.
  2. We all really just want to install nodejs

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.