Setting Default_parameters_Lookup_Path naming has a capitialization consistency nit

Development
1

While looking at the output of “hammer settings list --fields Name,Value” on Foreman 2.1.0rc3, I noticed that one setting name stood out from the others (if you ignore the the PXE entries). That was “Default_parameters_Lookup_Path” as it uses partial title case in its name - no other setting name does (excluding the aforementioned PXE entries, in which all but three use uppercase - as it an initialism). I was going to ignore it, bit a recursive grep of the foreman repositories, suggests that it is new to v2.1, so I though I would mention it.

Looking at grep(1) results (file list included at the end of this post), if we assume the documentation is generated, then the fix is limited to the foreman repository.

The fix may be as simple as:

cd foreman
grep -r -i Default_parameters_Lookup_Path    
sed -i -e 's/Default_parameters_Lookup_Path/default_parameters_lookup_path/' $(grep -r -l Default_parameters_Lookup_Path)
git diff

I realize the v2.1.0 release is currently almost complete according to Foreman 2.1.0 release process, but I thought it was worth mentioning as consistency is a marker of quality in software (IMHO).

Regards,
Peter

foreman/app/models/lookup_keys/lookup_key.rb
foreman/app/models/setting/puppet.rb
foreman/db/migrate/20200324210540_rename_default_variable_lookup_path.rb
foreman/test/fixtures/settings.yml
theforeman.org/api/2.1/apidoc/v2/settings.en.html
theforeman.org/api/2.1/apidoc/v2/settings.html
theforeman.org/api/2.1/apidoc/v2/settings/index.en.html
theforeman.org/api/2.1/apidoc/v2/settings/index.html
1 Like
2

Thanks for noticing and bringing this up!
Unfortunately, it is too late to fix for 2.1, but would you like to open a pull request to fix it for 2.2? This can be a great chance for a first contribution to the project.
Since the current name will be in a released version, you will need to create another migration to rename the setting, similar to foreman/db/migrate/20200324210540_rename_default_variable_lookup_path.rb. This can be done by running e.g. rails generate migration RenameParameterPath and editing the created file accordingly.
For more information on setting up a development environment and our coding guidelines take a look at Contributing Code and Foreman Handbook.

2 Likes
3

Given I have no experience in Ruby and thus Rails and its development environment, this will be quite the learning experience (I have a [C++/Java]/C/Shell/Perl background), and not something I can commit to at the moment; as I wish to get my Foreman server and remote Smart-Proxy up and going, to work on actually provisioning some systems :-). But if time permits I’ll look into it.

I’m currently merging the notes, I have taken on building Foreman 2.1.0rc* (on CentOS 7 & 8) on the command line into a single readable document, and extending it to cover setting up provisioning (principally via the CLI). So I can reproduce my Foreman systems, if/when required (especially given "foreman-maintain backup" fails on CentOS8 / Foreman 2.1.0rc* - Multiple Issues) and determine if and how to automate its construction further down the line. My initial provisioning testing was done via the WebUI on 2.1.0rc1, and I have learnt a lot since that work.

Once I have a Foreman 2.1.0 (non-rc*) system up and successfully provisioning systems, I would like to post that write-up to the community, as way to document my adventure (and receive feedback on it correctness), for those who may embark on such a journey in the future. [ “Pass on what you have learned.” – Yoda ]

Which given my current very positive view of the Foreman, I hope others will discover Foreman, and get their first Proof-of-Concept going and more importantly, their understanding of the Foreman ecosystem embedded a little more quickly than I did (maybe I’m getting old :wink: ). But at least now, I can say I have read most (but probably not all) of the product documentation :slight_smile:. You may have noticed from my posts, that I have actually been trying to treat Foreman as product (or blackbox), and not dive deeply under the covers - but as a programmer there is always the desire to dive in - I have been trying to suppress that. [ But: "Impossible to see the future is.” – Yoda ]

2 Likes
4

I think this summary would make a great blog post and I would be very happy to read it and share it further afield for new users getting started with Foreman 2.1.0. Looking forward to it!

5

While a bit off topic, I wonder if you tried automating it with Ansible instead?
We have a rather extensive collection of Ansible modules (documentation) that can help you with configuring Foreman after the initial installation happened. (Blog post 1 and post 2 could also help diving into this).

Writing a blog post about provisioning with the Ansible Modules is high on the wish list of a few people (hi @mcorr once more! :wink: )

1 Like
6

Ansible is my intended automated platform, but I’m guessing, most new users will want to try out Foreman, understand if its suitable for their environment; before committing to using it and automating its deployment. I have seen the Ansible modules announcement, you referred to and quickly looked at the modules during my earlier investigation.

But my thinking is, that you don’t start learning a product you hope to use regularly, by viewing it through another level of abstraction (that tools like ansible and puppet produce). As this could lead to misjudging a product, based on limitations or misunderstandings imposed by the author of the automation procedure (*1). Given that what I do is automation, I have seen plenty of automation procedures that did not create a good abstraction or that weren’t consistent with the underlying product’s terminology, and you do (in my opinion) have to understand a product before automating it.

So don’t worry, I hope get to the mentioned Ansible modules, but I thought it reasonable share what I have learnt along the way. As I have seen commented on, in this community site and its references to other posts online; getting started with Foreman may not be the easiest task (*2). But now having done a lot the reading and gotten a basic handle on the Foreman ecosystem, I thought a write-up from a different perspective, using mostly the command line and a concrete example configuration (one main site and one offsite location), may be of value to others who come after me.

I suppose what I wanted coming in, was a practical worked (and working) example of how to design and setup Foreman, with enough of a hands-on introduction, that I would better understand the available documentation. Because, knowing what I know now, the documentation is quite good, but I do understand where those negative sentiments expressed by others, may have come from.

There are couple of times in my career, where I have seen great technology dismissed by the majority, not because the documentation wasn’t good, but because it was great for someone who already understood the product / concepts, but somewhat impenetrable to those who do not (or don’t put in the effort and read more, to get that understanding). That also happens in many UNIX/Linux manual pages as well.

Regards,
Peter

(*1) this not a comment on the mentioned module - I have not looked into it, in detail yet. As I didn’t have (or felt I had) the background knowledge of the product itself, to evaluate it. That’s what I consolidating now by doing the write up (/merge of notes taken) and extending on what I have learnt about Foreman by reviewing previous methods/comments/assumptions/conclusions.

(*2) and I have extensive experience with the provisioning tools, that I hope Foreman and its Smart-Proxy will manage for me in the future.

2 Likes
7

I would like to disavow any notion that it might be a summary, a worked example might be closer to the truth, its already quite long. But maybe parts could be extracted to make a more general summary.

1 Like
8

No pressure :slight_smile: