RFC: Comfy - a CLI framework to bring the Ubuntu cloud feeling to snappy Ubuntu Core

Ben Howard ben.howard at canonical.com
Wed Jan 14 16:48:41 UTC 2015

On 01/13/2015 05:11 AM, Martin Pitt wrote:
> Hey all,
>> we have been asked a few times about adding one or another tool to
>> ubuntu-core to help you get your job done.
> I think this needs a more concrete definition. I take it we really
> don't want to try and build a framework for development, as that would
> need a gazillion packages, GUI, etc. For those cases it would be much
> better to make it easy to push stuff back and forth between a regular
> Ubuntu desktop and a snappy VM (or physical machine), which to me
> smells more like an sshfs or 9p thing than trying to put an entire
> development desktop into snappy.
> By the looks of your list it sounds like you aim for a comfortable
> shell environment aimed at admins? I. e. you need to be able to poke
> around and see what's wrong with your snappy packages/services, but
> you don't need to build/develop packages on it?
> Alexander Sack [2015-01-13 12:32 +0100]:
>>     + ?: accountsservice - discuss if this is useful/needed
> This is only really useful for graphical desktops, so "N" IMHO.
>>     + !!: apport -> prob. needs to be in ubuntu-core for crash reporting?
> For crashes in ubuntu-core itself it might be useful, but only in the
> restricted "phone" mode -- i. e. auto-submitting crashes to
> errors.u.c., not Launchpad bugs (as these need a web browser and
> interactivity).
>>     + Y: busybox-static
> I think this would only make sense as part of a "rescue" mode. But our
> boot never breaks, right? :-)
>>     + N: command-not-found - highly apt specific (asac believes); double check
> Right, it tells you which apt packages you need to install for a
> command. As you cannot do that on snappy anyway, I'd leave it out.
>>     + Y: cryptsetup
>>     + Y: cryptsetup-bin
> If we want to support encrypted devices, this belongs into snappy
> itself, not comfy.
>>     + Y: debconf-i18n
> IMHO we don't want debconf and thus this package. You can't apt on
> snappy anyway, and pretty much the only thing that would make use of
> this is "dpkg-reconfigure tzdata" for selecting a different time zone.
> But you can also do that with other CLI tools.
>>     + Y: dmidecode
> Rather obsolete and unnecessary IMHO.

Actually, this is a cloud-init dependency and is needed on the generic
target. In fact, right now Snappy will not work on RHEV, VMware/vSphere,
CloudSigma or SmartOS/Joyent with out it. The Cloud-init Datasource uses
dmidecode to detect the platform before doing things that will likely
break on other Clouds.

For example on Joyent and CloudSigma, the meta-data channel is the first
serial device. Rather than blindly writing to the serial console, we
check with dmidecode to figure out if its safe to whomp on the serial
console. This came about because of [1]. And to make things more fun, if
you query on the serial console for CloudSigma before Joyent, the
meta-data channel is broken and the instance won't be properly configured.

I won't argue whether its obsolete, but in terms of utility, it is
needed from in the Cloud world.

[1] https://bugs.launchpad.net/cloud-init/+bug/1322444

>>     + Y: ed
> Urgh, how could we forget about this :-)
> (Seriously, what for?)
>>     + Y: eject
> This should be !! or N IMHO.
>>     + Y: ethtool
> Smells more like !!
>>     + Y: ftp
> If we really want an ftp client (I don't think we do), I'd rather have
> lftp.
>>     + Y: fuse
>>     + Y: ntfs-3g
> If we want to support such file systems, then these should be !!
>>     + Y: gdisk
> Why? Repartitioning snappy sounds rather dangerous..
>>     + Y: git-man
>>     + ?: groff-base - anyone opinions?
> If you want to ship manpages, I think we need that.
>>     + N: grub-legacy-ec2 - lets not do legacy in snappy world
> +1 :-)
>>     + Y: hdparm
> !!
>>     + !!?: ntpdate - does this work in snappy, maybe in core?
> +1 for !!
>>     + Y: open-vm-tools
> Do we really want to support this? ATM snappy is mostly used in QEMU,
> where you can't (or shouldn't) really start sub-VMs in.
>>     + Y: os-prober
> Supporting multiple OSes in a snappy instance starts to sound really
> complex and not like something which we want to support?
>>     + Y: patch
>>     + Y: perl
>>     + Y: perl-modules
> This should be D. Or !! if we want to support Perl in snappy OS.
>>     + ?: policykit-1
> D
>>     + Y: powermgmt-base
> D please. This stuff is oooooooold and crufty.
>>     + Y: rsyslog
> Or just enable persistant journal?
>>     + Y: sgml-base
> D
>>     + ?: ureadahead - on first glance feels unlikely needed if we dont
>> need in the core system itself
> Not necessary, doesn't work under systemd anyway.
>>     + ?: xauth - not clear why xauth is needed on cli comfy systems
> It would be useful to install and run an X app in snappy with X
> forwarding (e. g. ssh -X).
>>     + ?: xdg-user-dirs - feels not relevant for snappy world with its
>> own set of dirs; maybe snappy-user-dirs in core? :)
> +1, snappy pretty much ignores FHS and XDG dirs anyway.
> Martin


Ben Howard
ben.howard at canonical.com
GPG ID 0x5406A866

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x5406A866.asc
Type: application/pgp-keys
Size: 110508 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150114/cc2be12c/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150114/cc2be12c/attachment-0001.pgp>

More information about the snappy-devel mailing list