| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-06-08 | |||
| 12:55:45 | mriedem | sdague: somehow stole author from lyarwood on https://review.openstack.org/#/c/441204/ | |
| 12:55:54 | mriedem | and noticed the same this morning when rebasing a change of dan's in devstack | |
| 12:55:57 | mriedem | but caught it this time | |
| 12:56:03 | sdague | mriedem: and nothing in the ~/.gitconfig? | |
| 12:56:20 | mriedem | user@ubuntu:~/git/nova$ cat ~/.gitconfig | |
| 12:56:21 | mriedem | [user] | |
| 12:56:21 | mriedem | name = Matt Riedemann | |
| 12:56:21 | mriedem | email = mriedem.os@gmail.com | |
| 12:56:21 | mriedem | [gitreview] | |
| 12:56:21 | mriedem | username = mriedem | |
| 12:56:21 | mriedem | [core] | |
| 12:56:22 | mriedem | excludesfile = /home/user/.gitignore | |
| 12:56:40 | sdague | and this is all at the cli and not using some other tool? | |
| 12:56:47 | bauzas | mriedem: possibly merging https://bugs.launchpad.net/nova/+bug/1696605 before pike-2 too | |
| 12:56:47 | openstack | Launchpad bug 1696605 in OpenStack Compute (nova) "TypeError: unorderable types: int() < NoneType() possible during quota limit check" [High,In progress] - Assigned to melanie witt (melwitt) | |
| 13:03:13 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Log a warning if there is only one cell when listing instances https://review.openstack.org/440652 | |
| 13:07:16 | bauzas | does the VM really supports the order of NICs that you provided when booting ? | |
| 13:07:24 | bauzas | looks to me hard to respect | |
| 13:07:28 | bauzas | https://bugs.launchpad.net/nova/+bug/1696664 | |
| 13:07:28 | openstack | Launchpad bug 1696664 in OpenStack Compute (nova) "Order of the interfaces is not honored when using virt and SR-IOV interfaces" [Undecided,New] | |
| 13:07:49 | bauzas | sfinucan: any idea of the above ? ^ | |
| 13:07:59 | bauzas | I mean, I suspect that as a non-issue | |
| 13:08:15 | bauzas | but it's not really related to SR-IOV | |
| 13:08:58 | sfinucan | bauzas: I concur - we don't say anywhere that the order is important | |
| 13:09:17 | sfinucan | /respected | |
| 13:10:18 | bauzas | well, we don't say anything in https://developer.openstack.org/api-ref/compute/?expanded=create-server-detail#create-server | |
| 13:10:26 | bauzas | and when looking at code, we're just getting the dict | |
| 13:10:41 | claudiub | bauzas: ah, cool, ty. It's in merge conflict though. :) https://review.openstack.org/#/c/471790/ | |
| 13:10:52 | bauzas | sfinucan: so I'm pretty sure we're not exactly verifying the order | |
| 13:10:59 | sfinucan | bauzas: Agreed. You can close it as invalid, IMO | |
| 13:11:09 | bauzas | sfinucan: will do | |
| 13:11:21 | bauzas | if the user cares about the order, that would be a feature to me | |
| 13:11:32 | bauzas | and good luck with that. | |
| 13:11:43 | bauzas | claudiub: oh good point, will rebase it | |
| 13:15:40 | mriedem | bauzas: sfinucan: there is some network sorting in the neutronv2.api code | |
| 13:15:59 | mriedem | https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L2522 | |
| 13:16:40 | mriedem | that's for networks, but when given ports we get the networks for those ports too so maybe that's what they are thinking | |
| 13:19:32 | bauzas | humpg | |
| 13:20:30 | bauzas | mriedem: so there are two possible outcomes | |
| 13:20:55 | bauzas | mriedem: either we say "sorry, but we don't sort NICs when you have both network and port requests" | |
| 13:21:07 | bauzas | mriedem: or we say it's a valid bug that requires resolution | |
| 13:22:47 | mriedem | i don't want to say anything | |
| 13:24:40 | bauzas | mriedem: so I'll keep the bug open | |
| 13:24:43 | bauzas | :) | |
| 13:24:52 | bauzas | anyone can just look at it | |
| 13:31:16 | mriedem | i replied with some details too and code links | |
| 13:31:30 | mriedem | looks like we do only preserve the order of requested networks, not the networks associated with a requested port | |
| 13:31:49 | mriedem | adding the port.network_id to the list of ordered_networks would be easy, but would probably break something else, | |
| 13:32:03 | mriedem | like i bet that would end up having it create another port on that other port's network or something | |
| 13:32:07 | mriedem | it just gets very complicated | |
| 13:32:29 | mriedem | we could build a 3rd list of networks :) | |
| 13:41:33 | openstackgerrit | Matt Riedemann proposed openstack/nova master: libvirt: handle missing rbd_secret_uuid from old connection info https://review.openstack.org/472266 | |
| 13:42:32 | openstackgerrit | Matt Riedemann proposed openstack/nova master: libvirt: handle missing rbd_secret_uuid from old connection info https://review.openstack.org/472266 | |
| 13:42:33 | mriedem | sdague: here is that fix for the rbd secret uuid ^ | |
| 13:42:47 | mriedem | sdague: which reminds me of something i've thought about for awhile, | |
| 13:43:02 | mriedem | which is adding an admin api to force a bdm.connection_info refresh | |
| 13:43:26 | openstackgerrit | Alex Szarka proposed openstack/nova master: Add method for verify multiple versioned notifications https://review.openstack.org/465526 | |
| 13:43:36 | mriedem | since if you changed things somewhere on the cinder side, or in your underlying storage, i think you have to detach the volume and re-attach it, or reboot the instance to refresh the connection info | |
| 13:43:48 | mriedem | this has come up when people recycle secrets in ceph | |
| 13:44:00 | mriedem | and the only way to update the existing bdm connection info is via straight db hackery | |
| 13:45:43 | mriedem | so we could do something as simple as an rpc cast to the compute, call os-initialize_connection in cinder to get the connection_info and then update the bdm record | |
| 13:45:59 | mriedem | melwitt: haven't you and i talked about something like this before? ^ or at least a periodic task | |
| 13:46:29 | mriedem | the problem is i bet initialize_connection in cinder isn't the same (idempotent) for all volume backends | |
| 13:49:15 | sdague | mriedem: could that come from cinder in the admin event interface? | |
| 13:49:32 | sdague | it would be best if cinder was the one that said to do that when needed | |
| 13:52:18 | mriedem | it could | |
| 13:52:29 | mriedem | but, | |
| 13:52:48 | mriedem | send what? just telling us to do it? because that api doesn't take something like a big json blob | |
| 13:53:15 | mriedem | we could get a "refresh-connection-info" event from cinder though yeah, like we do for network-changed in neutron | |
| 13:57:02 | sdague | yeh, that's kind of what I was thinking | |
| 13:57:24 | sdague | I guess it should be instance oriented? | |
| 13:58:22 | mriedem | yes it would be | |
| 13:58:26 | mriedem | just sent to the ML | |
| 13:58:33 | mriedem | might be a duplicate idea i've already brought up before | |
| 13:58:35 | mriedem | anyway, bbiab | |
| 14:13:37 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: remove cpuset_reserved from __init__ of InstanceNUMATopology https://review.openstack.org/466030 | |
| 14:13:37 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: remove related pinning from __init__ of InstanceNUMATopology https://review.openstack.org/408242 | |
| 14:13:38 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: remove pagesize from __init__ of InstanceNUMATopology https://review.openstack.org/408241 | |
| 14:18:56 | sfinucan | dansmith: I think I finally figured out the remaining kinks with the above ^^^ patches, if you want to take a look at some point | |
| 14:20:06 | openstackgerrit | Hironori Shiina proposed openstack/nova master: Ironic: Check a last error of power action https://review.openstack.org/470754 | |
| 14:20:20 | bauzas | sfinucan: I think the consensus is not to have __eq__ | |
| 14:20:42 | dansmith | sfinucan: nak on the __eq__ yeah :) | |
| 14:20:49 | sfinucan | bauzas: Oh? Any particular reason? | |
| 14:20:59 | bauzas | sfinucan: when you want to verify o.vo objects, you need to verify the fields | |
| 14:21:39 | sfinucan | bauzas: Yeah - we do that in nova/objects/pci_device.py and nova/objects/numa.py | |
| 14:21:51 | sfinucan | ...and we could also do with it in nova/objects/instance_numa_topology.py | |
| 14:22:09 | bauzas | sfinucan: there are multiple reasons, one being that objects can be semantically identical without being the same, like if they're passed over RPC | |
| 14:24:05 | sfinucan | bauzas: You mean there'd be differences other than timestamps and the likes? | |
| 14:25:30 | bauzas | well, take an object, pass it as an argument to a remote method, you won't get the same object at the end | |
| 14:29:52 | sfinucan | hmm, well I'm going to try something to see if it makes sense | |
| 14:30:01 | sfinucan | it might not, but then I'll know :) | |
| 14:31:19 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP/POC Implement new attach Cinder flow https://review.openstack.org/330285 | |
| 14:31:20 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Skip microversion discovery check for update/delete volume attachments https://review.openstack.org/469668 | |
| 14:31:21 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Use 3.27 microversion when creating new style volume attachments https://review.openstack.org/469609 | |
| 14:31:21 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Use microversions for new style volume attachments https://review.openstack.org/469579 | |
| 14:31:44 | mriedem | sdague: could you add the bottom 3 changes here to your review queue? ^ | |
| 14:31:50 | mriedem | the new cinder stuff depends on that | |
| 14:33:03 | sdague | yeh, can do | |
| 14:33:21 | sdague | it will be a minute, in the middle of unrelated stuff | |
| 14:34:24 | mriedem | sure, thanks | |