no way to get useful name for externally shared model

[Richard Harding]

In attempting to script against the Juju CLI I ran into an issue trying to loop through my controllers, loop through the models, and then juju status each model. The YAML output has a name of the model, but in a model that's been shared with me via JAAS the name isn't enough to complete a juju status. It needs to be prefixed by the user@external/modelname.

However, it's not obvious this needs to happen. If you look at the Juju output it "does the right thing" in that it outputs the prefixed model name using internal logic when it needs to. However, then I have to duplicate that logic in my script. Ideally there'd be some sort of id or field in the YAML I could rely on that uses the same logic Juju already uses to build that useful name up.

[Roger Peppe (rogpeppe)]

To rephrase this as I understand it:

"juju list-models -format yaml" produces entries
with "name" and "owner", but when selecting a model
with -m, the argument needs to contain both name
and owner.

If you know how model names work, you can just use
$name/$owner but it might be useful to have a field that
contained the full name too.

[Anastasia (anastasia-macmood)]

I am going to try to fit the fix into our next release.

@Richard Harding, @Roger Peppe (rogpeppe), @John A Meinel (jameinel),
Any preferences on the name of this field?
"Full name" or "Formal name" comes to my mind...

[John A Meinel (jameinel)]

brainstorming:

fully qualified name

path
(eventually this is more than just username, right?)

full path

url

uri

John
=:->

On May 30, 2017 06:15, "Anastasia" <email address hidden> wrote:

I am going to try to fit the fix into our next release.

@Richard Harding, @Roger Peppe (rogpeppe), @John A Meinel (jameinel),
Any preferences on the name of this field?
"Full name" or "Formal name" comes to my mind...

--
You received this bug notification because you are subscribed to juju.
Matching subscriptions: juju bugs
https://bugs.launchpad.net/bugs/1693581

Title:
  no way to get useful name for externally shared model

To manage notifications about this bug go to:
https://bugs.launchpad.net/juju/+bug/1693581/+subscriptions

[Richard Harding (rharding)]

I talked with jam on this in the morning and the "right" answer we think is that the name field includes the prefix if it's required as "name" input elsewhere.

This means that folks with scripts that currently append the user with the model name it'll break, but we think it's worth doing as the right fix.

Adding a special field that doesn't really have a good meaning in the model seems like it's patching things badly.

The only thing that comes up then is should it follow the logic such that the machine readable format always has it prefixed (regardless of the current user) while the table view will only prefix when it must be done to make the content more readable. This breaks down into machine readable vs human readable. If human readable, cut the prefixed username if we can. If machine readable, always prefix with the username so scripts always work for everyone.

[Anastasia (anastasia-macmood)]

I had a look at current model list behavior in our codebase that is aiming for 2.2-rc1.

Right now, in tabular format, we are already showing "full model name", including user where currently logged on user is not an owner.

Sample output looks like this (pastebin'ing to ensure formatting is preserved): http://pastebin.ubuntu.com/24732371/

I'll double-check that machine-readable output (yaml, json) always has a user in the name, regardless of ownership and currently logged on user as suggested...

[Anastasia (anastasia-macmood)]

I am also wondering if "show-model" command should exhibit similar behavior...

In other words, if model owner is currently logged on user, the model name will not be quantified with owner. Otherwise, model name will be displayed as owner/model.

Also, @Roger Peppe (rogpeppe),
I am guessing that in your clarification you intended to say $owner/$name not $name/$owner :D

[John A Meinel (jameinel)]

I wouldn't want us to lose the ability to use short names and see short
names in the simple cases (single user, single controller, small number of
models, etc). Having to always specify a fully qualified path especially
when you are already the right user feels annoyingly pedantic. (Its
entirely possible that we'll get really early feedback that on a multi-user
controller they want *everyone* to be able to use the short 'prod' name,
regardless rather than referencing someoneelse/prod.)

Maybe we do that with some sort of aliasing mechanism. Some care so that we
make it easy for people to be sure that they are talking about the *same*
object when they are talking to each other. Too much aliasing and then my
'prod' isn't your 'prod' and we're both fixing the wrong thing, etc.

I certainly don't have a clear "one true way" in mind yet. I do think being
consistent between commands is good. Having a way to be completely pedantic
is important, and very useful for scripting, etc. But I don't think it is
the best thing for all user-facing interactions.

On Thu, Jun 1, 2017 at 7:48 AM, Anastasia <email address hidden>
wrote:

> I am also wondering if "show-model" command should exhibit similar
> behavior...
>
> In other words, if model owner is currently logged on user, the model
> name will not be quantified with owner. Otherwise, model name will be
> displayed as owner/model.
>
> Also, @Roger Peppe (rogpeppe),
> I am guessing that in your clarification you intended to say $owner/$name
> not $name/$owner :D
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1693581
>
> Title:
> no way to get useful name for externally shared model
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1693581/+subscriptions
>

[Anastasia (anastasia-macmood)]

@John A Meinel (jameinel),
Thank you for your time and thoughts!
As per our off-line discussion, we will re-name current 'Name' field to read 'Short Name'. This will allow us to have a fully qualified $owner/$name model name value in the 'Name' field.

Note that this is presentation only logic and will not affect the data that API calls send back to 'models' or 'show-model'.

We will preserve current tabular behavior for 'models', i.e. logged on user will only see 'short name' in the Name column for their models.

It does, however, mean that the yaml and json output would have an additional field.

I'll attach a sample as soon as I generate it.

[Anastasia (anastasia-macmood)]

Sample output: https://pastebin.canonical.com/189744/
PR is following shortly..

[Anastasia (anastasia-macmood)]

PR against develop (2.2): https://github.com/juju/juju/pull/7435