On Wed, Oct 15, 2014 at 10:42 AM, Maarten Ectors < [email protected]> wrote:
> Hi Kapil, > > The problem Mike is trying to solve is that one Apache charm might host > multiple tenants and websites and each website needs to be protected > differently [e.g. different owner]. So might the solution be to have a > subordinate charm per tenant and like this each subordinate charm can have > the specific tenant configuration? > > Yup, that's a totally viable alternative, effectively move the config from a relation to a service subordinate instance. The one issue with subordinates for tenants, they can't be removed, but you could potentially blank their config as mitigation. -k > Thanks, > Maarten Ectors > Cloud, Big Data and IoT Strategy Director > Changing the Future of Cloud > Ubuntu <http://ubuntu.com> / Canonical <http://canonical.com> UK LTD > [email protected] > Fixed: +44 (0) 207 630 2435 > Mobile: +44 (0) 791 860 8145 > > > On Sat, Oct 4, 2014 at 1:04 PM, Kapil Thangavelu < > [email protected]> wrote: > >> Hi Michael, >> >> Thanks for elaborating. Afaics, the crux is two fold. >> >> The primary of being able to establish multiple relations between apache >> and identity providers per virtual host. This is supported today via api >> and cli. From a juju terminology apache is an IDP interface requirer (aka >> client) and the IDP is a provider (aka server). Simply doing juju >> add-relation apache idp multiple times suffices to add multiple relations >> between apache and different identity provider. Part of the confusion about >> this may have been a result of the gui not supporting this. The algorithm i >> used in the gui for dimming non valid relation targets, tries to simplify >> the common case and provide a guide to users and wont consider 'require' >> relation endpoints already satisfied as needing further relations >> established. Potentially the gui needs some sort of option/key press to >> enable an 'advanced' mode when creating relations that provides for this (i >> just filed bug http://pad.lv/1377414 for it). >> >> The secondary issue is that providing for configuration of the >> virtualhost idp mapping this way is currently tedious, as the config for >> the idp relation and virtualhost needs to flow from the service config or >> other charm accessible data source and then mapped onto the individual >> relation instances by the charm. This has come up in the context of other >> relation workflows/use cases as well. There are tentative plans to address >> it via providing for relation configuration that can be provided by the >> admin and managed as part of the relation lifecycle. ie add-relation apache >> idp --config="vhost=http://myapp.com acct=0123" Fwiw. The majority of >> the juju developers are sprinting this week on code and feature futures and >> relation config is on the agenda. >> >> cheers, >> >> Kapil >> >> >> >> On Fri, Oct 3, 2014 at 3:09 PM, Michael Schwartz <[email protected]> wrote: >> >>> Kapil, >>> >>> Here is a picture of a Juju Deployment of the Gluu Server: >>> http://www.gluu.org/blog/wp-content/uploads/2014/10/juju- >>> screenshot-gluu-apache.png >>> >>> In this digram, the Gluu Server is where the person is authenticated. It >>> is the Central "Identity Provider" or IDP. >>> >>> Everything's great right? The Apache Server uses the Gluu Server for >>> Authentication... nice and simple. >>> >>> The only problem.. the world is not quite so simple. Apache has a widely >>> used feature to support virtual hosting. So if you are an ISP, unless you >>> want to deploy one apache server for every customer, the above relationship >>> doesn't do you much good. >>> >>> In the real world, there are multiple IDPs. Many domains have their own >>> IDP. Google is really just another domain on the Internet. Many companies >>> also use google to authenticate their people. >>> >>> So in this diagram: http://www.gluu.org/blog/wp- >>> content/uploads/2014/10/juju_apache_charm.png >>> >>> I was showing a situation where a single Apache Web server might have >>> multiple folders for different websites that it is serving, and each >>> website may have a different IDP. >>> >>> Does that help? Can juju provide a nice interface or CLI controls for >>> this? >>> >>> thx, >>> >>> Mike >>> >>> >>> >>> On 2014-10-03 13:30, Kapil Thangavelu wrote: >>> >>>> not quite clear why you think it doesn't work, could you outline what >>>> you'd like to do and where the difficulty arises. a picture is worth a >>>> thousand words, but some words as context are useful to frame it. >>>> >>>> -k >>>> >>>> On Fri, Oct 3, 2014 at 1:15 PM, Michael Schwartz <[email protected]> >>>> wrote: >>>> >>>> Juju'ers: >>>>> >>>>> If you consider virtual hosting on a web server, each web folder >>>>> may be a different client, who may have their own OpenID Provider. I >>>>> made a quick diagram: >>>>> >>>>> >>>>> http://www.gluu.org/blog/wp-content/uploads/2014/10/juju_ >>>> apache_charm.png >>>> >>>>> [1] >>>>> >>>>> As far as I can tell, there is no really good way to do this in >>>>> Juju. Any ideas? >>>>> >>>>> thx, >>>>> >>>>> Mike >>>>> >>>>> ------------------------------------- >>>>> Michael Schwartz >>>>> Gluu >>>>> Founder / CEO >>>>> @gluufederation >>>>> >>>>> -- >>>>> Juju mailing list >>>>> [email protected] >>>>> Modify settings or unsubscribe at: >>>>> https://lists.ubuntu.com/mailman/listinfo/juju [2] >>>>> >>>> >>>> >>>> >>>> Links: >>>> ------ >>>> [1] http://www.gluu.org/blog/wp-content/uploads/2014/10/juju_ >>>> apache_charm.png >>>> [2] https://lists.ubuntu.com/mailman/listinfo/juju >>>> >>> >>> -- >>> >>> >>> ------------------------------------- >>> Michael Schwartz >>> Gluu >>> Founder / CEO >>> [email protected] >> >> >> >> -- >> Juju mailing list >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> >> >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
