| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-08 | |||
| 19:22:36 | dansmith | exactly | |
| 19:22:41 | dansmith | which is what I was saying: | |
| 19:22:51 | dansmith | you'd have to tag everything with X to make it come out properly | |
| 19:23:11 | dansmith | your disk and cpu and gpu would all have to have X applied so that you could ask for things with trait X, | |
| 19:23:31 | dansmith | but that doesn't make sense, assuming X is a networky trait you're using to pick which VF/PF/whatever you're looking for | |
| 19:23:37 | jaypipes | right | |
| 19:23:47 | dansmith | okay now I'm confused that you agree | |
| 19:23:57 | jaypipes | I think I've answered my own question :) | |
| 19:24:17 | dansmith | ....mmmokay :) | |
| 19:24:26 | jaypipes | just needed a willing sounding board. | |
| 19:24:32 | jaypipes | or unwilling I suppose ;) | |
| 19:24:54 | dansmith | heh | |
| 19:26:15 | mriedem | jaypipes: i don't know the answer to that - it was one of the questions i asked when that change in the placement api merged, i.e. "what are the rules on this new query parameter?" | |
| 19:26:32 | mriedem | specifically the "in_tree" parameter | |
| 19:26:52 | jaypipes | mriedem: this isn't about that parameter (that parameter doesn't exist for GET /allocation_candidates | |
| 19:27:10 | jaypipes | mriedem: but I can see a similar problem/point with that | |
| 19:34:53 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Collocate encryptor and volume driver calls https://review.openstack.org/460243 | |
| 19:36:57 | edleafe | jaypipes: (catching up) I wasn't clear if the tree for that compute node would contain everything (i.e., both child PFs), or only the children needed to satisfy the request | |
| 19:37:55 | jaypipes | edleafe: yes, tree would contain both PFs. | |
| 19:38:19 | edleafe | ah, ok | |
| 19:38:49 | edleafe | Just the allocation_candidate would be "minimal" | |
| 19:43:36 | jaypipes | edleafe: not sure I follow you.. | |
| 19:45:30 | edleafe | jaypipes: I wasn't clear if the provider tree would only contain parts of the entire tree that were "relevant" | |
| 19:46:07 | edleafe | since you were talking about meeting traits restraints | |
| 19:46:32 | jaypipes | edleafe: ah, so the provider_summaries will include all nodes in the tree, but the allocation_requests would only be the ones that were being consumed from. | |
| 19:46:51 | jaypipes | edleafe: but what I was wondering about was how to winnow the set of provider trees to begin with... | |
| 19:49:08 | edleafe | because the SQL can't be that specific? I.e., match trait to the PF with the inventory? | |
| 19:49:51 | jaypipes | edleafe: no, it's not really a SQL thing... more of a "what order do I apply this filter" thing... don't worry about it. I've got tests coming that show the idea. should be easier to read the tests. | |
| 19:51:51 | edleafe | jaypipes: ack | |
| 20:00:48 | openstackgerrit | Jay Pipes proposed openstack/nova master: add tests for _get_trees_matching_all() with trait https://review.openstack.org/531899 | |
| 20:01:08 | jaypipes | edleafe, mriedem, dansmith, efried: ^^ try that test description on for size... | |
| 20:05:28 | stvnoyes | mriedem: (I figured my problem, I neglected to set MA on the disk) So I was able to create a VM with a vol and did a bfv. I then created a new vm and attached the first vm's boot disk to it (as a data disk). I then did a nova image-create for both vm's. It all worked without errors. Was this the test you were looking for? | |
| 20:06:38 | mriedem | stvnoyes: yeah, that's what i have in https://review.openstack.org/266605 so far | |
| 20:07:34 | mriedem | stvnoyes: here is another one: create a bootable multiattach volume, create server1 from that volume with delete_on_termination=True; then create another server (not bfv) and attach the volume to server2, then delete server1 | |
| 20:07:45 | mriedem | assert that the volume is not deleted and still attached to server2, but server1 was deleted | |
| 20:08:00 | stvnoyes | kk | |
| 20:08:48 | mriedem | i'm going to add another test in here for resize with a multiattach volume attached | |
| 20:09:15 | mriedem | and we likely also need a test for swap volume with a multiattach volume, but that's an admin-level test | |
| 20:13:24 | mriedem | sdague: got a pretty easy +W on efried's neutronclient changes for the ksa adapter https://review.openstack.org/#/c/509892/ | |
| 20:14:05 | sdague | mriedem: looking | |
| 20:18:24 | edmondsw | mriedem sdague the powervm SEA and OVS patches shouldn't merge until we get the CI working, which is waiting on a global req change to merge (already has +W), but they are otherwise ready to start reviewing | |
| 20:18:43 | edmondsw | OVS: https://review.openstack.org/#/c/422512/ | |
| 20:18:52 | edmondsw | SEA: https://review.openstack.org/#/c/523216/ | |
| 20:40:45 | stvnoyes | it's 3:07 in my time zone | |
| 20:40:50 | mriedem | stvnoyes: mayhap you'd like to recreate and fix this https://bugs.launchpad.net/nova/+bug/1741476 | |
| 20:41:03 | stvnoyes | ok I'll take a look | |
| 20:44:10 | openstack | Launchpad bug 1741476 in OpenStack Compute (nova) "Attaching read-only volumes fails" [Undecided,New] | |
| 20:49:21 | efried | jaypipes Sorry, catching up. In the example you gave, I think you should *not* get that host back. We should construct trait presence as narrowly/strictly as possible in the nested scenario: i.e. the traits must exist in the set of providers we're actually *using*; it's not enough for some other (unused) provider in the tree to have that trait. | |
| 20:50:12 | efried | jaypipes And when you (as an op) want to be strict about which traits belong to which resource classes, you have to use granular. | |
| 20:50:52 | jaypipes | efried: k, that matches the assumptions in the patch with the test case. | |
| 20:51:15 | efried | excellent. | |
| 20:52:53 | efried | jaypipes When you say, "check. test assertions (and commented out assertions) are correct and represent the bugs appropriately." -- are you asking for a code comment, or was this just acknowledging that you had looked at the test case and saw that it was good (in the Genesis sense)? | |
| 20:53:09 | jaypipes | efried: no, I'm saying it was good. ++ | |
| 20:53:25 | efried | jaypipes Roger, thanks. | |
| 20:53:32 | jaypipes | efried: sometimes I mark reviews like that just to keep my place in the review. | |
| 20:53:49 | efried | suresure. Just making sure I understood correctly, since you *were* asking for comment updates elsewhere. | |
| 20:54:37 | jaypipes | ack | |
| 20:59:27 | openstackgerrit | Eric Berglund proposed openstack/nova master: WIP: PowerVM Driver: vSCSI https://review.openstack.org/526094 | |
| 21:40:46 | mriedem | nicolasbock: you're with suse right? is this something you can confirm and if so, update the nova install guide for suse? https://bugs.launchpad.net/nova/+bug/1741329 | |
| 21:40:47 | openstack | Launchpad bug 1741329 in OpenStack Compute (nova) "Install and configure controller node for openSUSE and SUSE Linux Enterprise in nova" [Undecided,New] | |
| 21:52:02 | mriedem | lyarwood: hemna: added some notes to https://bugs.launchpad.net/nova/+bug/1741364 - but yeah, spot on, doesn't do anything with getting the ephemeral disk config when building the new guest xml | |
| 21:52:03 | openstack | Launchpad bug 1741364 in OpenStack Compute (nova) "ceph ephemeral info not updated during live migrate" [Medium,Confirmed] | |
| 21:52:20 | mriedem | and cold migration would do that of course, or a hard reboot | |
| 21:52:28 | mriedem | but those involve downtime | |
| 21:54:12 | mriedem | would likely require something like https://github.com/openstack/nova/blob/74deea4d8f66a85e66ec79c72c9f257f562d5afd/nova/virt/libvirt/migration.py#L133 for non-volume disks | |
| 21:57:59 | flwang1 | mriedem: could you please help me understand the relationship between cell and sockets in cpu topo? | |
| 21:58:13 | mriedem | flwang1: i can't help you there | |
| 21:58:27 | flwang1 | mriedem: who is the right person I should ask? | |
| 21:58:30 | mriedem | probably need to talk to stephenfin or sahid when they are around | |
| 21:58:37 | mriedem | UK timezone | |
| 21:58:47 | flwang1 | mriedem: cool, thanks | |
| 21:58:54 | mriedem | or cfriesen (canada | |
| 21:59:26 | flwang1 | mriedem: great, and happy new year! | |
| 21:59:39 | mriedem | same to you | |
| 22:06:31 | bauzas | dansmith: still around ? | |
| 22:07:13 | bauzas | dansmith: I'll upload a new PS tomorrow for https://review.openstack.org/#/c/528832/ based on your's and jaypipes's comments | |
| 22:07:51 | bauzas | dansmith: but you had a main comment about how to recreate the existing mdevs with init_host() | |
| 22:20:24 | bauzas | dansmith: basically the main concern I have is that we don't know if an existing mdev is used by an instance unless by looking at the guest XML | |
| 22:21:13 | dansmith | bauzas: ...right, what's wrong with looking at the xml? that's what I was suggesting | |
| 22:21:37 | bauzas | dansmith: the main point is that it could be a long verification | |
| 22:21:47 | dansmith | bauzas: in what way? | |
| 22:22:04 | dansmith | we already iterate instances on startup | |
| 22:22:11 | dansmith | and do lots of db stuff for each | |
| 22:22:21 | bauzas | a-ha | |
| 22:22:43 | bauzas | in the libvirt init_host() or the compute service one ? | |
| 22:22:54 | bauzas | lemme see | |
| 22:23:12 | dansmith | we iterate instances in the compute manager init_host() | |
| 22:23:19 | dansmith | and call init_instance() (or something like that) for each | |
| 22:23:37 | dansmith | we could call into the driver in there, or just have the driver's init_host iterate instances again, tbh | |
| 22:23:52 | dansmith | just listing all instances from libvirt and re-creating mdevs would be fine and not heavy, IMHO | |
| 22:24:31 | bauzas | I see | |
| 22:25:01 | dansmith | dan@falcon:~$ time (for i in $(seq 0 100); do virsh dumpxml 10 >/dev/null; done) | |
| 22:25:01 | dansmith | real0m1.006s | |
| 22:25:06 | dansmith | on my quite slow machine | |
| 22:25:07 | bauzas | i just wonder how to verify the xml | |
| 22:25:10 | dansmith | I think it'll be fine :) | |
| 22:25:21 | bauzas | heh thanks | |
| 22:25:22 | dansmith | how to verify what/ | |
| 22:25:47 | bauzas | how to verify the guest XML whether it has some mdevs | |
| 22:25:48 | dansmith | it was right when we shut down, we're in init/startup, why not just restore them to the way they were? we can't have processed any compute-side deletes yet | |