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!
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.
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.
Attachments Open full size
Also requested is a
policy_date
, where the field is a string in ISO-8601 date format, that is parsed and displayed asPolicy Date
in the same format as other date strings in Automate.Attachments Open full size
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.
Attachments Open full size
I can just imagine sitting in a Change Control meeting a reading the SHA to a Project Manager
Attachments Open full size