Excerpts from Dan Prince's message of 2014-02-15 06:05:30 -0800: > > ----- Original Message ----- > > From: "Robert Collins" <robe...@robertcollins.net> > > To: "OpenStack Development Mailing List (not for usage questions)" > > <openstack-dev@lists.openstack.org> > > Cc: openstack-operat...@lists.openstack.org > > Sent: Friday, February 14, 2014 11:12:12 PM > > Subject: Re: [Openstack-operators] [openstack-dev] [TripleO] consistency vs > > packages in TripleO > > > > Currently we have two options for upgrading images. A) /mnt/state, B) > > a SAN + cinder. We haven't tested B), and I expect for many installs B > > won't be an option. /mnt/state is 100% technical, as no other options > > exist - none of the Linux distro 'read only root' answers today answer > > the problem /mnt/state solves in a way compatible with Nova. > > I would argue that we haven't tried all of the read only root mechanism > either... at least to the point where we can definitely don't work. Sure > the data has to go somewhere... but it is how we present this to the > end user that is the point in this thread, no? > > All I'm arguing for here is the ability to avoid doing this to our nova.conf > file (what we do today in TripleO): > > state_path=/mnt/state/var/lib/nova > > And instead simply use the Nova default (/var/lib/nova) and have some > other mechanism take care of the mapping for us (bind mounts, etc). In > the context of end user documentation I certainly think this has less > of an impact and is more pleasing to all. >
Could I divert you a bit into explaining what other readonly root schemes exist? I've not looked into them very much as none seemed "simple" to me when you consider that things like /var/lib/dpkg are intended to be readonly parts of the image. I'll start by saying that I'm very suspicious of any mechanism which tries to intermix writable data with readonly data. A TripleO user needs only learn once that "/mnt is preserved, everything else is not". It is also extremely discoverable. So I am quite curious to hear what alternative we could use that would make this simpler. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev