From: Matt Riedemann > On 5/15/2017 2:28 PM, Edmund Rhudy (BLOOMBERG/ 120 PARK) wrote: > > Hi all, > > > > I'd like to follow up on a few discussions that took place last week > > in Boston, specifically in the Compute Instance/Volume Affinity for > > HPC session > > (https://etherpad.openstack.org/p/BOS-forum-compute-instance- > volume-affinity-hpc). > > > > In this session, the discussions all trended towards adding more > > complexity to the Nova UX, like adding --near and --distance flags to > > the nova boot command to have the scheduler figure out how to place an > > instance near some other resource, adding more fields to flavors or > > flavor extra specs, etc. > > > > My question is: is it the right question to ask how to add more > > fine-grained complications to the OpenStack user experience to support > > what seemed like a pretty narrow use case? > > I think we can all agree we don't want to complicate the user experience. > > > > > The only use case that I remember hearing was an operator not wanting > > it to be possible for a user to launch an instance in a particular > > Nova AZ and then not be able to attach a volume from a different > > Cinder AZ, or they try to boot an instance from a volume in the wrong > > place and get a failure to launch. This seems okay to me, though - > > either the user has to rebuild their instance in the right place or > > Nova will just return an error during instance build. Is it worth > > adding all sorts of convolutions to Nova to avoid the possibility that > > somebody might have to build instances a second time? > > We might have gone down this path but it's not the intention or the use case > as I thought I had presented it, and is in the etherpad. For what you're > describing, we already have the CONF.cinder.cross_az_attach option in nova > which prevents you from booting or attaching a volume to an instance in a > different AZ from the instance. That's not what we're talking about though. > > The use case, as I got from the mailing list discussion linked in the > etherpad, is > a user wants their volume attached as close to local storage for the instance > as possible for performance reasons. If this could be on the same physical > server, great. But there is the case where the operator doesn't want to use > any local disk on the compute and wants to send everything to Cinder, and > the backing storage might not be on the same physical server, so that's > where we started talking about --near or --distance (host, rack, row, data > center, etc). > > > > > The feedback I get from my cloud-experienced users most frequently is > > that they want to know why the OpenStack user experience in the > > storage area is so radically different from AWS, which is what they > > all have experience with. I don't really have a great answer for them, > > except to admit that in our clouds they just have to know what > > combination of flavors and Horizon options or BDM structure is going > > to get them the right tradeoff between storage durability and speed. I > > was pleased with how the session on expanding Cinder's role for Nova > > ephemeral storage went because of the suggestion of reducing Nova > > imagebackend's role to just the file driver and having Cinder take over for > everything else. > > That, to me, is the kind of simplification that's a win-win for both > > devs and ops: devs get to radically simplify a thorny part of the Nova > > codebase, storage driver development only has to happen in Cinder, > > operators get a storage workflow that's easier to explain to users. > > > > Am I off base in the view of not wanting to add more options to nova > > boot and more logic to the scheduler? I know the AWS comparison is a > > little North America-centric (this came up at the summit a few times > > that EMEA/APAC operators may have very different ideas of a normal > > cloud workflow), but I am striving to give my users a private cloud > > that I can define for them in terms of AWS workflows and vocabulary. > > AWS by design restricts where your volumes can live (you can use > > instance store volumes and that data is gone on reboot or terminate, > > or you can put EBS volumes in a particular AZ and mount them on > > instances in that AZ), and I don't think that's a bad thing, because > > it makes it easy for the users to understand the contract they're > > getting from the platform when it comes to where their data is stored > > and what instances they can attach it to. > > > > Again, we don't want to make the UX more complicated, but as noted in the > etherpad, the solution we have today is if you want the same instance and > volume on the same host for performance reasons, then you need to have a > 1:1 relationship for AZs and hosts since AZs are exposed to the user. In a > public cloud where you've got hundreds of thousands of compute hosts, 1:1 > AZs aren't going to be realistic, for neither the admin or user. Plus, AZs are > really supposed to be about fault domains, not performance domains, as Jay > Pipes pointed out in the session. > > That's where the idea of a --near or --distance=0 came in. I agree that having > non-standard definitions of 'distance' is going to be confusing and not > interoperable, so that's a whole other ball of wax, but it does provide > flexibility for the operator, i.e. in my cloud, 'near' means same rack, but in > some other cloud 'near' means the same data center. >
Sorry about being late on this.... If you're going to use --distance, then you should have specific values (standard definitions) rather than operator defined: And for that matter, is there something better than distance? Collocated maybe? colocated={local, rack, row, module, dc} Keep the standard definitions that are already in use in/across data centers --Rocky > If there are alternative ideas on how to design or model this, I'm all ears. > Or if > some OpenStack clouds are already providing ways to do this, I'd love to hear > how they are doing it (I asked in the session and there are some replies in > the etherpad but we didn't get into details). > > -- > > Thanks, > > Matt > > __________________________________________________________ > ________________ > 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 __________________________________________________________________________ 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