On Mon, Mar 27, 2017 at 3:10 PM, Ewoud Kohl van Wijngaarden < ew...@kohlvanwijngaarden.nl> wrote:
> 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? > I would say keeping the UI consistent with multiple URLs would be better, as it would look funny IMO if you have grouped options listing URLs/hostname and ungrouped options listing proxies names. maybe Roxanna or someone else has some input on this? Maybe we could: Just listing the Hostname? or if the URL has a Name attribute they could select a Name? Something like "Atlanta - Dev Network". @stbenjam suggested that on the PR. > # 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. > That's the currently way, but when you have lots of networks you end up having to have lots of unnecessary Proxies on small networks that otherwise wouldn't need it. > > 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? > Kind of, but I don't really like it to be honest. Storing a URL N times for every feature seems unnecessary to me? If we need the IP then we could get that from a lookup using the hostname, which I think is how its done currently. Though yes, it is a valid point some features wouldn't be able to make use of all URLs, I would consider these edge cases (as most would 'JustWork'™) and we can document which features work and don't work with multiple interfaces. DHCP for example - I think the installer only currently supports 1 interface, but not everyone uses DHCP. *It'd be really nice to get other people input on this as well! Even a simple +1 or -1 with a short sentence would be appreciated :-) * Especially guys from OpenSCAP, Katello & Remote EX plugins... > > > > > > > > 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. > -- 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.