| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-18 | |||
| 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 | |
| 14:25:15 | johnthetubaguy | that is what I expected, yes | |
| 14:25:23 | johnthetubaguy | (clearly incorrectly) | |
| 14:25:30 | mriedem | that's probably because the RT isn't reporting allocations anymore once all of your computes are pike | |
| 14:25:31 | mriedem | sucka! | |
| 14:25:36 | johnthetubaguy | yup | |
| 14:25:48 | cdent | more importantly, with that expectation not met, scheduling breaks, right? | |
| 14:25:55 | johnthetubaguy | cdent: +1 | |
| 14:26:05 | edleafe | johnthetubaguy: this came up last cycle | |
| 14:26:06 | gibi | efried: I'm +1 on pushing that notification backport through | |
| 14:26:08 | mriedem | in the before times, the update_available_resource periodic task would update the allocations for the instances running on that node | |
| 14:26:13 | mriedem | until we squashed that | |
| 14:26:25 | johnthetubaguy | mriedem: yeah, that is what I was thinking | |
| 14:26:30 | mriedem | efried: i can't +W my own backport | |
| 14:26:52 | edleafe | johnthetubaguy: unfortunately, it was in the middle of a bunch of other discussions about the ironic transition to custom RCs | |