| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-18 | |||
| 16:36:46 | mnaser | yep | |
| 16:37:05 | sean-k-mooney | ok i normally use host-passthough with nested virt so the flag is there | |
| 16:37:08 | mnaser | `virsh capabilities` wouldn't report vmx there if it wasnt on either afaik | |
| 16:37:11 | mnaser | yeah, im trying to avoid that one | |
| 16:37:17 | sean-k-mooney | the model your using might just not included it | |
| 16:37:21 | sean-k-mooney | you could jsut add it | |
| 16:37:26 | mnaser | cat /sys/module/kvm_intel/parameters/nested => Y | |
| 16:37:29 | sean-k-mooney | with the config | |
| 16:37:53 | mnaser | sean-k-mooney: it actually does though -- http://paste.openstack.org/show/777431/ | |
| 16:37:54 | mnaser | thats the thing | |
| 16:38:09 | mnaser | i could add it manually but im trying to see if its something we can improve upstream :> | |
| 16:38:10 | sean-k-mooney | the host does | |
| 16:38:29 | mnaser | isnt the output of virsh capabiltiies show the model used by libvirt? | |
| 16:38:35 | mnaser | in this case IvyBridge-IBRS which does include vmx | |
| 16:38:36 | sean-k-mooney | that does not mean the IvyBridge-IBRS has the flag | |
| 16:38:43 | mnaser | wait what | |
| 16:38:45 | mnaser | seriously | |
| 16:38:51 | sean-k-mooney | yes | |
| 16:39:07 | sean-k-mooney | there is an xml file you can check | |
| 16:39:10 | mnaser | i thought virsh capabilities was what would host-model be | |
| 16:39:17 | sean-k-mooney | no | |
| 16:39:20 | mnaser | cpu_map.xml | |
| 16:39:28 | sean-k-mooney | its litrally the host capablites unfiltered | |
| 16:39:57 | sean-k-mooney | the model it reporet is the closet on to your host cpu | |
| 16:40:04 | mnaser | well | |
| 16:40:07 | mnaser | that explains all my confusion | |
| 16:40:14 | mnaser | then i need to add the extra cpu flag | |
| 16:40:28 | mnaser | cpu_map.xml shows nothing actually has vmx flag | |
| 16:40:37 | mnaser | i could _swear_ that it used to be there before | |
| 16:40:51 | sean-k-mooney | where is cpu_map by the way i was looking for it locally | |
| 16:41:03 | mnaser | sean-k-mooney: /usr/share/libvirt/cpu_map.xml | |
| 16:41:08 | mnaser | (on centos at least) | |
| 16:41:14 | sean-k-mooney | ah user share i was looking in /var/lib | |
| 16:41:54 | mnaser | ok im really confused as to how it used to work before but i guess it did | |
| 16:42:20 | sean-k-mooney | it could be a libvirt change | |
| 16:42:53 | sean-k-mooney | or you were using host-passthough and did not no/notice/remember | |
| 16:43:20 | mnaser | no as much as host-passthrough is great im very anti that because live migrations | |
| 16:43:51 | sean-k-mooney | you can use it with live migrations | |
| 16:43:59 | sean-k-mooney | but you need to group things by hardware type | |
| 16:44:08 | mnaser | yeah it gets tricky for new hardware | |
| 16:44:09 | sean-k-mooney | by the way host-model is not relaly better | |
| 16:44:40 | sean-k-mooney | if you use host model and you move for ivybridge to haswell then reboot the vm it wont be abel to migrte back | |
| 16:44:51 | mnaser | yeah im perfectly ok with migrating from old to new but not new to old | |
| 16:44:58 | sean-k-mooney | if you really care about migration you should use custom and select a version across all nodes | |
| 16:44:58 | mnaser | it enables my use case of "upgrading things" | |
| 16:52:26 | stephenfin | mriedem: Can you cut an sqlalchemy-migrate release? | |
| 16:53:17 | stephenfin | I'm seeing logs about a contextual_connect popping up and I assume that's not helping with our "we generate too many logs" gate issues. A patch from zzzeek is on master | |
| 16:55:33 | sean-k-mooney | stephenfin: we cant in train | |
| 16:55:48 | sean-k-mooney | but we can for U | |
| 16:56:01 | mriedem | stephenfin: i've got a release pending for U | |
| 16:56:08 | sean-k-mooney | stephenfin: i think mriedem may have fixed that | |
| 16:56:11 | mriedem | https://review.opendev.org/#/c/682656/ | |
| 16:57:32 | mriedem | i see what you mean in https://7adee8d979f9b27778af-fc266c4961a026b4ec86218d0c17f3b6.ssl.cf5.rackcdn.com/523559/10/check/openstack-tox-py36/55f9ad4/job-output.txt and https://ce11c0ee0a74ee8ebb7e-9c035ca54e1e355b36ad4d338836f375.ssl.cf2.rackcdn.com/523559/10/check/nova-tox-functional-py36/ac3beea/job-output.txt though | |
| 16:57:42 | mriedem | stephenfin: in nova we can add a warnings filter to only log that once | |
| 16:57:49 | mriedem | in the WarningsFixture we have | |
| 16:57:51 | sean-k-mooney | stephenfin: speaking of that im updating there tox file here https://review.opendev.org/#/c/682515/ if you care too take a look. the native coverage support still seam to not work. i spend an hour working on it so i did the same hack we have in nova | |
| 16:58:09 | mriedem | stephenfin: so let's do that in nova in Train and if it's fixed in sqla-migrate we can bump mins when that gets released in U | |
| 16:58:40 | mriedem | you could push the nova patch under bug 1813147 | |
| 16:58:41 | openstack | bug 1813147 in OpenStack Compute (nova) "p35 jobs are failing with subunit.parser ... FAILED" [High,In progress] https://launchpad.net/bugs/1813147 - Assigned to Balazs Gibizer (balazs-gibizer) | |
| 16:59:53 | mriedem | this is the patch you were talking about btw https://review.opendev.org/#/c/671040/ | |
| 17:01:46 | openstackgerrit | melanie witt proposed openstack/nova master: Add note about needing noVNC >= v1.1.0 with using ESX https://review.opendev.org/682946 | |
| 17:11:23 | melwitt | KeithMnemonic1: ^ (late) | |
| 17:15:39 | KeithMnemonic1 | lol | |
| 17:18:53 | sean-k-mooney | im not sure why i try to make my tests robost... | |
| 17:20:24 | sean-k-mooney | gibi: mriedem http://paste.openstack.org/show/777439/ | |
| 17:20:48 | sean-k-mooney | so you know why stat is not ment to be HARD_REBOOT ... | |
| 17:22:50 | sean-k-mooney | im going to add backin self._wait_for_state_change(self.api, shelved_server, 'ACTIVE') | |
| 17:23:46 | sean-k-mooney | or active_server in this case | |
| 17:24:20 | mriedem | idk what you are doing there | |
| 17:24:43 | sean-k-mooney | im using the fake notifiyer to wait for the reboot end notifcaiont | |
| 17:25:00 | mriedem | but why do you need a whole separate _get_server_info | |
| 17:25:07 | sean-k-mooney | the same one that is used in the allocation fucntional tests | |
| 17:25:26 | mriedem | self._wait_for_state_change(self.api, active_server, 'ACTIVE') does the same thing you added | |
| 17:25:27 | sean-k-mooney | because i was nolonger checking for the server being active | |
| 17:25:49 | sean-k-mooney | right but the whole point was the status was ment to always be active | |
| 17:26:01 | sean-k-mooney | or the previous patch would have been correct | |
| 17:26:11 | sean-k-mooney | its actully HARD_REBOOT | |
| 17:26:25 | mriedem | after the task_state is None? | |
| 17:26:34 | mriedem | if you wait for ACTIVE and task_state=None you shouldn't have a problem | |
| 17:26:43 | sean-k-mooney | no im not checking for that im waiting for the notificaiton | |
| 17:26:54 | sean-k-mooney | ya i can do that instead | |
| 17:27:05 | mriedem | i look forward to at least 5 more patch sets for this fix | |
| 17:27:51 | sean-k-mooney | i like how this is litrlly all because im swaping the order of two lines | |
| 17:29:07 | mriedem | pick one or the other i don't think it matters, the task_state is None here https://github.com/openstack/nova/blob/c67057dff34a0054977ae3873d33313c0617b308/nova/compute/manager.py#L3529 and the notification is here https://github.com/openstack/nova/blob/c67057dff34a0054977ae3873d33313c0617b308/nova/compute/manager.py#L3536 | |
| 17:29:12 | mriedem | for the purpose of your test either is sufficient | |
| 17:29:45 | mriedem | if you do wait for the task_state to be None, use https://github.com/openstack/nova/blob/c67057dff34a0054977ae3873d33313c0617b308/nova/tests/functional/integrated_helpers.py#L247 | |
| 17:29:49 | mriedem | don't write some new function | |
| 17:30:16 | mriedem | using _wait_for_server_parameter will get you the latest copy of the server with the config drive value in the api so i'd use that myself | |
| 17:30:33 | sean-k-mooney | yep i can do that | |
| 17:30:56 | openstackgerrit | Merged openstack/nova stable/stein: Fix the server group "policy" field type in api-ref https://review.opendev.org/662224 | |
| 17:31:00 | sean-k-mooney | but the reason i pinged you on irc was it look like our fixture are not doing the right thing | |
| 17:31:04 | openstackgerrit | Merged openstack/nova stable/stein: Fixing broken links https://review.opendev.org/681401 | |
| 17:31:11 | openstackgerrit | Merged openstack/nova stable/stein: libvirt: stub logging of host capabilities https://review.opendev.org/682210 | |
| 17:31:20 | openstackgerrit | Merged openstack/nova stable/stein: Fix rebuild of baremetal instance when vm_state is ERROR https://review.opendev.org/680869 | |
| 17:33:38 | sean-k-mooney | well either we really do go from ACTIVE->HARD_REBOOTING->ACTIVE which is why i orginaly thought in which case its not a race or the fixture is reutrning the worng value. ill look at that after i do the taskstae check | |
| 17:34:14 | mriedem | you're seeing HARD_REBOOTING b/c of the task_state not being None | |
| 17:34:17 | sean-k-mooney | for rebuild im getting the same behavior "esttools.matchers._impl.MismatchError: 'ACTIVE' != 'REBUILD'" | |
| 17:34:38 | mriedem | does your test properly stub out the fake notifier in setUp? | |
| 17:34:42 | sean-k-mooney | yes | |
| 17:35:06 | mriedem | this is why you saw HARD_REBOOT https://github.com/openstack/nova/blob/c67057dff34a0054977ae3873d33313c0617b308/nova/api/openstack/common.py#L53 | |