The gui also infers some behavior from require/provider roles when allowing drag creation of relations. ie. if i have a django charm which already has a satisified postgresql requires, then the gui won't consider a postgres service as a new possible relation when looking for valid relation targets. Ditto in reverse from a postgres service as a provider, the valid targets for a postgresql interface will be unsatisfied requires of extant services. -k
On Fri, Sep 6, 2013 at 8:24 AM, William Reade <[email protected]>wrote: > Hi Mike > > Without some distinction between provider and requirer, there's no way to > tell which charms can reasonably be connected to one another. If a node.js > charm and a django charm both declare a postgres interface alone, it would > appear that they could be reasonably connected to one another... but that > doesn't make any sense. By making them both *require* postgres, and making > the postgresql charm *provide* it, it's immediately clear (both to humans > and to machines) that node<->postgresql makes sense, and > django<->postgresql makes sense, but node<->django doesn't. > > Does that answer your question? > > Cheers > William > > > On Fri, Sep 6, 2013 at 1:24 AM, Mike Sam <[email protected]> wrote: > >> How does juju use the extra information inside meta file about knowing >> who is the requirer and who is the provider in a relationship? I mean if >> each side process their join and changed independently and anyone can call >> relation-set, why would juju care to know who is providing and who is >> requiring? >> >> >> >> >> >> >> -- >> Juju-dev mailing list >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >> > > -- > Juju-dev mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
