Yes - an additional field for each parameter saying it is a "file-property" and not a "standard-parameter". Then you can simply filter the properties already in the "select" phase for most parameters iterations....
On Fri, Jun 16, 2017 at 1:33 AM, Gelinas, Derek <[email protected]> wrote: > So you're suggesting we create boolean parameters as part of this? It's > an interesting notion and I can think of several places in the code where > that would be simpler. > > > > > On Jun 15, 2017, at 2:02 PM, Nir Sopher <[email protected]> wrote: > > > > +1 for Chris suggestion. > > Additionally, can we somehow differentiate "real parameters" from "file > > properties" (like the "no_header" field). For example with one of the > below: > > > > 1. Using a column in the parameters table marking the "properties" > > fields (bool or "type" enum) > > 2. A variable name convention (e.g. a "TC_CONFIG_FILE_PROPERTY:" prefix > > before the parameter name). > > 3. A file name convention (e.g. "TC_PROPERTY:" prefix beforr the file > > name) > > > > It may clarify things to the operator, as well as simplify&generalize the > > code changes needs to be done in some of the parameters iteration > > (identifying the "no_header" parameter and skip it). In the future, if we > > have more such properties (e.g "format"), this area in the code will > > already be covered. > > > > Nir > > > > On Thu, Jun 15, 2017 at 7:25 PM, Chris Lemmons <[email protected]> > wrote: > > > >> What if you did something like this? > >> > >> Parameter name: "header" > >> Config file name: "test_file.config" > >> Value: "none" > >> > >> And then, if you wanted to explicitly change it, you could use: > >> > >> Parameter name: "header" > >> Config file name: "test_file.config" > >> Value: "default" > >> > >> The default, ofc, would be "default", since there's no compelling > reason to > >> go back and add the parameter everywhere automatically. This makes it a > >> little clearer what's going on, and provides a bit of flexibility in the > >> future, should we decide that we need a specialized header for a > different > >> set of files. > >> > >> On Tue, Jun 13, 2017 at 2:26 PM, Gelinas, Derek < > [email protected] > >>> > >> wrote: > >> > >>> We've come across a use case in which we need to create a "take and > bake" > >>> file in traffic ops which cannot have the usual headers automatically > >> added > >>> to configuration files. Rather than hard-code a specific file type > that > >>> should not have these headers into the code, I'm thinking about adding > a > >>> filter during the take and bake process that, if a parameter with the > >>> filename is encountered with the name "no_header", the header will not > be > >>> included. > >>> > >>> In practice, a file without headers would have the following > parameters: > >>> > >>> Parameter name: location > >>> Config file name: test_file.config > >>> Value: /opt/trafficserver/etc/trafficserver > >>> > >>> Parameter name: data > >>> Config file name: test_file.config > >>> Value: rm -rf / > >>> > >>> Parameter name: no_header > >>> Config file name: test_file.config > >>> Value: [value ignored] > >>> > >>> Any thoughts on this? > >>> > >>> Derek > >> > >
