>> To be honest this is probably my fault, AZ's were pulled in as part of >> the nova-volume migration to Cinder and just sort of died. Quite >> frankly I wasn't sure "what" to do with them but brought over the >> concept and the zones that existing in Nova-Volume. It's been an issue >> since day 1 of Cinder, and as you note there are little hacks here and >> there over the years to do different things. >> >> I think your question about whether they should be there at all or not >> is a good one. We have had some interest from folks lately that want to >> couple Nova and Cinder AZ's (I'm really not sure of any details or >> use-cases here). >> >> My opinion would be until somebody proposes a clear use case and need >> that actually works that we consider deprecating it. >> >> While we're on the subject (kinda) I've never been a very fond of having >> Nova create the volume during boot process either; there's a number of >> things that go wrong here (timeouts almost guaranteed for a "real" >> image) and some things that are missing last I looked like type >> selection etc. >> >> We do have a proposal to talk about this at the Summit, so maybe we'll >> have a descent primer before we get there :) >> >> Thanks, >> >> John >> >> >> __________________________________________________________________________ >> >> 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 >> > > Heh, so when I just asked in the cinder channel if we can just > deprecate nova boot from volume with source=(image|snapshot|blank) > (which automatically creates the volume and polls for it to be > available) and then add a microversion that doesn't allow it, I was > half joking, but I see we're on the same page. This scenario seems to > introduce a lot of orchestration work that nova shouldn't necessarily > be in the business of handling. I tend to agree with this. I believe the ability to boot from a volume with source=image was just a convenience thing and shortcut for users. As John stated, we know that we have issues with large images and/or volumes here with timeouts. If we want to continue to support this, then the only way to make sure we don't run into timeout issues is to look into a callback mechanism from Cinder to Nova, but that seems awfully heavy handed, just to continue to support Nova orchestrating this. The good thing about the Nova and Cinder clients/APIs is that anyone can write a quick python script to do the orchestration themselves, if we want to deprecate this. I'm all for deprecating this.
Walt __________________________________________________________________________ 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