[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Rdo-list] [foreman-dev] [OFI] Astapor, Foreman, Staypuft interaction

On 12 May 2014 14:08, Martyn Taylor <mtaylor redhat com> wrote:
> 1.  Does there currently exist anyway to consistently detect the status of a
> role/list of classes within Foreman for Astapor classes that we can utilize?
>    -. If so can we do this without knowing the implementation details of the
> Astapor puppet modules?  (We do not want to, for example, look for class
> specific facts in foreman, since these vary between classes and may change
> in Astapor)?

This may be a single question, but it can be interpreted two ways, and
thus has two answers.

If you mean "Does Puppet report the status of a class" the answer is
yes. A given puppet report will either contain active changes, or
report "no changes". If you have the latter, you know all your classes
have been checked, and have been found to be in a consistent state. If
you get the former, then you have lines of the form
"Stage[main]/Class::Subclass/File[/etc/foo]: blah" containing the
class name - again, if there are no lines matching your class, it must
be consistent. But all of this is based on the last report - it's not

If you mean "is there an API I can query for the state of a class"
then the answer is no - you can only query the reports.

> 2.  If not 1.  Is is possible to add something to the puppet modules to
> explicitly show that a class/Hostgroup is complete?  I am thinking something
> along the lines of reporting a "Ready" flag back to foreman.

Potentially, yes. If the querying of reports above is not suitable,
then you have three further options, as I see it.

The first two involve the fact that Foreman's report API is pure JSON
- reports don't have to come from Puppet. So you could either (a) have
a chained Exec resource which fires a report in, or (b) you could add
a custom report processor to the deployed puppetmaster that looks for
specific things in the data recieved from the client and then sends
them to Foreman

Third, if you can't make your data fit the report format in Foreman,
or just want to hit a simpler URL, then your plugin could easily add a
new route to the Foreman API which either the Exec or report
processort from (a) or (b) could hit instead of uploading a report.
That might be simpler in the short term, but be careful of security
when implementing new API endpoints.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]