You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.5 (Maipo)
Scenario:
I've been using this cookbook for quite a while to mange LVM volumes and since the moment I switched to chef-client 14.x I notice that every lvm_logical_volume resource gets re-enabled with every chef-client run.
Steps to Reproduce:
# Create PV and VG using lvm_physical_volume and lvm_volume_group respectively
# (skipped for brevity)
lvm_logical_volume "lv_aem_publish" do
group "vg_app"
size "320G"
filesystem "ext4"
mount_point "/opt/aem/publish"
end
The code above produces the following output every single time I execute chef-client:
...
Recipe: cognifide-base::lvm
* lvm_physical_volume[/dev/nvme1n1] action create
* chef_gem[/dev/nvme1n1_di-ruby-lvm-attrib_removal] action remove (up to date)
* chef_gem[/dev/nvme1n1_di-ruby-lvm_removal] action remove (up to date)
(up to date)
* chef_gem[/dev/nvme1n1_di-ruby-lvm-attrib_removal] action remove (up to date)
* chef_gem[/dev/nvme1n1_di-ruby-lvm_removal] action remove (up to date)
* lvm_physical_volume[/dev/nvme2n1] action create (up to date)
* lvm_volume_group[vg_app] action create (up to date)
* lvm_volume_group[vg_backups] action create (up to date)
* lvm_logical_volume[lv_aem_publish] action create
* directory[/opt/aem/publish] action create (skipped due to not_if)
* mount[/opt/aem/publish] action mount (up to date)
* mount[/opt/aem/publish] action enable
- enable /dev/mapper/vg_app-lv_aem_publish
...
You can clearly see that mount's resource enable action got triggered. I took a look at the mount codebase and noticed that there were some changes between chef-client 13.x and 14.x.
To trigger enable action this condition has to be met.
My findings are as follows:
current_resource.enabled - that's definitely true (enabled? method sets that and I can see trace messages regarding /etc/fstab match)
mount_options_unchanged? - sounds like true to me, but read on for more details
device_unchanged? - 100% that's true, as it verifiesdevice property, which stays untouched
To see what gets assigned to current_resource I wrote a custom mount provider which overwrites load_current_resource.
mount_options_unchaged? compares fstype, options, dump and pass properties. As you can see options is nil for the new_resource and ["defaults"] for the current_resource, hence enable action gets re-triggered.
I guess the root cause is the fact that options accepts nil since chef-client 14.x:
only Array and String were accepted in 13.8.5 (reference)
chef-client 14.0.202 accepts Array, String and nil (reference), so default is not assigned
To be honest I don't know whether it should be fixed in the mount resource itself or mitigated in the lvm_logical_volume provider somehow.
Expected Result:
lvm_logical_volume must not apply changes if they're not required.
Actual Result:
mount resource embedded in lvm_logical_volume is executed with every chef-client run.
The text was updated successfully, but these errors were encountered:
Same issue here, similar platforms and versions.
RHEL 7.5
chef-client 14.2.0
lvm cookbook 4.1.13
I've worked around by explicitly adding options: 'default' in the mount_point property
lvm_logical_volume node['some_name'] do
group "vg_#{node['some_name']}"
size '100%VG'
filesystem 'ext4'
mount_point location: node['some_location'], options: 'defaults'
end
Cookbook version
v4.1.12
Chef-client version
Platform Details
AWS EC2 instance running RHEL 7.5
Scenario:
I've been using this cookbook for quite a while to mange LVM volumes and since the moment I switched to
chef-client
14.x I notice that everylvm_logical_volume
resource gets re-enabled with everychef-client
run.Steps to Reproduce:
The code above produces the following output every single time I execute
chef-client
:You can clearly see that
mount
's resourceenable
action got triggered. I took a look at themount
codebase and noticed that there were some changes betweenchef-client
13.x and 14.x.To trigger
enable
action this condition has to be met.My findings are as follows:
current_resource.enabled
- that's definitelytrue
(enabled? method sets that and I can see trace messages regarding/etc/fstab
match)mount_options_unchanged?
- sounds liketrue
to me, but read on for more detailsdevice_unchanged?
- 100% that'strue
, as it verifiesdevice
property, which stays untouchedTo see what gets assigned to
current_resource
I wrote a custommount
provider which overwritesload_current_resource
.Test recipe that mimics
mount
resource fromlvm_logical_volume
implementation (mount_spec assignment and mount resource execution in particular):Custom provider:
The output was as follows:
mount_options_unchaged? compares
fstype
,options
,dump
andpass
properties. As you can seeoptions
isnil
for thenew_resource
and["defaults"]
for thecurrent_resource
, henceenable
action gets re-triggered.I guess the root cause is the fact that
options
acceptsnil
sincechef-client
14.x:Array
andString
were accepted in 13.8.5 (reference)chef-client
14.0.202 acceptsArray
,String
andnil
(reference), so default is not assignedTo be honest I don't know whether it should be fixed in the
mount
resource itself or mitigated in thelvm_logical_volume
provider somehow.Expected Result:
lvm_logical_volume
must not apply changes if they're not required.Actual Result:
mount
resource embedded inlvm_logical_volume
is executed with everychef-client
run.The text was updated successfully, but these errors were encountered: