Ability to use two registered names for the same snap

[Stéphane Graber]

For LXD, we need both the "lxd" and "lxc" commands to provide a reasonable user experience.
We need folks to run "lxd init" for example and then interact with LXD using the "lxc" command.

It was suggested at the sprint that this would be reasonable so long as the snap author owns both names, which I now do for lxd.

[Jamie Strandboge (jdstrand)]

Not saying this shouldn't be done, but wondering why LXD is the exception when all of snaps have had to abide by this? I guess I see that 'lxd.lxc' is a little weird looking, but what about 'lxd.cmd'? Again, not blocking or anything, just curious.

[Stéphane Graber (stgraber)]

Every single available bit of online documentation, merchandise, scripts, ... expect the lxd client to be called "lxc". Folks also expect to install lxd to the get the lxc command.

So yes, we could use another command name, but then everything, including lxd's error messages and built-in documentation will tell you to use a command that you do not have on your system.

An alternative would be to package lxc as a separate snap, but then we'd run into different difficulties as it'd be two completely separate snaps built from the exact same source. Keeping things in sync would be a bit difficult and it would also require the user to install two separate snaps to get the expected user experience.

[Stéphane Graber (stgraber)]

Oh and yes, the current snap I have on the store for 16 does use "lxd.lxc" right now which while it looks ugly is probably less confusing to our users than lxd.cmd which is a name we've never used anywhere online yet.

Another interesting problem with the current setup is that folks who install the lxd snap on a system that has the Ubuntu packaged lxd, will have the "lxd" command go to the lxd snap, so "lxd init" does configure the snapped LXD as expected, but then the "lxc" command will work and talk to their Ubuntu packaged lxd daemon rather than the snapped one (they have to use lxd.lxc for that).

[John Lenton (chipaca)]

If they have lxd installed, that'll take precedence over the snap (/snap/bin is appended to $PATH).

Anyhow, yes this is a problem; it's not just lxd/lxc: e.g. https://lists.ubuntu.com/archives/snapcraft/2016-July/000559.html

I don't have a solution though.

[Stéphane Graber (stgraber)]

Ah, good point. I assumed the snap path would be ahead of the system paths so that folks can use snaps as a way to get backports even for bits that are already installed on their classic system.

[Jamie Strandboge (jdstrand)]

As Stephane mentioned, if a name is registered to the publisher then the publisher can upload a snap with that name and own it (ie, lxd). Perhaps it makes sense for the store to offer 'additional toplevel commands' (or something) that register those command names with the user but that won't allow uploads of snaps with that name. In that way, Stephane registers lxd like normal, clicks through some stuff under lxd in the store to register 'lxc' as an additional command and if it is free gets, it registered to him, and he can upload as usual. He would not be able to register 'lxc' as a project then since the name is taken as an additional command. In in this idea, wouldn't want to change the snap.yaml-- just let snapd sort it out with the store (hmm, but what about sideloads...).

Just spitballing here of course. This needs proper design, etc but like Stephane said, the request seems plausible. Part of me thinks that people might (ab)use this functionality to register scores of commands (I've seen a project with 47 commands in it for example) and I think the norm should probably be what we have today. 2 cents

[Mark Shuttleworth (sabdfl)]

Good idea Stephane. We'll create a mechanism to have multiple
first-class names in a snap. Gustavo and I sketched the basics today and
it should come together nicely - will depend on snap-declaration,

Mark

[Martin Pitt (pitti)]

lxd is not just an unique snowflake here -- the same problem came up with snapifying NetworkManager, which *must* provide "nmcli" in order to not break compatibility with lots of software which expects that name (e. g. see https://code.launchpad.net/~morphis/netplan/+git/netplan/+merge/306607). Same will Till's cups snapd -- that must provide the official lpadmin etc. binaries.

I. e. more generally, snaps which are not a leaf application but system-level services must also behave like them and not provide prefixed names. They already are colliding with their corresponding debs anyway, on the D-Bus name at least (maybe also on the Unix socket path in the LXD/cups cases).

[Luis Lobo (luislobo)]

In the mean time, I'm aliasing /snap/bin/lxd.lxc as lxc

[Michael Vogt (mvo)]

Part of the "toplevel commands work" that is currently in progress.

[Stéphane Graber (stgraber)]

The aliases work that landed in 2.20 combined with the store assertions provide exactly what we needed there. The LXD snap now provides both "lxd" and "lxc".

[Luis Lobo (luislobo)]

@stgraber

How do you get that version? Is it released? I just tried to update lxd using

sudo snap refresh lxd --edge

but I still don't have lxc as a command. I do have lxd and it reports version 2.7

Thanks!

[Stéphane Graber (stgraber)]

On January 10, 2017 2:57:05 AM GMT+02:00, Luis Lobo <email address hidden> wrote:
>@stgraber
>
>How do you get that version? Is it released? I just tried to update lxd
>using
>
>sudo snap refresh lxd --edge
>
>but I still don't have lxc as a command. I do have lxd and it reports
>version 2.7
>
>Thanks!

Make sure that you have snapd 2.20 installed too.