Hey all, I submitted this to the Foreman users group originally, but
thought it may be better suited here in foreman-dev.
The changes to fqdn in Foreman 1.8.0, and a side effect of the issues I ran
into as part of Bug #10403: Smart Class Parameter Overrides using the FQDN fact as a match no longer applies the override - Foreman, made me begin
to consider how matchers on host level overrides are being handled;
especially since a host can have multiple nics with varying names.
Currently overriding a parameter on a host level creates the match value
pair of:
fqdn="somefqdn.example.com", value="some value"
With the changes to fqdn in Foreman 1.8.0, I think that it makes more sense
for host level overrides to create the match based on either name or
certname as they are most intuitive to the action you are wanting to
perform. So you would then end up with 1 of the 2 match/value pairs.
name="nameinforeman", value="some value"
certname="hostcertname", value="some value"
You can currently do this from the Puppetclass level, but the default when
performing it on the host level is to assign the match/value pair to the
fqdn, which feels a little off now in 1.8.
I could also see this being useful for the Run Puppet button, where it uses
the name/certname instead of the fqdn as well.
What are your thoughts on this? What would be some underlying complications
that I may be missing?
Hello,
sending some comments inline
> Hey all, I submitted this to the Foreman users group originally, but
> thought it may be better suited here in foreman-dev.
>
>
> The changes to fqdn in Foreman 1.8.0, and a side effect of the issues I ran
> into as part of Bug #10403: Smart Class Parameter Overrides using the FQDN fact as a match no longer applies the override - Foreman, made me begin
> to consider how matchers on host level overrides are being handled;
> especially since a host can have multiple nics with varying names.
> Currently overriding a parameter on a host level creates the match value
> pair of:
> fqdn="somefqdn.example.com", value="some value"
>
> With the changes to fqdn in Foreman 1.8.0, I think that it makes more sense
> for host level overrides to create the match based on either name or
> certname as they are most intuitive to the action you are wanting to
> perform. So you would then end up with 1 of the 2 match/value pairs.
> name="nameinforeman", value="some value"
> certname="hostcertname", value="some value"
I think that fqdn is still usable as it used to be before (with the fix for
unmanaged hosts, thanks Dominic!). fqdn is delegated to primary interface so
not much should change in this area if I don't miss something obvious.
> You can currently do this from the Puppetclass level, but the default when
> performing it on the host level is to assign the match/value pair to the
> fqdn, which feels a little off now in 1.8.
>
> I could also see this being useful for the Run Puppet button, where it uses
> the name/certname instead of the fqdn as well.
>
>
> What are your thoughts on this? What would be some underlying complications
> that I may be missing?
But using the fqdn or any other text based value certname, name) for
associations does not seem great to me. I think we should on backend rather
use foreign keys like host_id. Not only it would make the matching faster but
would be less prone to typos. The way how we present this in UI is detail (if
we get fqdn, certname or whatever) of associated host.
One disadvantage of using foreign keys is that it would make things like
fqdn=*.example.com more complicated. We don't support it today AFAIK but seems
like it would complicate it even more. So my question is whether we want to
support such complicated overrides (I vote for no, since it's complicated
enough already).
···
On Wednesday 13 of May 2015 06:24:56 Ryan Sabatini wrote:
–
Marek
> The changes to fqdn in Foreman 1.8.0, and a side effect of the issues I
> ran into as part of Bug #10403: Smart Class Parameter Overrides using the FQDN fact as a match no longer applies the override - Foreman
> <Bug #10403: Smart Class Parameter Overrides using the FQDN fact as a match no longer applies the override - Foreman>, made me begin to consider
> how matchers on host level overrides are being handled; especially since
> a host can have multiple nics with varying names. Currently overriding a
> parameter on a host level creates the match value pair of:
> > fqdn="somefqdn.example.com
> <http://somefqdn.example.com/>", value="some value"|
>
> With the changes to fqdn in Foreman 1.8.0, I think that it makes more
> sense for host level overrides to create the match based on either name
> or certname as they are most intuitive to the action you are wanting to
> perform. So you would then end up with 1 of the 2 match/value pairs.
> >
> >name="nameinforeman", value="some value"|
> certname="hostcertname", value="some value"|
>
> You can currently do this from the Puppetclass level, but the default
> when performing it on the host level is to assign the match/value pair
> to the fqdn, which feels a little off now in 1.8.
>
> I could also see this being useful for the Run Puppet button, where it
> uses the name/certname instead of the fqdn as well.
Yeah, I do agree. I'd like to see the 'fqdn' removed entirely, as I
think in 1.8 it has little or no value now, except to confuse matters
and create bugs that affect only these two specific features.
This probably does mean moving to overriding based on 'name' because
'fqdn' specifically calls Host::Managed#fqdn, or as an interim step,
alias #fqdn to #name.
The hostname related methods on Host::Managed and Nic::* are a bit of a
mess in general, and now the network details moved into NICs in 1.8, now
would be a good time to start tidying it:
http://projects.theforeman.org/issues/10425
···
On 13/05/15 14:24, Ryan Sabatini wrote:
On 14/05/15 08:47, Marek Hulan wrote:
But using the fqdn or any other text based value certname, name) for
associations does not seem great to me. I think we should on backend rather
use foreign keys like host_id. Not only it would make the matching faster but
would be less prone to typos. The way how we present this in UI is detail (if
we get fqdn, certname or whatever) of associated host.
This is very appealing, text is very fragile.
–
Dominic Cleal
Red Hat Engineering
> Hey all, I submitted this to the Foreman users group originally, but
> thought it may be better suited here in foreman-dev.
>
>
> The changes to fqdn in Foreman 1.8.0, and a side effect of the issues I ran
> into as part of Bug #10403: Smart Class Parameter Overrides using the FQDN fact as a match no longer applies the override - Foreman, made me begin
> to consider how matchers on host level overrides are being handled;
> especially since a host can have multiple nics with varying names.
> Currently overriding a parameter on a host level creates the match value
> pair of:
> fqdn="somefqdn.example.com", value="some value"
>
> With the changes to fqdn in Foreman 1.8.0, I think that it makes more sense
> for host level overrides to create the match based on either name or
> certname as they are most intuitive to the action you are wanting to
> perform. So you would then end up with 1 of the 2 match/value pairs.
> name="nameinforeman", value="some value"
> certname="hostcertname", value="some value"
>
> You can currently do this from the Puppetclass level, but the default when
> performing it on the host level is to assign the match/value pair to the
> fqdn, which feels a little off now in 1.8.
>
> I could also see this being useful for the Run Puppet button, where it uses
> the name/certname instead of the fqdn as well.
>
>
> What are your thoughts on this? What would be some underlying complications
> that I may be missing?
I can see name being a better default as well. Particularly unmanaged
hosts with no network configuration could use it too. Right now they use
a fake fqdn if I recall correctly, which is not ideal.
···
On 05/13, Ryan Sabatini 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.
–
Daniel Lobato Garcia
@eLobatoss
blog.daniellobato.me
daniellobato.me
GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
Keybase: https://keybase.io/elobato
While i generally agree, I'm not sure about make it faster part, a few
optimizations are already in place, and we see the enc data calculation
time goes between each ruby version ( i saw about 100% speed improve from
1.9 to 2.2 for example).
···
On Thu, May 14, 2015 at 11:58 AM, Dominic Cleal wrote:
fqdn or any other text based value certname, name) for
associations does not seem great to me. I think we should on backend
rather
use foreign keys like host_id. Not only it would make the matching
faster but
would be less prone to typos. The way how we present this in UI is
detail (if
we get fqdn, certname or whatever) of associated host.
