| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-16 | |||
| 09:47:36 | openstackgerrit | Takashi NATSUME proposed openstack/nova-specs master: Abort Cold Migration https://review.openstack.org/334732 | |
| 09:47:44 | openstackgerrit | Takashi NATSUME proposed openstack/nova-specs master: Specify keymap on server boot https://review.openstack.org/448830 | |
| 09:49:13 | openstackgerrit | jichenjc proposed openstack/nova master: [placement] Add api-ref for /resource_classes/{name} https://review.openstack.org/462837 | |
| 10:36:14 | openstackgerrit | Matthew Booth proposed openstack/nova master: libvirt: Use SubclassSignatureTestCase on all volume drivers https://review.openstack.org/465022 | |
| 11:20:16 | openstackgerrit | melanie witt proposed openstack/nova master: WIP Cache database and message queue connection objects https://review.openstack.org/465042 | |
| 11:56:10 | openstackgerrit | Monty Taylor proposed openstack/nova master: WIP Add description of server addresses objects https://review.openstack.org/464331 | |
| 12:18:13 | alex_xu | gmann: thanks! | |
| 13:19:00 | openstack | Launchpad bug 1579876 in OpenStack Compute (nova) "os-resetState should return a 204 rather than a 202" [Low,Triaged] | |
| 13:19:00 | alex_xu | sdague: johnthetubaguy are we real going to fix something like change status from 202 to 204? like this bug https://bugs.launchpad.net/nova/+bug/1579876. I'm think whether I should mark it as 'won't fix' | |
| 13:19:22 | sdague | alex_xu: right now it seems really low priority to fix | |
| 13:20:30 | alex_xu | sdague: yea, agree that it is super low. and I actually think about we are never going to fix it. | |
| 13:20:35 | sdague | yeh | |
| 13:20:48 | sdague | honestly, Opinion / Wishlist is how I would file the bug | |
| 13:21:47 | alex_xu | sdague: ok, got it | |
| 13:31:07 | bauzas | dansmith: edleafe: sorry for not yet uploading my series, but I discovered some possible issues that I'm not wanting | |
| 13:32:02 | dansmith | ...alright | |
| 13:41:13 | dansmith | sdague: so, setting ulimit so mysql can actually use the number of connections we have configured seems to have made the test pass | |
| 13:41:21 | dansmith | sdague: I'm running again to get another sample | |
| 13:46:19 | bauzas | dansmith: for example, now that we will pass N nodes back to the conductor for rescheduling, we still want to only consume the first one in the scheduler | |
| 13:47:57 | dansmith | okay | |
| 14:15:13 | openstackgerrit | dane-fichter proposed openstack/nova master: Add trusted certificates to InstanceExtras https://review.openstack.org/457711 | |
| 14:27:20 | openstackgerrit | Gábor Antal proposed openstack/nova master: Transform instance.resize_prep notification https://review.openstack.org/465081 | |
| 14:28:39 | mriedem | o/ | |
| 14:29:08 | mriedem | someone want to put this veritas libvirt volume driver through so we can close the blueprint? https://review.openstack.org/#/c/443951/ | |
| 14:33:18 | mdbooth | mriedem: The connection_info munging in there is evil and undocumented, btw | |
| 14:34:09 | mriedem | mdbooth: i realize the connection_info dict from cinder is a vendor-specific wild west | |
| 14:34:36 | mriedem | i flirted with the idea of trying to formalize that into a versioned object in cinder/os-brick years ago, but never had enough energy to really work on that | |
| 14:34:41 | mdbooth | Right, but in general we erect a 'wild west fence' around it with os-brick, right? | |
| 14:34:56 | mriedem | mdbooth: the same can be said for port binding details in neutron | |
| 14:36:48 | openstackgerrit | Alvaro Lopez Garcia proposed openstack/nova master: Ensure that periodic reclaim cleans DB deleted instances https://review.openstack.org/323250 | |
| 14:39:41 | mriedem | mdbooth: i don't think os-brick is really actually involved much here for connection_info, | |
| 14:39:53 | lyarwood | mriedem: we did bring that up again with walter during summit btw, agreed we should do it, just need people as with every other bug, feature, focus area within OpenStack atm. | |
| 14:39:58 | mriedem | nova calls os-initialize_connection in the cinder api which calls down to the volume driver and return the dict back to nova | |
| 14:40:19 | mriedem | the connector dict is created in os-brick and is something else i toyed with formalizing | |
| 14:40:21 | mriedem | but abandoned | |
| 14:40:27 | mdbooth | mriedem: What else would the extra info in connection_info be for? | |
| 14:40:42 | mdbooth | For terminate_connection? | |
| 14:40:44 | lyarwood | mdbooth: it's for libvirt most of the time | |
| 14:40:50 | mriedem | lyarwood: mdbooth: https://review.openstack.org/#/c/269867/ | |
| 14:40:50 | lyarwood | mdbooth: source_path etc | |
| 14:41:01 | mdbooth | lyarwood: Right, there's device_path | |
| 14:41:09 | mdbooth | That's become kinda standardised | |
| 14:41:31 | mriedem | there are definitely some 'standard' things we can usually expect in connection_info, | |
| 14:41:35 | mriedem | and then vendor-specific extras | |
| 14:41:55 | mdbooth | lyarwood mriedem: So I'm looking specifically here: https://review.openstack.org/#/c/443951/15/nova/virt/libvirt/volume/vrtshyperscale.py | |
| 14:41:58 | mriedem | sort of like what is being attempted with cleaning up the instance diagnostics stuff in nova | |
| 14:42:16 | mdbooth | We're getting device_info back from os-brick, and stuffing some of it into connection_info | |
| 14:42:37 | mdbooth | That's unusual, and there's no comment explaining why we do it | |
| 14:42:42 | mdbooth | Take 'vsa_ip' | |
| 14:43:08 | mdbooth | I don't see where that information would be subsequently used. It's not used by os-brick's disconnect_volume for that driver. | |
| 14:43:25 | mdbooth | The only place I can think off the top of my head would be terminate_connection | |
| 14:43:48 | lyarwood | mdbooth: yeah agreed, unless get_config is going to use it I can't see why would stash it, unless they have plans to use it in the future? | |
| 14:43:49 | mdbooth | lyarwood: Does that make more sense to you? | |
| 14:43:51 | mriedem | we don't pass the connection_info over to terminate_connection | |
| 14:44:02 | mriedem | just the connector | |
| 14:44:15 | mdbooth | mriedem: Ah, not even there, then | |
| 14:44:33 | mdbooth | I thought we did pass it back to cinder in that case | |
| 14:44:48 | mriedem | so yeah good point on stashing stuff in connection_info after calling os-brick, i'm not sure why that's there | |
| 14:45:03 | mriedem | mdbooth: i dropped my +2 if you want to ask why they are doing that | |
| 14:46:32 | mdbooth | mriedem: Done. You notice I also wrote your prior patch btw? ;) | |
| 14:47:38 | mriedem | mdbooth: i didn't | |
| 14:48:05 | mriedem | sorry i was hoping the irc pings notified you that i wrote a patch | |
| 14:49:00 | mdbooth | mriedem: NP, it only took a couple of minutes anyway :) Pretty obvious and can't remember why I didn't do it like that originally. | |
| 14:53:21 | mriedem | still looking for core reviews on this upgrade issue for cells v2 https://review.openstack.org/#/c/464088/ | |
| 14:53:28 | mriedem | ^ needs to go back through newton | |
| 15:06:45 | cfriesen | kashyap, you on? | |
| 15:10:43 | sdague | dansmith / melwitt was anything figured out about db connection leaks yesterday? | |
| 15:10:55 | cfriesen | there's someone on the openstack-dev mailing list asking about whether the cpu-throttle-initial and cpu-throttle-increment options in libvirt auto-converge are stable enough to use....anyone have any thoughts? The Newton spec said not, but that was a while ago now. | |
| 15:11:07 | dansmith | sdague: earlier this morning I said that raising ulimit to actually allow the number of connections we have configured seems to resolve my problem | |
| 15:11:26 | sdague | oh, I see it now | |
| 15:11:35 | dansmith | sdague: I'm about finished with a second run to get another sample, which appears to also have worked | |
| 15:11:44 | mriedem | shouldn't ulimit be 64k in deployment now? | |
| 15:11:48 | sdague | ok, cool, because our ulimit is 1024 by default or something | |
| 15:11:51 | mriedem | deployment == devstack? | |
| 15:12:00 | dansmith | sdague: this bit: https://review.openstack.org/#/c/436094/28/lib/databases/mysql | |
| 15:13:40 | sdague | ok cool | |
| 15:14:28 | dansmith | sdague: so, I dunno whether to just (ask you to allow) that into devstack or what | |
| 15:14:29 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Use plain routes list for os-services endpoint instead of stevedore https://review.openstack.org/460818 | |
| 15:14:48 | dansmith | sdague: 1024 still seems high, but we do have a bunch of databases, tables, and connections going on... | |
| 15:15:21 | sdague | dansmith: yeh, if we've got 1024 db connections it feels like ulimit should at least be double that | |
| 15:15:38 | dansmith | okay, I'll split that out and make it 2048 | |
| 15:15:43 | sdague | otherwise it's just shooting ourselves in the foot | |
| 15:15:47 | dansmith | right | |
| 15:16:24 | sdague | dansmith: so... here is what I think we should do | |
| 15:16:36 | sdague | add a new stackrc variable so that's tunable | |
| 15:16:42 | sdague | default to 2048 | |
| 15:16:45 | dansmith | okay | |
| 15:16:50 | sdague | do the change early in stack.sh for the system | |
| 15:17:07 | sdague | then if people want to play around with other values for constraints, it's easy | |
| 15:17:15 | dansmith | okay | |
| 15:17:38 | dansmith | by early does that mean in stack.sh or in functions somewhere? | |
| 15:18:27 | dansmith | and by "for the system" you mean in limits.conf? | |
| 15:19:02 | dansmith | and hope that systemd just inherits that properly when we start mysql? | |
| 15:19:30 | openstackgerrit | Stephen Finucane proposed openstack/nova master: rbd: Remove unnecessary 'encode' calls https://review.openstack.org/412356 | |
| 15:21:03 | sdague | dansmith: well probably build a function for it, but call it before we start any services in stack.sh directly | |
| 15:21:08 | sdague | yeh, limits.conf | |
| 15:21:15 | dansmith | okay | |
| 15:21:23 | sdague | and if set, I'm hoping it inherits through for the world | |
| 15:22:42 | dansmith | yeah, limits.conf is read by pam, so I'm not sure | |
| 15:24:30 | dansmith | sdague: just tested, doesn't seem to have any effect | |