Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-17
10:06:58 tojuvone johnthetubaguy, yes, could remove that part. It was more or less to have os-hypervisors inline with fileds shown, but really not needed
10:11:17 johnthetubaguy tojuvone: I added a comment on the use cases, I think you should write out two flows: what the admin does during a "typical" maintenance, and what the user does. That should show how the new APIs are needed to enable those flows.
10:11:48 johnthetubaguy tojuvone: stuff like schedules windows for AZ A, B and C, user notes the windows and decides what workloads are affected, etc, etc
10:12:14 johnthetubaguy tojuvone: I would keep them separate though, do the admin flow, then the user flow that relates to what the admin has done
10:15:02 tojuvone johnthetubaguy, ok, now just have link to external material. But like you said, better to explain more in spec, so it is more readable
10:15:33 johnthetubaguy tojuvone: right, but you need to describe how that link gets used within the real situation
10:16:08 johnthetubaguy tojuvone: something tells me we should define expected start/stop times and a link for more information, so the scheduler can be told about what is happening
10:17:13 johnthetubaguy but once the use case is clear, it should be easier to understand
10:17:25 xiaoyang i think haveif make compute node add other aggregate which have different availability zone. The instance`s availability zone on this node will not change
10:17:46 tojuvone all that was moved away in Ocata as it was agreed earlier not to have that much in Nova
10:18:08 tojuvone I mean spec in Ocata
10:18:42 tojuvone all that start, stop, state was put to external service where there would only be a link
10:19:10 tojuvone that surely is not so good when looking scheduler should read it from there
10:19:14 lyarwood mdbooth: well given where we are in the cycle now I guess I'm fine with going after the bigger fix but I don't see the harm in also resolving this edge case in the short term
10:19:33 mdbooth lyarwood: The harm I see is that it's obtuse.
10:19:46 mdbooth I think if we add that there, it will never be removed.
10:20:28 lyarwood mdbooth: and if we fix the underlying issue that shouldn't be a problem right?
10:20:35 mdbooth lyarwood: Right.
10:20:49 mdbooth That fix is going to work for shops who use almost entirely BFV.
10:21:03 mdbooth Because it basically disables DiskFilter.
10:21:11 mdbooth But... they might as well just disable DiskFilter.
10:21:18 tojuvone Well, if I get to write enough to spec about the case in admin, user and host monitoring perspective. Let's see where it goes
10:21:38 johnthetubaguy tojuvone: well, we really want to see if just the URL is enough for the required use cases, and write that up in a spec to show that it is
10:21:59 lyarwood mdbooth: right but to hit this you would need to run a mix of bfv and local disks
10:22:19 lyarwood mdbooth: for the reported host values to go negative, AFAICT at least
10:22:19 mdbooth I think you'll hit this if you run 100% bfv
10:22:38 lyarwood ah, it's just on the flavors?
10:22:44 mdbooth Yeah
10:22:46 tojuvone johnthetubaguy, yes
10:23:18 johnthetubaguy tojuvone: basically, a very common request is for the scheduler to not place new VMs where maintenance is about to occur, and prefer unaffected places
10:23:27 mdbooth lyarwood: Did you see the code I highlighted in resourcemanager?
10:23:47 lyarwood mdbooth: yeah, just going back through scrollback now, I missed your convo with bauzas about this yesterday
10:23:48 mdbooth Not 100% sure, but at least moderately sure that's the source of the error.
10:23:53 johnthetubaguy tojuvone: or just prefer things that now are no longer impacted by the maintenance, I guess
10:24:08 lyarwood https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L1049-L1053
10:24:11 johnthetubaguy tojuvone: lets discuss making sure we have enough information to make that all work
10:24:18 mdbooth resource tracker, even. Yeah
10:24:19 bauzas mdbooth: sorry, yesterday's evening was pretty busy and I had no time replying to you
10:24:31 mdbooth bauzas: NP. I was just trying to short cut :)
10:24:33 bauzas mdbooth: what's the gist of the problem ?
10:24:51 mdbooth bauzas: I think it's the code lyarwood just pasted above
10:25:13 tojuvone johnthetubaguy, yes, the scheduling I had earlier as it was mostly wanted by ops
10:25:17 mdbooth bauzas: The issue, I think, is that it doesn't take account of bdms.
10:25:34 mdbooth So, although the flavor has root_gb of X, if the instance is BFV it actually doesn't use that
10:25:41 mdbooth Same with ephemeral
10:25:49 johnthetubaguy tojuvone: we need to keep the use cases that are required like that one
10:25:54 mdbooth And it doesn't account for swap, or kernel/ramdisk
10:26:23 bauzas mdbooth: right, that's a known issue that we're trying to solve by using shared resource providers
10:26:33 mdbooth bauzas: That's a different problem
10:26:42 mdbooth This has nothing to do with shared storage
10:27:01 bauzas mdbooth: it has to do about volumes, right?
10:27:19 mdbooth bauzas: In this case it has to do with block device mappings
10:27:45 bauzas mdbooth: lemme rephrase then
10:27:49 mdbooth IIUC, that code is what's calculating an instance's resource usage to update whatever
10:27:59 mdbooth However, it's incorrectly calculating an instance's resource usage
10:28:16 mdbooth If the thing it's updated is aware of shared storage, it'll still update it incorrectly
10:28:16 bauzas mdbooth: the problem you state is that if you have an attached volume that maps your instance, the flavor disk information is not accurate, right?
10:28:34 mdbooth The flavor disk information doesn't necessarily apply to the instance
10:28:51 mdbooth So although the instance is booted with flavor X which has root_gb=20
10:29:08 bauzas so, mdbooth I said :
10:29:10 bauzas (11:28:16) bauzas: mdbooth: the problem you state is that if you have an attached volume that maps your instance, the flavor disk information is not accurate, right?
10:29:11 mdbooth It may actually be using any amount of root disk between 0 and 20
10:29:21 tojuvone johnthetubaguy, Thanks, I'll work that out.
10:29:56 bauzas mdbooth: it may be using less than 20, but in which case ?
10:29:59 mdbooth bauzas: block device mappings also do volumes, so yeah I guess that's an aspect
10:30:11 bauzas ah-ah I see
10:30:16 bauzas I see your point about BDMs
10:30:28 bauzas the fact that we don't know the real size ?
10:30:31 mdbooth Yes
10:30:33 johnthetubaguy tojuvone: yeah, the aim here is to cover your use cases in a way that fits with long term direction of the APIs etc
10:30:57 johnthetubaguy tojuvone: so keep all the use cases and problems that need to be solved, and concentrate on getting a good user story
10:31:17 johnthetubaguy tojuvone: the negotiation here is on how we implement it, and where the hard stuff goes
10:32:06 bauzas mdbooth: well, the fact is that it depends on what's behind the BDM, right?
10:32:40 bauzas mdbooth: but whatever it is, it's still capping at the maximum size given by the flavor ?
10:32:51 tojuvone johnthetubaguy, Yes and there is different sides. Generic "host state" to be outside with notif about change makes it again easier to catch that in monitoring hosts
10:32:57 mdbooth bauzas: Yes, flavor is a maximum.
10:33:37 mdbooth The issue reported here is that if your instances are predominantly BFV, then RM thinks you ran out of disk long before you actually did.
10:34:02 mdbooth In fact, RM thinks you have negative disk space
10:34:06 bauzas mdbooth: but those instances could max out up to that size
10:34:21 johnthetubaguy tojuvone: yeah, lets get that admin view and user view pinned down nicely
10:34:40 mdbooth bauzas: Interesting idea. Not without rescheduling, I think.
10:34:56 mdbooth bauzas: I think you'd have to resize.
10:35:08 bauzas mdbooth: if my BDM source type is image
10:35:19 mdbooth Even then, can you change the non-volume bdms?
10:36:00 lyarwood don't we have periodic jobs already checking the sizes of local disks etc on each of the hosts? I assumed we were already reporting this somewhere for quotas etc?
10:36:13 bauzas the size on the disk can grow for a non-volume, right?
10:36:26 mdbooth bauzas: I can't think of anything in the libvirt driver which allows resizing/adding ephemeral disks, except for the resize operation
10:36:30 mdbooth bauzas: No
10:36:41 mdbooth This isn't overcommit.
10:36:55 bauzas I'm puzzled honestly
10:36:56 mdbooth This is, the user specified a BDM with a smaller disk size.
10:37:07 mdbooth Or in the case of BFV, no disk at all.
10:37:34 bauzas okay, let's admit a flavor of 0
10:40:53 bauzas mdbooth: tbh, I'm not particularly seasoned with BDMs, so reading https://docs.openstack.org/developer/nova/block_device_mapping.html
10:41:11 mdbooth bauzas: You're not alone :)
10:41:41 bauzas mdbooth: I mean, I trust you when you describe it could be suboptimal
10:42:03 bauzas mdbooth: I'm just tryint to get more picture to know whether it's by design
10:42:40 bauzas mdbooth: lemme explain
10:42:50 mdbooth bauzas: So I'm not that familiar with the resource manager code, which was probably pretty apparent yesterday
10:43:15 bauzas mdbooth: that's how community works :)

Earlier   Later