I am taking this course as an "expert" for feedback purposes. I am being particularly nit-picky because that is what I would want if I asked for feedback :)
- Put the section "title" at the top. Maybe this would only help during the feedback phase, but I had to wait till I got to the next section to find out the title of the first one. (on the back button)
- If the test button is "disabled" there needs to be a reason
- There are several places where it is obvious that rspec is being used (from the errors), but upon success, I get the output
passedwhich really doesn't need to be there. I recommend omitting the "passed" output if that is all there is, stick with the bold text "success" that is already there. In several cases, it might be better to have the puppet output, but in others it is probably not useful. - The "errors" from the rspec-puppet tests made sense to me, but I think for a "Puppet 101" course, rspec-puppet is not going to be useful. There will need to be a more "hands on" approach to helping with coding errors... I am sorry I don't really have any recommendations on how that could be done.
- On the Anatomy of a resource image, it would be better if the image matched the video (owner/group/mode attributes). https://learn.puppet.com/static/images/courses/syntax/363-anatomy-of-a-resource-narrow-2.png
- Obviously the text of the page would also need to be updated to match the image/video if it were changed.
- It was not completely obvious to me that I had to re-type the text in the command line. It looked like it was already there. Perhaps it might be better to make it two lines long where you could have some text that is "above" the prompt instead of needing to click/type over the text. Of course now that I understand the system, it should be obvious.
- The example output for
puppet resource file /etc/motdis strange. Here is what I find on CentOS 7
[root@linux01 ~]# puppet resource file /etc/motd
file { '/etc/motd':
ensure => 'file',
content => '{md5}d41d8cd98f00b204e9800998ecf8427e',
ctime => '2017-08-03 16:55:44 +0000',
group => 0,
mode => '0644',
mtime => '2013-06-07 14:31:32 +0000',
owner => 0,
selrange => 's0',
selrole => 'object_r',
seltype => 'etc_t',
seluser => 'system_u',
type => 'file',
}
vs what was provided:
file { '/etc/motd':
ensure => 'file',
audit => ['ensure', 'content', 'checksum_value', 'target', 'owner', 'group', 'mode', 'type', 'seluser', 'selrole', 'seltype', 'selrange', 'ctime', 'mtime'],
backup => 'puppet',
checksum => 'md5',
checksum_value => ,
content => '{md5}d41d8cd98f00b204e9800998ecf8427e',
ctime => '2018-04-11 21:37:05 +0000',
group => 0,
links => 'manage',
loglevel => 'notice',
mode => '0644',
mtime => '2018-04-11 21:37:05 +0000',
owner => 0,
provider => 'posix',
purge => false,
replace => true,
selinux_ignore_defaults => 'false',
selrange => ,
selrole => ,
seltype => ,
seluser => ,
show_diff => true,
source_permissions => 'ignore',
sourceselect => 'first',
type => 'file',
validate_replacement => '%',
}
Obviously, that output is not from the command puppet resource file /etc/motd (or there are other customizations)? it is also syntactically incorrect in multiple lines.
- On this task, it felt more logical to "edit" the existing code.
- I thought the purpose of the execise would have been to use the
puppet resourcecommand to change the mode?- Maybe something like:
puppet resource file /etc/motd mode='0600'
- Maybe something like:
- Maybe not? I wonder if there needs to be a transition from using
puppet resourceto using a test.pp?
- I liked the concept of this one, but "accidentally" validated the wrong file (/tmp/fixme) and it said success. In fact, the code block is not validating the filename at all. It might be worth checking that the command is correct.
- I really like that we are jumping straight into an example of what needs to be accomplished, rather than continuing to practice on arbitray code (silly examples).
- I personally prefer to not use the "Single-Page" resource type reference page. It makes searching more difficult.
- Perhaps somewhere in the text of the package example, put a link to https://puppet.com/docs/puppet/latest/types/package.html
- For the package example, it lists several "important" attributes, then only has "ensure" in the example code. Perhaps it would be worth adjusting the example or the description.
- It might be worth mentioning that with many (most) resources the "title" becomes the "name" if you don't specify a name.
- It might also be worth mentioning that "source" is only required for certain providers. (RPM or AIX or "windows?")
- It might also be worth mentioning some other providers, sticking with the RHEL example architecture.
- For example: The default provider in Red Hat Enterprise Linux is
yum. Each operating system will have its own default package provider. However, some other package providers are also available, such as rpm, gem, pip, etc.
- For example: The default provider in Red Hat Enterprise Linux is
- This example is somewhat incorrect. The correct package name is
puppet-agent. There does appear to be some sort of "aliasing" going on...
[root@linux01 ~]# puppet resource package puppet
package { 'puppet':
ensure => ['5.3.5'],
}
[root@linux01 ~]# puppet resource package puppet-agent
package { 'puppet-agent':
ensure => '5.3.5-1.el7',
}
... the second one is correct. The example output is incorrect, it does not say ensure => 'installed'.
- I realize this is about puppet code, but it might be useful to do something similar to the parser validate, where there is a Contents of dbserver.pp: (and the code in the editor), and a command line with "puppet apply dbserver.pp" (with the Test button beside it)
- It might be worth listing the name of the package (
httpd) in the instructions. Not everyone who wants to learn Puppet will know that. - There is no reason to require
ensure => 'installed'on a package resource, as it is the default. It should be optional.
- As with above, what is the package name for Robby, that should be listed in the directions
- As with above, no reason to have
ensure => installed
- This seems like a repeat of the first section, with the same errors. See above for feedback on that.
- Perhaps it would make more sense to leave out this repeated example and jump straight to the postgresql config.
- This example is not valid. This code is going to replace the contents of the file with just that single line, not "Add" it.
- Maybe the "NOTE: should be more clear that this exercise is designed to learn syntax, and should not be applied to a postgresql server?
- Please change the wording to "Set the following line as the content attribute..."
- Also, for what its worth, the listen_addresss should just be set to
*, otherwise we need to start talking about facts/variables.
- Again, this example is completely invalid.
- As per above, there should be a note to that effect. This will result in a non-functioning postgresql server.
- As per above it should probably be "Set the following line..." instead of "Add" (which indicates to me that you are adding a line to the file)
- The command output is from
puppet facts, notfacter -pwhich is probably the "recommended" way to look at facts? So, most likely the command needs changed topuppet factsor the output needs corrected, as will some of the followup text. - On a side note, you may want to produce this output on a more simple RHEL/CentOS vagrant machine as to prevent all the leakage of AWS Elastic Beanstalk type info, plus it will keep the "facts" output more simple and straightforward.
- The example code for My hostname: should be
${::hostname}or${facts['hostname']} - Below the task, there is some raw html:
you use a <pre>$</pre> plus <pre>{ }</pre>
- It would not let me click the "Test" button (faded out). I tried with
${osfamily},${::osfamily}and even${facts['osfamily']}. Sadly, it was looking forcontent => "My OS family: $osfamily",... so that needs fixed too.
- Same error as above, except this time it will accept
${hostname}which is probably only a stylesheet violation? It also accepts$hostnamewhich is technically valid, but again, not what we want to be teaching people.
- Suggestion: Change "This resource type manages services running on the node." to "The
serviceresource type manages services running on the node." (perhaps with a link to https://puppet.com/docs/puppet/latest/types/service.html )
- Example output is missing the
enable => true, which would be helpful for the next task.
[root@pe-201735 ~]# puppet resource service puppet
service { 'puppet':
ensure => 'running',
enable => 'true',
}
- "passed" output (see general feedback)
- Really good content here, covers the basics without getting into the weeds. :)
- As noted above, the package name is
puppet-agent. - "passed" output (see general feedback)
- "passed" output (see general feedback)
- Again, really good content here.
- "passed" output (see general feedback)
- "passed" output (see general feedback)
- AWESOME!
- (1:37) The variables should look like
${file_share_path}inside strings on the first example. The video contradicts itself by not doing that the first time. - (2:10-2:13) There is some mis-wording about putting a "variable" in double quotes, when they meant "string"
- (2:30) Here they say you must use curly braces, when they should say "should" (and this is the part that contradicts the first example)
- The directions say to set
$package_nametopostgresql-server, but the code expectsrobby. It is probably simpler to fix the directions than to fix the example and the tests. - "passed" output (see general feedback)
(just links)