| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-26 | |||
| 16:38:59 | johnthetubaguy | its basically saying, for this flavor, that optional argument is required | |
| 16:39:11 | johnthetubaguy | i mean thats messy, but all the other fixes seem miles out | |
| 16:39:25 | mriedem | cburgess: specifically so you can tie those types of flavors to certain host aggregates? | |
| 16:39:30 | cburgess | What do you mean by this optional argument is required? | |
| 16:39:40 | mriedem | bdms are optional when creating a server | |
| 16:39:47 | cburgess | Oh right yes. | |
| 16:39:50 | mriedem | a flavor saying they are required makes them non-optional | |
| 16:40:48 | cburgess | What if instead of local_disk=True/False we call it bdm_only=True/False. If false use existing logic if True, require BMD and ignore root/ephemeral/etc on flavor. | |
| 16:40:57 | cburgess | That seems like it might be a bit cleaner and less confusing? | |
| 16:41:04 | cburgess | or is it just symantics? | |
| 16:41:25 | johnthetubaguy | but the bdm can have source=local | |
| 16:41:32 | johnthetubaguy | I think | |
| 16:41:46 | cburgess | What? | |
| 16:41:47 | cburgess | Really? | |
| 16:41:50 | mriedem | yes | |
| 16:41:58 | mriedem | https://docs.openstack.org/developer/nova/block_device_mapping.html | |
| 16:41:58 | cburgess | That makes it use the hypervisor local instance path? | |
| 16:42:08 | johnthetubaguy | its maybe more volume_backed_disks_only=True | |
| 16:42:20 | johnthetubaguy | cburgess: yup | |
| 16:42:20 | cburgess | Dear lord... we made a mess. | |
| 16:42:23 | mgagne | what's the use case? Have a flavor with source=volume only? no local whatsoever? | |
| 16:42:28 | johnthetubaguy | cburgess: +1 | |
| 16:42:30 | cburgess | mgagne Correct | |
| 16:42:46 | cburgess | mgagne Make it impossible to ever have nova create disks of any type local to the hypervisors. | |
| 16:43:04 | mgagne | like johnthetubaguy suggested, maybe we need to define the use cases that need to be supported because I see a lot of them | |
| 16:43:30 | johnthetubaguy | so some of them have API workarounds, some don't | |
| 16:43:44 | johnthetubaguy | I think the no_local_disk thing is the big one with no workarounds today | |
| 16:43:46 | cburgess | johnthetubaguy mriedem The other way to do this is make it a confug option on the compute side. Not a flavor extra spec. | |
| 16:43:52 | mriedem | nope | |
| 16:43:56 | mgagne | you can already restrict with max_local_block_devices but I think it's system-wide, not per aggregate or flavor | |
| 16:43:59 | johnthetubaguy | don't like configs changing the API behaviour | |
| 16:44:11 | johnthetubaguy | cburgess: so you get it wrong, and you just get an instance in the error state, I guess? | |
| 16:44:23 | cburgess | johnthetubaguy scheduler does it | |
| 16:44:31 | cburgess | The compute node reports it can't host local disk | |
| 16:44:46 | johnthetubaguy | you still get an instance in the error sate | |
| 16:44:49 | johnthetubaguy | I think | |
| 16:44:59 | mgagne | this means the request still manage to get to the scheduler, past the API | |
| 16:45:00 | mriedem | not if the scheduler can find a host that supports local disk | |
| 16:45:08 | cburgess | johnthetubaguy Thats not different then the 1000s of other things that the scheduler can barf on. | |
| 16:45:22 | johnthetubaguy | mgagne: I totally didn't know that existed, you are right, its API level I think | |
| 16:45:28 | mriedem | which eventually becomes a trait on the compute resource provider | |
| 16:45:39 | cburgess | mriedem Right which would be fine. If I want to support some local and some not that really a characteristic of the compute node directly. | |
| 16:45:44 | johnthetubaguy | mgagne: oh, I see your point, its system wide not per flaovr | |
| 16:45:56 | cburgess | mriedem Right.. I was thinking a trait. | |
| 16:46:03 | mgagne | yea so we would need something flavor scoped | |
| 16:46:04 | cburgess | This compute node can support local, this can't. | |
| 16:46:08 | cburgess | But thats a long way out again. | |
| 16:46:22 | johnthetubaguy | cburgess: yeah, I mean that all makes sense | |
| 16:46:26 | mriedem | johnthetubaguy: i knew about max_local_block_devices because people thought if you set it to 0 it meant nova would automagically always do bfv for you | |
| 16:46:35 | johnthetubaguy | mriedem: ah... right | |
| 16:46:44 | johnthetubaguy | mriedem: I remember that coming up now you mention it | |
| 16:46:46 | cburgess | I actually don't know what that setting does. | |
| 16:46:54 | mgagne | https://wiki.openstack.org/wiki/BlockDeviceConfig#max_local_block_devices | |
| 16:46:59 | mriedem | cburgess: traits are closer than everything else at this point | |
| 16:47:00 | mgagne | it's only to prevent DoS | |
| 16:47:04 | johnthetubaguy | gives you 400 errors, I presume | |
| 16:47:22 | mgagne | so people don't create an infinite amount of local disks | |
| 16:47:32 | cburgess | Ahh... | |
| 16:47:34 | cburgess | OK.. | |
| 16:47:35 | mriedem | cburgess: so that's an alternative we haven't talked about before, | |
| 16:47:40 | cburgess | mriedem Traits? | |
| 16:47:48 | mriedem | traits on the resource provider to say it's local_disk=False | |
| 16:47:58 | mriedem | then tag your flavor with local_disk=False | |
| 16:48:08 | mriedem | scheduler / placement has to find a compute that matches those | |
| 16:48:12 | cburgess | mriedem Why do we need to tag the flavr? | |
| 16:48:22 | melwitt | I thought BFV was supposed to get solved with placement. are you just talking about how to do it in placement? | |
| 16:48:35 | cburgess | mriedem I'm not wild about having to set something in the flavor. | |
| 16:48:54 | cburgess | The fact that a compute node can or can not host local disks is something the compute node is aware of. | |
| 16:48:55 | mriedem | cburgess: how are you going to know where to put instances? | |
| 16:49:02 | cburgess | You shouldn't have to also set the right thing on a flavor. | |
| 16:49:14 | cburgess | I flavor you should I need local disk and the compute node should be able to say "nope not me". | |
| 16:49:27 | mriedem | so all of your bfv goes to the local_disk=False computes, and all non-bfv goes to the local_disk=True computes? | |
| 16:49:49 | cburgess | mriedem Thinking through all the use cases... | |
| 16:50:01 | mriedem | dansmith: super fun cells v2 meeting in 10 minutes i hope | |
| 16:50:04 | cburgess | mriedem This is why I was suggesting a working sessions focused on this... | |
| 16:50:12 | dansmith | oh yep | |
| 16:50:14 | mriedem | cburgess: well, we have the forum session | |
| 16:50:17 | dansmith | mriedem: didn't realize it was that late | |
| 16:50:21 | cburgess | mriedem So many different use case | |
| 16:50:26 | mriedem | cburgess: that's about as working as it's going to get at the summit | |
| 16:50:32 | cburgess | mriedem I know... | |
| 16:50:55 | cburgess | mriedem How badly bike shedded would we get trying to do this on the ML? | |
| 16:51:06 | cburgess | mriedem Where this = discuss different options. | |
| 16:51:17 | openstackgerrit | melanie witt proposed openstack/nova master: Add get_count_by_vm_state() to Instance object https://review.openstack.org/446244 | |
| 16:51:18 | openstackgerrit | melanie witt proposed openstack/nova master: Remove 'reserved' count from used limits https://review.openstack.org/446242 | |
| 16:51:18 | openstackgerrit | melanie witt proposed openstack/nova master: Remove useless quota_usage_refresh from nova-manage https://review.openstack.org/446243 | |
| 16:51:19 | openstackgerrit | melanie witt proposed openstack/nova master: Count instances to check quota https://review.openstack.org/416521 | |
| 16:51:21 | openstackgerrit | melanie witt proposed openstack/nova master: Make Quotas object favor the API database https://review.openstack.org/410945 | |
| 16:51:21 | openstackgerrit | melanie witt proposed openstack/nova master: Add online migration to move quotas to API database https://review.openstack.org/410946 | |
| 16:51:27 | mriedem | cburgess: idk, it's probably worth starting to prime the pump for that session at the forum, | |
| 16:51:42 | mriedem | so we don't start a 40 minute session discussing all of the history and previously discussed options | |
| 16:51:56 | mriedem | and then find out we have 5 minutes left with nothing new to say | |
| 16:52:22 | cburgess | mriedem What I don't like about most of the solutions we have discussed is that if you forget to flag a flavor correctly then it could get placed on a compute node that doesn't want local storage. | |
| 16:52:36 | mriedem | cburgess: before starting a ML thread, | |
| 16:52:47 | mriedem | maybe i start an etherpad, which i'll need for the session anyway, | |
| 16:52:48 | cburgess | mriedem I feel like we need a method that ensures a compute node can assert that it can never ever host a local disk. | |
| 16:52:58 | mriedem | and we can start listing the use cases and options, and pros/cons for each option | |
| 16:53:01 | mgagne | maybe just list the use cases, we don't need to agree on the validity of the need, just list them, list associated workaround/limitations, etc. and start from there | |
| 16:53:07 | mriedem | *then* put that in the ML for discussion | |
| 16:53:08 | cburgess | mriedem Yeah.. lets start with an etherpad. Once we get it to an ok state we can post it to the ML. | |