Closed DavidS closed 7 years ago
Of course, unit tests are failing. If you can :+1: the general approach, I'll fix those up and add implementation for v3 versions.
I see more complications than benefits here, and I like the idea of having service and package resources showing the actual names used for different os. To have the same behaviour it should be enough to add : alias => $name, to service and package resource, this should both needs. What do you think?
Sadly, aliases are not as powerful, as you think they are:
$ cat manifests/tp.pp
class rspec::tp {
notify { "test1": alias => "foo1" }
notify { "test2": alias => "foo2" }
notify { "test3": alias => "foo3" }
notify { "test4": alias => "foo4" }
notify { "test5": alias => "foo5", require => Notify["foo4"] }
Notify["test1"] -> Notify["foo2"] -> Notify["test3"]
}
include rspec::tp
$ bundle exec puppet apply manifests/tp.pp --verbose
Error: Could not find resource 'Notify[foo2]' for relationship from 'Notify[test1]' on node .....
$ bundle exec puppet --version
4.4.1
$
Uhm that's bad, I was convinced that aliases could be used for resources references. Let me ponder on the thing, I also wonder how painful could it be to actually refer packages / services with their real namme, according to the OS (tp_lookup function can be used to query tiny data accordingly)
Just released tp 2.0 This won't apply there, so closing it. Package and services names are still the actual ones and not the ones matching the tp install title. tp already manages all the dependencies, if tp defines are used, to refer to packages or services from outside tp, there are 2 alternatives:
This allows the following usage:
without having to know anything about the underlying OS and data, when tp::conf and tp::dir do not suffice.