RFC: Snappy shell
YC Cheng
yc.cheng at canonical.com
Thu Jun 18 04:52:17 UTC 2015
Hi, Please also be aware that there could be different developer. Debug /
hacking / patch to different part of the system could happen like:
- debug certain library in OS snap
- debug Kernel snap: we probably still need to use android bsp/library
like what we do in ubuntu phone now. So the kernel snap might also include
some device tree binaries with/without source code.
- new bsp programming happened inside chip vendor.
We are not only need to make end-user / high-level programmer happier,
without make the life of lower level developer worse (you know that
sometime low level developer need to work even without network enable)
BR, YC
2015-06-16 19:37 GMT+08:00 Rick Spencer <rick.spencer at canonical.com>:
> 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
>>
>>
>
> --
> 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/20150618/9a67369d/attachment-0001.html>
More information about the snappy-devel
mailing list