| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-03 | |||
| 16:25:21 | jaypipes | ralonsoh: np | |
| 16:25:29 | cdent | ralonsoh: it’s (too) easy to do | |
| 16:25:35 | ralonsoh | jaypipes: I always have this in mind: https://youtu.be/LVkknWuGq_I?t=841 | |
| 16:27:39 | mriedem | edleafe: we don't really need both https://blueprints.launchpad.net/nova/+spec/return-selection-objects and https://blueprints.launchpad.net/nova/+spec/return-alternate-hosts do we? | |
| 16:27:56 | mriedem | alternate hosts depends on the selection object stuff, and that's just an object model thing | |
| 16:29:16 | edleafe | mriedem: the selection object spec only came about because of disagreement over a) whether it is needed at all, and b) what it should look like. It was simply a way to reach consensus. | |
| 16:29:36 | mriedem | ok, but all code is going to be written under the return-alternate-hosts bp right? | |
| 16:29:37 | edleafe | alternate hosts could work with the unstructured glob | |
| 16:30:31 | mriedem | maybe i just don't know how you're going to split this up | |
| 16:30:36 | stephenfin | jaypipes: Per comments on that doc you reviewed, you should probably look at https://review.openstack.org/#/c/461456/5 | |
| 16:31:14 | edleafe | it's just the result of switching direction in the middle. Moving forward, let's put all the code under the return-alternate-hosts bp | |
| 16:31:24 | mriedem | ok | |
| 16:31:30 | jaypipes | stephenfin: you mean my "clear as mud..." comment? | |
| 16:31:34 | stephenfin | claudiub: Think this is something you could tackle, given that you are the Hyper-V guy https://bugs.launchpad.net/nova/+bug/1660001 | |
| 16:31:35 | openstack | Launchpad bug 1660001 in OpenStack Compute (nova) " Hyper-V PCI Passthrough" [Low,Confirmed] | |
| 16:31:39 | stephenfin | jaypipes: Correct | |
| 16:32:05 | jaypipes | stephenfin: heh, ok, will do. :) | |
| 16:32:42 | stephenfin | fwiw, I get where sahid is coming from but I think it's a helpful enough usability improvement to warrant inclusion | |
| 16:32:47 | stephenfin | jaypipes: Spot on | |
| 16:35:10 | mriedem | oh btw who is going to be brave and just push this through? https://review.openstack.org/#/c/457532/ | |
| 16:41:28 | claudiub | stephenfin: docimpact, huh. hm, adding details about how to configure assignable PCI devices on Hyper-V in doc/source/admin/pci-passthrough.rst should be enough, IMO. any other thing is the same as other drivers. | |
| 16:41:44 | claudiub | stephenfin: will send a patch today / tomorrow | |
| 16:44:04 | jaypipes | mriedem: done. | |
| 16:45:16 | mriedem | danke | |
| 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 | |