| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-06-08 | |||
| 12:37:44 | mriedem | i know what caused that | |
| 12:38:15 | mriedem | https://review.openstack.org/#/c/389399/ | |
| 12:38:37 | mriedem | i think | |
| 12:40:51 | mriedem | so it looks like in newton they had rbd auth enabled on the cinder side, but didn't have the secret uuid coming from cinder, it was coming from nova.conf | |
| 12:42:07 | sdague | right | |
| 12:42:17 | mriedem | i can work up a patch | |
| 12:42:24 | sdague | mriedem: there is a patch in the bug | |
| 12:42:30 | sdague | they just didn't gerrit it | |
| 12:43:04 | sdague | http://paste.ubuntu.com/24497744/ | |
| 12:45:10 | mriedem | i know, but that needs tests and comments, etc | |
| 12:45:15 | mriedem | i can co-author them | |
| 12:48:49 | openstack | Launchpad bug 1696001 in OpenStack Compute (nova) ocata "duplicate for #1696685 nova-manage cell_v2 map_cell0 can create invalid connection URL" [Undecided,In progress] - Assigned to Sylvain Bauza (sylvain-bauza) | |
| 12:48:49 | bauzas | claudiub: see https://bugs.launchpad.net/nova/+bug/1696685 | |
| 12:49:01 | bauzas | claudiub: you can review the stable/ocata change | |
| 12:50:02 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Reconnect volumes and encryptors during a hard reboot https://review.openstack.org/400384 | |
| 12:50:14 | openstack | Launchpad bug 1696417 in OpenStack Compute (nova) "nova-manage db online_data_migrations can fail when upgrading to newton under certain conditions" [Undecided,Incomplete] | |
| 12:50:14 | bauzas | mriedem: we have a super weird issue for stable/newton with db migrations when you have different TZs https://bugs.launchpad.net/nova/+bug/1696417 | |
| 12:50:26 | bauzas | mriedem: for sure we could just say "meh" | |
| 12:50:48 | lyarwood | mriedem: huh, are you using an alias for git commit or something? | |
| 12:52:54 | sdague | mriedem: git author or git committer? | |
| 12:54:51 | lyarwood | sdague: both, https://review.openstack.org/#/c/441204/ is an example. | |
| 12:55:00 | mriedem | lyarwood: nope | |
| 12:55:03 | mriedem | just git commit | |
| 12:55:07 | mriedem | sdague: author | |
| 12:55:21 | sdague | mriedem: author shouldn't change unless you --reset-author | |
| 12:55:27 | mriedem | which i didn't do | |
| 12:55:31 | mriedem | just git review | |
| 12:55:33 | mriedem | git rebase | |
| 12:55:35 | lyarwood | yeah that's weird | |
| 12:55:35 | mriedem | git commit | |
| 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 | [core] | |
| 12:56:21 | mriedem | username = mriedem | |
| 12:56:21 | mriedem | [gitreview] | |
| 12:56:21 | mriedem | email = mriedem.os@gmail.com | |
| 12:56:21 | mriedem | name = Matt Riedemann | |
| 12:56:21 | mriedem | [user] | |
| 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 | 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) | |
| 12:56:47 | bauzas | mriedem: possibly merging https://bugs.launchpad.net/nova/+bug/1696605 before pike-2 too | |
| 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 | 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:28 | bauzas | https://bugs.launchpad.net/nova/+bug/1696664 | |
| 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 | |