> Unfortunately, you're trying to work around misuse of the cloud API's, not > missing features from them. Don't use those volume types, and don't build > systems that rely on single ports and interfaces. IMO rebuild is a misguided > concept (something that took me a long time to realize).
Slightly tangential to this discussion but specifically to your comment about rebuild: HP (and I believe RAX) kept asking OpenStack infra to use rebuild in node pool instead of constantly deleting and creating instances. The reason being it would give them a significant performance advantage and dramatically improve the use of resources in the operators cloud. Node pool would have gained a vastly better resource utilization. The fact infra did not do that (I believe) is partly because it was difficult to refactor node pool for the purpose (after all, it works and there's other things to do) and partly because the resources were free. In a pay-per-use scenario the decision would have been different. This is off topic because it's not about cinder volumes. But I guess there are two take aways: On one hand, in the end they didn't really need rebuild - node pool works without it. On the other, it would have reduced their costs (if paying) and made better use of resources. I'll leave it to the reader to decide which of these matter to you. > ....It requires one > service (Nova) to take all of the responsibility for cross-service > reinitialization > and that doesn't happen so you get weird disconnects like this one. Heat > would be a better choice, as you can simply deploy a new template, which > will replace the old instance in a relatively safe way including detaching and > re-attaching volumes and any VIP's. > > So, to be clear: > > *DO* build systems that store data on volumes that are _not_ the root disk. > Boot a new instance, initialize the configuration using your tools, and then > move the volume attachment from the old to the new. > > *DO* build systems that use DNS or a VIP to communicate so that new ports > can be allocated and attached to the new instance while the old one is stil > active. > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
