Closed chewi closed 7 years ago
Neither of these Rubocop errors were flagged up when I ran rake style
locally and only one actually relates to a change I have made.
I've rebased this but haven't got time to retest it right now. Hopefully soon.
@chewi I've merged this. Any chance you can take a Fauxhai dump of XenServer sometime so we can get specs.
Thanks for merging. I'll hopefully be looking at XenServer again soon so I'll get that to you when I can.
XenServer cannot use the usual repository URLs for three reasons.
First, the usual $releasever of 7 is no good because attempting to update to 7.3 causes too many package conflicts when XenServer is currently built around 7.2.
Second, even if $releasever was 7.2 or 7.2.1511, for some reason the mirrorlist script only accepts a release value of 7 so baseurl must be used in order to avoid 7.3.
Last, XenServer doesn't set $releasever to 7 or 7.2 or even 7.2.1511. Bizarrely, it sets it to 7-2.1511.el7.centos.2.10, which isn't much use in any context. This value is not picked up by Ohai so we have to run the rpm command to examine the xenserver-release provider list. The baseurl therefore needs to be set by the recipe rather than the attributes. Making the baseurl resource property lazy prevents us from doing a
nil?
check but that's okay because this property does not have a default value.Although XenServer leaves all the repositories disabled by default, it does exclude certain packages to prevent you from breaking the system if you do decide to enable them. This exclusion list is mirrored here.
This may seem like a lot of hassle for a relatively obscure platform but anyone wanting to use Chef on XenServer will almost certainly need to reconfigure these repositories in order to install anything.