Multiple Juju Relationships to a Single Charm

Tue Oct 21 11:05:30 UTC 2014

On Wed, Oct 15, 2014 at 10:42 AM, Maarten Ectors <
maarten.ectors at canonical.com> 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
> maarten.ectors at canonical.com
> Fixed: +44 (0) 207 630 2435
> Mobile: +44 (0) 791 860 8145
>
>
> On Sat, Oct 4, 2014 at 1:04 PM, Kapil Thangavelu <
> kapil.thangavelu at canonical.com> 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 <mike at gluu.org> 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 <mike at gluu.org>
>>>> 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
>>>>> Juju at lists.ubuntu.com
>>>>> 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
>>> mike at gluu.org
>>
>>
>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20141021/bc41c6de/attachment.html>