| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-24 | |||
| 21:44:55 | dansmith | bauzas: it's just MHO | |
| 21:45:23 | bauzas | dansmith: okay again, I don't disagree with both of you | |
| 21:45:30 | bauzas | dansmith: I'm just trying to be pragmatic | |
| 21:49:58 | vladikr | mriedem, sorry I was away.. Yes, I didn't find any jobs that uses vlans | |
| 21:50:59 | vladikr | mriedem, also, in order to test it, we need something that will set the {binding:{details:{vlan: X}}} | |
| 21:51:42 | vladikr | mriedem, which is not available for all vnic types | |
| 21:51:44 | mriedem | vladikr: right that's what got me thinking about it | |
| 21:51:53 | mriedem | if we don't have a job that sets the vlan tag on the port details, | |
| 21:52:04 | mriedem | then any tempest test for checking it probably isn't going to do anything | |
| 21:53:09 | vladikr | mriedem, I'm still looking for how to do it.. artom is helping as well (took a break to pickup the kids though) - but I don't know if it's all possible | |
| 21:54:11 | mriedem | vladikr: if the vif details don't have a vlan tag, do we not put anything into the metadata json response? if we always have something in there for vlan tags, even if it's just None or [], we could check for that | |
| 21:55:20 | vladikr | mriedem, if we don't have anything in the binding we just skip the device (unless it has tags) | |
| 21:58:50 | mriedem | bauzas: replied to your thread with a question/clarification | |
| 22:03:13 | bauzas | mriedem: I think your clarification works with me | |
| 22:03:28 | bauzas | mriedem: I'm not only worried by CDs like TripleO | |
| 22:03:59 | bauzas | mriedem: I'm more worried of people trying to change their cloud because we decided so without a warning cycle | |
| 22:04:33 | bauzas | in general, we try to first notice them for a cycle and do the cut on the next one | |
| 22:05:05 | bauzas | here, if you're not changing your cloud before upgrading, you won't get any failure but the scheduler won't work like you set it previosuly | |
| 22:05:24 | bauzas | so I'm pretty sure lots of folks will be confused then | |
| 22:05:56 | bauzas | that said, I'm still having 2 concerns | |
| 22:06:11 | mriedem | bauzas: well you should be reading the release notes before upgrading | |
| 22:06:22 | bauzas | mriedem: I know | |
| 22:06:31 | bauzas | mriedem: and I'm all in favor of that | |
| 22:06:45 | bauzas | but for example, take the flavor root_gb=0 | |
| 22:07:02 | bauzas | people do that for avoiding having issues with shared volumes, right? | |
| 22:07:18 | bauzas | I know we're going to help them with the aggregates BP | |
| 22:07:32 | bauzas | but for the moment, they still have flavors set with that zero size | |
| 22:07:46 | mriedem | we account for that in the RT don't we? | |
| 22:08:01 | mriedem | *scheduler report client | |
| 22:08:04 | mriedem | for disk inventory | |
| 22:08:05 | bauzas | mriedem: but what should we ask to the PlacementAPI if the flavor is 0 ? | |
| 22:08:42 | bauzas | mriedem: eg. https://review.openstack.org/#/c/417961/22/nova/scheduler/filter_scheduler.py@164 | |
| 22:09:13 | mriedem | looking at https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L129 | |
| 22:09:33 | mriedem | it looks like we wouldn't include the DISK_GB resource class if the flavor is 0 root_gb | |
| 22:10:00 | mriedem | bauzas: yeah what you have in there looks correct | |
| 22:10:29 | bauzas | mriedem: because we don't accept an amount of 0 | |
| 22:10:33 | bauzas | in the PlacementAPI | |
| 22:11:04 | bauzas | anyway, my thoughts are: we all agree it's bad to disable those filters | |
| 22:11:17 | bauzas | people should rather use allocation ratios | |
| 22:11:28 | bauzas | and that, we all agreed multiple times in the past | |
| 22:12:01 | bauzas | what I'm advocating is a certain deprecation window for operators | |
| 22:12:30 | bauzas | asking them to make sure they set correct allocation ratios to their computes | |
| 22:12:46 | bauzas | that could be infinite | |
| 22:13:03 | bauzas | that's where I want to be pragmatic | |
| 22:13:09 | mriedem | i personally don't have a problem with that, if we're deprecating the Core/RAM/Disk filters at the same time | |
| 22:13:19 | mriedem | the thing is, | |
| 22:13:33 | mriedem | if we mark those as deprecated, people will probably remove them from their enabled_filters list | |
| 22:13:55 | mriedem | which then gets them into this situation where we don't request VCPU and log a warning saying you don't have the CoreFilter in enabled_filters | |
| 22:13:58 | mriedem | so it gets weird | |
| 22:14:03 | amrith | mriedem, andreykurilin I see that the requirements change has blocked novaclient 7.0.0 | |
| 22:14:09 | amrith | is there a new client version coming? | |
| 22:14:15 | mriedem | amrith: working on it | |
| 22:14:23 | amrith | ok, thx mriedem | |
| 22:15:26 | bauzas | mriedem: the fact with those legacy filters is that johnthetubaguy pointed out that CachingScheduler still needs them | |
| 22:15:39 | mriedem | ok so we can't deprecate them, | |
| 22:15:39 | bauzas | mriedem: so I haven't targeted to deprecate them | |
| 22:15:47 | bauzas | exactly | |
| 22:16:08 | mriedem | and if CoreFilter isn't in the enabled_filters list for the filter scheduler, it's going to log a warning? | |
| 22:16:22 | bauzas | why so? | |
| 22:16:33 | dansmith | mriedem: we have to account for swap and ephemeral in DISK_GB, remember.. | |
| 22:16:36 | mriedem | because long-term we don't want to rely on that | |
| 22:16:52 | mriedem | bauzas: i'm trying to figure out at what point this becomes an error, | |
| 22:16:56 | mriedem | and how you plan to signal that | |
| 22:18:07 | bauzas | mriedem: I was rather thinking of the contrary | |
| 22:18:35 | bauzas | mriedem: ie. signal that by Pike you shouldn't use the legacy filters *if and only if you run the FilterScheduler* | |
| 22:19:36 | mriedem | which means removing CoreFilter from the enabled_filters list right? | |
| 22:19:44 | bauzas | mriedem: yup | |
| 22:20:01 | bauzas | ideally, deployers should stop having the CoreFilter set by Pike | |
| 22:20:09 | bauzas | unless they use another scheduler driver | |
| 22:20:21 | mriedem | and when you make that a hard requirement, you'll remove any conditional check on the CoreFilter such that you're always requesting VCPU filtering of RPs in the filter scheduler? | |
| 22:20:32 | bauzas | yup | |
| 22:21:05 | bauzas | people in general don't disable all three legacy filters | |
| 22:21:14 | bauzas | so they would still get a warning for at least one | |
| 22:21:32 | mriedem | still, | |
| 22:21:33 | mriedem | "ideally, deployers should stop having the CoreFilter set by Pike" | |
| 22:21:49 | mriedem | so at runtime in Ocata, are you going to log a warning if CoreFilter is in enabled_filters? | |
| 22:22:16 | bauzas | mriedem: that's not part of my change yet but I could do that | |
| 22:22:21 | mriedem | but if you do that, | |
| 22:22:36 | mriedem | it means, 'remove CoreFilter from enabled_filters before pike' | |
| 22:22:47 | mriedem | which also means, you don't get an VCPU filtering with RPs in the filter scheduler | |
| 22:22:52 | mriedem | so it's a catch-22 | |
| 22:22:58 | bauzas | mmm good point | |
| 22:22:58 | mriedem | s/an/any/ | |
| 22:23:08 | bauzas | lemme reconsider that | |
| 22:23:25 | bauzas | okay, so your option | |
| 22:23:43 | bauzas | within the FilterScheduler, log a warning if one of the 3 filters is disabled | |
| 22:24:01 | bauzas | that's for Ocata | |
| 22:24:31 | bauzas | so people would need to change their ratios for that during Ocata and enable the filter in Ocata | |
| 22:25:33 | bauzas | now, in Pike we would assume that all clouds have those 3 filters enabled and we would remove the conditionals I just wrote | |
| 22:26:43 | bauzas | honestly, I dunno | |
| 22:26:57 | bauzas | maybe it's because it's becoming late to me and my brain is fried | |
| 22:27:51 | bauzas | dansmith: FWIW, devstack uses the flavor #42 which is having both root, ephemeral and swap set to 0 | |
| 22:28:11 | mriedem | enabling the filters just to say, 'don't do this b/c we're going to stop caring about them for the filter scheduler' is very weird | |
| 22:28:51 | bauzas | mriedem: I agree, that doesn't sound a great plan | |
| 22:29:26 | dansmith | bauzas: yeah, I know.. I'm not sure what root=0 has to do with this discussion at all | |
| 22:30:03 | bauzas | dansmith: https://review.openstack.org/#/c/417961/22/nova/scheduler/filter_scheduler.py@164 | |
| 22:30:43 | mriedem | bauzas: those are different issues, | |
| 22:32:41 | openstackgerrit | Steven Webster proposed openstack/nova: Release PCI devices on drop_move_claim() https://review.openstack.org/370374 | |
| 22:34:45 | mriedem | bauzas: given the retarded dance we'd have to come up with just to say this stuff is changing, i think i'd prefer to just always request VCPU/RAM/DISK_GB as outlined in the spec and make it clear in the release notes that if you didn't have those filters enabled before, you need to adjust for that with allocation ratios now before upgrading to ocata | |
| 22:34:54 | mriedem | bauzas: and as dansmith said, we could also work that into the nova-status upgrade check | |