RFC: Snappy shell

Tue Jun 16 10:52:33 UTC 2015

On Tue, Jun 16, 2015 at 10:44 AM, Loïc Minier <loic.minier at ubuntu.com> wrote:
> You're suggesting to kill the idea entirely; that might be a valid
> standpoint, but you've dismissed this a bit quickly.
>
> First, consider that the networking industry is proposing this today: in all
> products, for all major brands, you end up in a custom CLI experience. I
> certainly agree it's painful to learn a new one each time, much like it's a
> pain to learn how to use/configure a new piece of software of any kind. But
> at least we get to define this one and offer it as a base for others to
> derive from. Perhaps frameworks/snaps could extent the command set with
> additional commands, e.g. to manage the ASIC, or provide hardware
> diagnostics etc.
>
> I'm not convinced that this shell approach is inherently good or bad for
> these network vendors, but it's a fact that they all do this, and snappy
> shell gives a path towards this kind of user experience.
>
>
> Second, you've dismissed the other benefits towards delivering a more locked
> down user experience (e.g. I want to ship a critical piece of hardware based
> on snappy, they may/may not install apps, they may/may not change the config
> of snaps, they may/may not run random shell commands).
>
> I also mentioned smoothing the move to a more minimal system (without some
> of the tools you like). But on this Comfy part, it's fair to point out we
> should judge this one on its own merits though.
>
>
> Snappy shell needs not be required for all snappy based images and/or needs
> not be on port 22, it is rather an optional interface to snappy, much like
> webdm is an useful tool and default web user experience. (Perhaps it should
> be implemented as a completely separate addon, but it felt more natural to
> tie it to the main command-line tool.) Perhaps we'll have a snappy router
> image where it makes sense to make this shell the default, with or without
> direct shell access enabled, while a snappy media-center image would not
> have it.

For me the snappy shell proposal came as a pair with comfy, which - if
installed - would deliver the user an even more powerful ubuntu shell
experience than what we have in snappy core. Afaiu loic's vision of
comfy shell would be that its a full blown ubuntu chroot/docker
experience that one could customize through apt-get etc...

Would't such story deliver best of both worlds and make some of the
concerns in this thread go away?

Maybe Loic should elaborate a bit more on this part of the vision?

>
> Cheers,
>
> On Mon, Jun 15, 2015 at 6:42 PM, Gustavo Niemeyer
> <gustavo.niemeyer at canonical.com> wrote:
>>
>> I'm personally two-hearted about this idea.
>>
>> On one hand, I can see the appeal, and have used something similar to that
>> myself for Smart Package Manager, where people could use a shell to type in
>> the all of the subcommands that they could use under the "smart" command
>> line tool. It was a neat way to type several subcommands in a row without
>> the cost of initializing the in-memory graph cache necessary for computing
>> operations, and was expensive to do.
>>
>> On the other hand, there's no relevant init cost for the snappy cli, and
>> custom shell can become an annoyance rather than an advantage. For example,
>> I use traditional unix tools such as grep, sed, awk, sort, all the time when
>> interacting with textual output from dpkg, apt, etc, and also use text files
>> as temporary storage, shell variables, etc. Being in a custom shell means
>> people will be constrained in an unusual way within an atypical shell to the
>> tasks which they tend to understand otherwise.
>>
>> The thing that fired my worries while reading your message was the part
>> where you say the goal is to deliver a slick console user experience as
>> found when telneting into network equipment. While I don't have much
>> experience there, the few times I did that I found myself within an alien
>> and apparently clumsy environment where I'd have to re-learn everything. It
>> wasn't a smooth feeling at all.
>>
>> So, here is an idea: rather than redoing the whole shell, can we identify
>> what are the winning aspects of that integrated shell (good help? pleasant
>> command names? etc) and try to replicate that within a traditional shell?
>>
>>
>>
>> On Mon, Jun 15, 2015 at 12:50 PM, Loïc Minier <loic.minier at ubuntu.com>
>> wrote:
>>>
>>> User experience
>>>
>>>
>>> When you SSH into a Snappy system, you currently end up on a shell
>>> prompt. Wouldn’t it be great to actually land in Snappy itself?
>>>
>>>
>>> Welcome to Snappy Ubuntu Core 15.04
>>>
>>> snappy#
>>>
>>>
>>> How do I get started?
>>>
>>>
>>> snappy# help
>>>
>>> Usage:
>>>
>>>  <command> [<arg>...]
>>>
>>>
>>> Available commands
>>>
>>>  booted              Flag that rootfs booted successfully
>>>
>>>  build               Builds a snap package (aliases: bu)
>>>
>>>  config              Set configuration for an installed package.
>>>
>>> [... edited for brievety...]
>>>
>>>  shell               Start a shell
>>>
>>>  update              Update all installed parts
>>>
>>>  versions            (deprecated) please use "list"
>>>
>>>
>>> Simple commands like install, update etc. work as expected:
>>>
>>>
>>> snappy# info
>>>
>>> release: ubuntu-core/15.04/stable
>>>
>>> architecture: amd64
>>>
>>> frameworks: webdm
>>>
>>> apps:
>>>
>>> snappy# list -v
>>>
>>> Name          Date       Version Developer
>>>
>>> ubuntu-core   2015-06-11 3       ubuntu*
>>>
>>> webdm         2015-06-11 0.9     *
>>>
>>> generic-amd64 2015-06-11 1.1.1   *
>>>
>>>
>>> We should revisit some commands or aliases to have a friendlier, more
>>> rewarding user experience, e.g. update could provide some output when no
>>> update is available and entering a shell command like ls would hint at using
>>> help:
>>>
>>>
>>> snappy# update
>>>
>>> System is up-to-date!
>>>
>>> snappy# ls
>>>
>>> No such command; “help” for a list of commands
>>>
>>>
>>> Configuration is only possible for snaps that have the required hook and
>>> may be set manually by key or globally from an URL, and of course immutable
>>> configs can’t be changed.
>>>
>>>
>>> snappy# config
>>>
>>> (config)# list
>>>
>>> Name           Date       Version Developer
>>>
>>> ubuntu-core    2015-06-11 3       ubuntu
>>>
>>> config-example 2015-06-15 1.0.6   canonical
>>>
>>> webdm          2015-06-11 0.9
>>>
>>> (config)# config xkcd-webserver
>>>
>>> No config found for this snap
>>>
>>> (config)# config ubuntu-core
>>>
>>> (ubuntu-core)# show
>>>
>>> autopilot: true
>>>
>>> timezone: Etc/UTC
>>>
>>> hostname: localhost.localdomain
>>>
>>> (ubuntu-core)# set autopilot false
>>>
>>> Config set
>>>
>>> (ubuntu-core)# exit
>>>
>>> snappy# config config-example set -u
>>> https://conf.example.com/config-example.yaml
>>>
>>> Config set
>>>
>>>
>>> A new shell command is provided to start the default user’s interactive
>>> shell or to run commands ( under “sh -c”).
>>>
>>>
>>> Goals of snappy shell
>>>
>>>
>>> Deliver a slick console user experience as found when SSH-ing (or
>>> telnet-ing) into network equipments such as switches, routers, firewalls
>>> etc.
>>>
>>> Allows restricting access to the shell while allowing for useful features
>>> such as update, install etc. (could be controlled by a new
>>> allowed-cli-commands ubuntu-core config or similar)
>>>
>>> Smoothes transition into a Comfy world where the regular rootfs becomes
>>> smaller and smaller.
>>>
>>>
>>> Implementation
>>>
>>>
>>> This user experience would be delivered by the main “snappy” binary when
>>> it’s launched as “snappy-cli” as the basename of argv[0]. If this feature is
>>> not enabled by default, or from a shell, you would run “snappy cli” to start
>>> an interactive snappy shell session. NB: cli is to avoid confusion with the
>>> shell command to run a command or an interactive shell.
>>>
>>>
>>> SSH integration could be done in multiple ways:
>>>
>>> integrate a SSH server in snappy itself; I don’t know how hard this is in
>>> go today; this might be a worthwhile exercise long-term to get a smaller
>>> rootfs
>>>
>>> configure SSH server and login to always start /bin/snappy-cli instead of
>>> the user’s shell, then lookup the user’s shell in the passwd database to run
>>> the preferred shell with “snappy shell”
>>>
>>> (preferred) configure the user’s shell to /bin/snappy-cli and create a
>>> new snappy-only ubuntu-core config for the preferred interactive shell
>>> (defaults to /bin/bash); drawback: this would be system-wide as we don’t
>>> have per-user configs
>>>
>>>
>>> Questions? Comments? Pile on at:
>>> https://docs.google.com/document/d/1DeR2JoCBDX2C1r6a2wV60uqvi7a89OwHh5gJ19tBZvM/edit
>>>
>>>
>>> Cheers,
>>> --
>>> Loïc Minier
>>>
>>> --
>>> snappy-devel mailing list
>>> snappy-devel at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/snappy-devel
>>>
>>
>>
>>
>> --
>> gustavo @ http://niemeyer.net
>
>
>
> --
> snappy-devel mailing list
> snappy-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/snappy-devel
>