Re: [foreman-dev] external_node_v2 refactor!

[Dominic Cleal]

On 19/07/16 18:23, otheus uibk wrote:
> https://theforeman.org/manuals/1.12/index.html#3.5.5FactsandtheENC
>  
> briefly describes these functions at the bottom of the section. 
> 
> 
> Thanks for pointing me to the specific doc! The documentation is
> certainly better and more detailed than I expected.
> 
> After, I still don't get:
> 
> * what SETTINGS[:facts] is for.  Here's the comment:
> 
>   # send facts to Foreman - enable 'facts' setting to activate
>   # if you use this option below, make sure that you don't send
> facts to foreman via the rake task or push facts alternatives.
> 
> This looks like process_all_facts but for the given certname only. It
> uploads the facts to the #{url} via the mapped hostname, and then
> downloads them from the given certname. What's the use-case here?  In
> the docs, :facts is always set to true, but I'm not sure it actually
> does anything most of the time. (that might be just our environment, though)

It doesn't download _facts_, it downloads the ENC output. It should be
uploading facts to Foreman, then retrieving the ENC output that contains
lists of classes, parameters etc in YAML, which may depend on the facts
previously uploaded.

This is the normal fact upload method if the ENC is in use, not using
process_all_facts/push.

> * What is no_env for? I see what it does: it removes "environment" from
> the facts that are *reported*. I see what the documentation says about
> it. The questions are (1) shouldn't this be in SETTINGS? and (2) how
> does the presence force puppet to use a particular environment? 

(1) Yes, probably - it pre-dates the settings file.
(2) Agents make two calls to the master during a run that cause the ENC
script to run. The first is an environment ("node") query. If the ENC
script returns an environment then the agent and master will use that
configured environment, ignoring anything the agent has set on the CLI
or in puppet.conf. This allows users to disable that on the Puppet
master by passing --no-environment.

> * Why is the watch functionality incorporated into this script?
> Shouldn't this really be a separate task/script altogether? (I'm
> thinking of partitioning of activities via sudo, for instance)

Perhaps. It's probably just convenience to put them together, given that
this script has all of the code to upload and track facts. If it was
split into many files (e.g. library and binaries) it should probably
also move into a package so it's easier to deploy.

-- 
Dominic Cleal
domi...@cleal.org

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] external_node_v2 refactor!

[otheus uibk]

>
> https://theforeman.org/manuals/1.12/index.html#3.5.5FactsandtheENC 
> briefly describes these functions at the bottom of the section. 


Thanks for pointing me to the specific doc! The documentation is certainly 
better and more detailed than I expected.

After, I still don't get:

* what SETTINGS[:facts] is for.  Here's the comment:

  # send facts to Foreman - enable 'facts' setting to activate
  # if you use this option below, make sure that you don't send facts 
to foreman via the rake task or push facts alternatives.

This looks like process_all_facts but for the given certname only. It 
uploads the facts to the #{url} via the mapped hostname, and then downloads 
them from the given certname. What's the use-case here?  In the docs, 
:facts is always set to true, but I'm not sure it actually does anything 
most of the time. (that might be just our environment, though)

* What is no_env for? I see what it does: it removes "environment" from the 
facts that are *reported*. I see what the documentation says about it. The 
questions are (1) shouldn't this be in SETTINGS? and (2) how does the 
presence force puppet to use a particular environment? 

* Why is the watch functionality incorporated into this script? Shouldn't 
this really be a separate task/script altogether? (I'm thinking of 
partitioning of activities via sudo, for instance)

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] external_node_v2 refactor!

[otheus uibk]

>
> In addition to what Dominic said, I'll throw two more options out there 
> for you:
>
> 1) Most of the developers hang out in #theforeman-dev on Freenode IRC [1] 
> - you're more than welcome to join us to chat about what you're working on.
>

I'm a bit unhappy with using IRC. I don't understand how you can have 
meaningful conversation there that last longer than a few minutes.
 

> 2) What Dominic said about sending pull requests is absolutely fine, but 
> if you feel the need to follow a design process, we do have an RFCs repo 
> [2] which can be used to work on designs. This is not mandatory, but can be 
> handy for detailed discussions.
>

OK

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.