> If there are alternative ideas on how to design or model this, I'm all > ears.
How about aggregates? https://www.youtube.com/watch?v=fu6jdGGdYU4&feature=youtu.be&t=1784 On 05/15/2017 05:04 PM, Matt Riedemann wrote: > 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. > > 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). > __________________________________________________________________________ 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