On 2017-09-14 11:56, Peter Tribble wrote: > On Thu, Sep 14, 2017 at 8:31 AM, Alexander Pyhalov <[email protected]> wrote: > On 09/13/17 11:01 PM, Peter Tribble wrote: > > Which begs the question - is systems innovation done and dusted? Hi. > I speak from user perspective, 'the things I want to see in illumos'. > > 1) Simple zone/system sharing. I just want to create an image and share it, > so that it could be run on bare metal or in zone.
So, like the Universal Archives (or whatever it's called) that Solaris has. I've been looking at using the aci format (from Linux container space) to do this. > And I hope that it will be able to run on any more-or-less up-to-date illumos > distribution. And it would be good to do something with to make GZ and NGZ > more loosely coupled, so that I shouldn't update them at the same times > (running fresh zones on older kernels). Tribblix has this, partly. I have alien zones (run a different distro in a zone) and images like docker (from my mvi project). > Docker had us in this area. They have a slightly eaiser time of it, because their stability boundary is the kernel syscall layer, rather than libc. (Even so, it isn't actually true that you can take a docker image and move it to a different system and guarantee it behaves identically. It'll work most of the time, though.) Perhaps it's time we considered stabilising syscalls or looking at libc evolution a bit differently. > 2) Zone/VM live migration. Don't tell me "it's too hard, use clusters". I > want to have an illumos-based cluster for virtualization purposes, > VMware/Linux KVM/even OpenVZ do it, why can't we? I'm not sure you could do that easily for zones. Although this is actually tied in with suspend/resume (of a process), and potentially migrating the suspended process to a different node or restarting it after a reboot. which used to work but I haven't seen for a while. Although I see a need for higher-level tooling to manage a distributed set of zones (as opposed to moving zones about). > 3) RAIDZ reconfiguration. I want to enlarge pool without introducing new > logical vdev. > > 4) ZFS shrinking. I've provisioned too much space for this FS on my storage > and want to shrink volume. What should I do? Yes. But not our problem, as OpenZFS is a separate project. I suspect they'll get around to this in time. I've heard various suggestions to avoid the full BP rewrite problem. Just a quick note, I think Nexenta is in the process of getting the vdev removal stuff merge. Which is a step in that direction, you can then remove a top level vdev (not sure if it is just a single disk vdev or also a mirror, raidz,...) > 5) Be usable as OpenStack node (at least compute node). I started to get OpenStack working once, but it's an enormous pile of different projects and I couldn't justify the effort as I couldn't see a situation in which I would actually use it personally. > 6) Customizable FMA agents. I want to have generic API for writing custom > agents, which would, for example, allow me to write an agent to send me a SMS > when DBMS service has suddenly gone to maintenance (in ~ 10 lines of shell > code). That's a good example of a small project that could give huge benefits. The whole SMF/FMA notification piece needs a good rework. (And implementing SMF monitor methods while we're at it). > As I understand, 1/2/5 is already implemented (perhaps, partially) in Solaris > 11. > -- > Best regards, > Alexander Pyhalov, > system administrator of Southern Federal University IT department -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ILLUMOS-DISCUSS | Archives [1] | Powered by Topicbox [2] Links: ------ [1] https://illumos.topicbox.com/groups/discuss/discussions/T83f198c8597cf8e3-M94aec48fdae0b1f2806a5809 [2] https://topicbox.com ------------------------------------------ illumos-discuss Archives: https://illumos.topicbox.com/groups/discuss/discussions/T83f198c8597cf8e3-M63afa6e948441695b85d43a9 Powered by Topicbox: https://topicbox.com
