| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-01-28 | |||
| 14:12:44 | openstack | Launchpad bug 1786451 in OpenStack Compute (nova) "Nova Instance creation is failing with request_spec.instance_group appears to be None" [Undecided,In progress] - Assigned to Lee Yarwood (lyarwood) | |
| 14:12:51 | bauzas | mriedem: but cells v1 is deprecated | |
| 14:13:00 | bauzas | so, should we fix the bug or not ? | |
| 14:14:04 | cdent | lyarwood: have you got any updates on placement+tripleo? | |
| 14:14:14 | mriedem | https://docs.openstack.org/nova/latest/user/cells.html#status | |
| 14:15:25 | mriedem | bauzas: shrug. i would make it the lowest of priorities. | |
| 14:15:44 | mriedem | unless you have a customer making it a high priority | |
| 14:15:55 | bauzas | mriedem: correct | |
| 14:16:02 | bauzas | mriedem: I don't really have a customer issue | |
| 14:16:08 | mriedem | then i guess it's more a question about what red hat supports | |
| 14:16:11 | mriedem | ok | |
| 14:16:22 | bauzas | mriedem: it's a related issue for a customer backport :) | |
| 14:16:37 | lyarwood | cdent: https://review.openstack.org/#/c/630644/ - the main tripleo-heat-templates change is passing CI (looking at the RDO failures now), the only outstanding work to land that part is some puppet-tripleo refactoring and unit test work. | |
| 14:16:39 | bauzas | but that's then a Newton concern ;) | |
| 14:17:09 | bauzas | lyarwood: if you agree, I'll close https://bugs.launchpad.net/nova/+bug/1786451 | |
| 14:17:10 | openstack | Launchpad bug 1786451 in OpenStack Compute (nova) "Nova Instance creation is failing with request_spec.instance_group appears to be None" [Undecided,In progress] - Assigned to Lee Yarwood (lyarwood) | |
| 14:17:19 | cdent | thanks lyarwood | |
| 14:17:20 | lyarwood | bauzas: ack sure | |
| 14:17:32 | bauzas | lyarwood: that's a cells v1 only issue now | |
| 14:17:40 | lyarwood | cdent: the check in call is next week right? | |
| 14:17:50 | cdent | lyarwood: yes | |
| 14:17:51 | tssurya | alex_au: thanks will see what I can do | |
| 14:17:56 | bauzas | lyarwood: but the problem exists for releases *before* https://github.com/openstack/nova/commit/3c2ce9450bea8d417bfd3fbe26ee688446c6a348 | |
| 14:25:02 | mriedem | gibi: i've got a nit in https://review.openstack.org/#/c/570079/ but if you want to address it in a follow up that's OK with me | |
| 14:25:33 | openstackgerrit | Merged openstack/nova master: Skip checking of target_dev for vhostuser https://review.openstack.org/627540 | |
| 14:26:33 | gibi | mriedem: I'll reshpin it as I have nothing to loos | |
| 14:45:10 | efried | tssurya: Greetings! Thanks for letting me know about tests on the placement traffic series. Did you do any testing with ironic yet? | |
| 14:50:39 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reject networks with QoS policy https://review.openstack.org/570079 | |
| 14:50:49 | gibi | mriedem: fixed your nit in ^^ | |
| 14:51:46 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Create RequestGroup from neutron port https://review.openstack.org/625941 | |
| 14:51:47 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Read port resource request from Neutron https://review.openstack.org/630720 | |
| 14:51:47 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Include requested_resources to allocation candidate query https://review.openstack.org/625942 | |
| 14:51:48 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reject resize with port having resource request https://review.openstack.org/630722 | |
| 14:51:48 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reject server create with port having resource request https://review.openstack.org/630721 | |
| 14:51:49 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reject evacuate with port having resource request https://review.openstack.org/630724 | |
| 14:51:49 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reject migrate with port having resource request https://review.openstack.org/630723 | |
| 14:51:50 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Transfer port.resource_request to the scheduler https://review.openstack.org/567268 | |
| 14:51:50 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reject unshelve with port having resource request https://review.openstack.org/630725 | |
| 14:51:51 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Calculate RequestGroup resource provider mapping https://review.openstack.org/616239 | |
| 14:51:51 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Extend RequestGroup object for mapping https://review.openstack.org/619527 | |
| 14:51:52 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Pass resource provider mapping to neutronv2 api https://review.openstack.org/616240 | |
| 14:51:52 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Fill the RequestGroup mapping during schedule https://review.openstack.org/619528 | |
| 14:51:53 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Send RP uuid in the port binding https://review.openstack.org/569459 | |
| 14:51:53 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Recalculate request group - RP mapping during re-schedule https://review.openstack.org/619529 | |
| 14:51:54 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Remove port allocation during detach https://review.openstack.org/622421 | |
| 14:51:54 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317 | |
| 14:51:55 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Record requester in the InstancePCIRequest https://review.openstack.org/625310 | |
| 14:55:17 | mriedem | +2 | |
| 14:56:41 | stephenfin | lyarwood: Fancy hitting this? https://review.openstack.org/#/c/626361/ | |
| 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/ | |