Bug 1299024

Summary: [RFE] Provisioning Templates successful build time stamp
Product: Red Hat Satellite Reporter: Chris Henderson <chenders>
Component: Provisioning TemplatesAssignee: Lukas Zapletal <lzap>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1.5CC: asanders, bkearney, lzap
Target Milestone: UnspecifiedKeywords: FutureFeature, Triaged
Target Release: UnusedFlags: lzap: needinfo? (bkearney)
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-05-25 08:17:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Comment 14 Lukas Zapletal 2018-05-25 07:48:39 UTC
PUBLIC DESCRIPTION:

It would be nice to have some kind of timestamp when a provisioning template does a successful build.

What happens is that you have a provisioning template and you build a server and it is all good. Then you need to make a change to fix something or add something and so you edit the template a few times and in the process break it.
So now you have a broken provisioning template. How do you know when it worked last and what version was it that  worked last?  If you had that timestamp then it would be easier to figure out what had changed since the last working build.

EVALUATION:

Satellite does not archive old version of templates, we do have an audit with changes to. It is feasible to add a last_build_time column to template and set it on successful build.

This BZ was associated with a patch which creates similar column but to host. We can extend it and create similar column for template as well.

Audit can be then used to identify the changes in template.

Comment 15 Satellite Program 2018-05-25 08:05:23 UTC
Upstream bug assigned to lzap

Comment 16 Satellite Program 2018-05-25 08:05:26 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/3861 has been resolved.

Comment 17 Lukas Zapletal 2018-05-25 08:17:39 UTC
FURTHER EVALUATION:

After spending more time on this, it actually does not make much sense to add last_build_time column to templates. We could add last_rendered_time but that will not indicate if provisioning was successful or not. Satellite has no notion of "failed provisioning" state.

We are working on bringing this up as part of upstream ticket http://projects.theforeman.org/issues/21007 but that's only for PXE provisioning and only for particular templates and error cases (error in post scriplet). This has not yet been merged.

There are improvements in this area for 6.4: all templates contents can be configured to appear in production.log or syslog/journald and this can be further integrated with 3rd party logging solutions. Logger named "blob" must be enabled and the following fields are available: template_digest, template_name, template_context, template_host_name and template_host_id.

It does not tell however if provisioning was successful - template stack can't tell this and it depends on provisioning workflow.

For more details: http://projects.theforeman.org/issues/3861

CONCLUSION:

In Satellite 6.4 it will be possible to configure logging stack to find rendered template contents in log/syslog/journal and export it further into 3rd party logging stack for easy visibility.

In Satellite 6.5 we can add "failed PXE" error state to hosts which will indicate when host failed, so it will be possible to pair up template contents from logging using date/time.

However, we plan no further integration of the two features short-term. We specifically do not want to store rendered templates in Satellite database, that would be necessary to add feature this BZ requires.

Since there is a progress and things are getting better in 6.4 and 6.5 timeframe, I am going to close this RFC. We won't work on this particular integration short-term, but it will be possible to dig the information out of the system.