Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-08
18:25:47 mriedem i just don't want it to be a distraction for queens
18:25:55 mriedem queuing it up for rocky is cool
18:26:16 mriedem reminds me i need to start an etherpad for various rocky ptg stuff, to include spill over from queens
18:26:22 cdent I'm happy to let jaypipes and efried decide. I simply volunteered to do the implementation.
18:27:13 jaypipes mriedem: rocky is fine
18:27:59 mriedem cdent: jaypipes: https://etherpad.openstack.org/p/nova-ptg-rocky
18:28:10 mriedem now i've forgotten what i wanted to put on there from friday :(
18:28:10 cdent ack
18:28:19 mriedem oh yeah
18:29:31 cdent mriedem: If we're punting that to rocky, I don't reckon we need to put it on the ptg agenda, we talked it to deaht already today. I'm sure we'll have plenty of stuff more interesting. So I'll kill it.
18:30:12 mriedem i'll at least target the bp to rocky in launchpad so it's in the list
18:30:42 jaypipes mriedem: the aggregate-affinity one would be good to add to the ptg agenda. I'll do that.
18:31:00 mriedem yeah definitely while we have ironic people around
18:57:31 jaypipes oh shitbuckets.
19:03:16 openstackgerrit Jay Pipes proposed openstack/nova master: func tests for nested providers in alloc candidate https://review.openstack.org/531443
19:03:17 openstackgerrit Jay Pipes proposed openstack/nova master: placement: _get_trees_matching_all() https://review.openstack.org/531512
19:03:17 openstackgerrit Jay Pipes proposed openstack/nova master: add _has_provider_trees() utility function https://review.openstack.org/531474
19:10:31 jaypipes efried: for n-r-p traits handling, we agreed that the following is true, right? "if user requests traits X, Y, and Z and at least one provider within a tree has one of each of those traits associated with it, then collectively the tree meets the required traits constraint"
19:11:35 jaypipes efried: or did we instead say "the providers **that end up providing the resources involved in the request** must collectively be associated with all of the required traits"?
19:12:12 jaypipes edleafe, mriedem, dansmith: your thoughts welcome on ^^
19:12:59 dansmith until we have the more expressive query language, neither is really what we want, right?
19:13:10 dansmith and we kinda have to do the "any" instead of "all" until that point I thought
19:16:18 jaypipes dansmith: let's say I have a compute node with 24 VCPU and 32768G RAM with two child providers representing two PFs. One PF has trait X and one has trait Y. The one with trait X has inventory available for 2 VFs. the PF has no more inventory of VFs. If I request 2 VCPU, 1024 MEMORY_MB and 1 SRIOV_NET_VF, along with required_traits=Y. should the compute node be returned? I would say "no"...
19:16:31 dansmith wow 32T of ram?
19:16:37 jaypipes heh
19:16:41 jaypipes you get my drift..
19:17:06 dansmith it just means we have to tag everything with every trait right?
19:17:23 dansmith like you'd have to tag a compute node with "has-nvidia" so that you could ever get a gpu
19:19:05 jaypipes dansmith: no, that's not quite what I'm getting at... I'm wondering whether the "collectively meets the required traits constraint" should only consider those (child) resource providers that would be providing the resources for the request. In the case described above, the child provider that has the required trait Y does not provide the inventory of SRIOV_NET_VF for the request. Instead, the child provider with trait X is providing that
19:19:06 jaypipes inventory.
19:19:47 dansmith well, I think I get that, I'm just not sure how you're going to scope it to the right thing,
19:19:54 jaypipes but "collectively", the provider tree representing the compute node and all its child providers "meets the constraints"
19:20:03 dansmith meaning how placement is going to know that "has required trait X" applies to the vif and not the disk
19:20:25 dansmith since the query didn't scope it as such
19:20:35 jaypipes dansmith: well, I can apply the filter on traits *after* already processing the filter for resource amounts.
19:20:46 dansmith right,
19:20:53 dansmith which will filter out disks without trait X yes?
19:20:59 jaypipes right
19:21:09 dansmith which means you don't get any disk, which isn't a useful thing if you're trying to boot an instance, no?
19:22:06 jaypipes well, that would just mean that this compute node would not be returned in the GET /allocation_candidates query since the required traits are not associated with the providers that would end up providing the resources for the request
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]

Earlier   Later