| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-01-28 | |||
| 15:41:44 | artom | oslo.norway | |
| 15:42:00 | mriedem | agopi: https://docs.openstack.org/oslo.cache/latest/configuration/index.html | |
| 15:43:16 | mriedem | looks like our config docs aren't generating the oslo.cache options https://github.com/openstack/nova/blob/master/etc/nova/nova-config-generator.conf which is a bug | |
| 15:43:38 | agopi | mriedem, I'd noticed that but it mentions that it takes only dogpile.cache.memcache and oslo_cache.memcache backends only. I'm specifically trying to using keystonemiddleware's memcached_servers but I notice the option being deprecated( although still present in nova.conf) | |
| 15:44:42 | agopi | ^ [keystone_authtoken]/memcache_servers according to https://docs.openstack.org/nova/queens/configuration/sample-config.html | |
| 15:44:47 | mriedem | abhi89: 'discoverable' was a legacy artifact of the v2.0 api from what i recall. alex_xu and/or gmann can probably help with what to use instead | |
| 15:45:06 | mriedem | abhi89: as far as i know there is no generic "capabilities" type API which tells a given project/user what they have access to do | |
| 15:47:19 | mriedem | agopi: that's coming from oslo.cache https://github.com/openstack/oslo.cache/blob/stable/queens/oslo_cache/_opts.py#L76 - so you'd probably need to figure out why it says only those backends, which is a question for the #openstack-oslo channel | |
| 15:47:34 | mriedem | i think dogpile.cache.memcache is just pymemcache though | |
| 15:48:48 | mriedem | https://dogpilecache.sqlalchemy.org/en/latest/api.html#memcached-backends | |
| 15:50:06 | agopi | thanks mriedem, i'll try asking there. | |
| 15:50:13 | agopi | mriedem++ | |
| 15:50:50 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Refactor bdm handling in ServersController.create method https://review.openstack.org/633535 | |
| 15:56:34 | mriedem | oh i guess the nova conf docs do have oslo.cache options https://docs.openstack.org/nova/latest/configuration/config.html#cache.memcache_servers | |
| 15:57:14 | mriedem | stephenfin: sean-k-mooney: do one of you want to do backports for https://review.openstack.org/#/c/627540/ ? | |
| 15:57:52 | sean-k-mooney | mriedem: i can add it to my list. | |
| 15:58:34 | sean-k-mooney | mriedem: im working on https://review.openstack.org/#/c/626381/ currently but i can backport that after | |
| 15:58:47 | agopi | Yes mriedem, they do and they also have another option [keystone_authtoken]/memcache_servers but it has been deprecated, while the [cache]/memcache_servers only took dogpile.cache.memcache and oslo_cache.memcache_pool backends and thats where my struggle began. | |
| 16:01:25 | mriedem | agopi: if i'm reading https://docs.openstack.org/nova/queens/configuration/config.html#keystone_authtoken.memcached_servers correctly, the option itself is not deprecated | |
| 16:01:27 | mriedem | it was renamed | |
| 16:01:46 | mriedem | it used to be [keystone_authtoken]/memcache_servers and was renamed to memcached_servers | |
| 16:01:48 | mriedem | with the "d" | |
| 16:01:55 | mriedem | so different from the oslo.cache options | |
| 16:02:06 | mriedem | so you just need to update your config management tooling to use the new name | |
| 16:02:08 | mriedem | the option is still there | |
| 16:02:15 | agopi | oh shoot | |
| 16:02:29 | agopi | this is super awkard, thanks mriedem | |
| 16:04:53 | mriedem | https://github.com/openstack/keystonemiddleware/blob/899aa07a648d82d6e7ea6b7e22638b5d876507ea/keystonemiddleware/auth_token/_opts.py#L105 | |
| 16:04:54 | mriedem | np | |
| 16:15:20 | mriedem | gibi: more nits in this one as well https://review.openstack.org/#/c/630721/ | |
| 16:15:24 | mriedem | fodder for a fup patch | |
| 16:27:45 | abhi89 | mriedem: ok.. but the main intent of 'discoverable' policy rule was to get to know what all apis a user has access to. so is this feature also dropped! more importantly, i am not clear on how is this 'discoverable' concept related to extensions api & its deprecation | |
| 16:29:42 | mriedem | johnthetubaguy: since you did can you answer that? ^ https://review.openstack.org/#/c/459608/ | |
| 16:31:09 | mriedem | abhi89: i think the intent was more about nor longer being able to whitelist/blacklist parts of the API via the extensions, which were a v2.0 concept and with v2.1 all extensions are enabled, | |
| 16:31:30 | mriedem | and was not meant to be used as a kind of capabilities api | |
| 16:32:55 | mriedem | also mentioned here https://developer.openstack.org/api-ref/compute/#extensions-extensions-deprecated | |
| 16:36:04 | abhi89 | mriedem: but 'discoverable' wasn't just limited to extensions api. we can use it with any api, no matter extended or not | |
| 16:52:43 | openstackgerrit | Theodoros Tsioutsias proposed openstack/nova master: Add requested_networks to RequestSpec https://review.openstack.org/570201 | |
| 16:52:44 | openstackgerrit | Theodoros Tsioutsias proposed openstack/nova master: Add instance hard delete https://review.openstack.org/570202 | |
| 16:52:44 | openstackgerrit | Theodoros Tsioutsias proposed openstack/nova master: [WIP] Enable rebuild for instances in cell0 https://review.openstack.org/570203 | |
| 17:08:27 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Cleanup return_reservation_id in ServersController.create https://review.openstack.org/633560 | |
| 17:09:06 | mriedem | abhi89: i'd suggest starting an email discussion on the openstack-discuss mailing list since the people mostly involved in that change are not online right now (UK, china and japan); make sure to tag the subject with [nova] so it is filtered properly | |
| 17:17:00 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Cleanup return_reservation_id in ServersController.create https://review.openstack.org/633560 | |
| 18:53:23 | tssurya | efried: we are testing it on ironic currently; at least the basic stuff works well and requests are reduced as expected, whole testing and upgrading is expected to be within the next two weeks, will keep you posted on that if we do hit something. Thanks for all the work | |
| 18:53:38 | tssurya | mriedem: have added it in the queue | |
| 18:53:41 | cdent | tssurya++ | |
| 19:07:44 | artom | In placement world (specifically, https://review.openstack.org/#/c/599208/12/nova/virt/libvirt/driver.py@5925) what's max_unit? | |
| 19:08:54 | artom | And how is it different from total? | |
| 19:10:17 | artom | Aha, "A maximum amount any single allocation against an inventory can have." | |
| 19:14:19 | artom | I'm in awe, by the way, naturally | |
| 19:23:58 | jaypipes | artom: max_unit is used to prevent "natural oversubscription". for example, if I have a compute node with 12 physical CPUs and 16.0 overcommit ratio, I still do not want to accept VMs that wants >12 vCPUs because that would consume more qemu-kvm CPU threads than actual physical processors on the box. | |
| 19:24:54 | jaypipes | artom: so while I am cool with 16 VMs having 12 vCPUs each, I'm not cool with 1 VM having 13 vCPU. | |
| 19:25:20 | jaypipes | artom: whether or not this is reasonable is a different story, but that's the reason why max_unit is currently set to total. | |
| 19:25:44 | artom | jaypipes, aha, thanks for the context | |
| 19:26:06 | artom | max_per_allocation makes more sense to my brain | |
| 19:26:10 | artom | If that's indeed what it is | |
| 19:28:58 | jaypipes | artom: it is indeed. | |
| 19:29:12 | jaypipes | artom: "unit" is "per allocation". | |
| 19:29:36 | artom | Mmm, jargon ;) | |
| 19:29:43 | jaypipes | yes, yummy jargon. | |
| 19:30:36 | artom | Only slight more beloved than our other least favourite Jar - Jar Binks. | |
| 19:31:13 | jaypipes | heh, I friggin hate that character. | |
| 19:32:31 | artom | The world's scape-alien | |
| 19:47:36 | mriedem | need another core for this easy bug fix https://review.openstack.org/#/c/624959/ | |
| 19:53:28 | mriedem | https://review.openstack.org/#/c/632904/ would also help move mel's max attached volumes thing along as well | |
| 19:56:46 | jaypipes | mriedem: on it. | |
| 19:57:02 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Refactor "networks" processing in ServersController.create https://review.openstack.org/633594 | |
| 19:57:08 | jaypipes | mriedem: nm, dansmith was on it faster :) | |
| 19:59:07 | dansmith | just the first one | |
| 20:00:37 | mriedem | jaypipes: i've gone through a bunch of the bottom half of gibi's bw provider series as well if you want to step through those | |
| 20:00:43 | mriedem | lots of nits but no major issues | |
| 20:00:56 | mriedem | he's broken it all out pretty nicely | |
| 20:01:13 | mriedem | also, welcome back dansmith | |
| 20:02:30 | dansmith | thanks | |
| 20:02:38 | cdent | good dogs? | |
| 20:03:40 | dansmith | yup | |
| 20:04:21 | cdent | joy | |
| 20:05:21 | dansmith | 26 mushers this year, so.. like, a friggin lot of dogs | |
| 20:05:57 | cdent | do all the mushers run the same number of dogs, or is that a personal preference thing? | |
| 20:06:09 | dansmith | it depends on the distance | |
| 20:07:36 | dansmith | 7 with 12 dogs, 8 with 8 dogs, 9 with 6 dogs, two dropped out before running, so not counting those, 202 dogs being tracked | |
| 20:07:53 | dansmith | no pug teams, sorry jaypipes | |
| 20:08:11 | cdent | many dogs | |
| 20:08:30 | cdent | pug sled dogs would be great, especially if jaypipes was the musher | |
| 20:08:35 | cdent | he loves the cold | |
| 20:08:35 | jaypipes | dansmith: a real shame, I think. | |
| 20:08:54 | dansmith | he'd be lucky if he could pull the sled and they'd ride | |
| 20:09:05 | jaypipes | cdent: it would be more along the lines of humans pulling the sled and the pugs enjoying snoring under a fur blanket *on* the sled. | |
| 20:09:18 | jaypipes | dansmith gets it. | |
| 20:09:20 | cdent | some kind of jinx there | |
| 20:09:21 | dansmith | yeah. | |
| 20:09:23 | jaypipes | :) | |
| 20:55:45 | mriedem | seems that tox -e functional -- --failing no longer works in nova | |
| 20:55:51 | mriedem | maybe the tox sibling stuff screws that up? | |
| 21:02:23 | openstackgerrit | sean mooney proposed openstack/nova master: PCI: do not force remove allocated devices https://review.openstack.org/626381 | |
| 21:29:53 | openstackgerrit | Merged openstack/nova stable/pike: Handle binding_failed vif plug errors on compute restart https://review.openstack.org/626361 | |
| 21:30:00 | openstackgerrit | Merged openstack/nova stable/pike: Handle unbound vif plug errors on compute restart https://review.openstack.org/626554 | |
| 21:33:34 | artom | mriedem, efried, started looking at https://review.openstack.org/#/c/599208/12 | |
| 21:33:56 | artom | I have... suggestions? I dunno what to call them. I basically wrote pseudocode to make it clearer to my brain. | |
| 21:34:20 | artom | If it helps people, implement it. If it doesn't, it at least helped me understand what's up. | |