Posted	Nick	Remark
#openstack-nova - 2017-01-24
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
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

Earlier   Later