Configuration issue in Puppet setup for server5

[matze]

When in development environment, both the initial vagrant up server5 as well as any subsequent vagrant provision server5 command currently leads to the following error:

warning: Scope(Concat[/home/rsync/.ssh/known_hosts]): Could not look up qualified variable 'concat::setup::root_group'; class concat::setup has not been evaluated at /tmp/vagrant-puppet-2/modules-0/concat/manifests/init.pp:129

It occurred with a fresh clone of the repository at aa17d808aee9, but seems to affect earlier versions, too. However, I'm not sure about the consequences in e.g. production yet - if any.

[matze]

It seems like there are more servers affected:

• filter1
• filter2
• filter3
• filter4
• filter5
• filter6
• filter7
• filter8
• notification1
• notification2
• server11
• server12
• server15
• server19
• server5
• server6
• server7

All of the aforementioned guests raise the exact same issue.

[trev]

There are no implications - this is a warning, not an error. Older versions of the concat module (like the one we are using) warned when concat::setup wasn't invoked explicitly, this has been fixed and concat::setup is now deprecated. Feel free to update concat, so far we didn't bother doing that.

[matze]

I've prepared a pull request via GitHub (see review URL field above) for updating to the 1.0.4 version. I believe the hg Repository is just a clone of the former, so this seems the easiest way to go. Though it requires a subsequent merge from git to hg, however.

Currently this is still under test; I'll hard-wire it in my development environment and check whether the provisioning of each box is still working. Results will follow.

Fortunately this can be done with some commandline-foo, so it's more a background job. Yet it may take a while - my last run through all boxes (one initial and one additional provision) took around four hours.

[matze]

The update has been applied via hg.adblockplus.org now. Testing is at 50%, and although no box so far seemed to have any trouble with the update, some of them still show the message quoted in the ticket description. I'll try to fix them in the context of #760.

[matze]

I'm closing this issue because I do not consider it an issue any more. Especially because it does not block #760. However, please note that the warnings won't disappear until I publish the changes for that very ticket.

[trev]

It would probably be better to update the dependency on concat module in a separate commit referencing this issue rather than throwing it into #760.

[trev]

Reopening since "fixed" is wrong regardless of what you decide to do, it's either "works for me" or "waiting for the fix."

[matze]

Ok.

[matze]

As discussed in IRC; I'll monitor the upstream (where the entire concat::setup class should disappear soon) for an update. IMHO, we can close this ticket now, especially because all remaining warnings are caused by the concat module itself and we do not plan to manually fix the module when the upstream is planning on doing to itself already.. OK?

[trev]

I think the usual approach is setting externaldependency keyword and leaving the issue open. Does it make sense to update the dependency on concat module regardless or should we only do it once the issue is completely resolved?

[matze]

There is no need to do the update now, we could wait until they report the fix in their changelog. But:

An upgrade, whenever done, requires testing efforts. And this one I've tested excessively. Furthermore, it is always recommended do run updates and the like as often as you can (I don't think I need to examine the arguments for that here). So, since it does not seem to have any negative impact, why should we not upgrade now?

[trev]

Replying to matze:

So, since it does not seem to have any negative impact, why should we not upgrade now?

Feel free to commit a dependency update then, LGTM for that.

[ferris]

concat::setup is not in use anymore.