Skip to content
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

Open
ryanlelek opened this issue Feb 10, 2016 · 19 comments
Open

Role Broken, possible external package removed #24

ryanlelek opened this issue Feb 10, 2016 · 19 comments

Comments

@ryanlelek
Copy link
Contributor

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

@vjpr
Copy link

vjpr commented Feb 10, 2016

+1 Same issue here.

@ryanlelek
Copy link
Contributor Author

@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
Copy link

vjpr commented Feb 10, 2016

@ryanlelek Thanks! I used your fix already :)

@gillesdemey
Copy link

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

@vjpr
Copy link

vjpr commented Feb 10, 2016

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

@wolfeidau
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link

vjpr commented Feb 11, 2016

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
Copy link
Contributor

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

@wolfeidau wolfeidau reopened this Feb 11, 2016
@chrislea
Copy link
Contributor

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
Copy link

Welp, looks like we hit it for 4.4:

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

@makmanalp
Copy link

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
Copy link

tsturzl commented Aug 18, 2016

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

@ghost
Copy link

ghost commented Aug 19, 2016

same issue as @tsturzl. Any workarounds ?

@francisdb
Copy link

francisdb commented Aug 19, 2016

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
Copy link

wyaeld commented Aug 20, 2016

@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
Copy link

tsturzl commented Sep 4, 2016

@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
Copy link
Contributor Author

@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
Copy link
Contributor

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.

MattiSG added a commit to betagouv/aides-jeunes-ops that referenced this issue Mar 10, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants