Posted	Nick	Remark
#openstack-nova - 2017-10-03
16:46:40	cfriesen	mriedem: I've reviewed https://review.openstack.org/#/c/381912 (Strict isolation of group of hosts for image and flavor) as promised.
16:49:26	mriedem	ok
16:50:47	openstackgerrit	Merged openstack/osc-placement master: CLI for resource providers https://review.openstack.org/457532
16:52:34	jaypipes	holy shit, the osc thing merged.
16:52:48	cdent	limited tess
16:52:49	cdent	ts
16:52:49	openstackgerrit	Chris Dent proposed openstack/nova-specs master: Spec for limiting GET /allocation_candidates https://review.openstack.org/504540
16:53:10	cfriesen	mriedem: I had an alternate proposal...rather than "strict" flags on the flavor/image (which would affect all the other image properties/flavor extra-specs) I think it'd make more sense to have a "strict" prefix on the metadata key in the host aggregate.
16:53:33	cfriesen	that way you could be strict on some keys but not on others
16:54:24	efried	cdent Nits/questions https://review.openstack.org/#/c/508164/
16:54:54	cdent	roger con aye
16:56:15	openstackgerrit	Matt Riedemann proposed openstack/nova-specs master: List/show all server migration types https://review.openstack.org/489029
17:00:26	cfriesen	I just noticed something really weird...can someone confirm? It looks like AggregateInstanceExtraSpecsFilter will *not* match if a flavor specifies something and a host is not in an aggregate or the aggregate metadata doesn't have what the flavor is looking for.
17:00:52	cfriesen	But it looks like AggregateImagePropertiesIsolation *will* match if the image specifies something that isn't in the aggregate metadata
17:01:32	cfriesen	AggregateInstanceExtraSpecsFilter loops over the flavor extra-specs looking for a match, but AggregateImagePropertiesIsolation loops over the aggregate metadata looking for a match.
17:02:40	exarr	Anyone around I can ask about rabbit connection problems?
17:02:42	openstackgerrit	Merged openstack/nova-specs master: Return Alternate Hosts https://review.openstack.org/504275
17:02:45	exarr	Invalid credentials it says. So I readd the user, change password, check the transtport_url details, all seems correct.
17:02:48	exarr	rabbit logs say "AMQPLAIN login refused: user 'openstack' - invalid credentials"
17:03:00	exarr	Seems clear cut, huh?
17:13:24	dansmith	mriedem: stephenfin: so what is the deal on this nova-manage spec? we're going to just dump syntax compatibility across one release?
17:14:04	mriedem	i wondered about that too, since it said it was unavoidable when moving to cliff
17:14:13	mriedem	which is kind of a non-starter for me
17:14:15	dansmith	seems kinda bad to me
17:14:19	mriedem	you can't break everyone's tooling
17:14:26	mriedem	just because we don't like our under the hood impl
17:14:33	dansmith	right, that's my concern
17:14:39	mriedem	well, unless it's cells v1 :)
17:14:42	mriedem	then break away!
17:20:38	sdague	the flagging structure should be the same more or less
17:20:58	sdague	I guess the devil in the details there, but I wasn't imaging a big shift
17:21:06	openstackgerrit	Lee Yarwood proposed openstack/nova-specs master: Libvirt: Native LUKS decryption by QEMU https://review.openstack.org/490824
17:21:27	melwitt	I'd think we'd need a deprecation cycle for changing nova-manage syntax. is that clock already in motion?
17:22:41	mriedem	sdague: cdent: this needs some more thought https://review.openstack.org/#/c/507762/
17:22:45	mriedem	plus, it came up in newton
17:22:51	mriedem	and there are some issues to overcome
17:22:52	clarkb	as a drive by comment, the use of stevedore (via cliff aiui) in osc is what makes it so painfully slow to use for commands
17:23:07	clarkb	so please don't use entrypoints for cli commands
17:23:21	melwitt	good to know
17:23:21	mriedem	dansmith: you too on https://review.openstack.org/#/c/507762/ because it would require paging instance actions across cells...
17:23:23	mriedem	which we know is fun
17:23:43	mriedem	melwitt: there were some deprecations made in pike
17:23:48	mriedem	to prep for this in queens
17:23:49	cdent	ah, fart, forgot about cross cell biz
17:24:05	mriedem	it's not only that - it's that we literally don't update the updated_at column for intsance actions
17:24:11	mriedem	so filtering on changes-since for that is kind of dumb
17:24:19	dansmith	mriedem: ack will look
17:24:22	sdague	clarkb: it's not going to be entry points
17:24:24	mriedem	like i said, it's come up before
17:24:33	cdent	mriedem, why is that not a bug? (as in, to fix)
17:24:44	sdague	clarkb: it's just going to be non custom cli parsing
17:24:52	sdague	clarkb: there is nothing about stevedore here
17:24:59	mriedem	Kevin_Zheng is on holiday this week but i'll also bug him on the wechat-o-sphere
17:25:40	dansmith	mriedem: instance action list is per instance, right? so no paging across cells?
17:26:03	clarkb	sdague: I thought cliff had some baked in ideas of registering commands via stevedore as part of its command parsing
17:26:10	clarkb	sdague: but maybe its optional
17:27:18	cdent	mriedem: “ it's that we literally don't update the updated_at column for intsance actions” <- Is there a reason why for that? Isn’t that what updated_at means?
17:28:13	melwitt	I didn't think we updated individual instance action records. aren't they just written once?
17:28:50	melwitt	like, "instance created" "instance rebooted" "instance rebuilt" it's not like you go back and edit those
17:30:03	dansmith	updated_at is built into oslo.db
17:30:14	dansmith	so if it's never set on those, it's because we never did a save, AFAIK
17:30:35	dansmith	there are other things missing in that spec,
17:30:44	dansmith	like it doesn't show them actually using the marker they say they're going to,
17:31:06	dansmith	but I assume they really mean start_time, which is its own field
17:31:11	dansmith	separate from the usual three default ones
17:31:31	dansmith	there is a finish_time on that object too
17:31:37	melwitt	yeah, I was trying to say I don't think instance action rows are ever saved, they're created/written once and that's it
17:31:48	sdague	melwitt: how is end time set then?
17:32:08	sdague	or, only if it's set all at once
17:32:25	dansmith	we can update them actually
17:32:34	dansmith	action_event_finish()
17:32:47	dansmith	sets the finish time and calls action.update()
17:32:54	melwitt	oh, weird
17:33:15	dansmith	I'd bet we don't finish all the actions we start though.. like everything else:P
17:38:56	mriedem	i'd have to read back through the specs, but we create the action record and then we just deal with the events
17:38:59	mriedem	which are different records
17:39:15	mriedem	so there is event_start and event_finish
17:40:35	mriedem	and i don't see us ever updating the action record when the event is finished
17:41:31	dansmith	mriedem: https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L6224
17:41:48	dansmith	ohh, the action and event I'm getting confused I guess
17:42:07	dansmith	we actually just return the action from the action_finish() thing
17:42:17	dansmith	not sure why or how that makes sense
17:42:25	dansmith	but I guess that means we're never updating the _action_
17:42:40	mriedem	correct
17:42:46	dansmith	it doesn't matter though, because changes-since should key on the start_time I would think
17:43:25	dansmith	or it could be on max(start_time, finish_time) in case we ever set finish_time
17:43:30	dansmith	but not updated_at I wouldn't think
17:43:37	melwitt	I think the question was, why isn't updated_at updated and I was saying because it's never updated
17:44:13	cdent	tautology alert
17:44:19	cdent	but: yes
17:44:24	melwitt	haha yeah
17:44:26	dansmith	melwitt: right, I get that, and it's because we're not updating it from action_finish
17:44:43	dansmith	melwitt: I had found action_event_finish() when looking for action_finish() which _does_
17:44:51	melwitt	yeah
17:44:58	dansmith	I dunno _why_ we're not updating it during the finish, but..
17:45:22	dansmith	regardless, I would expect changes-since on this kind of thing to use the inbuilt fields
17:45:22	melwitt	well, because each action is just "instance create started" "instance create finished" and they're separate right?
17:45:27	dansmith	not the default one
17:45:33	melwitt	there's nothing to update about it, it's just there
17:45:48	dansmith	melwitt: except we have a finish method that doesn't finish it, and a finish_time field we never set, apparently

Earlier   Later