On Thu, Jun 12, 2014 at 12:59 PM, Robert Mustacchi <[email protected]> wrote:
> On 6/11/14 17:47 , Nicholas Lee via smartos-discuss wrote: > > On Thu, Jun 12, 2014 at 7:30 AM, Nahum Shalman via smartos-discuss < > > [email protected]> wrote: > > > >> On 06/11/2014 02:55 PM, Alain O'Dea via smartos-discuss wrote: > >> > >>> It is probably possible, but with sharp edges. > >>> > >> > >> The edges are very sharp, even in the simple case. > >> Having just done it last week I would summarize with: > >> If you have to ask how to do it, you shouldn't. > >> > >> -Nahum > > > > > > This is on aspect of smartos that would be nice to have a better system. > > They are talking about a more LTS-style arrangement, which would be good. > > > > Being forced to rebuild a zone if you wish to upgrade to the latest > quarter > > could be fine many cases - simple one application servers - but on the > flip > > side likely to be painful in more complex situations - say when manual > > configuration is required. > > > > > > In part I think the difficult because the zones lofs mount in file from > the > > GZ into /usr. There may be some technical reasons for this, but > personally > > I think that storage is cheap so it shouldn't have to be done that way. > > The sparse nature of the zone, eg. that your /usr is from the GZ > actually has very little to do with this problem and in fact makes the > upgrade path easier when doing a platform update. Because the core > libraries have to be in sync with the kernel, it means that you'd have > to go and copy data around to every zone and manage that -- definitely > not something we want to change. > I wasn't aware of how this work, but this is a good technical reason. Since 95% of unix source built applications can be configure/installed into places like /opt, it's probably not a problem for most of these applications. However, even some important applications seem to have issues. For example like recent struggle with samba (at least one issue is nss_winbind libraries being unable to be installed in /usr/lib) and cpan. While these and other application install issues may be unrelated to the GZ:/usr+/lib readonly filesystem, it does make it harder to debug for people used to the /standard/ way of doing it. > The challenge with upgrading from one release to the next comes from the > third party packages themselves doing things in incompatible ways. We > can't guarantee that your favorite library will not change or break its > ABI. In addition, there are painful things like when Dovecot change its > configuration format, or when you end up having to cross a flag day in > postgres where the version has an on-disk change. > > The problem is that there are so many different packages and upgrade > challenges to come across, that it can be really quite difficult just to > enumerate and test them all. Do we write software to automate all of > those cases, what do you about the cases where you can't do that, etc.? > Most Linux distributions get around this by having package maintainers and package tool sets. Any major change in a package during an upgrade is handled by 1) documentation via console messages, changelogs and readmes, 2) assumption of reasonable defaults, or 3) scripted upgrades - like with mysql. I'm not sure how many people Joyent has working on packaging, but probably less than "one per package" like debian/ubuntu/etc. So that type of system is likely to not possible unless joyent want to build that community. I'm not entirely sure if there is a cure for this, but as Ian says it's a very good reason for clear separation between a vm and the hypervisor. On another note, one of the reasons why I stopped using *bsd was sourced based packaging distribution, which forced everyone to be a package maintainer. Nicholas ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
