| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-17 | |||
| 05:19:34 | openstackgerrit | christopher.uhler proposed openstack/nova-specs master: Spec for libvirt driver extension for Veritas HyperScale https://review.openstack.org/430488 | |
| 06:10:30 | openstackgerrit | Anh Tran proposed openstack/nova master: Remove unused logging import https://review.openstack.org/435261 | |
| 08:17:25 | openstackgerrit | Anh Tran proposed openstack/nova master: Remove unused logging import https://review.openstack.org/435261 | |
| 08:33:17 | xiaoyang | hi, everyone. Why instance live migration after success doesn't change the availability zone? | |
| 08:53:18 | johnthetubaguy | xiaoyang: we don't really support availability zone concept, except for scheduling Nova resources close to Cinder resources when you first boot the instance | |
| 08:53:37 | johnthetubaguy | xiaoyang: sounds like a bug worth reporting (and fixing) though | |
| 08:54:12 | johnthetubaguy | it seems like live-migration shouldn't really allow you to move outside the original availability zone, but I guess we don't check that. | |
| 09:07:59 | bauzas | johnthetubaguy: there is something I saw about AZs | |
| 09:08:09 | bauzas | and live-migration | |
| 09:08:52 | bauzas | johnthetubaguy: tbc, if an instance is booted using the az flag, then we force to keep that instance in the AZ if live-migrate is calling the scheduler | |
| 09:09:01 | bauzas | but only after Mitaka | |
| 09:09:19 | johnthetubaguy | bauzas: ah, right, and I guess unless we force it to a host | |
| 09:11:48 | bauzas | yup using the new flag I added in Newton IIRC | |
| 09:12:01 | bauzas | (or Mitaka? not sure) | |
| 09:12:03 | bauzas | anyway | |
| 09:12:32 | bauzas | that said, I saw something weirdo in that from a internal perspective, and I'm still looking at it | |
| 09:16:46 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Should raise correct error instead of class exist in Placement API https://review.openstack.org/428612 | |
| 09:19:54 | openstackgerrit | Silvan Kaiser proposed openstack/nova master: Removes getfattr from Quobyte Nova driver https://review.openstack.org/428646 | |
| 09:27:53 | openstackgerrit | Markus Zoeller (markus_z) proposed openstack/nova master: live-migration test hook for serial console https://review.openstack.org/347471 | |
| 09:29:32 | bauzas | johnthetubaguy: found the bug I noticed internally https://bugs.launchpad.net/nova/+bug/1652335 | |
| 09:29:32 | openstack | Launchpad bug 1652335 in OpenStack Compute (nova) "The scheduler returns limits even if the instance was boot using AZ forced flag" [Medium,Confirmed] - Assigned to Sylvain Bauza (sylvain-bauza) | |
| 10:01:21 | tojuvone | johnthetubaguy, Hi, continuing host maintenance where left before Ocata as working with it in Craton | |
| 10:01:29 | tojuvone | johnthetubaguy, https://review.openstack.org/428070/ | |
| 10:01:52 | mdbooth | lyarwood: Do you have an opinion on https://review.openstack.org/#/c/430091/5, btw? Trade off of expedient fix for 1 edge case vs a more complex fix for the underlying problem. I ask because your previous reviews were positive. | |
| 10:03:37 | johnthetubaguy | tojuvone: ah, remember to bug me about that one when we are back from the PTG, interesting in getting progress on that | |
| 10:05:05 | tojuvone | johnthetubaguy, Thanks | |
| 10:05:28 | johnthetubaguy | tojuvone: my initial take is you should focus on the os-services API instead of looking as os-hypervisors, because that is where all the actions are like force-host-down | |
| 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? | |