Juju tends to splat the prefix “juju-” all over the place. Docker and LXD use an <adjective>-<noun> scheme, or similar. I think that we should follow that approach.
The MAAS naming convention is quite cool ($adjective)-($animal)
“aware-trout”
“chief-aphid” etc.
Maybe Juju could do ($adjective)-($somethingmagical)
“eerie-mage”
“creepy-couldron”
“weary-lamp” etc. 
Juju always makes me think of Jujubes - https://en.wikipedia.org/wiki/Jujube_(confectionery)
Like JellyBellies, they came out with a bunch of whacky flavours.
($flavour)-($noun) could be funny.
1 Like
Weird, I was trying to add a link to Wikipedia, and kept getting an error 500…
Our Discourse instance is self-hosted. I think something is misconfigured with naked links. Try wrapping your link in Markdown
That’s got it. Thanks.
The MAAS names, at least at one time, can from this python library for “pet names” https://github.com/dustinkirkland/python-petname
Even better would be to have something meaningful for hostnames, such as {model}-{unit} or configurable during deployment.
One issue with semantic naming is that the units deployed to machines can change.
It might be useful to bake in the model name though, as models have exclusive access to machines. That would potentially make it clearer in cloud consoles and dashboards. (Much more boring than the original suggestion though!)
There is a golang version golang-petname
It is certainly possible to do pet names. Though the simple integer naming in “juju status” is very much intentional. It also is helpful to have something like model uuid in names for things like LXD, if you ever have multiple models/multiple controllers just pet names don’t tell you any context.
I don’t believe juju makes much use of “Name” as usually there is more of an “instance-id” of some form that is more Canonical for the instance (I think that isn’t true for LXD, but is true elsewhere). There is a general intent from Juju that we follow the “pets vs cattle” mantra. (We try to make any individual machine easily replaceable, rather than expecting long-lived meaningful names for them.) If we wanted, we could go with “what is the primary unit on a machine”, which often has an answer, but there is colocation that does happen. I do think it is rare that a given machine has its primary unit removed and another unit added to it. (Our default is to remove a machine when its last primary goes away anyway.)
Code-wise, machine allocation tends to happen outside the view of what unit is going onto it, especially wrt deploying a bundle (the machines are allocated before the applications are).
I got “ample man” for a MAAS pod the other day…
+1 on retaining integers as the primary machine ID (although I would begin from 1, as we’re not talking about an offset from the beginning of an array as per C-like indexing).
I’m more focused on “Inst ID” column. If Juju can be seen to behave more consistently with other Canonical products, the whole product suite feels more unified in my opinion.
Instance ID is the underlying provider’s identifier so you can look up the instance (in ec2 dashboard, maas UI, lxd list, etc) So for systems that provide an instance ID, there isn’t much we could do there.
AIUI lxd doesn’t have 2 different name vs ID and we do generate one there. But then we are stuck with having a clear cut way to identify all machines in a model (especially wrt destroy-model) and having more human identifiable names.
I agree that it is tasteless to use juju-* when it’s not necessary. I think we do less of that these days, and a review of the places where we still do it would be a nice clean-up action. Generally, I think the user-given names for things like models and applications is going to feel much nicer and friendlier to the user than a tool-brand. When GCC compiles firefox it doesn’t spit out a gcc-firefox 
2 Likes