(PUP-1628) Fix mount provider for AIX#3740
Conversation
9e0df65 to
779cf2d
Compare
|
CLA signed by all contributors. |
|
Limitations:
|
|
Hello Hunner, I've patched my parsed.rb and mount.rb with these changes. What I'm seeing is that for "nodename" in /etc/filesystems the value is the entire string which is defined in the manifest "hostname:device" where it should just be "hostname". Here is the string from the "nodename" property of the mount resource: '/someplace': So our /etc/filesystems look like this now: Wrong: /someplace: Should look like: /someplace: |
7b05b6f to
b0f17a4
Compare
lib/puppet/provider/mount/parsed.rb
Outdated
There was a problem hiding this comment.
This should be turned into logic, not a scary regex.
|
Ok, so this works great. Could you make one cosmetic change and put in one blank before each entry you put in /etc/filesystems? |
|
@helperton Blank lines and comments are preserved across updates, so if you have blank lines before each entry, they should stay there. I'd rather not enforce blank lines before every entry, as some users may not prefer that style. Is that okay? |
|
I think it's a requirement by IBM Filesystems are mounted at AIX boot time in the order they appear in /etc/filesystems. Filesystems are added to /etc/filesystems in the order they are defined. The easiest way to change the order in which filesystems are mounted is to edit /etc/filesystems and change the ordering of the filesystem stanzas. (But be careful to maintain a blank line between each stanza. If blank lines are removed, some filesystems won't get mounted at boot time!) |
|
@helperton I read that three times and I'm still somewhat baffled. What do the blank lines signify? That advice says not to remove blank lines but not what they mean. It sounds like this is not a cosmetic change so I'm curious how it actually works. |
|
Ya, I thought it was cosmetic until I found that article. I was suspicious that all of our /etc/filesystems have that blank line, then when I looked at examples of /etc/filesystems on the internet I found those too, have the blank line. Then I found the IBM article. |
|
Here's another article which talks about the blank line (still doesn't answer your question). http://bio.gsi.de/DOCS/AIX/2x/faqssoft.html Looks like an IBM/AIX thing. They use this same format in other files as well. This one too mentions no blank line being a problem: http://ps-2.kev009.com/tl/techlib/qna/sfam/html/AC/AC3400L.htm |
|
I can't find anything about it, but the examples I found have a blank line between stanzas. So probably better safe than sorry .... Also in the surprising-to-a-non-AIX-admin department:
which I found in http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.files/filesystems.htm |
|
@helperton Oooo, okay. I'll update the PR with blank lines then. Thanks! |
The way that AIX tracks its mounted filesystems is different than other unix or linux operatingsystems. AIX uses /etc/filesystems and has entirely different filesystem options. This commit takes advantage of two parsedfile hooks, `post_parse` and `to_line`, to read & generate /etc/filesystem entries. Parsedfile was not created with arbitrary-ordering in mind, and any /etc/filesystem entries will have their attributes reordered by `to_line` Options in AIX without related properties in Puppet's mount type are placed under the "options" property. The specs I wrote for instances work, but there are many other failures when running specs on AIX. This PR doesn't include specs for `to_line`
The regex worked, but any comments or blank lines in the middle of a stanza would end the stanza parsing resulting in a malformatted file. Plus it was not easy to read or debug. This updates the "parser" to use simple state when parsing the file and does not barf on comments or blank lines in the middle of stanzas (though they will be moved to the end of the stanza to avoid edge cases on file regeneration).
Also handle trailing spaces on the resource name, and cases when device is malformatted nfs mounts
1b5671e to
1fb6f56
Compare
|
Newlines updated. The only issue I've seen still occurring is the The mount type previously just ran an unmount & mount instead of a remount, but this PR changes the default to do remount... How should this be solved?
|
|
Ok, so it did fix the newline issue, but we now seem to have some issue with the option ordering and it saying that it's updated the options, but it's not actually reflected in /etc/filesystems. During the puppet run: Info: Retrieving pluginfacts It keeps saying that it's changing the options, but it doesn't actually change them in the file, so the next puppet run outputs the exact same thing again. |
|
@helperton Okay. I was sorting the list of options returned from /etc/filesystem (which is why it returned However, some "options" (account, boot, check, free, mount, size, type, vol, log, and quota) are passed to the mount type via the |
|
Bravo! Works. |
|
@hunner if this is going to get into Puppet 3.8, could you retarget this pull request against the 3.x branch? The stable branch now corresponds to 4.0 and master to 4.1. |


The way that AIX tracks its mounted filesystems is different than other
unix or linux operatingsystems. AIX uses /etc/filesystems and has
entirely different filesystem options.
This commit takes advantage of two parsedfile hooks,
post_parseandto_line, to read & generate /etc/filesystem entries. Parsedfile wasnot created with arbitrary-ordering in mind, and any /etc/filesystem
entries will have their attributes reordered by
to_lineOptions in AIX without related properties in Puppet's mount type are
placed under the "options" property.