On 10/28/2013 06:17 AM, John Garbutt wrote: > Is there a reason why you could not just use a Cinder Volume for your > data, in this case?
Yeah, he was saying that's the long term goal, and an Ironic-targeted feature. > While at a first glance, it feels rather wrong, and un-cloudy, I do > see something useful about refreshing the base disk, and leaving the > data disks alone. Prehaps it's something that could be described in > the block device mapping, where you have a "local volume" that you > choose to be non-ephemeral, except for server terminate, or something > like that? Agreed that my first reaction is that it feels wrong. It's making ephemeral disks not so ephemeral. Knowing this isn't the ideal long-term solution doesn't make me feel better about it. But, we can err on the side of practical instead of technical purity here. I'm OK with that. A new block device attribute sounds like a good way to do it, too. There's a somewhat similar flag 'delete_on_termination' for block device mappings. It's used to specify that a cinder volume should be automatically deleted when an instance is terminated. We could have 'preserve_on_rebuild' or something that would just apply to ephemeral disks. -- Russell Bryant _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev