Thanks for all the comments,
I answered below, I hope it makes more sense.
> > Hello,
> > As posted on the user list we are trying to improve the workflows
> > around parameters usage. The feature team used last sprint to get some
> more
> > feedback, mostly through a survey [1].
>
> Can we have a link to the results?
>
When we have a full summery I'll send it here.
>
> > Taking the results and the existing tracker bug [2] into consideration
> > we divided the refactoring into two steps:
> >
> > First step:
> > 1. Changing Smart class Parameter/Smart variable UI (without touching
> Global
> > Parameters).
> > 2. Moving validations and type casting out of lookup key.
> > 3. Adding the option to hide smart variables values by moving the
> password
> > helper out of global parameters and reusing it.
> >
> > Second step:
> > 1. Finishing UI changes for Smart class Parameter/Smart variable.
> > 2. Merging Smart Variables into Global Parameters which could be
> attached to
> > puppetclass or other objects.
> > 3. Basic editor for yaml/json values.
> >
> > All of the expected UI changes can be seen in [3] (thanks to Kyle!).
>
> Some comments based on these slides:
>
> Slide 3: "Global Parameters" is completely separate to class
> parameters, and ends up in a different part of the ENC. Thus the
> "current workflow" on slide 3 is wrong - the true case is actually as
> depicted on slide 4. Global parameters (at any level, be that Host,
> Hostgroup, Domain, OS, or Common) are modified independantly of class
> paramaters. (EDIT: I see Stephem noticed this too ;P)
> Slide 5, Note 2: I agree that Smart Variables is outdated. However,
> I'd like to see the multi-type options available to class parameters
> (hash, yaml etc) be available in global parameters too, so we should
> remove the requrement for smart variables to have a base class, and
> instead use the smart variable code paths for global params.
>
That is what we wanted and it can be seen on the last slide in global
parameters.
The connection to puppetclass on slide 3 and the two last slides should be
removed.
These are leftovers from smart variables as they look today and shouldn't
have been shown
in global parameters, thanks for noticing.
>
> Slide 5, Note 3: How will a user stop the ENC containing a parameter?
> That's the function of the override flag (and the use-puppet-default
> flag) and they seem to be missing. I don't want that to be a
> regression…
>
The reasoning was that use puppet default prevents from sending the default
and also checking if the user changes the default or not.
The only issue is the default, if overrides where added it's as if the
override checkbox was clicked.
Maybe this should be in the next step of changes and not right away,
the idea was to eliminate the need for the override all button and maybe
get some unexpected results.
>
> Slide 6: Fully agree with moving optional stuff to the end.
>
> Slide 7: I like the wireframe here, class filtering is a good idea.
> Note 4: Add Parameter is fairly useless as a button on the Class
> Parameter page, as it adds a Global Parameter (unless you're planning
> on allowing overrides to be added from this page, which would be
> awesome but I suspect a lot of work). We don't see a wireframe for the
> Global tab, but if the Source Column is there it should say "Host" not
> Custom, as it's a host level parameter (as compared to hostgroup, os,
> domain etc)
>
I agree, the button should be moved to Global Parameter and it can say host.
The hostgroup there should show these parameters were inherited from the
hostgroup.
I guess we should change it to inherited or maybe just add them as normal
class parameters
and in the additional info put a comment about it.
>
> Slide 8: again we see a conflation of global and class parameters -
> the page is called "Global Parameters" but the table contains class
> parameters. Whats the intention here? I do like the revamp of the
> class parameter display though.
> Slide 9: again the conflation - what are class-related fields doing on
> a global parameter page?
>
I responded to both above - this wasn't the intention and it will be fixed.
>
> Overall I think we're going in the right direction (thanks Kyle!), but
> I'd like to see either (a) an explanation of the thinking behind the
> conflation of global and class params (their separate in the ENC, I'm
> not sure I like the idea of blurring that in Foreman), or (b) a
> re-examination of the base assumptions (slides 2/3/4) that lead to
> this UI, if the conflation was accidental.
>
They will be separate. I'll try to explain the parts of global parameters
that are missing from the wireframes.
The reasoning was to merge smart variables and global parameters.
We want to keep the global parameters functionality (adding it from
domain/os… and now from puppetclass)
and the smart variable backend (without the connection to puppetclass that
shouldn't be there).
Instead of the current STI for parameters we want the meaning of adding a
global parameter to be
adding another matcher. Instead of adding a DomainParameter just add a
domain=example.com matcher
to a global parameter. All the existing parameters will be migrated into
matchers for a global parameter.
···
On Thu, Apr 16, 2015 at 6:38 PM, Greg Sutcliffe wrote:
> On 16 April 2015 at 14:44, Ori Rabin wrote:
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
