gui does not allow multiple relations between wordpress and ha proxy

[Dave Cheney]

To reproduce

#!/bin/bash

set -e

juju bootstrap --upload-tools
juju deploy wordpress -n2 w1
juju deploy wordpress w2
juju deploy mysql m1
juju deploy haproxy p1
juju deploy --to 0 juju-gui g1
juju add-relation w1 m1
juju add-relation w2 m1
#juju add-relation w1 p1
#juju add-relation w2 p1
juju expose p1
juju expose g1

will build an environment

the gui does not allow w1 and p1 AND w2 and p1 to be related together, yet the same is possible on the cli.

[Richard Harding (rharding)]

per hazmat, this is intended behavior.

[Dave Cheney (dave-cheney)]

With respect, I can do it from the command line

juju add-relation w1 p1
juju add-relation w2 p1

Is this a juju bug, is the gui doing the right thing and the cli the wrong thing ?

[Gary Poster (gary)]

Dave's comment #2 is on the money, IMO. Let's figure out what the right behavior is and sync the CLI and GUI correspondingly.

[Gary Poster (gary)]

I have asked fwereade to clarify expected/correct behavior.

[William Reade (fwereade)]

This is *probably* intended behaviour -- the haproxy charm's reverseproxy relation doesn't specify a limit, and it's a "requires" relation, so its limit is implicitly 1; so you should indeed not expect to connect more than service to it.

But juju doesn't enforce that internally, and AFAIK never actually has, so *if* the haproxy charm actually works when deployed like that, it'd probably be best to (1) fix the haproxy charm to have an explicit limit of 0 and (2) fix the gui to accept limits > 0. If it doesn't work right when deployed like that, the right answer is to fix juju-core to respect the implicit limit (lp:1089297).

Helpful?

[Kapil Thangavelu (hazmat)]

This behavior is intended for the gui btw and should absolutely remain this way unless you want to cause a massive usability problem and end user env breakage. If there's a fix to be made it should be made in cli first wrt to respecting relation limits so that we can converge the two on behavior. Pretty much all charms are broken are broken if they have multiple relations on a requirer. I'd say if people want to expose/abuse this particular functionality they should indeed use the cli. Williams suggestion of limit > 1 as a discriminator is valid, but given there is ZERO usage of this in the wild i find that not particularly a useful waste of time.

[Gary Poster (gary)]

== Basic facts as of this moment ==

Charms can specify that their relations each have a "limit." It is defined on https://juju.ubuntu.com/docs/authors-charm-anatomy.html as the following:

"The maximum number of relations of this kind which may be established to other service units. Defaults to 1 for requires relations, and to "none" (no limit) for provides and peers relations. While you may define it, this field is not yet enforced by juju."

The GUI also ignores the "limit" value, but simply does not currently allow more relations than 1.

== Things I think Kapil, William, and I all agree on ==

Both the CLI and GUI would ideally honor the relation limit.

This is a low-priority issue. The current situation is OK.

== Things we might agree on ==

If the GUI honored the limit, using the default rules listed above (for required, limit is 1, and for provided, limit is none), and the CLI didn't, that would be fine. It would not introduce any new pain AFAICS.

== Things I seem to disagree with Kapil on (?) ==

I think honoring the limit in the GUI is not a waste, but simply a low priority. It would be pretty trivial to implement, I suspect.

I don't like the fact that a reasonable use case can be handled in the CLI but not in the GUI, even if the charm is correctly annotated with limits.

== In sum... ==

I'm leaving this as valid, and marking it as low. Fixing this would mean honoring the limit value in the GUI, incorporating the defaults described in the documentation.

[Gary Poster (gary)]

Correction: The GUI also ignores the "limit" value, but simply does not currently allow more *requires* relations than 1.

[Kapil Thangavelu (hazmat)]

Addendum
 - zero charms use limit
 - 1 charm currently supports requires and only if service config is specified alongside it.

As i recall from implementing the solver its probably a bit more than a trivial. I don't find much value atm in changing the gui behavior till limits are enforced on the cli or there are any uses of such functionality. There are lots of needs real world use cases and end user features that effort could better be spent on imo.

Its also not a goal of the gui to be 100% functionality equivalent to the cli afaik, so there's nothing wrong with punting on this, till we have an actual use case.

[Dave Cheney (dave-cheney)]

> Its also not a goal of the gui to be 100% functionality equivalent to
> the cli afaik, so there's nothing wrong with punting on this, till we
> have an actual use case.

Whoa! hold up now. We (I) tell customers that everything you can do in
the GUI you can do on the CLI, that is the promise.

As for a use case,
https://bugs.launchpad.net/charms/+source/haproxy/+bug/1154179

[Dave Cheney (dave-cheney)]

Interestingly, you *can* do this in the sandbox, but not in a deployed gui.

[Dave Cheney (dave-cheney)]

Wow, this keeps getting weirder.

If I modify the haproxy charm to specify

=== modified file 'metadata.yaml'
--- metadata.yaml 2013-04-22 19:42:18 +0000
+++ metadata.yaml 2013-10-02 03:36:19 +0000
@@ -10,6 +10,7 @@
 categories: ["cache-proxy"]
 requires:
   reverseproxy:
+ limit: 1000
     interface: http
 provides:
   website:

then deploy this charm from my local repo, and the gui will allow me to create multiple relations to the requires:reverseproxy:http relation.

So

1. the gui is doing the right thing, but it is relying on some very hand wavy details from the docs, saying that the limit of requires relations is by default 1. Given that juju doesn't implement this itself, the gui probably wins via first movers advantage.

2. juju needs to respect limit, https://bugs.launchpad.net/juju-core/+bug/1089297

3. the haproxy charm, well, that is confusing. The way it is currently written is to enforce a requires limit of 1. If you can trick juju into establishing multiple relations to the reverseproxy endpoint, then it smooshes them altogether, totally not doing what you want. BUT, given that limit isn't actually supported, either in it's limit 1 default, or some other value, even if the HA proxy charm did request a limit of 1, it wouldn't be respected.

[Gary Poster (gary)]

https://bugs.launchpad.net/juju-gui/+bug/1238859 is another use case.

We have two concrete use cases from users to try and fix this issue. I think that's compelling enough to prioritize, given where we are.

I don't see where the GUI is honoring limit, which is weird. We'll have to investigate.