Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-01-28
14:59:01 gibi mriedem: thanks
14:59:04 mriedem https://review.openstack.org/#/c/570079/ and the next few changes in gibi's series have a +2
14:59:15 mriedem if people want to help shrink that series
14:59:24 gibi thant would be awesome
14:59:43 lyarwood stephenfin: looking
15:00:10 mriedem tssurya: if https://review.openstack.org/#/c/591657/ is ready for review you should probably put it in the runways queue
15:00:13 mriedem https://etherpad.openstack.org/p/nova-runways-stein
15:00:25 mriedem looks like Kevin_Zheng has been reviewing it already
15:16:30 mriedem gibi: some nits in https://review.openstack.org/#/c/630720/ as well but nothing major
15:17:50 efried artom: When you get a chance, would you please have a look at mriedem's refactor of https://review.openstack.org/#/c/599208/ to make sure it gels with what you had in mind?
15:18:34 artom efried, yep, thanks for poking me
15:32:44 agopi Hi, I am looking to use keystonemiddleware's memcached_servers for nova on queens, however I noticed in https://docs.openstack.org/nova/queens/configuration/sample-config.html that the option has been deprecated, is there still a way to use keystonemiddleware's memcached servers to optimize nova's performance?
15:37:49 abhi89 Hi All.. i am working on the policies related to nova.. I observed that in previous releases of nova, we had something called 'discoverable' in the API & their respective policies.. for eg: "os_compute_api:os-evacuate:discoverable": "". it was introduced so that a user (with some role) knows which all apis he has access to run..
15:37:57 abhi89 https://blueprints.launchpad.net/nova/+spec/remove-discoverable-policy-rules talks about removing this 'discoverable' policy rules because we now have fixed list of extensions to list (https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/extension_info.py) in the API..
15:37:58 abhi89 that means, no need to check any of the discoverable rules..
15:38:07 abhi89 but how still we need these discoverable policy rules for the user to check what all apis he can access, right? am i missing something here!
15:40:34 mriedem agopi: yes i think that's part of oslo.policy
15:41:24 mriedem agopi: https://docs.openstack.org/oslo.policy/latest/configuration/index.html#oslo-policy
15:41:33 mriedem oh sorry,
15:41:34 mriedem oslo.cache
15:41:37 mriedem too many oslos
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?

Earlier   Later