| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-19 | |||
| 22:28:35 | openstackgerrit | Dustin Cowles proposed openstack/nova master: Provider Config File: Function to further validate and retrieve configs https://review.opendev.org/676029 | |
| 22:28:36 | openstackgerrit | Dustin Cowles proposed openstack/nova master: WIP: Provider Config File: Merge provider configs to provider tree https://review.opendev.org/676522 | |
| 23:15:41 | openstackgerrit | Eric Fried proposed openstack/nova master: libvirt: Enable driver configuring PMEM namespaces https://review.opendev.org/679640 | |
| #openstack-nova - 2019-09-20 | |||
| 00:21:22 | openstackgerrit | sean mooney proposed openstack/nova-specs master: resubmit image metadata prefiltering spec for ussuri https://review.opendev.org/683258 | |
| 08:59:52 | luyao | efried_pto, stephenfin: Hi, could you help review the vpmems doc if you get time, since you both are familiar with the vpmems series. :D I think I get the content close which is focusing on the current functionality. https://review.opendev.org/#/c/680300. | |
| 09:02:32 | luyao | And the patch 'objects: use all_things_equal from objects.base' is ready to merge , need +W on it, https://review.opendev.org/#/c/681397/13 | |
| 09:07:35 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Add a prelude for the Train release https://review.opendev.org/683327 | |
| 09:59:32 | AdamMork | Hello, friends! I have a openstack contains 2 controllers an 4 compute node's. I need to enable AES-NI for one or more vm. Openstack deployed via kolla and work on docker containers(nova container, neutron container etc. on controller). I read manual https://software.intel.com/en-us/articles/openstack-epa-feature-breakdown-and-analysis . On the | |
| 09:59:33 | AdamMork | compute node (in bios i enable AES-NI) . But in vm use command (cat /proc/cpuinfo | grep aes) i not found aes support. How to configure nova to enable aes instructions? | |
| 10:28:35 | AdamMork | ok! How i can modify Nova conf "The Nova* libvirt driver takes its configuration information from a section in the main Nova file /etc/nova/nova.conf." I have docker containers and how to find /etc/nova/nova.conf.? should i connect to nova container? | |
| 11:28:54 | AdamMork | ok. I see more manuals and understand : in globals.yml need uncomment :node_custom_config: "/etc/kolla/config" and overrides basic config for nova (As of now kolla only supports config overrides for ini based configs.) https://github.com/openstack/kolla-ansible/blob/master/doc/source/admin/advanced-configuration.rst THX | |
| 12:54:46 | mriedem | gibi: i saw your resize reschedule rpc pin bug, do you know if that's a new regression in train? | |
| 12:55:28 | gibi | mriedem: not yet. I'm about to push a reproduction patch, then I will look into when the fault was introduced | |
| 12:55:57 | gibi | it is clear that the problem is with the legacy request spec in prep_resize ending up in the conductor during a re-schedule with rpc pinned to 5.0 | |
| 12:58:38 | gibi | mriedem: this is where it blows https://github.com/openstack/nova/blob/9b2e00e015f22b2d876cd3c239af8e139040c8c8/nova/conductor/manager.py#L327 | |
| 12:58:51 | mriedem | i know that in compute rpc api 5.1 we send the RequestSpec to compute https://opendev.org/openstack/nova/src/branch/master/nova/compute/rpcapi.py#L833 | |
| 12:58:58 | mriedem | but backlevel if to the dict form if we can't | |
| 12:59:13 | mriedem | gibi: ah yeah - that's my patch | |
| 12:59:15 | mriedem | remember? | |
| 12:59:34 | mriedem | https://review.opendev.org/#/c/680762/ | |
| 13:00:03 | mriedem | so if you have a recreate we can lay that on top | |
| 13:00:43 | gibi | mriedem: ohh you have a fix for it. cool. Yeah I will push a functional repro soon and the you can rebase | |
| 13:00:50 | gibi | or I can rebase | |
| 13:00:55 | gibi | your series | |
| 13:01:00 | mriedem | you can rebase it, | |
| 13:01:06 | mriedem | also, i've duplicated your bug against 1843090 | |
| 13:01:17 | gibi | mriedem: thanks. I will update my patch accordingly | |
| 13:01:42 | gibi | mriedem: I reached this bug while tried to create a func test for the bandwidth case when rpc in pinned | |
| 13:02:06 | gibi | mriedem: it seems there will also be extra issues | |
| 13:02:07 | mriedem | yeah it was this patch that made me think of it in your bw series for prep_resize where you were using the request spec | |
| 13:03:36 | gibi | mriedem: btw do you know about a bug regading booting a instance with --availablity-zone az:node and then migrate it. I saw that in this case nova does not try to re-schedule the migration if the first dest host fails in prep_resize | |
| 13:03:57 | gibi | it seem the that filter_properties are not populated for re-schedule | |
| 13:04:17 | gibi | if I boot the server with the new host parameter then the re-schedule work | |
| 13:05:18 | mriedem | gibi: that's working as designed https://opendev.org/openstack/nova/src/branch/master/nova/scheduler/utils.py#L801 | |
| 13:05:44 | mriedem | using az::node will set force_nodes | |
| 13:06:07 | mriedem | do you see "Re-scheduling is disabled due to forcing a host" in the logs? | |
| 13:06:13 | gibi | mriedem: but forcing the host during the boot allows me to migrate it without dest host specified, but it does not allow nova to re-schedule | |
| 13:06:27 | gibi | during that migrate | |
| 13:07:06 | gibi | mriedem: I have to go back and re-create the situation as I saw this while I created the func test for the rpc pin bug. | |
| 13:07:26 | mriedem | gibi: which release? https://review.opendev.org/#/q/I3f488be6f3c399f23ccf2b9ee0d76cd000da0e3e | |
| 13:07:47 | gibi | mriedem: master :) | |
| 13:07:54 | mriedem | oh nvm that's ignore_hosts | |
| 13:08:46 | mriedem | so i think force_hosts/nodes gets persisted for some reason, i'm not sure why, but for every move operation we call this to basically unset those fields https://opendev.org/openstack/nova/src/branch/master/nova/objects/request_spec.py#L692 | |
| 13:08:55 | mriedem | it would be simpler if we just didn't persist those values | |
| 13:09:24 | mriedem | gibi: so maybe we're calling ^ *after* populate_retry | |
| 13:10:03 | mriedem | yup https://opendev.org/openstack/nova/src/branch/master/nova/conductor/tasks/migrate.py#L293 | |
| 13:11:29 | gibi | mriedem: so is the order of pupulate and rest wrong there? | |
| 13:11:53 | mriedem | it appears so | |
| 13:11:54 | gibi | s/pupulate/populate_retry | |
| 13:12:07 | gibi | mriedem: OK I will create a reproduction for that as well | |
| 13:12:10 | mriedem | i'm checking if that's a regression | |
| 13:13:37 | mriedem | gibi: looks like it's been that way since newton https://review.opendev.org/#/c/284974/18/nova/conductor/tasks/migrate.py | |
| 13:14:02 | gibi | mriedem: then nobody cares :D | |
| 13:14:42 | mriedem | ha | |
| 13:14:51 | gibi | mriedem: btw there are re-schedule func tests that uses az:node boot, so those will start behaving differently if we fix this | |
| 13:14:52 | mriedem | or nobody just ever thought to ask if that's wrong | |
| 13:15:19 | mriedem | dansmith: bauzas: can you think of any rason why we persist RequestSpec.force_hosts/nodes? | |
| 13:15:31 | mriedem | like many of the other request spec fields, persisting that seems to only cause headaches | |
| 13:15:34 | bauzas | PEBKAC ? | |
| 13:16:00 | bauzas | I thought we have a method for this | |
| 13:16:13 | mriedem | i understand that when request spec was originally written everything was persisted, but we've rolled back a lot of that piece by piece as we find problems | |
| 13:16:24 | mriedem | bauzas: yeah, but that's kind of ... dumb, right? | |
| 13:16:30 | bauzas | mriedem: https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L692 | |
| 13:16:36 | mriedem | we could just not persist the damn field and then we wouldn't have to explicitly reset for every move operation | |
| 13:16:38 | bauzas | mriedem: yeah, this | |
| 13:17:09 | bauzas | mriedem: when alaski provided the persistence for the spec, his and me forgot to discuss about this :( | |
| 13:17:15 | bauzas | him* | |
| 13:17:22 | bauzas | so we created this method | |
| 13:18:21 | mriedem | ok but going forward, to avoid new ways of shooting off our toes, we could just stop persisting force_hosts/nodes and only rely on that method as a workaround for existing request specs | |
| 13:19:39 | mriedem | these are the fields i count that we've changed to not be persisted on the requestspec: ignore_hosts, requested_destination, retry, network_metadata, requested_resources | |
| 13:20:08 | mriedem | the latter 2 are newer and were not persisted since they were introduced, but the first 3 were all retroactive | |
| 13:20:39 | mriedem | oh and the instance_group members/hosts https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L614 | |
| 13:21:20 | mriedem | which reminds me, if any stable core cares about pike and ocata https://review.opendev.org/#/q/topic:bug/1830747+status:open | |
| 13:21:37 | bauzas | mriedem: cool with this | |
| 13:22:10 | bauzas | mriedem: I was also thinking about some way to say which specific fields shouldn't be persisted | |
| 13:22:31 | bauzas | mriedem: and sure, will look at the stable changes | |
| 13:23:40 | mriedem | gibi: as for existing functional resize reschedule tests using az::node, i'd have to see the impacts to assess really | |
| 13:23:59 | bauzas | mriedem: efried_pto: btw. https://review.opendev.org/#/c/683327/ | |
| 13:24:02 | mriedem | but if we ignore the forced host/node to boot the server during resize scheduling, it seems we should allow rescheduling to alternates | |
| 13:26:12 | gibi | mriedem: sure. we will see when I managed to write the reproduction and reorder the populate_retry call | |
| 13:27:04 | mriedem | stephenfin: are you working on an admin guide docs patch for pcpu? | |
| 13:27:12 | stephenfin | mriedem: yup | |
| 13:27:16 | stephenfin | atm, in fact | |
| 13:27:39 | stephenfin | should have something ready to go before EOD | |
| 13:35:59 | mriedem | bauzas: notes on the prelude patch | |
| 13:36:06 | bauzas | cool | |
| 13:40:26 | mriedem | weee https://zuul.opendev.org/t/openstack/build/e3f767dbd32247ffa5aa7daa79e0e5af/log/job-output.txt#32748 | |
| 13:40:31 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Func test for migrate reschedule with pinned compute rpc https://review.opendev.org/683385 | |
| 13:41:21 | gibi | mriedem: reproduction for 1843090 ^^ | |
| 13:41:52 | gibi | mriedem: now I'm going to do the rebase of your fix on it | |
| 13:42:15 | mriedem | gibi: when you rebase you might as well strike whatever word efried_pto didn't like from my comment | |
| 13:42:23 | gibi | mriedem: sure thing | |
| 13:52:39 | mriedem | gibi: comments in your functional recreate patch | |
| 13:54:59 | gibi | mriedem: thanks. regarding the request_spec uglyness. I can cook up something that is test only. But sooner or later we (I) need to go back and fix this uglyness as it is now needed in two places (as noted) | |
| 13:55:50 | gibi | mriedem: the rest of your comments is valid and clear. | |
| 13:55:59 | mriedem | yeah i have no idea why that object is a problem b/c we pass request spec over rpc (select_destinations and such) all the time | |
| 13:56:09 | mriedem | in tests i mean | |
| 13:56:11 | gibi | mriedem: in the meantime I can tell you that your fix works according to the functional test | |
| 13:56:19 | mriedem | \o/ | |
| 13:56:45 | gibi | ... what a nice Friday it is | |