Chef Ideas

We believe that the best way to build software is to do it in close collaboration with the people who use it. We invite you to submit your ideas using the form below. Please be sure to include the problem for which you are solving and the benefits of implementing the idea.

We do our best to implement as many Ideas as we can. Our Product team will evaluate all submitted ideas in a timely manner and will disposition each into one of the following categories: will integrate into the product roadmap, further research is needed, unlikely to implement.

Thanks for collaborating with us!

Add optional `policy_version` to infrastructure header

Many orgs use CI/CD to build policyfiles. Many of those have a build version (1.2.3) for each policy_revision (hash).

Allow orgs to define a policy_version string in their policy that has the build-system policy version associated with the hash. If this attribute is present on a node, display it as "Policy Version" in the METADATA section of the Client run in the Infrastructure tab in Automate, underneath the "Policy Revision" hash.

This is a free-form field and is for display and user purposes only.

  • Ken MacLeod
  • May 7 2021
  • New
  • Attach files
  • Ken MacLeod commented
    20 Jan 01:53pm

    Cc from Chef Success #chef-automate:

    Ankur Mundhra @kmacleod Are you suggesting to display revision id of a policy file as x.y.z?

    kmacleod @Ankur Mundhra No, the revision ID remains unchanged and I am not asking for Chef to add Semantic Versioning to the chef install command. These are attributes a user adds to a policyfile themselves, and it gets passed in builds and appears in policyfile.lock.json that get pushed to policy groups. Once the attributes appear on a node in Automate, then Automate displays the values in the header, under the existing policy revision and policy name.

    kmacleod More clearly, after this change up to five policy values appear on a node in the "METADATA" section of the page header in the Infrastructure tab: Policy Group, Policy Name, Policy Revision, Policy Version, and Policy Date. The last two can either be empty or not shown at all if their corresponding attribute is not set on the node.

  • Ken MacLeod commented
    19 Jan 09:32pm

    Also requested is a policy_date , where the field is a string in ISO-8601 date format, that is parsed and displayed as Policy Date in the same format as other date strings in Automate.

  • Jeff Dean commented
    1 Dec, 2021 03:33pm

    Without some sort of version representation within a Policy I don't know if we'll ever be able to use them. Our Change Control folks would not allow unversioned releases.

  • Karl Fischer commented
    28 May, 2021 01:54pm

    I can just imagine sitting in a Change Control meeting a reading the SHA to a Project Manager