| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-24 | |||
| 21:19:22 | openstackgerrit | Andrey Kurilin proposed openstack/python-novaclient: DO NOT MERGE: check OSC https://review.openstack.org/420941 | |
| 21:23:54 | mriedem | vladikr: so i was thinking about vlan vifs and tempest testing, we probably don't have any jobs that use vlan tags on ports do we? | |
| 21:29:44 | cdent | bauzas: your grenade run has just finished | |
| 21:29:56 | bauzas | cdent: yup, was following | |
| 21:30:06 | cdent | on the old side it looks like placement auth isn't in place: http://logs.openstack.org/30/424730/2/check/gate-grenade-dsvm-neutron-ubuntu-xenial/6ccea97/logs/old/screen-n-cpu.txt.gz#_2017-01-24_20_36_57_937 | |
| 21:30:47 | bauzas | cdent: that's for the full grenade job right? | |
| 21:31:02 | bauzas | cdent: if so, I think it's not a problem | |
| 21:31:13 | cdent | Oh, is it just changed for one of the jobs not all? | |
| 21:31:32 | bauzas | cdent: I was rather looking at the multinode job | |
| 21:31:51 | bauzas | cdent: I provided a from-newton script | |
| 21:32:04 | bauzas | cdent: so it's not changing the old side AFAICU | |
| 21:32:24 | cdent | ah, I follow now | |
| 21:33:03 | bauzas | cdent: that said, I'd like to see the old compute calling the new scheduler by grenade | |
| 21:33:13 | bauzas | cdent: so IIUC it's the multinode job | |
| 21:33:36 | bauzas | but maybe dansmith can insight? | |
| 21:34:11 | bauzas | I think I'm also starting the placement engine for any node, including a specific compute only | |
| 21:34:38 | cdent | bauzas: I've got to call it a night, but if there's something I can do to help out tomorrow morning leave me a note somewhere (email or here is fine) | |
| 21:34:52 | bauzas | cdent: I'm just rechecking the scheduler change | |
| 21:35:00 | bauzas | cdent: for seeing if it's now happy | |
| 21:35:03 | bauzas | cdent: sure | |
| 21:37:37 | dansmith | bauzas: from-$release only runs on the main node AFAK | |
| 21:38:28 | bauzas | dansmith: I replied to you on the ML thread about optional resources | |
| 21:38:38 | bauzas | dansmith: have you seen my other emails ? | |
| 21:38:45 | dansmith | yeah | |
| 21:39:01 | bauzas | and why I think it's understandable, I think asking that for Ocata seems difficult to me | |
| 21:39:17 | bauzas | the gate itself is even not running DiskFilter... | |
| 21:39:22 | bauzas | oops | |
| 21:39:26 | bauzas | CoreFilter I meant | |
| 21:39:57 | bauzas | and we also have an assertion that says amount can't be 0 - but we have a lot of flavors having root_gb=0 | |
| 21:40:51 | bauzas | so what should I ask for if a flavor is set to root_gb=0 for example ? | |
| 21:41:13 | bauzas | I mean, I totally understand jaypipes's opinion about why it's a wrong direction | |
| 21:41:24 | bauzas | I just think it's not something we should stop by Ocata | |
| 21:42:52 | cburgess | dansmith: If I have an instance object (returned from novaclient) is there an easy way to refresh the status and task_status from the DB? Or do I have to do a full server.get() again? | |
| 21:43:33 | dansmith | cburgess: you don't get instance objects back from novaclient, you get a dict.. so yeah, you have to .get() again | |
| 21:43:35 | cburgess | OK well not from the DB since clearly it has to make an API call since I'm using novaclient. I mean do you just get it again or is there some swanky built-in to refresh it? | |
| 21:43:40 | cburgess | Oh ok.. | |
| 21:44:18 | bauzas | dansmith: saw my points above ? | |
| 21:44:29 | cburgess | Hmm weird.. its got methods defined on it, but I get your point. I'll re-fetch it. | |
| 21:44:52 | dansmith | bauzas: yes, I've read your emails and the points above, I'm not sure what to say and I'm frantically trying to get other work done | |
| 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 | bauzas | mriedem: so I haven't targeted to deprecate them | |
| 22:15:39 | mriedem | ok so we can't 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 | |