Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Josh Cooper updated an issue Puppet / PUP-10491 Allow adding descriptive or administrative information to resources Change By: Josh Cooper Team: Phoenix Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.357687.1588699805000.3752.1658869320055%40Atlassian.JIRA.
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Reid Vandewiele commented on PUP-10491 Re: Allow adding descriptive or administrative information to resources Noting for the future: Given that this is fairly trivial to implement (PR is already up), the main consideration for the future is really just what to call it, and what use cases motivate it. If we're waiting for other Puppet products to drive the motivation to decide on a name and merge the PR, I expect that if it comes, it will come from HDP. HDP's analytics and reporting platform is the potential Puppet product benefactor of richer annotations on resources describing their business purpose. If I were confident on the naming I would advocate for merging as-is, but without naming confidence I won't take that position yet. When we're ready, this should be fairly trivial to accomplish. Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.357687.1588699805000.24357.1645812540106%40Atlassian.JIRA.
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Lisa Ross commented on PUP-10491 Re: Allow adding descriptive or administrative information to resources nirupama Reviewed and investing in this part of the platform is not a priority Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.357687.1588699805000.24236.1645811820116%40Atlassian.JIRA.
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title productboard updated an issue Puppet / PUP-10491 Allow adding descriptive or administrative information to resources Change By: productboard productboard URL: https://puppet.productboard.com/feature-board/planning/features/11160860 Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.357687.1588699805000.6135.1639576560048%40Atlassian.JIRA.
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Ciprian Badescu commented on PUP-10491 Re: Allow adding descriptive or administrative information to resources Austin Blatt, Rob Browning , do you have any concerns about increase of data to be saved in puppetdb? Charlie Sharpsteen, what is your view on this feature? Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.357687.1588699805000.151672.1633963320143%40Atlassian.JIRA.
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Gene Liverman commented on PUP-10491 Re: Allow adding descriptive or administrative information to resources Ciprian Badescu - we kinda do but this would be even better. We utilize https://forge.puppet.com/modules/ploperations/profile_metadata, which we own, do accomplish a higher level version of this. We combine that with https://forge.puppet.com/modules/ploperations/meta_motd to show metadata in the message of the day (motd) and also have https://github.com/puppetlabs/infinitory which gives us a web interface to browse this information. These serve us fairly well but an in-built solution would be way better and could easily enhance what we are already doing - I could absolutely see utilizing what is proposed here to enhance one or both of our modules and to enhance infinitory. Feel free to hit me up if you'd like to see a live demo of what this looks like in our environment. Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.357687.1588699805000.149810.1633610820032%40Atlassian.JIRA.
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Ciprian Badescu commented on PUP-10491 Re: Allow adding descriptive or administrative information to resources Gene Liverman, are we using something similar on customer0? Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.357687.1588699805000.149747.1633599000193%40Atlassian.JIRA.
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Ciprian Badescu commented on PUP-10491 Re: Allow adding descriptive or administrative information to resources Moved this to Open so we can discuss it on triage Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.357687.1588699805000.134564.1632207780032%40Atlassian.JIRA.
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title
Reid Vandewiele commented on PUP-10491
Re: Allow adding descriptive or administrative information to resources
Josh Cooper I put a note out to puppet-dev on May 14, 2020, here: https://groups.google.com/g/puppet-dev/c/cDCyp_U8Sv0/m/FiN1EqxWAwAJ. No responses or commentary in that forum. What else needs to happen to move this ticket forward?
Henrik Lindberg that's a good consideration. Type validation is a powerful feature, provides some compelling benefits, and that idea inspires the example below. However, I think use of types needs to be optional, not something that could act as a barrier to entry. To be most useful, annotations need to be very, very easy to use. Users who want type validation could adopt this pattern:
type OurOrg::Annotation =
Struct[Optional[owner] => String[1],
Optional[department] => Enum[operations, support, engineering]]
notify { 'example':
annotation => OurOrg::Annotation({'owner' => 'Riley'})
}
In the proposed implementation, the metaparameter is validated by a type already (Data). If this is a compelling adjustment, we could choose someday to make that configurable. E.g.
annotation_assert_type = Data # default; could set to OurOrg::Annotation instead
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Josh Cooper updated an issue Puppet / PUP-10491 Allow adding descriptive or administrative information to resources Change By: Josh Cooper Sprint: Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.357687.1588699805000.98523.1628028840163%40Atlassian.JIRA.
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Josh Cooper updated an issue Puppet / PUP-10491 Allow adding descriptive or administrative information to resources Change By: Josh Cooper Sprint: Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.357687.1588699805000.98510.1628028780692%40Atlassian.JIRA.
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Josh Cooper updated an issue Puppet / PUP-10491 Allow adding descriptive or administrative information to resources Change By: Josh Cooper Sprint: Community PRs Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.357687.1588699805000.98520.1628028780998%40Atlassian.JIRA.
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title
Henrik Lindberg commented on PUP-10491
Re: Allow adding descriptive or administrative information to resources
A couple of thoughts to make annotations composable is to require that they are set for a specific data type. This way users can both get validation (the value must match the data type), and clashes are avoided, say you want to use more than one annotation. The data type can be a simple alias, but have to exist. For example:
type OurOrg::Owner = String[1]
annotation => { OurOrg::Owner => "Kim Jones" }
Also note that Pcore has the notion of annotation that works in a similar way - there the type must be a kind of annotation, and any Pcore Object can be annotated. Annotations are included in the serialization of a Pcore Object. Puppet has a function to allow users to annotate Objects. In Pcore, you use the annotation type to retrieve the annotation value from the object. This was done so that annotations can have behavior - for example, the value associated with the annotated target could be some kind of identifier and the value may be stored some place else and retrieved from an external source, or it could be some other kind of derived value. Something important to decide on is if annotations should propagate (like tags) or not. The use case "notify an owner if resource failed" kind of implies that it needs to propagate. Just my 2c thrown into the mix.
Add Comment
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Josh Cooper commented on PUP-10491 Re: Allow adding descriptive or administrative information to resources This makes sense to me, overall to the annotation name and not using tags. As this is a foundational kind of feature, could you post what you’ve written up to puppet-dev (if you haven’t already)? Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.357687.1588699805000.151579.1614234300038%40Atlassian.JIRA.
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title
Reid Vandewiele updated an issue
Puppet / PUP-10491
Allow adding descriptive or administrative information to resources
Change By:
Reid Vandewiele
Consider the following use cases.|1 |As a Puppet code workflow designer, I want to my teams to create document-as-you-go annotations in their code for • Business-process identifiers pertaining to configuration items • Human-readable descriptions of configuration items • Responsible party for configuration items So that later when Puppet is is making changes to a system, I can easily look up who, what, and why.||2|As a Puppet content developer, I want to attach ownership information to resources, So my team can be identified and alerted if Puppet has a problem applying my resources.||3|As a change deployment approver, When reviewing changes made in a lower-tier environment to decide if it's ok to promote, I want to consume a high-level summation for the _meaning_ of changes applied to a system, So I can quickly get a sense of what's being done, Without needing to read low-level Puppet implementation code.||4| As a customer receiving a Puppet-managed server as a service, I want to review a *human-readable* list of all “stuff” managed by Puppet on my system, So I can have some understanding of what Puppet is doing.|Currently, we don't have a way to attach any kind of self-documenting information to Puppet content, or produce dynamic reports about what Puppet is doing on a target system based on documentation or annotations written for human consumption.Further, while we have puppet-strings to create self-documenting _code_, we don't have any tooling to create self-documenting _catalogs_ or _reports_—these being examples of artifact outputs produced by the potentially documented code.h2. Feature RequestProvide a solve for use case #1 above, in support of the rest of the use cases.h3. SuggestionA simple way to solve for this would be to add a new, non-operative metaparam, "*annotation*". As a metaparam, "annotation" would be available to specify on any Puppet resource or class. Because it is non-operative and for reporting purposes only, the addition of the metaparam would by itself constitute foundational delivery of this feature.The annotation metaparam could be built on by later PE features to produce polished reports, but would not depend on such a thing to deliver value today.For a customer engagement, a proof-of-concept module has been implemented [here|https://github.com/reidmv/reidmv-annotation]. (Note that the module is more complicated than a built-in integration would be).Example usage:{code:java}notify { 'example': message => 'this is a notify resource', annotation => 'this is some annotation, a description, about it',}file { '/tmp/example.conf': ensure => file, owner=> 'root', metadata annotation => {'description' => ' Metadata Annotation does not need to be a string','product' => 'Example Product','owner' => 'Kelly', },} {code}h3. What about tags?Tags have two
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title
Reid Vandewiele updated an issue
Puppet / PUP-10491
Allow adding descriptive or administrative information to resources
Change By:
Reid Vandewiele
Consider the following use cases.|1 |As a Puppet code workflow designer, I want to my teams to create document-as-you-go annotations in their code for • Business-process identifiers pertaining to configuration items • Human-readable descriptions of configuration items • Responsible party for configuration items So that later when Puppet is is making changes to a system, I can easily look up who, what, and why.||2|As a Puppet content developer, I want to attach ownership information to resources, So my team can be identified and alerted if Puppet has a problem applying my resources.||3|As a change deployment approver, When reviewing changes made in a lower-tier environment to decide if it's ok to promote, I want to consume a high-level summation for the _meaning_ of changes applied to a system, So I can quickly get a sense of what's being done, Without needing to read low-level Puppet implementation code.||4| As a customer receiving a Puppet-managed server as a service, I want to review a *human-readable* list of all “stuff” managed by Puppet on my system, So I can have some understanding of what Puppet is doing.|Currently, we don't have a way to attach any kind of self-documenting information to Puppet content, or produce dynamic reports about what Puppet is doing on a target system based on documentation or annotations written for human consumption.Further, while we have puppet-strings to create self-documenting _code_, we don't have any tooling to create self-documenting _catalogs_ or _reports_—these being examples of artifact outputs produced by the potentially documented code.h2. Feature RequestProvide a solve for use case #1 above, in support of the rest of the use cases.h3. SuggestionA simple way to solve for this would be to add a new, non-operative metaparam, "* metadata annotation *". As a metaparam, " metadata annotation " would be available to specify on any Puppet resource or class. Because it is non-operative and for reporting purposes only, the addition of the metaparam would by itself constitute foundational delivery of this feature.The metadata annotation metaparam could be built on by later PE features to produce polished reports, but would not depend on such a thing to deliver value today.For a customer engagement, a proof-of-concept module has been implemented [here|https://github.com/reidmv/reidmv-annotation]. (Note that the module is more complicated than a built-in integration would be).Example usage:{code:java} notify { 'example': message => 'this is a notify resource', metadata annotation => 'this is some metadata annotation , a description, about it',}file { '/tmp/example.conf': ensure => file, owner=> 'root', metadata => {'description' => 'Metadata does not need to be a string','product' => 'Example Product','owner' => 'Kelly', },} {code}h3. What
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title
Reid Vandewiele updated an issue
Puppet / PUP-10491
Allow adding descriptive or administrative information to resources
Change By:
Reid Vandewiele
Consider the following use cases.|1 |As a Puppet code workflow designer, I want to my teams to create document-as-you-go annotations in their code for • Business-process identifiers pertaining to configuration items • Human-readable descriptions of configuration items • Responsible party for configuration itemsSo that later when Puppet is is making changes to a system, I can easily look up who, what, and why.||2|As a Puppet content developer, I want to attach ownership information to resources, So my team can be identified and alerted if Puppet has a problem applying my resources.||3|As a change deployment approver, When reviewing changes made in a lower-tier environment to decide if it's ok to promote, I want to consume a high-level summation for the _meaning_ of changes applied to a system, So I can quickly get a sense of what's being done, Without needing to read low-level Puppet implementation code.||4| As a customer receiving a Puppet-managed server as a service, I want to review a *human-readable* list of all “stuff” managed by Puppet on my system, So I can have some understanding of what Puppet is doing.|Currently, we don't have a way to attach any kind of self-documenting information to Puppet content, or produce dynamic reports about what Puppet is doing on a target system based on documentation or annotations written for human consumption.Further, while we have puppet-strings to create self-documenting _code_, we don't have any tooling to create self-documenting _catalogs_ or _reports_—these being examples of artifact outputs produced by the potentially documented code.h2. Feature RequestProvide a solve for use case #1 above, in support of the rest of the use cases. h3. SuggestionA simple way to solve for this would be to add a new, non-operative metaparam, "*metadata*". As a metaparam, "metadata" would be available to specify on any Puppet resource or class. Because it is non-operative and for reporting purposes only, the addition of the metaparam would by itself constitute foundational delivery of this feature.The metadata metaparam could be built on by later PE features to produce polished reports, but would not depend on such a thing to deliver value today.For a customer engagement, a proof-of-concept module has been implemented [here|https://github.com/reidmv/reidmv-annotation]. (Note that the module is more complicated than a built-in integration would be). Example usage:{code:java}notify { 'example': message => 'this is a notify resource', metadata => 'this is some metadata, a description, about it',}file { '/tmp/example.conf': ensure => file, owner=> 'root', metadata => {'description' => 'Metadata does not need to be a string','product' => 'Example Product','owner' => 'Kelly', },} {code} h3. What about tags?Tags have two characteristics that make them unsuitable to
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Rob Braden updated an issue Puppet / PUP-10491 Allow adding descriptive or administrative information to resources Change By: Rob Braden Sprint: Coremunity Grooming Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.357687.1588699805000.64719.1589824440037%40Atlassian.JIRA.
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Reid Vandewiele commented on PUP-10491 Re: Allow adding descriptive or administrative information to resources I've managed to come up with one possible reason to prefer "annotation" over "metadata". Recording it here for consideration. In the specific context of Puppet, we've already used "meta-" to describe the general space that a parameter like this exists in. It is literally a meta parameter. In a sense, all of the metaparameters (tag, notify, loglevel) are metadata; just different kinds of metadata. Perhaps the name "annotation" should be preferred as it is a clarification of what metadata is being assigned, and that it is metadata is already communicated by way of the set of parameters, metaparameters, to which it belongs. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.357687.1588699805000.63415.1589555760039%40Atlassian.JIRA.
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Reid Vandewiele commented on PUP-10491 Re: Allow adding descriptive or administrative information to resources I've updated the description quite a bit, and changed the suggested name to "metadata" (reasoning given). Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.357687.1588699805000.63102.1589497020111%40Atlassian.JIRA.
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Reid Vandewiele updated an issue Puppet / PUP-10491 Allow adding descriptive or administrative information to resources Change By: Reid Vandewiele Consider the following use cases.|1 |As a Puppet code workflow designer, I want to my teams to create document-as-you-go annotations in their code for • Business-process identifiers pertaining to configuration items • Human-readable descriptions of configuration items • Responsible party for configuration itemsSo that later when Puppet is is making changes to a system, I can easily look up who, what, and why.||2|As a Puppet content developer, I want to attach ownership information to resources, So my team can be identified and alerted if Puppet has a problem applying my resources.||3|As a change deployment approver, When reviewing changes made in a lower-tier environment to decide if it's ok to promote, I want to consume a high-level summation for the _meaning_ of changes applied to a system, So I can quickly get a sense of what's being done, Without needing to read low-level Puppet implementation code.||4| As a customer receiving a Puppet-managed server as a service, I want to review a *human-readable* list of all “stuff” managed by Puppet on my system, So I can have some understanding of what Puppet is doing.|Currently, we don't have a way to attach any kind of self-documenting information to Puppet content, or produce dynamic reports about what Puppet is doing on a target system based on documentation or annotations written for human consumption.Further, while we have puppet-strings to create self-documenting _code_, we don't have any tooling to create self-documenting _catalogs_ or _reports_—these being examples of artifact outputs produced by the potentially documented code.h2. Feature RequestProvide a solve for use case #1 above, in support of the rest of the use cases.h3. SuggestionA simple way to solve for this would be to add a new, non-operative metaparam, "*metadata*". As a metaparam, "metadata" would be available to specify on any Puppet resource or class. Because it is non-operative and for reporting purposes only, the addition of the metaparam would by itself constitute foundational delivery of this feature.The metadata metaparam could be built on by later PE features to produce polished reports, but would not depend on such a thing to deliver value today.For a customer engagement, a proof-of-concept module has been implemented [here|https://github.com/reidmv/reidmv-annotation]. (Note that the module is more complicated than a built-in integration would be). h2 h3 . What about tags?Tags have two characteristics that make them unsuitable to fully address these use cases.# Tags cannot contain text written for human consumption, such as descriptions or text-form comments due to not allowing spaces and other special characters.# Tags propagate. Especially for long-form comments, it may be desirable NOT to propagate them, as duplication and accidental scope escape can be undesirable.For some use cases the
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Reid Vandewiele updated an issue Puppet / PUP-10491 Allow adding descriptive or administrative information to resources Change By: Reid Vandewiele Consider the following use cases.|1 |As a Puppet code workflow designer, I want to my teams to create document-as-you-go annotations in their code for • Business-process identifier pertaining to configuration items • Human-readable descriptions of configuration items • Responsible party for configuration itemsSo that later when Puppet is is making changes to a system, I can easily look up who, what, and why.||2|As a Puppet content developer, I want to attach ownership information to resources, So my team can be identified and alerted if Puppet has a problem applying my resources.||3|As a change deployment approver, When reviewing changes made in a lower-tier environment to decide if it's ok to promote, I want to consume a high-level summation for the _meaning_ of changes applied to a system, So I can quickly get a sense of what's being done, Without needing to read low-level Puppet implementation code.||4| As a customer receiving a Puppet-managed server as a service, I want to review a *human-readable* list of all “stuff” managed by Puppet on my system, So I can have some understanding of what Puppet is doing.|Currently, we don't have a way to attach any kind of self-documenting information to Puppet content, or produce dynamic reports about what Puppet is doing on a target system based on documentation or annotations written for human consumption.Further, while we have puppet-strings to create self-documenting _code_, we don't have any tooling to create self-documenting _catalogs_ or _reports_—these being examples of artifact outputs produced by the potentially documented code.h2. Feature RequestProvide a solve for use case #1 above, in support of the rest of the use cases.h3. SuggestionA simple way to solve for this would be to add a new, non-operative metaparam, "*metadata*". As a metaparam, "metadata" would be available to specify on any Puppet resource or class. Because it is non-operative and for reporting purposes only, the addition of the metaparam would by itself constitute foundational delivery of this feature.The metadata metaparam could be built on by later PE features to produce polished reports, but would not depend on such a thing to deliver value today.For a customer engagement, a proof-of-concept module has been implemented [here|https://github.com/reidmv/reidmv-annotation]. (Note that the module is more complicated than a built-in integration would be).h2. What about tags?Tags have two characteristics that make them unsuitable to fully address these use cases.# Tags cannot contain text written for human consumption, such as descriptions or text-form comments due to not allowing spaces and other special characters.# Tags propagate. Especially for long-form comments, it may be desirable NOT to propagate them, as duplication and accidental scope escape can be undesirable.For some use cases the
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Reid Vandewiele updated an issue Puppet / PUP-10491 Allow adding descriptive or administrative information to resources Change By: Reid Vandewiele Consider the following use cases.|1 |As a Puppet code workflow designer, I want to my teams to create document-as-you-go annotations in their code for • Business-process identifier identifiers pertaining to configuration items • Human-readable descriptions of configuration items • Responsible party for configuration itemsSo that later when Puppet is is making changes to a system, I can easily look up who, what, and why.||2|As a Puppet content developer, I want to attach ownership information to resources, So my team can be identified and alerted if Puppet has a problem applying my resources.||3|As a change deployment approver, When reviewing changes made in a lower-tier environment to decide if it's ok to promote, I want to consume a high-level summation for the _meaning_ of changes applied to a system, So I can quickly get a sense of what's being done, Without needing to read low-level Puppet implementation code.||4| As a customer receiving a Puppet-managed server as a service, I want to review a *human-readable* list of all “stuff” managed by Puppet on my system, So I can have some understanding of what Puppet is doing.|Currently, we don't have a way to attach any kind of self-documenting information to Puppet content, or produce dynamic reports about what Puppet is doing on a target system based on documentation or annotations written for human consumption.Further, while we have puppet-strings to create self-documenting _code_, we don't have any tooling to create self-documenting _catalogs_ or _reports_—these being examples of artifact outputs produced by the potentially documented code.h2. Feature RequestProvide a solve for use case #1 above, in support of the rest of the use cases.h3. SuggestionA simple way to solve for this would be to add a new, non-operative metaparam, "*metadata*". As a metaparam, "metadata" would be available to specify on any Puppet resource or class. Because it is non-operative and for reporting purposes only, the addition of the metaparam would by itself constitute foundational delivery of this feature.The metadata metaparam could be built on by later PE features to produce polished reports, but would not depend on such a thing to deliver value today.For a customer engagement, a proof-of-concept module has been implemented [here|https://github.com/reidmv/reidmv-annotation]. (Note that the module is more complicated than a built-in integration would be).h2. What about tags?Tags have two characteristics that make them unsuitable to fully address these use cases.# Tags cannot contain text written for human consumption, such as descriptions or text-form comments due to not allowing spaces and other special characters.# Tags propagate. Especially for long-form comments, it may be desirable NOT to propagate them, as duplication and accidental scope escape can be undesirable.For some use cases the
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Reid Vandewiele updated an issue Puppet / PUP-10491 Allow adding descriptive or administrative information to resources Change By: Reid Vandewiele Consider the following use cases.|1 |As a Puppet code workflow designer, I want to my teams to create document-as-you-go annotations in their code for * • Business-process identifier pertaining to configuration items * • Human-readable descriptions of configuration items * • Responsible party for configuration items So that later when Puppet is is making changes to a system, I can easily look up who, what, and why.||2|As a Puppet content developer, I want to attach ownership information to resources, So my team can be identified and alerted if Puppet has a problem applying my resources.||3|As a change deployment approver, When reviewing changes made in a lower-tier environment to decide if it's ok to promote, I want to consume a high-level summation for the _meaning_ of changes applied to a system, So I can quickly get a sense of what's being done, Without needing to read low-level Puppet implementation code.||4| As a customer receiving a Puppet-managed server as a service, I want to review a *human-readable* list of all “stuff” managed by Puppet on my system, So I can have some understanding of what Puppet is doing.|Currently, we don't have a way to attach any kind of self-documenting information to Puppet content, or produce dynamic reports about what Puppet is doing on a target system based on documentation or annotations written for human consumption.Further, while we have puppet-strings to create self-documenting _code_, we don't have any tooling to create self-documenting _catalogs_ or _reports_—these being examples of artifact outputs produced by the potentially documented code.h2. Feature RequestProvide a solve for use case #1 above, in support of the rest of the use cases.h3. SuggestionA simple way to solve for this would be to add a new, non-operative metaparam, "*metadata*". As a metaparam, "metadata" would be available to specify on any Puppet resource or class. Because it is non-operative and for reporting purposes only, the addition of the metaparam would by itself constitute foundational delivery of this feature.The metadata metaparam could be built on by later PE features to produce polished reports, but would not depend on such a thing to deliver value today.For a customer engagement, a proof-of-concept module has been implemented [here|https://github.com/reidmv/reidmv-annotation]. (Note that the module is more complicated than a built-in integration would be).h2. What about tags?Tags have two characteristics that make them unsuitable to fully address these use cases.# Tags cannot contain text written for human consumption, such as descriptions or text-form comments due to not allowing spaces and other special characters.# Tags propagate. Especially for long-form comments, it may be desirable NOT to propagate them, as duplication and accidental scope escape can be undesirable.For some use cases
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Reid Vandewiele updated an issue Puppet / PUP-10491 Allow adding descriptive or administrative information to resources Change By: Reid Vandewiele Consider the following use cases.|1 |As a Puppet code workflow designer, I want to my teams to create document-as-you-go annotations in their code for* Business-process identifier pertaining to configuration items * Human-readable descriptions of configuration items * Responsible party for configuration items So that later when Puppet is is making changes to a system, I can easily look up who, what, and why.||2|As a Puppet content developer, I want to attach ownership information to resources, So my team can be identified and alerted if Puppet has a problem applying my resources.||3|As a change deployment approver, When reviewing changes made in a lower-tier environment to decide if it's ok to promote, I want to consume a high-level summation for the _meaning_ of changes applied to a system, So I can quickly get a sense of what's being done, Without needing to read low-level Puppet implementation code.||4| As a customer receiving a Puppet-managed server as a service, I want to review a *human-readable* list of all “stuff” managed by Puppet on my system, So I can have some understanding of what Puppet is doing.|Currently, we don't have a way to attach any kind of self-documenting information to Puppet content, or produce dynamic reports about what Puppet is doing on a target system based on documentation or annotations written for human consumption.Further, while we have puppet-strings to create self-documenting _code_, we don't have any tooling to create self-documenting _catalogs_ or _reports_—these being examples of artifact outputs produced by the potentially documented code.h2. Feature RequestProvide a solve for use case #1 above, in support of the rest of the use cases.h3. SuggestionA simple way to solve for this would be to add a new, non-operative metaparam, "*metadata*". As a metaparam, "metadata" would be available to specify on any Puppet resource or class. Because it is non-operative and for reporting purposes only, the addition of the metaparam would by itself constitute foundational delivery of this feature.The metadata metaparam could be built on by later PE features to produce polished reports, but would not depend on such a thing to deliver value today.For a customer engagement, a proof-of-concept module has been implemented [here|https://github.com/reidmv/reidmv-annotation]. (Note that the module is more complicated than a built-in integration would be).h2. What about tags?Tags have two characteristics that make them unsuitable to fully address these use cases.# Tags cannot contain text written for human consumption, such as descriptions or text-form comments due to not allowing spaces and other special characters.# Tags propagate. Especially for long-form comments, it may be desirable NOT to propagate them, as duplication and accidental scope escape can be undesirable.For some use cases the propagation
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Reid Vandewiele updated an issue Puppet / PUP-10491 Allow adding descriptive or administrative information to resources Change By: Reid Vandewiele Consider the following use cases.|1 |As a Puppet code workflow designer, I want to my teams to create document-as-you-go annotations in their code for * Business-process identifier pertaining to configuration items * Human-readable descriptions of configuration items * Responsible party for configuration items | So that later when Puppet is is making changes to a system, I can easily look up who, what, and why.||2|As a Puppet content developer, I want to attach ownership information to resources, So my team can be identified and alerted if Puppet has a problem applying my resources.||3|As a change deployment approver, When reviewing changes made in a lower-tier environment to decide if it's ok to promote, I want to consume a high-level summation for the _meaning_ of changes applied to a system, So I can quickly get a sense of what's being done, Without needing to read low-level Puppet implementation code.||4| As a customer receiving a Puppet-managed server as a service, I want to review a *human-readable* list of all “stuff” managed by Puppet on my system, So I can have some understanding of what Puppet is doing.|Currently, we don't have a way to attach any kind of self-documenting information to Puppet content, or produce dynamic reports about what Puppet is doing on a target system based on documentation or annotations written for human consumption.Further, while we have puppet-strings to create self-documenting _code_, we don't have any tooling to create self-documenting _catalogs_ or _reports_—these being examples of artifact outputs produced by the potentially documented code.h2. Feature RequestProvide a solve for use case #1 above, in support of the rest of the use cases.h3. SuggestionA simple way to solve for this would be to add a new, non-operative metaparam, "*metadata*". As a metaparam, "metadata" would be available to specify on any Puppet resource or class. Because it is non-operative and for reporting purposes only, the addition of the metaparam would by itself constitute foundational delivery of this feature.The metadata metaparam could be built on by later PE features to produce polished reports, but would not depend on such a thing to deliver value today.For a customer engagement, a proof-of-concept module has been implemented [here|https://github.com/reidmv/reidmv-annotation]. (Note that the module is more complicated than a built-in integration would be).h2. What about tags?Tags have two characteristics that make them unsuitable to fully address these use cases.# Tags cannot contain text written for human consumption, such as descriptions or text-form comments due to not allowing spaces and other special characters.# Tags propagate. Especially for long-form comments, it may be desirable NOT to propagate them, as duplication and accidental scope escape can be undesirable.For some use cases the
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Reid Vandewiele updated an issue Puppet / PUP-10491 Allow adding descriptive or administrative information to resources Change By: Reid Vandewiele Consider the following use cases.|1 |As a Puppet code workflow designer, I want to my teams to create document-as-you-go annotations in their code for * Business-process identifier pertaining to configuration items * Human-readable descriptions of configuration items * Responsible party for configuration items So that later when Puppet is is making changes to a system, I can easily look up who, what, and why.||2|As a Puppet content developer, I want to attach ownership information to resources, So my team can be identified and alerted if Puppet has a problem applying my resources.||3|As a change deployment approver, When reviewing changes made in a lower-tier environment to decide if it's ok to promote, I want to consume a high-level summation for the _meaning_ of changes applied to a system, So I can quickly get a sense of what's being done, Without needing to read low-level Puppet implementation code.||4| As a customer receiving a Puppet-managed server as a service, I want to review a *human-readable* list of all “stuff” managed by Puppet on my system, So I can have some understanding of what Puppet is doing.|Currently, we don't have a way to attach any kind of self-documenting information to Puppet content, or produce dynamic reports about what Puppet is doing on a target system based on documentation or annotations written for human consumption.Further, while we have puppet-strings to create self-documenting _code_, we don't have any tooling to create self-documenting _catalogs_ or _reports_—these being examples of artifact outputs produced by the potentially documented code.h2. Feature RequestProvide a solve for use case #1 above, in support of the rest of the use cases.h3. SuggestionA simple way to solve for this would be to add a new, non-operative metaparam, "*metadata*". As a metaparam, "metadata" would be available to specify on any Puppet resource or class. Because it is non-operative and for reporting purposes only, the addition of the metaparam would by itself constitute foundational delivery of this feature.The metadata metaparam could be built on by later PE features to produce polished reports, but would not depend on such a thing to deliver value today.For a customer engagement, a proof-of-concept module has been implemented [here|https://github.com/reidmv/reidmv-annotation]. (Note that the module is more complicated than a built-in integration would be).h2. What about tags?Tags have two characteristics that make them unsuitable to fully address these use cases.# Tags cannot contain text written for human consumption, such as descriptions or text-form comments due to not allowing spaces and other special characters.# Tags propagate. Especially for long-form comments, it may be desirable NOT to propagate them, as duplication and accidental scope escape can be undesirable.For some use cases the propagation
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Reid Vandewiele updated an issue Puppet / PUP-10491 Allow adding descriptive or administrative information to resources Change By: Reid Vandewiele Consider the following use cases. # |1 | As a Puppet developer code workflow designer , I want to attach comments my teams to resources, create document-as-you-go annotations in their code for * Business-process identifier pertaining to configuration items So I can export a high * Human - level summary readable descriptions of what configuration items * Responsible party for configuration items |So that later when Puppet is being managed by is making changes to a catalog system, I can easily look up who, what, and why.| # |2| As a sysadmin / change reviewer Puppet content developer , I want to easily identify at a high level what is changing on my system attach ownership information to resources , So I don’t need to understand all the low-level my team can be identified and alerted if Puppet implementation code has a problem applying my resources.| # |3| As an auditor a change deployment approver , When reviewing changes made in a lower-tier environment to decide if it's ok to promote, I want to review consume a *human high - readable* list level summation for the _meaning_ of changes made applied to a system in the last month , So I can verify all audit controls are quickly get a sense of what's being satisfied by done, Without needing to read low-level Puppet implementation code.| # |4| As a manager customer receiving a Puppet-managed server as a service , I want to review a *human-readable* list of all “stuff” managed by Puppet on a given my system, So I can understand have some understanding of what Puppet is doing .| Currently, we don't have a way to attach any kind of self-documenting information to Puppet content, or produce dynamic reports about what Puppet is doing on a target system based on documentation or annotations written for human consumption. Further, while we have puppet-strings to create self-documenting _code_, we don't have any tooling to create self-documenting _catalogs_ or _reports_—these being examples of artifact outputs produced by the potentially documented code. h2. Feature RequestProvide a solve for use case #1 above, in support of the rest of the use cases. h3. Suggestion A very simple way to solve for this would be to add a new, non-operative metaparameter metaparam , " annotation *metadata* ". As a metaparameter metaparam , annotation "metadata" would be available to specify on any Puppet resource or class. Because it is non-operative and for reporting purposes only, the addition of the metaparameter metaparam would by itself constitute a fully functional foundational delivery of this feature. The Puppet feature metadata metaparam could be built on by later PE features to produce polished reports, but would not depend on them being delivered such a thing to deliver value today.For a customer
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title Reid Vandewiele updated an issue Puppet / PUP-10491 Allow adding descriptive or administrative information to resources Change By: Reid Vandewiele Summary: Provide annotation capability for Allow adding descriptive or administrative information to resources Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.357687.1588699805000.62943.1589489040035%40Atlassian.JIRA.
