On Wed, Mar 22, 2017 at 04:44:51PM +0000, Sean O'Keeffe wrote:
> On Wed, Mar 22, 2017 at 1:40 PM, Ewoud Kohl van Wijngaarden <
> ew...@kohlvanwijngaarden.nl> wrote:
> 
> > On Mon, Mar 20, 2017 at 03:50:30PM +0000, Sean O'Keeffe wrote:
> > > On Mon, Mar 20, 2017 at 2:25 PM, Lukas Zapletal <l...@redhat.com> wrote:
> > > > Can you elaborate more on motivation? Multi-homed proxy is still one
> > > > instance, why would
> > > > Foreman need to reach to it in two different ways?
> > >
> > > This is for clients to reach a proxy in the different ways, NOT foreman.
> > >
> > >
> > > > Isn't the result always the same (a change on the same instance)? How
> > > > about relaxing
> > > > the constraing when each individual proxy must have unique URL? Just
> > > > checking before introducing another table (more SQL joins and query
> > > > complexity).
> > > >
> > > If a Host / HostGroups can be assigned a URL/Hostname instead of a proxy
> > > its useful for Multi-homing, loadbalancing & NAT'ed environments, maybe
> > > others?
> > > What does relaxing the unique URL constrain actually give us? I think if
> > > you have 2 proxies with the same URL that's just effectively duplicating
> > > the object?
> > >
> > > Or if you mean creating 2 proxies with different URLs (an external & and
> > > another internal one) I think would be problematic when Foreman needs to
> > > talk to the Proxy. E.g Host needs to talk to proxy1-external.example.com
> > > but foreman must talk to the proxy via proxy1-internal.example.com. If
> > we
> > > have 2 proxies in foreman ( proxy1-internal & proxy1-external ) and you
> > > assign a host proxy1-external foreman would try to connect to
> > > proxy1-external.example.com to create a DHCP or DNS or something else
> > with
> > > would not work.
> >
> > I think a different URL for clients and Foreman itself makes a lot of
> > sense. Now I have some trouble reading the design from the code. Could
> > you describe how this would be used by a user? Maybe a screenshot from
> > the new configuration page.
> >
> 
> Sure,
> 
> I've added another tab to the Smart Proxies form, where you can add
> "Secondary URLs". On the Host/Hostgroup from the user can then select a URL
> for attributes like Puppet Master, Puppet CA (and Openscap and content
> source for those plugins). I've uploaded some pictures to the PR as well
> which should explain it much better.
> 
> https://github.com/theforeman/foreman/pull/4346#issuecomment-288461410
> 
> One thing Stephen mentioned on the PR was if URLs could have many proxies
> as well as proxies have many URLs. That would go someway to better load
> balanced proxies. Which I think would be great, though I personally don't
> like the idea of another form & menu item just to create URLs, I think we
> have lots of forms and menu items already..

As a user it feels very complex and overwhelming. This is a perfect
example where a use case for a complex deployment makes it harder for
simple deployments.

I'm not against it, but just some thinking out loud to see if we both
get what the impact is.

How often do you have multiple URLs? My feeling is that there are the
following use cases:

# A proxy has 1 URL

This is the current situation. Speaks for itself. Question here is how
you display a proxy with only 1 URL. Do you simplify it so it matches
the current UI or keep it consistent with multiple URLs?

# A proxy has 2 URLs

Here we have a separate network for Foreman and its proxies. Then the
clients talk to their proxies on another network for other services
(puppet, DHCP etc).
That means we have a URL for the internal network and a URL for the
client network.

# A proxy has multiple URLs for multiple clients

A proxy could live in multiple client networks and serve them with
different names. I'm wondering how common this is and it's really an
added benefit. If you're separating anyway, maybe we should just
recommend deploying multiple proxies.

Regarding the use case where a URL has multiple proxies: this is a proxy
cluster. You could reason the other way around. Let me explain that.
Currently a proxy has multiple features. Each feature is reachable under
the same URL as a proxy. What you could consider is that you have the
proxy feature class.

ProxyFeature
* name (puppet, tftp)
* URL
* foreman proxies (1 or more)

Now you do need some logic to know if Foreman needs to talk to 1 of the
proxies or all. In the case of importing puppet classes you just need 1,
but in case of tftp all need to download. Some features might not allow
multiple proxies.

One complexity might be that not everything is a URL. tftp is just an IP
or hostname.

Does that make sense?

> >
> > > > On Wed, Mar 15, 2017 at 11:18 AM, Sean O'Keeffe <sokee...@redhat.com>
> > > > wrote:
> > > > > Hey!
> > > > >
> > > > > So lzap suggested this.. lets see how it goes :-)
> > > > >
> > > > > I'm looking to solve the following issues
> > > > > - I would like to have a multi-homed proxy.
> > > > > - I would like clients to connect to a Proxy when there is a NAT
> > between.
> > > > >
> > > > > My approach has been for proxies to have multiple URLs and during
> > > > > provisioning the user would then select a URL instead of the current
> > > > method
> > > > > of selecting a Proxy, This would be then mean all communication
> > between
> > > > the
> > > > > Client -> Proxy would be via the selected URL. Each proxy would also
> > > > have a
> > > > > 'primary' URL which Foreman would always use to connect to it via.
> > > > >
> > > > > Does this approach make sense?
> > > > > Any feedback to greatly appreciated
> > > > >
> > > > > Changes required:
> > > > > Foreman: https://github.com/theforeman/foreman/pull/4346
> > > > > - Adds Proxy URL concept
> > > > > - Puppet CA & Puppet Master selection are now URLS
> > > > >
> > > > > Katello: PR to be raised
> > > > > Content Source selection need to list URLS.
> > > > > Bootstrap RPM will need to create one for each URL
> > > > >
> > > > > Let me know what you think or any questions you have!
> > > > > Sean

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to