no way to list application's current space bindings

[Jason Hobbs]

I'd like to check that my applications have all their bindings set properly, but there is no command (that I or #juju@freenode can find) that shows the bindings for all applications in a model.

This is with 2.3.1.

[Anastasia (anastasia-macmood)]

Seems like a useful information to see :-)

Thank you for suggestion!

[Anastasia (anastasia-macmood)]

With further look into this, it seems that the most useful information for your use case would be to see application endpoints, i.e. not 'mysql' but 'mysql:juju-info'.

[Jason Hobbs (jason-hobbs)]

Anastasia,

Can you clarify what you mean? mysql:juju-info is a relation right?
Not all space bindings are tied to relations; I want to make sure I
get to see them all.

Jason

On Thu, Feb 8, 2018 at 6:04 AM, Anastasia
<email address hidden> wrote:
> ** Changed in: juju
> Status: Triaged => In Progress
>
> ** Changed in: juju
> Assignee: (unassigned) => Anastasia (anastasia-macmood)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1742550
>
> Title:
> no way to list application's current space bindings
>
> Status in juju:
> In Progress
>
> Bug description:
> I'd like to check that my applications have all their bindings set
> properly, but there is no command (that I or #juju@freenode can find)
> that shows the bindings for all applications in a model.
>
> This is with 2.3.1.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1742550/+subscriptions

[Anastasia (anastasia-macmood)]

@Jason Hobbs (jason-hobbs),

"Not all space bindings are tied to relations; " - *I agree. This is part of the reason why we cannot, in full conscience, put spaces information in a relations' section in status output.*

So, some terminology to make sure that we are talking about the same thing :)

An application has endpoint(s) that are used in relations: to and from connections between applications. Relations are generally displayed in terms of the endpoints that they link, for e.g.
'mysql:juju-info' (as relation provider) and 'logging:info' (as requirer).

So, yes, you have seen the format I referred to in relations, say in 'juju status' output. But this format, <application_name>:<endpoint_name> actually represents an endpoint.

When you specify application bindings, you are binding application endpoints. I propose we list them although I am not sure that it will be logistically possible to do it as an output of a 'juju spaces' command [1].

Can you give me an example where space binding is not tied to an endpoint?
(The only situation I can think of is when your application only has one endpoint so we *know* to bind what you mean when you ask to put this application into a space...) :D

[1]
Currently, the output of spaces command looks like this: https://pastebin.ubuntu.com/26544370/

If I add another column to this output that lists the endpoints [https://pastebin.ubuntu.com/26544380/] or applications [https://pastebin.ubuntu.com/26544389/ .... I am not sure if this is helpful since you cannot see which application endpoint is in a particular space, i.e. look at mysql case] in here, it will be confusing since the last two columns are not related to each other but because each item is on a separate row, it looks like an application endpoint sits in a particular subnet...

I think that we'd be better off either:
(1) have 'juju spaces' out put 2 tables - one for subnets and one for applications/endpoints;
(2) have a separate command to display where application endpoints are for the whole model;
(3) change the tabular output to have a space name column to be in the middle (am not a fan of this version - https://pastebin.ubuntu.com/26544399/)

What do you think?

Meanwhile, while we elaborate on how to display space usage for a whole model, we could potentially work on something like a 'show-application' command that will include spaces information for the application. Unfortunately, up until now we did not have the need for this command....

[Anastasia (anastasia-macmood)]

The other places where model-level spaces information may reside is status:

* Application's section... But this section already displays Name, Version, Status, Scale, Charm, Store, Rev, OS, Notes... and, thus, is too long to also display spaces for each app;

* A new 'Spaces' section with columns [Space Name, Application, Endpoint] or [Space Name, Application:Endpoint]

* Change how we display relations endpoints to include spaces, for e.g. https://pastebin.ubuntu.com/26544530/ will become https://pastebin.ubuntu.com/26544535/

[John A Meinel (jameinel)]

If we did that, would it be clearer if we put it into real columns:
https://pastebin.ubuntu.com/p/P2hsMkz9mK/

But even then, it seems like we're missing 'extra-bindings' and other such information. If we consider Openstack, the binding of the endpoints that you relate to is actually *not* the interesting information. The charms as designed decouple the bindings because they have multiple network spaces to be in (internal, admin, external), and they don't pun the relation information with the network space information. (they might for some relations, but certainly not all.)

I also think 90% of cases don't leverage the ability to put different endpoints in different spaces, but just use 1 default space for all endpoints. And some charms have a *lot* of potential endpoints:

eg https://api.jujucharms.com/charmstore/v5/mysql/archive/metadata.yaml
has 13 bindings

It would be good to grab a couple of real world deployments (probably 1 openstack on a maas with multiple networks, and 1 cdk), and then play with the bindings that people are using, and see what form comes out understandable for users.

[Anastasia (anastasia-macmood)]

@Jason Hobbs,

Want to help decide on a useful format? Any of the suggestions above call to you?

[Anastasia (anastasia-macmood)]

PR that introduces new 'show-application' and including binding information is: https://github.com/juju/juju/pull/9662