RFC: Snappy shell
Rick Spencer
rick.spencer at canonical.com
Tue Jun 16 11:37:46 UTC 2015
When I develop for the phone, I:
1. Work on my application inside Qt Creator on my desktop until I am either
"done" or need to develop against specific phone capabilities that are hard
to mock on the desktop. This is a normal run -> debug -> edit -> run cycle
that everyone is familiar with on the desktop.
2. Use "Run on Device" to test it on the device. This command packages the
applications, moves any old version on the phone out of the way, runs my
app, and gives me a full account of what is happening (error messages,
stdout messages, etc...) within QtCreator.
Contrast #2 with my experience yesterday on snappy. I accomplished #1, my
service was running fine, but then I had to snappy build (fair enough),
snappy remote intstall (fair enough), and then my snap doesn't work on the
device. And I got absolutely no feedback from the system what the problem
was. I learned that I can grovel through systemctl to launch the service,
and look in syslog and journctl to read my stdout after sshing into the
device. In other words, I was forced to content with the internal
implementation details of snappy.
So, I think we need 3 things:
1. An admin shell on the device to make admin commands discoverable and to
hide the implementation details of the system.
2. A developer shell (could just be expanded snappy remote) run from the
desktop that hides all the implementation detailss of snappy from the
developer, and makes it easy to deploy, test, and debug snaps on a snappy
image, just like QtCreator does for the phone.
3. SSH for the rare times when someone needs to grovel around the system
and deal with snappy implementation details.
I get that we care about making it comfy for people who are used to Ubuntu
working a certain way. However, snappy does not work that way. I think we
should rather be focused on making snappy easy to use.
Cheers, Rick
On Tue, Jun 16, 2015 at 4: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.
>
> 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:
>>>
>>> 1.
>>>
>>> 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
>>> 2.
>>>
>>> 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”
>>> 3.
>>>
>>> (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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150616/5caae05c/attachment-0001.html>
More information about the snappy-devel
mailing list