| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-17 | |||
| 02:58:30 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add zvm CI information https://review.openstack.org/533512 | |
| 02:59:34 | mriedem | melwitt: final zvm docs change is approved | |
| 02:59:38 | mriedem | should be able to cut rc2 after that merges | |
| 03:01:57 | mriedem | +2 on that forced_down docs change as well | |
| 03:10:13 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Update contributor guide for Stein https://review.openstack.org/591258 | |
| 03:21:04 | openstackgerrit | Merged openstack/nova master: Add zvm CI information https://review.openstack.org/533512 | |
| 03:24:21 | Kevin_Zheng | mriedem just came to my head, another thing that strict project to cells won't help much for us is that, we have admin softwares that queries with --all_tenants | |
| 03:26:35 | mriedem | Kevin_Zheng: well, it wouldn't help that specific software, but it would help user server list response timem | |
| 03:26:36 | mriedem | *time | |
| 03:26:52 | mriedem | CERN obviously would have the same issue for admin tooling | |
| 03:26:54 | Kevin_Zheng | yeah I know | |
| 05:54:03 | openstackgerrit | Tao Li proposed openstack/nova master: Rollback instance vm_state to original where instance claims failed https://review.openstack.org/592252 | |
| 06:21:11 | nehaalhat | stephenfin: Hi do you know any periodic task that will update the aggregates list in Nova? | |
| 07:11:49 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Remove the deprecated API extensions policies https://review.openstack.org/586872 | |
| 07:58:58 | openstackgerrit | Merged openstack/nova master: Update api-guide and api-ref to be clear about forced-down https://review.openstack.org/492533 | |
| 08:26:30 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Merge extended_status extension response into server view builder https://review.openstack.org/592092 | |
| 08:40:58 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Add get_by_cell_and_project() method to InstanceMappingList https://review.openstack.org/591656 | |
| 08:40:59 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: API microversion bump for handling-down-cell https://review.openstack.org/591657 | |
| 08:41:00 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Return a minimal construct for nova list when a cell is down https://review.openstack.org/567785 | |
| 08:41:01 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Return a minimal construct for nova show when a cell is down https://review.openstack.org/591658 | |
| 08:41:02 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Return a minimal construct for nova service-list when a cell is down https://review.openstack.org/584829 | |
| 08:50:48 | openstackgerrit | Tao Li proposed openstack/nova master: Rollback instance vm_state to original where instance claims failed https://review.openstack.org/592252 | |
| 09:04:58 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Placement: any traits in allocation_candidate query https://review.openstack.org/565730 | |
| 09:25:32 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Placement: support mixing required traits with any traits https://review.openstack.org/565741 | |
| 09:39:02 | kosamara | efried: about trait "ownership": Given RP ownership, the only issue that I see trait ownership addressing is the separation of generated and user-provided traits. I see your discussion with Sundar (https://review.openstack.org/#/c/579359/10/doc/source/specs/rocky/device-passthrough.rst@173), but is this actually an issue if RPs are owned by the drivers? | |
| 09:44:30 | kosamara | efried: And for separating user and generated traits, I would also like to hear your argument. When you say "conflict" between the 2, you imply a set of rules that make some traits mutually exclusive? | |
| 09:47:08 | sean-k-mooney | kosamara: we promised operators the ablitiy to add traits to any resouce provider in the past | |
| 09:48:55 | sean-k-mooney | so there is a confilt in that the virt drivers would like to fully own the traits on the resouces they create and the fact that we said operator can add traits to resouce provirers that the virt driver may not be able to determin itself | |
| 09:51:20 | sean-k-mooney | kosamara: also some traits could be multally inclusive such as a disk can both be an ssd and mechanical | |
| 09:52:33 | sean-k-mooney | kosamara: we dont model the compatiablity of traits anyehere and curerntly assume the entity adding the traits will do the right thing | |
| 09:53:22 | sean-k-mooney | for standard traits we might be able to handel that in os-tratis but in general it a problem that we cant fix directly. | |
| 09:53:50 | sean-k-mooney | at least in the CUSTOM_ case | |
| 09:57:56 | kosamara | sean-k-mooney: ok, so the namespacing addresses the operator vs generated part. What I actually don't understand is why the driver *must* fully own the traits, over the operator. If we accept that, then namespacing makes sense, so please explain to me that. | |
| 10:00:37 | sean-k-mooney | well im not sure how namespacing is proposed to work. my understanind is that prevent both the operator and virt drivers form both using stadard traits as such i do not see that as a viable option | |
| 10:01:13 | sean-k-mooney | e.g. either the operator or the virt direver would be able to use the un namespaced standard tratis | |
| 10:06:29 | kosamara | sean-k-mooney: See here the traits sections of my 2nd PS draft: https://etherpad.openstack.org/p/device-placement-passthrough-2 | |
| 10:07:41 | kosamara | sean-k-mooney: exactly, that could be an issue. But still I'm not clear on this, let's wait for efried's input | |
| 10:09:04 | sean-k-mooney | kosamara: i would be stongly opposed to having a CUSTOM_%(virt_driver)_ prefix if i ever need to set that in a flavor to match against it | |
| 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 | |