| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-18 | |||
| 13:38:04 | stephenfin | efried: Knock yourself out | |
| 13:38:32 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Add pagination and timestamp filtering support for os-migrations API https://review.openstack.org/506030 | |
| 13:38:46 | markus_z | Here's a doc change waiting for review for 5 weeks: https://review.openstack.org/#/c/476188/ | |
| 13:38:55 | stephenfin | efried: Also, saw your reply on the "two spaces indicate age" comment. It was just an amusing article I read once upon a time that stuck with me. Not an actual ageist thing or anything! | |
| 13:39:19 | efried | cdent I agree with you (at least in the sense that I've accepted the stated limitations of the placement architecture). We could conceivably get some mileage out of overloading the 'name' field, or embedding information into gross custom traits. But I would be wanting to look for cleaner alternatives pretty hard before resorting to that. | |
| 13:39:21 | stephenfin | markus_z: Sure, I'll take a look | |
| 13:39:27 | markus_z | stephenfin: thanks! | |
| 13:39:58 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Explain the flow of the "serial console" feature https://review.openstack.org/476188 | |
| 13:41:33 | efried | stephenfin No offense taken, of course. It's an argument that's been made to me before, so you may have caught some blowback from arguments I've had with others who were... um... more serious about it (to the point of -1ing stuff). My take on it is that the reasons for "never do that" don't apply to programmers. | |
| 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? | |