| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-19 | |||
| 22:19:48 | dansmith | melwitt: yeah, then you need to do something in a different order I guess | |
| 22:19:50 | melwitt | dansmith: check_deltas only works if the quota has been converted to Countable | |
| 22:19:56 | dansmith | yeah | |
| 22:24:34 | melwitt | I shall think on it | |
| 22:25:03 | melwitt | my brain's too fried at the moment | |
| 22:28:23 | eandersson | Is there a way to extend the data in metadata? (e.g. adding tenant name) | |
| 22:53:45 | mriedem | eandersson: you can update the metadata associated with a server yes | |
| 22:54:09 | mriedem | eandersson: https://developer.openstack.org/api-ref/compute/#server-metadata-servers-metadata | |
| 22:54:42 | mriedem | https://docs.openstack.org/cli-reference/nova.html#nova-meta | |
| 23:04:53 | mriedem | melwitt: did you get a patch up for that ironic unit test failure? | |
| 23:05:20 | melwitt | mriedem: yes, https://review.openstack.org/458161 | |
| 23:05:28 | mriedem | sweet | |
| 23:06:00 | melwitt | I think the only thing it misses out on is running the _wait_state function but I think one of the other unit tests runs it | |
| 23:06:10 | melwitt | double check it though | |
| 23:06:39 | mriedem | the commit message says it's covered in other tests | |
| 23:06:43 | mriedem | i guess you're lying | |
| 23:06:45 | mriedem | potentially | |
| 23:07:42 | mriedem | but yeah there are | |
| 23:07:45 | mriedem | off the hook this time witt | |
| 23:10:48 | openstackgerrit | Mathieu Gagné proposed openstack/nova master: Add ability to signal and perform online volume size change https://review.openstack.org/454322 | |
| 23:10:56 | melwitt | haha | |
| 23:11:57 | melwitt | I thought I saw it covered in other tests but maybe I misunderstood something | |
| 23:12:38 | mriedem | +2 | |
| 23:14:07 | melwitt | mriedem: thanks. at first I removed those overrides but then kept them to use in the assert_called_with to verify they're being passed along to the timer as expected | |
| 23:14:36 | mriedem | alright - that's fine for the configurable one, the module scope variable was just there for tricking the timer | |
| 23:14:46 | melwitt | oh | |
| 23:22:27 | mriedem | mdbooth: do you plan on rebasing this https://review.openstack.org/#/c/430213/ ? - something came into triage today that was a duplicate | |
| 23:23:18 | mriedem | sean-k-mooney: who is running the intel 3rd party ci now that wznoinsk is gone? | |
| 23:39:25 | imacdonn | mriedem, still around ? | |
| 23:41:29 | mriedem | imacdonn: yeah | |
| 23:42:11 | openstack | Launchpad bug 1662483 in OpenStack Compute (nova) "duplicate for #1683972 detach_volume races with delete" [Undecided,In progress] - Assigned to Matthew Booth (mbooth-9) | |
| 23:42:11 | imacdonn | hey .. re. https://bugs.launchpad.net/nova/+bug/1683972 | |
| 23:42:20 | imacdonn | thanks, openstack | |
| 23:42:57 | imacdonn | I'm not sure it's really the same problem as the one you marked it a dup of .. it's slightly related, I guess | |
| 23:43:30 | mriedem | feel free to unduplicate it if you want, but i thought the solution was the same | |
| 23:43:36 | mriedem | lock on detach_volume in the compute manager | |
| 23:44:01 | imacdonn | my locking was way more extensive (and possibly way more wrong, but it works for me) | |
| 23:44:12 | mriedem | care to post your change? | |
| 23:44:18 | mriedem | i'm sure mdbooth would like to look at it | |
| 23:44:24 | imacdonn | but my case was overlap between attach and detach .. not two detach's | |
| 23:44:39 | imacdonn | if mdbooth is the right guy, I can get with him ... what TZ is he in ? | |
| 23:45:08 | mriedem | UK | |
| 23:45:27 | mriedem | so he'd be around in the morning | |
| 23:46:05 | imacdonn | OK, I'll look for him them ... I can post what I did somewhere, but I'm fairly sure it's not "right" | |
| 23:46:27 | mriedem | hard to know if you don't post it | |
| 23:46:40 | mriedem | posting to gerrit would be preferrable, else you could attach a patch file in the bug report | |
| 23:47:44 | imacdonn | I think it's too much of a hack to put in a review .. should I attach to my bug (the one marked as a dup) ? | |
| 23:49:41 | mriedem | nothing is too much of a hack to put it in a review - just put WIP in the prefix of the commit title | |
| 23:49:47 | mriedem | or -Workflow it in gerrit | |
| 23:49:53 | mriedem | no one is going to think less of you :) | |
| 23:50:15 | imacdonn | heh | |
| 23:50:45 | imacdonn | I'll take another look at it first ... don't want to embarrass myself any more than necessary :) | |
| 23:52:49 | imacdonn | I have another thing I wanted to get your opinion on (completely unrelated) | |
| 23:55:36 | mriedem | ok | |
| 23:55:52 | imacdonn | so when nova plugs an instance's vif into a neutron network that has MTU != 1500, something needs to set the MTU on the tap interface. Whose job is that? nova-compute? os_vif? the neutron l2 agent? ... ? | |
| 23:56:02 | imacdonn | asking because it's currently not getting done, and I'm not sure who to blame. | |
| 23:56:18 | imacdonn | For more detail, see https://ask.openstack.org/en/question/105521/whos-supposed-to-set-the-mtu-on-a-nova-instances-vifs-tap-interface/ | |
| 23:56:52 | mriedem | sean-k-mooney: ^ | |
| 23:57:02 | mriedem | imacdonn: in part it depends on the vif type | |
| 23:57:15 | mriedem | the libvirt driver isn't using os-vif yet for all vif types | |
| 23:57:35 | imacdonn | it is in my case .. vif_type is bridge | |
| 23:58:08 | mriedem | then i believe os-vif does it | |
| 23:58:28 | imacdonn | I think I have the terminology right there ... in any case, vif_plug_linux_bridge under os_vif creates the bridge | |
| 23:58:52 | imacdonn | then libvirt creates the domain, which creates the tap interface, and puts it on the bridge | |
| 23:58:57 | mriedem | does the network in neutron have the mtu attribute set? | |
| 23:59:06 | imacdonn | yes | |
| 23:59:40 | imacdonn | I've studied the code, and I can't find anything that's supposed to do the job | |
| 23:59:56 | imacdonn | I don't think os_vif can do it, because the tap interface doesn't exist yet | |
| #openstack-nova - 2017-04-20 | |||
| 00:00:09 | imacdonn | it doesn't exist until libvirt creates the domain | |
| 00:02:50 | imacdonn | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5079 | |
| 00:02:55 | mriedem | do you see Converting VIF in the nova-compute logs at debug level? | |
| 00:03:05 | imacdonn | note that plug_vifs() is called before _create_domain() | |
| 00:03:08 | mriedem | right that's where we start with os-vif | |
| 00:03:09 | mriedem | yeah | |
| 00:03:38 | mriedem | kevinbenton: are you around? | |
| 00:04:01 | kevinbenton | mriedem: AHOy! | |
| 00:04:16 | mriedem | kevinbenton: ^ whats set the MTU on the tap interface? | |
| 00:04:21 | mriedem | for vif_type == bridge? | |
| 00:05:04 | mriedem | i thought it was os-vif | |
| 00:05:15 | kevinbenton | mriedem: no | |
| 00:05:30 | kevinbenton | mriedem: it's either libvirt internals or it inherits from bridge as part of linux | |
| 00:05:33 | mriedem | or does neutron do it once we plug the vif and neutron agent picks that up? | |
| 00:05:43 | mriedem | hmm | |
| 00:06:15 | kevinbenton | mriedem: this is sort of why i wanted to move away from libvirt plugging things into the bridge | |
| 00:06:34 | imacdonn | inheriting from the bridge doesn't work, because the bridge is initially created with MTU 1500, and it won't go any higher until a interface is added .. then it assumes the lowest MTU amongst all member interfaces | |
| 00:06:48 | kevinbenton | imacdonn: hang on | |
| 00:06:51 | imacdonn | k | |
| 00:06:59 | kevinbenton | MTU is set on the bridge by os-vif | |
| 00:07:13 | mriedem | i thought it was this https://github.com/openstack/os-vif/blob/master/vif_plug_linux_bridge/linux_net.py#L91 | |
| 00:07:23 | imacdonn | it can't be | |
| 00:07:28 | imacdonn | or .. maybe I have a bug in the OS | |
| 00:08:09 | imacdonn | # brctl addbr test-bridge | |
| 00:08:17 | imacdonn | # ip l set test-bridge mtu 9000 | |
| 00:08:21 | imacdonn | RTNETLINK answers: Invalid argument | |
| 00:09:15 | kevinbenton | oh hang on | |
| 00:09:24 | kevinbenton | maybe not | |
| 00:09:49 | kevinbenton | i think that branch in os-vif is not exercised with neutron | |
| 00:10:20 | kevinbenton | because https://github.com/openstack/os-vif/blob/master/vif_plug_linux_bridge/linux_bridge.py#L98 is not true with neutron | |
| 00:10:59 | imacdonn | yeah, I only have should_provide_bridge | |
| 00:15:36 | mriedem | ok, well i guess that's why then | |