| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-17 | |||
| 10:09:56 | sean-k-mooney | well that depends | |
| 10:10:36 | sean-k-mooney | if the driver ever generated a CUSTOM_%(virt_driver)_ trait for something that was a standard trait then i think that is a very bad design | |
| 10:11:51 | sean-k-mooney | e.g. i should be able to jsut say HW_CPU_X86_AVX not CUSTOM_LIBVIRT_HW_CPU_X86_AVX | |
| 10:13:07 | sean-k-mooney | if a virt driver has a capablity that is truely unique to it, then i can see it useing a CUSTOM_%(virt_driver) trait that siad i would still prefer them to standarise it in os-tratis | |
| 10:23:08 | sean-k-mooney | kosamara: i have added a potentally dumb alternitive to https://etherpad.openstack.org/p/device-placement-passthrough-2 | |
| 12:28:21 | kosamara | sean-k-mooney I think any custom trait is suboptimal to standard ones, therefore I'll explicitly say that the drivers must use a standard trait for a capability if it exists. What's the point otherwise. | |
| 12:48:31 | openstackgerrit | Jose Castro Leon proposed openstack/nova master: Fix get_device_path from network mounted volume https://review.openstack.org/590188 | |
| 13:13:49 | fried_rice | mriedem: I thought there was a reason we don't claim shelve support. edmondsw? | |
| 13:17:36 | fried_rice | kosamara, sean-k-mooney: It would not be for something like CUSTOM_LIBVIRT_HW_CPU_X86_AVX. The purpose of the separation is so that an operator doesn't attempt to "spoof" some capability that the compute doesn't really have. (Or, easier to manage, if the operator removes a trait the compute really does have - by accident or on purpose - the driver should restore it.) | |
| 13:18:31 | fried_rice | Namespacing is an easy way to do it with custom traits, but I agree having the driver name in there is potentially problematic. The reason I did that was exactly so that it wouldn't conflict with traits we standardized later on. | |
| 13:18:49 | fried_rice | Because I was implementing in an OOT driver :) | |
| 13:19:53 | fried_rice | So if I start with CUSTOM_POWERVM_IOSLOT_VENDOR_ID_XXXX and then we integrate into nova where it becomes POWERVM_DEVICE_VENDOR_ID_XXXX they can both coexist, and when we've had enough time for people to migrate over to the new one, we can remove the old one. | |
| 13:20:15 | fried_rice | But I agree this is also problematic for standard traits. | |
| 13:20:47 | fried_rice | The other obvious way to do it is for the driver to maintain a comprehensive list of all the traits it owns - i.e. all the traits it could *ever* decide to set. | |
| 13:21:41 | fried_rice | And on every iteration, it needs to go through that list and unset any of those traits that shouldn't be set, and set the ones that should. | |
| 13:25:45 | edmondsw | fried_rice mriedem I think we can change that to say shelve is supported | |
| 13:26:16 | fried_rice | edmondsw: Cool, you going to propose? | |
| 13:26:28 | edmondsw | fried_rice sure | |
| 13:29:05 | openstackgerrit | Matthew Edmonds proposed openstack/nova master: comment correction for libvirt multiattach https://review.openstack.org/593050 | |
| 13:44:32 | openstackgerrit | Matthew Edmonds proposed openstack/nova master: Doc: PowerVM does support shelve https://review.openstack.org/593052 | |
| 13:44:40 | edmondsw | fried_rice mriedem ^ | |
| 13:44:42 | fried_rice | ack | |
| 13:45:29 | fried_rice | edmondsw: Do we have a way to test that in the CI? | |
| 13:45:54 | fried_rice | edmondsw: Or at least a local run? | |
| 13:51:19 | edmondsw | fried_rice I presume there are tempest tests for this... | |
| 13:51:48 | fried_rice | edmondsw: I presume that too, but have not investigated. Guessing we could grep our blacklist? | |
| 13:53:06 | openstackgerrit | Chen proposed openstack/nova master: Fix evacuate logging https://review.openstack.org/593055 | |
| 14:04:35 | melwitt | . | |
| 14:07:05 | fried_rice | ō/ melwitt | |
| 14:30:26 | SteelyDan | sean-k-mooney: you confirmed that the new approach works for LB right? If so, can you comment on this patch? https://review.openstack.org/#/c/591735 | |
| 14:30:37 | SteelyDan | *the new waiting during live migration approach | |
| 15:14:30 | openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP Add regression for bug 1787606 https://review.openstack.org/593073 | |
| 15:14:30 | openstack | bug 1787606 in OpenStack Compute (nova) "Multi instance creation rescheduling fails due to a lack of alternates" [Undecided,New] https://launchpad.net/bugs/1787606 | |
| 15:14:31 | openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP scheduler: Only skip the selected host when finding alternates https://review.openstack.org/593074 | |
| 15:18:48 | cdent | melwitt, SteelyDan: Do either of you recall if this be taken back to ocata standalone or the whole stack associated with topic is needed? | |
| 15:19:01 | cdent | melwitt, SteelyDan https://review.openstack.org/#/c/580498/ | |
| 15:19:52 | SteelyDan | cdent: needs to be taken? was taken? | |
| 15:20:02 | melwitt | cdent: if that can be taken standalone? | |
| 15:20:17 | cdent | can be, sorry | |
| 15:20:34 | cdent | looks like probably not, but the commit message kind of implies maybe it could | |
| 15:21:36 | SteelyDan | I dunno, I'd have to look pretty closely, because ocata had very different allocation behavior | |
| 15:21:50 | SteelyDan | so in general I would expect few things that applied to pike to apply directly to ocata | |
| 15:21:55 | cdent | yeah. | |
| 15:22:38 | melwitt | yeah, that's what I wasn't sure about, since a lot of foundational stuff was done in pike, whether this does the right thing on its own without other pike changes in placement | |
| 15:23:24 | SteelyDan | placement didn't change as a result of this, | |
| 15:23:38 | SteelyDan | it was the difference in how/where nova does the allocations in placement in ocata vs. pike | |
| 15:23:48 | melwitt | that is, why wasn't this proposed to ocata along with pike, if there was a reason for that | |
| 15:23:58 | SteelyDan | like, the doubling of the allocations for a migation | |
| 15:24:11 | melwitt | usually things get backported to all applicable places at the same time | |
| 15:24:13 | SteelyDan | although I guess if you're deleting an instance you should delete both | |
| 15:24:59 | SteelyDan | cdent: are you in a hurry such that waiting to ask matt isn't reasonable? | |
| 15:25:09 | SteelyDan | not sure he'll remember more, but.. | |
| 15:25:31 | cdent | SteelyDan: no, not in a super rush, just happened to cross my radar because of some internal flim flammery | |
| 15:25:53 | cdent | i'm going to see what happens if I try to pick just it | |
| 15:26:21 | SteelyDan | in ocata the compute node is authoritative over the allocations, | |
| 15:26:39 | SteelyDan | but even post pike it will be for deleted instances only, | |
| 15:26:47 | SteelyDan | so I'm not positive why this was even a thing on pike | |
| 15:27:48 | melwitt | what do you mean? the compute node will remove allocations for a local deleted instance on pike? | |
| 15:27:57 | melwitt | via auto-heal or something? | |
| 15:28:08 | SteelyDan | yes, | |
| 15:28:13 | SteelyDan | it used to always auto-heal everything, | |
| 15:28:24 | SteelyDan | but as of pike it should only do it for deleted instances once all the ocata computes are gone | |
| 15:28:25 | cdent | looking a bit more closely, it seems the real issue on the internal discussion is this part of the bug fix: https://review.openstack.org/#/c/580499/ , for cleaning up host mappings | |
| 15:28:27 | SteelyDan | let me see if I an find that | |
| 15:28:31 | melwitt | I see | |
| 15:28:56 | openstackgerrit | melanie witt proposed openstack/nova stable/rocky: add zvm into support matrix https://review.openstack.org/593079 | |
| 15:28:57 | openstackgerrit | melanie witt proposed openstack/nova stable/rocky: Add zvm admin intro and hypervisor information https://review.openstack.org/593080 | |
| 15:28:58 | openstackgerrit | melanie witt proposed openstack/nova stable/rocky: Add zvm CI information https://review.openstack.org/593081 | |
| 15:29:18 | SteelyDan | melwitt: https://github.com/openstack/nova/blob/stable/pike/nova/compute/resource_tracker.py#L1249-L1258 | |
| 15:29:37 | SteelyDan | melwitt: prior to pike, the other conditions in that heal/check loop would heal things, but as of pike only the instance.deleted one would | |
| 15:30:05 | SteelyDan | because as of pike the scheduler/conductor/api are authoritative for allocations | |
| 15:30:09 | melwitt | a-ha, thanks | |
| 15:31:54 | cdent | le sigh. it seems the root cause of the internal problem is: we messed various database tables and now things don't look like they should | |
| 15:32:14 | cdent | doctor it hurts when I punch myself! | |
| 15:35:41 | fried_rice | Choke yourself instead. Self-limiting. | |
| 15:39:07 | cdent | what you do in the privacy of your own home... | |
| 15:40:32 | SteelyDan | hehe, thanks I was looking for how to acknowledge the kink | |
| 15:49:09 | cdent | said SteelyDan | |
| 15:49:26 | SteelyDan | :) | |
| 16:35:34 | SteelyDan | sean-k-mooney: did you see my query here earlier? | |
| 16:35:54 | sean-k-mooney | oh am no ill scoll back | |
| 16:36:13 | SteelyDan | (repeat) sean-k-mooney: you confirmed that the new approach works for LB right? If so, can you comment on this patch? https://review.openstack.org/#/c/591735 | |
| 16:37:13 | sean-k-mooney | i confimed that the current code on master works. this is the queens backport of the same? | |
| 16:37:28 | SteelyDan | sean-k-mooney: you don't need to confirm it separately for queens | |
| 16:37:41 | SteelyDan | but if you could comment there I'd appreciate it | |
| 16:38:10 | sean-k-mooney | yes ill just triple check i have the commit in question on the relevent nodes | |
| 16:38:44 | SteelyDan | I think we've already established when the event is sent from neutron in the LB case, so it really shouldn't even be an issue, but... | |
| 16:39:53 | sean-k-mooney | yep i have the master change on both linux bidge node an the conf change. ill comment to that effect | |
| 16:47:18 | sean-k-mooney | speaking of LM testing i should work on that email to the list. | |
| 16:57:16 | melwitt | SteelyDan: docs changes for rc2 proposed starting here https://review.openstack.org/593079 if you could pls take a look | |
| 16:57:39 | melwitt | backports | |
| 16:57:42 | SteelyDan | ugh okay, I'll add it to the list | |
| 16:57:58 | melwitt | thanks | |
| 17:11:27 | SteelyDan | melwitt: don't we know that zvm doesn't support rebuild? | |
| 17:14:33 | melwitt | SteelyDan: mriedem asked them to change it from missing => unknown because since they support spawn and destroy, it sounds like it could work https://review.openstack.org/#/c/532720/8/doc/source/user/support-matrix.ini@378 | |
| 17:15:28 | melwitt | but they aren't testing that path, so "unknown" | |
| 17:17:51 | SteelyDan | it's not implemented in the driver, and untested, which sounds a lot more like "unsupported" than "maybe it'll work if code we wrote long ago to handle it for normal hypervisors, which zvm is not" | |
| 17:17:53 | SteelyDan | but.. okay | |
| 17:18:39 | melwitt | yeah, I think that's why they put "missing" initially | |
| 17:18:48 | SteelyDan | ...yeah | |