| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-18 | |||
| 13:42:55 | dansmith | mriedem: tell me you don't care and I'll +W: https://review.openstack.org/#/c/512406/3 | |
| 13:44:17 | openstackgerrit | Ghanshyam Mann proposed openstack/nova-specs master: Spec for API extensions policy removal https://review.openstack.org/508101 | |
| 13:44:48 | efried | stephenfin Before I start, can you confirm that https://review.openstack.org/#/c/361140/29/specs/queens/approved/share-pci-between-numa-nodes.rst@131 was indeed supposed to be "without"? | |
| 13:45:29 | gmann | johnthetubaguy: sdague alex_xu ^^ updated spec - https://review.openstack.org/#/c/508101/ | |
| 13:45:46 | mriedem | dansmith: i could fix quick, but don't care too much | |
| 13:45:48 | gmann | janki: where i can see the nova logs? i see all networking things there | |
| 13:46:10 | stephenfin | efried: Ah, cool, just making sure. I don't do it because it was never something that was taught to do, though I have been known to strip them out when I rewrite stuff. All good point though | |
| 13:46:15 | stephenfin | efried: Yes, without | |
| 13:46:18 | dansmith | mriedem: if it were master I'd want it fixed, but I guess you could make the argument that it doesn't matter on a frozen branch | |
| 13:46:38 | peter-hamilton | hi everyone, i'm hoping to get final feedback on the updated cert validation spec: https://review.openstack.org/#/c/488541/ | |
| 13:46:44 | mriedem | dansmith: i'll fix it quick, 2 minutes | |
| 13:46:45 | peter-hamilton | let me know if you have any questions | |
| 13:46:48 | janki | gmann, https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-pike-upstream-stateful-carbon/36/control_1/n-api.log.2017-10-16-060444.gz | |
| 13:47:15 | mdbooth | dansmith: The problem with that is the hair pulling when some random other test fails because of it, and then you end up having to bisect a testrun to determine the ordering which causes a failure. | |
| 13:47:21 | janki | gmann, nova-cpu logs https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-pike-upstream-stateful-carbon/36/compute_1/n-cpu.log.2017-10-16-060456.gz | |
| 13:47:30 | dansmith | mdbooth: that's what I said in my review, yes | |
| 13:47:51 | dansmith | mdbooth: the thing is that it's in a branch that shouldn't really get a lot of debug anymore | |
| 13:48:04 | mdbooth | dansmith: I was agreeing with you, but with additional angst. | |
| 13:48:35 | mdbooth | lol | |
| 13:48:56 | johnthetubaguy | gmann: there is a bit of wording in there I am not totally sure about, agreed with what I think you mean. | |
| 13:50:06 | gmann | johnthetubaguy: right, ll update thanks | |
| 13:50:18 | gmann | janki: error is floating ip pool is not found | |
| 13:51:00 | janki | gmann, yes. because the API call to create it fails right. | |
| 13:51:21 | gmann | janki: API fail because there is no floating ip pool in your env | |
| 13:52:06 | janki | gmann, isnt that what /compute/v2.1/os-floating-ips do? | |
| 13:52:36 | gmann | janki: you mean POST? | |
| 13:53:00 | janki | gmann, ya. POST on compute/v2.1/os-floating-ips returns 404 | |
| 13:53:01 | gmann | janki: error is raised from here but i can double check the logs to confirm them same - https://github.com/openstack/nova/blob/fce56ce8c04b20174cd89dfbc2c06f0068324b55/nova/network/neutronv2/api.py#L1985 | |
| 13:54:37 | janki | gmann, https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-pike-upstream-stateful-carbon/36/tempest/tempest.log.gz - search for os-floating-ips | |
| 13:56:23 | openstackgerrit | Matthew Booth proposed openstack/nova master: libvirt: Don't VIR_MIGRATE_NON_SHARED_INC without migrate_disks https://review.openstack.org/507202 | |
| 13:58:03 | dansmith | mriedem: fyi, this is the last thing i think is critical to land for fixing up our weird cell0 listing wart: https://review.openstack.org/#/c/508595/8 | |
| 13:58:14 | dansmith | the smartness patches after that are not critical, just gravy | |
| 13:58:38 | dansmith | that jenkins -1 isn't going to disappear, in case that has been deterring review | |
| 13:58:50 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/ocata: libvirt: add check for VIR_DOMAIN_BLOCK_REBASE_COPY_DEV https://review.openstack.org/512406 | |
| 13:58:51 | mriedem | dansmith: ^ | |
| 13:59:07 | mriedem | dansmith: ok, what's been deterring review is the looming newton eol and spec freeze | |
| 13:59:21 | dansmith | mriedem: ack | |
| 13:59:47 | gmann | janki: yea floating ip pool is needed to create the floating ip and if there is nothing then raise error. | |
| 14:00:07 | gmann | janki: what is value of default_floating_pool in conf? under default or neutron section | |
| 14:00:28 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Extract instance allocation removal code https://review.openstack.org/513041 | |
| 14:00:34 | dansmith | mriedem: then speaking of spec freeze: https://review.openstack.org/#/c/510244/ | |
| 14:00:39 | openstackgerrit | Merged openstack/nova-specs master: Add pagination and timestamp filtering support for os-migrations API https://review.openstack.org/506030 | |
| 14:00:46 | dansmith | we *have* to have that for a variety of things | |
| 14:01:16 | dansmith | mriedem: it's a thick review, so you might just want to assume that efried has worded the ass off it and stamp it through | |
| 14:02:03 | efried | stephenfin Are you still looking at ^? | |
| 14:03:10 | janki | gmann, its "public" under [DEFAULT] In nova.conf | |
| 14:03:28 | janki | gmann, these will also depend on values in tempest.conf right? | |
| 14:03:34 | stephenfin | efried: At what now? | |
| 14:03:46 | efried | stephenfin The granular resource request spec | |
| 14:04:14 | stephenfin | efried: It's on my backlog, but I think I saw it merge this morning? | |
| 14:04:23 | stephenfin | Or at least get some +2s? | |
| 14:04:51 | efried | stephenfin Not merged yet, has dansmith +2 and some +1s. | |
| 14:05:42 | gmann | janki: hat tests did not pass the pool so default is being used and not found in neutron | |
| 14:05:55 | gmann | *that | |
| 14:07:15 | janki | gmann, ohhkk..so what next? I still doubt if tempest.conf has anything to do with this | |
| 14:08:17 | stephenfin | efried: Then yes, I should get to it before EOD | |
| 14:08:41 | gmann | janki: did you specified this in tempest.conf - floating_network_name | |
| 14:09:01 | efried | stephenfin Cool, thanks. | |
| 14:09:12 | janki | gmann, thats the blockage. I have no access to tempest.conf and trying to find it somewhere in the logs :( | |
| 14:09:17 | gibi | bauzas: hi! I pushed the follow up patch to refactor allocation removal as you suggested https://review.openstack.org/#/c/513041/ | |
| 14:10:18 | gmann | janki: no prob, i got it fro log and its None | |
| 14:10:48 | janki | gmann, but then again floating IP related calls are passing for other tempest tests expect this one. | |
| 14:10:53 | janki | gmann, where did you find it? | |
| 14:11:06 | openstackgerrit | Steve Noyes proposed openstack/nova master: Update live migration to use v3 cinder api https://review.openstack.org/463987 | |
| 14:13:10 | johnthetubaguy | I am looking at ironic and resource classes, and hitting some problems with the transition around claims, is that a known issue / known user error? | |
| 14:14:37 | johnthetubaguy | basically we update the resource class in the flavor, but the allocations don't get updated | |
| 14:14:47 | johnthetubaguy | dunno if that is as designed | |
| 14:14:52 | johnthetubaguy | it seems to cause problems | |
| 14:15:24 | cdent | johnthetubaguy: you mean already exisitng allocations? | |
| 14:15:30 | johnthetubaguy | cdent: yes | |
| 14:15:50 | cdent | I think you’d have to do some kind of move/migration/resize/whatever for them to change | |
| 14:15:52 | mriedem | johnthetubaguy: isn't that similar to editing a flavor on an existing instance? which we don't allow outside of resize? | |
| 14:16:35 | mriedem | we probably never considered that, but now that flavor resource allocations are going to be tied to classes in the flavor extra specs, and you can edit extra specs at will, | |
| 14:16:41 | johnthetubaguy | so... I should roll back, this is basically trying to do the Pike resource class transition for ironic | |
| 14:16:44 | mriedem | people might think that will auto-adjust the instance using that flavor somehow | |
| 14:17:14 | johnthetubaguy | so I update my ironic nodes to have resources classes, thats all cool | |
| 14:17:40 | johnthetubaguy | put the existing instances have only allocations for some of the resources now | |
| 14:18:02 | johnthetubaguy | so if I update my existing flavors to request the new resource class, and stop requesting VCPU I have a problem | |
| 14:18:33 | johnthetubaguy | when I do a build instance, obviously I see all the nodes with existing instances as candidate hosts, as they still have the resources I need | |
| 14:18:43 | johnthetubaguy | boom... my transition path is busted | |
| 14:19:06 | johnthetubaguy | now what does work, is keeping claiming VCPU and RAM in the flavor | |
| 14:19:26 | johnthetubaguy | but I think that will cause problems in queens when we stop reporting those resources for ironic | |
| 14:19:47 | johnthetubaguy | ... wondering if I am missing something here | |
| 14:20:52 | cdent | does it make any different if you keep the old flavors and makeentirely new flavors? | |
| 14:21:05 | johnthetubaguy | no, same resource request problem | |
| 14:21:48 | mriedem | johnthetubaguy: are you seeing logs in the compute from here? https://github.com/openstack/nova/blob/master/nova/virt/ironic/driver.py#L531 | |
| 14:21:51 | cdent | what about not updating the in use node to have resource classes? | |
| 14:22:08 | johnthetubaguy | all my nodes have a resource class now | |
| 14:22:31 | johnthetubaguy | mriedem: that stuff all works, all my instances have their flavor updated, but the allocations are not refreshed | |
| 14:22:59 | johnthetubaguy | (basically I did update the in use nodes to have a resource class) | |
| 14:23:02 | mriedem | johnthetubaguy: did you change the allocation amounts? | |
| 14:23:04 | efried | mriedem dansmith Can we get https://review.openstack.org/#/c/510957/ pushed through, please? Clean cherry-pick, and got a vendor request for it. | |
| 14:23:19 | johnthetubaguy | mriedem: where would I do that? | |
| 14:23:31 | efried | (cc gibi) | |
| 14:23:40 | mriedem | johnthetubaguy: well i'm confused what you mean by allocations being refreshed | |
| 14:23:52 | mriedem | the allocation amounts shouldn't change just because there is a resource class now | |
| 14:23:55 | mriedem | or, | |
| 14:24:03 | mriedem | do you mean the custom resource class allocatoin isn't showing up for the instance? | |
| 14:24:35 | johnthetubaguy | I mean old instances don't have allocations for the new resource, which breaks the scheduling of new flavors that use the resource class | |
| 14:24:49 | mriedem | so instance A had vcpu/ram/disk allocations before the node.resource_class was set, then you set node.resource_class = baremetal and now you expect to see a 'baremetal' allocation for instance A in placement | |