Earlier  
Posted Nick Remark
#openstack-nova - 2017-11-22
13:48:34 mdbooth The nova mount manager stuff is really generic. If it fit into the os-brick model it should probably live there.
13:48:36 stephenfin OK. So instead of them doing what the do there, would it make more sense for them to change LibvirtVZStorageVolumeDriver to subclass from LibvirtMountedFileSystemVolumeDriver
13:48:45 stephenfin *what they do
13:48:51 jianghuaw bauzas, I created a new patch to enable only one vGPU type on each compute node. So that we will have same behavior for both libvirt and XenAPI befre we switch to use n-rp. https://review.openstack.org/#/c/521769/
13:49:04 mdbooth I recommended that in a review comment. I won't leave a -1 for that, though.
13:49:12 stephenfin Like you did for the NFS driver in 4aa39c44a4b08ee4e05548d5c258e795089b2bdd
13:49:23 stephenfin OK. To be honest, that sounds like a viable -1 to me
13:49:42 bauzas jianghuaw: ack
13:49:43 stephenfin I mean, we have a good pattern for how to do this. Why not insist we use the same pattern everywhere
13:49:43 mdbooth Well the problem already exists
13:49:49 mdbooth And the patch they've proposed makes it better
13:49:55 bauzas jianghuaw: maybe stacking that with the other changes could help us reviewing ?
13:50:02 mdbooth The time to -1 was a while back
13:50:42 jianghuaw bauzas, That's in the PS stack. I'd like you help to reivew it.
13:51:17 jianghuaw bauzas, note I kept the original logic which will handle multiple gpu group, so it's easy for me to switch to multiple types once n-rp is ready.
13:51:34 bauzas jianghuaw: sure, but I mean squashing
13:51:58 stephenfin mdbooth: I assume it would require significant rework?
13:52:30 jianghuaw bauzas, ok. I see. Will squash it.
13:52:57 mdbooth stephenfin: Well I don't know enough about how it mounts, but if it's basically just a wrapper round 'mount -t vzstorage' or whatever, it should be very simple.
13:53:26 stephenfin Oh, so we'd be doing it ourselves instead of relying on os-brick?
13:53:52 mdbooth Yeah, the existing code doesn't use os-brick because it was replacing code which didn't use os-brick.
13:54:00 mdbooth There's no reason it couldn't, though.
13:54:09 mdbooth That would require a bit of rework, though.
13:54:43 stephenfin Ah, that's where I was confused. I thought it was a case of removing that new code, changing what we subclassed, and one or two other minor things
13:54:53 mdbooth Still, the os-brick connector doesn't implement umount, so I'm surprised anybody would use it.
13:55:20 stephenfin If there's other rework there then it makes sense to not ask for that. It's a nice-to-have for future
13:55:26 stephenfin Agreed. That seems...odd
13:56:35 openstackgerrit Matt Riedemann proposed openstack/nova master: Adding NVMEoF for libvirt driver https://review.openstack.org/482640
14:06:45 stephenfin mdbooth: Overall though, are you happy with that patch?
14:08:09 bauzas jianghuaw: I plan to write some functional tests for verifying our implementations
14:08:18 bauzas jianghuaw: it takes me a long time for that tho
14:08:37 bauzas but once I'll upload them, it could be nice to use them
14:09:06 mdbooth stephenfin: It serialises calls to connect, so it probably solves the reported issue.
14:09:19 mdbooth However, if they implement umount, which they should, it's insufficient.
14:10:22 mdbooth stephenfin: So I think my +0 accurately reflects my feelings.
14:10:47 jianghuaw bauzas, do you mean adding tests in tempest?
14:11:00 stephenfin mdbooth: That sounds fair. I'd edge towards +2 because it _does_ resolve the bug
14:11:07 openstackgerrit Radoslav Gerganov proposed openstack/nova master: VMware: expose max vCPUs and max memory per ESX host https://review.openstack.org/516635
14:11:07 openstackgerrit Radoslav Gerganov proposed openstack/nova master: VMware: fix memory stats https://review.openstack.org/516634
14:11:08 stephenfin Though I would much rather they implement disconnect also
14:11:08 openstackgerrit Radoslav Gerganov proposed openstack/nova master: VMware: implement get_inventory() driver method https://review.openstack.org/506175
14:11:22 stephenfin ...allowing them to use that superclass in the process
14:11:34 bauzas jianghuaw: nope, just in nova.tests.functional
14:11:48 mdbooth stephenfin: Ok.
14:14:00 jianghuaw bauzas, ah, got it. Thanks for letting me know of it.
14:14:11 jianghuaw bauzas, yes. that's needed.
14:14:15 openstackgerrit Merged openstack/nova master: Allow shuffling hosts with the same best weight https://review.openstack.org/494136
14:15:58 openstackgerrit Matt Riedemann proposed openstack/python-novaclient master: Add support for microversion 2.55 - flavor description https://review.openstack.org/520819
14:33:00 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/nova master: Format NIC features using os-traits definitions https://review.openstack.org/466051
14:35:14 ralonsoh stephenfin: why the -1 in https://review.openstack.org/#/c/466051/?
14:35:20 stephenfin bauzas: I think what ralonsoh was doing here is correct https://review.openstack.org/#/c/466051/
14:35:26 stephenfin ralonsoh: Just left the comment
14:35:26 openstackgerrit Balazs Gibizer proposed openstack/nova master: Moving more utils to ProviderUsageBaseTestCase https://review.openstack.org/499539
14:35:43 stephenfin Quick -1 to stop it getting merged :)
14:36:30 bauzas stephenfin: well, there are 2 possibilities
14:37:02 bauzas stephenfin: #1 either we wait for a specific nova global requirements update and then we don't need to ask ralonsoh to modify directly the reqs.txt file
14:37:38 bauzas stephenfin: #2 or ralonsoh depends-on his change to https://review.openstack.org/#/c/521883/ and amending directly reqs.txt
14:38:43 stephenfin bauzas, ralonsoh: Hmm, yeah I was thinking the requirements job might fail
14:39:33 bauzas stephenfin: the reqs job failed because the g-r patch is not yet merged
14:39:56 bauzas so ralonsoh can modify reqs.txt directly if he provides a Depends-On
14:40:10 stephenfin ralonsoh: That job checks to make sure requirements are synchronized between projects so, for example, nova doesn't depend on requirements '==0.1.0', while neutron depends on '==0.2.0'
14:40:21 stephenfin Because if we did that, then we couldn't install them side-by-side
14:40:35 openstackgerrit Balazs Gibizer proposed openstack/nova master: factor out compute service start in ServerMovingTest https://review.openstack.org/503037
14:40:45 openstackgerrit Balazs Gibizer proposed openstack/nova master: Test resource allocation during soft delete https://review.openstack.org/495159
14:40:50 stephenfin At least, not using system packages (vs. virtualenvs or installing things in containers)
14:40:57 openstackgerrit Balazs Gibizer proposed openstack/nova master: Change live_migrate tests to use fakedriver https://review.openstack.org/505202
14:41:05 openstackgerrit Balazs Gibizer proposed openstack/nova master: Use FakeLiveMigrateDriver in notification test https://review.openstack.org/519405
14:41:19 openstackgerrit Balazs Gibizer proposed openstack/nova master: Transform instance-live_migration_pre notification https://review.openstack.org/482070
14:42:36 gibi stephenfin, bauzas: there is a small test refactor patch that blocks other already +Wd patches in a chain. Could you quickly take a look? It only needs a second +2 https://review.openstack.org/#/c/503037
14:42:53 stephenfin bauzas: It did? I was waiting to see that
14:44:12 stephenfin ralonsoh: OK, so bauzas is right there. You'll need to wait for the g-r change to fix. I thought the fact that https://github.com/openstack/requirements/commit/6fbb909760926a51156203a0f55c7c0259ab1d38 had merged was good enough
14:44:13 stephenfin Clearly not
14:48:54 stephenfin ralonsoh: Yeah, so I guess that's blocked by https://review.openstack.org/#/c/521883/ Sorry about the confusion
14:49:08 stephenfin This is the fun stuff we live with :D
14:54:40 mriedem alex_xu: gmann_afk: looks like the 2.36 microversion broke the os-quota-sets 'force' parameter :(
14:58:59 openstack Launchpad bug 1733886 in OpenStack Compute (nova) "'force' parameter broken in os-quota-sets microversion >= 2.36" [Undecided,New]
14:58:59 mriedem https://bugs.launchpad.net/nova/+bug/1733886
15:04:39 openstackgerrit Sylvain Bauza proposed openstack/nova master: libvirt: Provide VGPU inventory for a single GPU type https://review.openstack.org/514763
15:04:58 bauzas gibi: +Wd
15:05:15 gibi bauzas: thanks!
15:20:02 bauzas quick question, does anyone know how to ask systemctl to restart all the failing services in case of devstack ?
15:20:12 bauzas or like, saying all the nova ones ?
15:20:28 bauzas for sure I can loop over each of them
15:20:43 bauzas but I wondered if there was like a screen -c stuff
15:21:31 openstackgerrit Stephen Finucane proposed openstack/nova master: Don't create instance_extra entry for deleted instance https://review.openstack.org/412771
15:22:06 kashyap bauzas: If you don't mind a bit of typing: `systemctl restart foo bar baz whizz` should restart them all
15:22:22 bauzas kashyap: yeah I knew about that
15:22:25 bauzas but meh
15:22:27 bauzas okay
15:24:23 openstackgerrit Matthew Booth proposed openstack/nova master: libvirt: Re-initialise volumes, encryptors, and vifs on hard reboot https://review.openstack.org/400384
15:25:11 bauzas kashyap: given we have a 'systemctl list-units --failed' comment, I was hoping to see a 'systemctl start --failed'
15:25:27 bauzas but meh, I can gawk that
15:29:32 bauzas kashyap: oh hell, see that https://docs.openstack.org/devstack/latest/systemd.html#operating-on-more-than-one-unit-at-a-time
15:29:42 bauzas bauzas, RTFM, man !
15:30:17 kashyap bauzas: Ah
15:30:18 openstackgerrit Jianghua Wang proposed openstack/nova master: XenAPI: get vGPU stats from hypervisor https://review.openstack.org/512965
15:34:35 alex_xu mriedem: the second time we break the API due to the schema copy :(
15:37:14 mriedem alex_xu: yeah, a functional api sample test for that one at 2.36 would have caught it
15:37:31 mriedem anyway, i think i'll just document it in the api-ref and do a release note and we're good
15:37:40 mriedem the force parameter doesn't matter since pike anyway

Earlier   Later