> >
> > > >
> > > > > Hi,
> > > > >
> > > > > I'm working on how we determine the Remote Execution Proxy to use for
> > > > > a
> > > > > particular host. There's currently a bit of magic involved that
> > > wouldn't
> > > > > work
> > > > > in multi-proxy/complex environments well.
> > > > >
> > > > > Full description with screenshots are in this PR, with a new
> > > > > approach:
> > > > > fixes #11554, #11827 - execution proxy through subnet, with load balancing by stbenjam · Pull Request #33 · theforeman/foreman_remote_execution · GitHub
> > > > >
> > > > > Your feedback would be very valuable, particularly:
> > > > >
> > > > > 1. How does this setup feel from a usability perspective? Any
> > > suggestions?
> > > > >
> > > >
> > > > This keeps on coming up in multiple contexts, for example:
> > > > 1. the proxy to use for provisioning/templates
> > > > 2. the puppet master to use (could use multple, not just one)
> > > > 3. the pulp server to fetch content from
> > > > 4. the scap server to send reports to
> > > > …
> > > >
> > > > I feel the location attribute needs to be extended, to resolve per
> > > > proxy
> > > > feature.
> > >
> > > Or just use the subnet?
> > >
> > > I think subnet applies to any of those, as the network segment is
> > > probably the most relevant thing when asking the question "What proxy
> > > should this host talk to?"
> > >
> > > I can see why using locations as an additional layer of abstraction
> > > might be useful - but I think this makes the average user's life too
> > > difficult.
> > >
> >
> > I would probably want to think about this a bit more, somehow the Location
> > "feels" more generic object for this kind of usage cases, and since we have
> > inheritance, it could come in handy (instead of defining it per subnet), it
> > also allows multple proxies vs one.
>
> The PR allows many execution proxies to one subnet, that's the
> foundation of how I pictured us doing HA. It's very simple.
> Taxonomies are not simple, by any means.
>
> >
> > >
> > > >
> > > > >
> > > > > 2. Should you also be able to assign remote execution proxies
> > > > > directly
> > > to
> > > > > hosts? The default action would always be inherit from subnet, but a
> > > user
> > > > > could
> > > > > want in some cases some one-off overrides.
> > > > >
> > > >
> > > > no, but you could let the user select a proxy (as in some advance
> > > > hidden
> > > > place)?
> > >
> > > Ok, I'll look for a good place to hide something like that, any ideas?
> > > Maybe an 'Advanced' button inside the hosts form? Or a tab hidden by a
> > > setting?
> > >
> >
> > I was thinking per job execution vs yet another host property.
> >
> > >
> > > >
> > > > >
> > > > > 3. Are there environments where this setup will not work well?
> > > > >
> > > >
> > > > > 4. Any concerns about integration with Katello?
> > > > >
> > > >
> > > > what exactly do you mean?
> > >
> > > Anything here that might make it difficult for Katello to integrate. We
> > > haven't discussed plugins in detail yet, but it was worth asking now in
> > > case someone saw something obvious.
> > >
> > > One thing was Katello has this "Content Source" selection which is
> > > basically "this host's capsule" - is that relevant for REX? I would say
> > > no and perhaps Katello should use subnets someday, but maybe others have
> > > a different perspective.
> > >
> >
> > Yes, i agree, this is some how the same conversation, I do feel that up
> > until now the flow of lets add another proxy to host/hostgroup (puppet,
> > puppetca, realm, salt, capsule…) was good enough, but i belive its
> > time to build something more generic, maybe with some sort of general
> > purpose abstraction ? for sure we can do better then yet another dropdown
> > in the host creation/edit.
I there a plan on tackling this from all the different angles?
The proposed solution seems to work pretty well for the remote execution
(with question mark on the Katello use-case: that's why we ask the folks
with opinions on the behavior from this side).
Would it make sense to go the simpler solution first (taking the things
that we already have), and looking at the bigger picture, involving
the more generic solution afterwards?
I've felt for some time, that assigning proxies to the hosts directly
doesn't scale. Using subnets seems to work, although one might question,
if the relation between subnets and proxies isn't just accidental?
Maybe a silly question, but couldn't there be even more subnets,
just to achieve the HA on the networking side? Also, we assigning puppet master
or content source to hosts directly. Would it make sense to do so via network,
or would it be a misuse of the object to something that it's not reflecting the reality?
The most important questions for me are:
- wouldn't introducing additional layer make it more complicated for users to understand
- would the new concept be added to the foreman in timely fashion (Foreman 1.10)
From our experience, it's hard to make this kind of changes, that affect the whole core,
without proper justification, corresponding design, discussion and general acceptance.
Things like "we need it for our plugin" are usually not enough.
Therefore, I tent to approve the proposed solution and in the meantime, getting
more folks together from all the areas that touches this topic, to make the effort of
unifying the proxy selection (and maybe they will just agree, that using subnets
makes most sense). From remote execution point of view, it's "just" a question
of one migration, once the new concept is there.
– Ivan
···
----- Original Message -----
> On Wed, Sep 02, 2015 at 09:37:04PM +0300, Ohad Levy wrote:
> > On Wed, Sep 2, 2015 at 9:30 PM, Stephen Benjamin > > wrote:
> > > On Wed, Sep 02, 2015 at 09:11:18PM +0300, Ohad Levy wrote:
> > > > On Wed, Sep 2, 2015 at 8:46 PM, Stephen Benjamin > > > wrote:
Ohad
–
Best Regards,
Stephen Benjamin
Red Hat Engineering
–
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.
–
Best Regards,
Stephen Benjamin
Red Hat Engineering
–
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.
–
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.
–
Best Regards,
Stephen Benjamin
Red Hat Engineering
–
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.
