| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-08 | |||
| 17:51:54 | mriedem | confusing method name | |
| 17:52:06 | jaypipes | mriedem: still takes 10+ seconds to run the "develop-inst-nodeps" part of the job :( | |
| 17:53:23 | jaypipes | mriedem: which I presume is just comparing pip freeze outputs? | |
| 17:53:32 | mriedem | no idea | |
| 17:54:16 | dtantsur | jaypipes: also downloads upper-constraint, if it's a typical job | |
| 17:54:24 | jaypipes | :) | |
| 17:56:58 | mriedem | probably an easy +W on efried's neutronclient change to use the ksa adapter stuff https://review.openstack.org/#/c/509892/ | |
| 17:58:38 | dtantsur | mriedem: oh, you guys haven't switched to in-tree zuul stuff, have you? | |
| 17:59:01 | mriedem | dtantsur: started to | |
| 17:59:06 | mriedem | but not much there yet | |
| 17:59:18 | mriedem | actually nothing until https://review.openstack.org/#/c/514309/ | |
| 17:59:19 | dtantsur | I see. so any changes still go to project-config? | |
| 17:59:25 | mriedem | dtantsur: yeah | |
| 17:59:32 | mriedem | unless you want to build it on top of https://review.openstack.org/#/c/514309/ | |
| 17:59:59 | mriedem | melwitt: you want to get https://review.openstack.org/#/c/514309/ since you've looked at the zuulv3 in-repo stuff before? | |
| 18:00:42 | dtantsur | lemme see what is easier | |
| 18:01:26 | mriedem | stvnoyes: an update on multiattach testing - i added some more tests over the weekend to https://review.openstack.org/#/c/266605/ - the list multiple attachments one and boot from volume one are passing ( https://review.openstack.org/#/c/531386/ ) - the snapshot one is failing, looks like due to some response validation in tempest that doesn't handle 2.59 | |
| 18:02:56 | stvnoyes | mreidem- ok thanks for the update. I am running into a m-a attach failure when attaching to the second instance. debugging that now. | |
| 18:03:15 | mriedem | stvnoyes: with libvirt 3.10? | |
| 18:03:48 | stvnoyes | no, with 3.6 | |
| 18:03:56 | mriedem | what version of qemu? | |
| 18:04:40 | stvnoyes | 2.8 | |
| 18:04:51 | mriedem | hmm | |
| 18:05:07 | mriedem | i'm getting things to work with lvm as the backend, and qemu 2.5 and libvirt 3.6 | |
| 18:05:10 | stvnoyes | may just be that I am missing a patch. I am running it down now | |
| 18:05:36 | stvnoyes | this had been working for me before | |
| 18:08:10 | dtantsur | mriedem: https://review.openstack.org/#/c/531868/ should do it. do you remember if Depends-On project-config changes works? | |
| 18:08:23 | mriedem | you can't depends-on a project-config change, no | |
| 18:09:27 | mriedem | andreas is usually pretty quick to hit these though | |
| 18:10:01 | dtantsur | yep | |
| 18:10:14 | mriedem | dtantsur: does ironic-tempest-dsvm-ipa-wholedisk-agent_ipmitool-tinyipa-multinode also test the multitenant stuff? | |
| 18:10:24 | mriedem | *multitenant network | |
| 18:10:30 | dtantsur | mriedem: that's the correct name of that job, so yes | |
| 18:10:46 | mriedem | oh maybe it was renamed and we just never noticd | |
| 18:10:54 | dtantsur | I think so | |
| 18:14:26 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Ironic: Get IP address for volume connector https://review.openstack.org/468353 | |
| 18:15:42 | jaypipes | mriedem, jgriffith_: your thoughts on this? https://review.openstack.org/#/c/528740/ | |
| 18:16:05 | mriedem | jaypipes: we can't change that as a bug fix | |
| 18:16:06 | mriedem | imo | |
| 18:16:14 | mriedem | it's an api change | |
| 18:16:24 | jaypipes | mriedem: oh, I agree... I don't think it's actually something we should do *at all*. | |
| 18:16:26 | mriedem | https://blueprints.launchpad.net/nova/+spec/volume-backed-server-rebuild | |
| 18:17:05 | mriedem | i've -2ed for now just due to procedure | |
| 18:17:25 | mriedem | i'm sure people want rebuild of volume-backed instances, but i'm not interested in that rats nest atm | |
| 18:19:16 | cdent | efried, jaypipes I've stubbed in https://blueprints.launchpad.net/nova/+spec/placement-aggregate-generation . Since it is microversion, officially we need a spec. | |
| 18:19:42 | ameeda | Hi , when I try to execute this command "mistral-db-manage --config-file /etc/mistral/mistral.conf populate", I got many errors as this http://paste.openstack.org/show/640994/ | |
| 18:20:25 | jaypipes | cdent: you want to handle the spec? | |
| 18:20:33 | cdent | yeah, will do | |
| 18:20:47 | mriedem | that's rocky at this point right? | |
| 18:20:57 | jaypipes | ameeda: wrong channel... try #openstack-mistral | |
| 18:21:08 | ameeda | Thanks ! | |
| 18:21:14 | jaypipes | mriedem: which one? | |
| 18:21:22 | jaypipes | mriedem: the placement agg gen? | |
| 18:21:24 | mriedem | aggregates generation | |
| 18:21:37 | mriedem | or is that blocking something for queens? | |
| 18:22:00 | jaypipes | mriedem: well, not *really* but it can be seen as more of a bug fix that enables drivers like vcenter and powervm | |
| 18:23:44 | mriedem | ok, but we're not prioritizing sharing providers in rocky right? | |
| 18:23:46 | mriedem | *queens | |
| 18:23:58 | cdent | mriedem: it's discussed near here at today's meeting http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-01-08-14.00.log.html#l-127 | |
| 18:24:07 | cdent | it's not clear what the time table is | |
| 18:24:25 | mriedem | it's a rhetorical question :) | |
| 18:24:33 | mriedem | we said in denver that we weren't focusing on sharing providers in queens | |
| 18:24:37 | mriedem | and nested resource providers was the goal | |
| 18:25:05 | cdent | sure, I'm not disputing that. I'm merely asking where management of aggregates fits in | |
| 18:25:13 | mriedem | do aggregates butt up against nested providers? | |
| 18:25:25 | cdent | I'm very happy to not do the work, but in the meeting it was wanted. If we don't want it, cool. | |
| 18:25:30 | mriedem | "butt up" is the technical term | |
| 18:25:36 | cdent | quite | |
| 18:25:38 | mriedem | well, want is fine, | |
| 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, | |