Earlier  
Posted Nick Remark
#openstack-nova - 2017-04-12
14:05:39 frickler btw. can anyone give that EMC ScaleIO CI a kick?
14:06:22 sdague the fact that it emails everyone about patches all the time
14:07:40 openstackgerrit Dan Smith proposed openstack/nova master: Fix hypervisors api missing HostMappingNotFound handlers https://review.openstack.org/456227
14:08:00 frickler sdague: it seems to do multiple NOT_REGISTERED votes per patch for some time now, yes
14:08:30 openstackgerrit Sylvain Bauza proposed openstack/nova-specs master: Placement doing claims https://review.openstack.org/437424
14:08:39 mriedem frickler: yeah
14:08:57 openstackgerrit Gábor Antal proposed openstack/nova master: Transform instance.live_migration_rollback notification https://review.openstack.org/402124
14:09:07 mriedem emc scaleio is xyang1's team i think
14:09:38 sdague frickler: yeh, it's just massively misconfigured I think
14:09:44 mriedem well,
14:09:45 xyang1 mriedem: hi
14:09:51 mriedem it also relies on something that isn't merged yet
14:10:06 mriedem xyang1: can we get the emc scaleio ci in nova just restricted to the one patch that it cares about?
14:10:17 mriedem this one https://review.openstack.org/#/c/407440/
14:10:24 mriedem xyang1: it shows up as NOT_REGISTERED for all nova patches
14:11:08 xyang1 mriedem: oh, the nova CI. I think our CI team is still working on it. It is not working properly yet
14:11:31 xyang1 mriedem: I'll ask them to turn it off for now
14:11:36 mriedem ok, but it really won't work on anything except https://review.openstack.org/#/c/407440/ yet,
14:11:42 mriedem and probably not even that given the state it is in
14:11:46 mriedem xyang1: great thanks
14:11:52 sdague xyang1: they should also configure it to not email
14:12:09 sdague it's sending emails to all patch submissions
14:12:16 mriedem i didn't notice the email, those are all filtered for me
14:12:27 xyang1 mriedem: sdague noted. Will fix it
14:12:35 sdague xyang1: thank you
14:12:45 xyang1 sdague: np
14:14:51 sfinucan frickler: I assume the other two patches can be abandoned now?
14:16:04 frickler sfinucan: I think I still want to move on with them, but I'll wait with the rebase until the other is finished, so i'll -W for now
14:16:25 sfinucan (y)
14:26:44 openstack Launchpad bug 1675791 in OpenStack Compute (nova) "Instance created by demo user(non-admin), shelved by admin and unshelved by demo user --> ends up in error state " [Medium,In progress] - Assigned to Nikolai Korablin (nkorabli)
14:26:44 nkorabli Hi there! I am working on this bug: https://bugs.launchpad.net/nova/+bug/1675791
14:26:46 mriedem nkorabli: so you want to write a functional test to recreate https://bugs.launchpad.net/nova/+bug/1675791 ?
14:27:21 mriedem nkorabli: you should be able to do that in the functional test tree, we have an admin and non-admin user
14:28:05 nkorabli Alright! But, as i remember - you said it is better to fix the bug and then to write a test?
14:28:20 mriedem nkorabli: well, you could write the test that shows the bug first
14:28:28 mriedem see nova/tests/functional/regressions
14:28:53 mriedem although i'm not totally sure if our glance fixture would handle this
14:29:23 mriedem the case where it fails is the admin shelves the instance so they own the snapshot right? and the user tries to unshelve the instance but glance fails since they don't have visibility to the image
14:29:25 mriedem it's a 404 or something
14:29:46 mriedem we use a glance fixture for this in nova functional tests, and i very much doubt it tracks ownership for an image
14:29:52 nkorabli Correct
14:30:03 mriedem not that we couldn't update the fixture
14:30:09 mriedem you could also do this with a tempest test
14:30:27 mriedem tempest is probably easier
14:31:10 nkorabli So, fixture is kind of abstraction, that not reproduces 100% functionality?
14:31:16 mriedem correct
14:31:29 mriedem nova functional tests don't talk to a real live glance service
14:31:34 mriedem the fixture is basically a stub
14:31:45 mriedem it has some state and logic, but it's not th real thing
14:32:05 nkorabli I see!
14:33:31 mriedem nkorabli: if i remember correctly you were going to ask about this scenario in the mailing list too right?
14:33:33 mriedem did that happen?
14:34:03 nkorabli Just wondering how complicated is it to add this kind of functionality that I need? Is it possible to make in couple of days? Maybe it won't worth it if it's more than that
14:34:29 mriedem it would be relatively easy to write a test for the recreate in tempest
14:34:34 mriedem more so than nova functional tests
14:34:59 mriedem see http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/compute/servers/test_server_actions.py#n504
14:35:01 mriedem for an example
14:35:13 mriedem you could have to write a test mostly like that, except the shelve happens by the admin client
14:35:19 mriedem s/could/would/
14:35:48 nkorabli mriedem: Yes, I believe I raised a mailing thread, but nobody responded
14:35:58 mriedem nkorabli: link?
14:36:06 mriedem nkorabli: here is a tempest test that uses both admin and non-admin clients http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/compute/admin/test_servers.py#n30
14:36:27 mriedem i think the test just needs to define these credentials http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/compute/base.py#n467
14:36:40 mriedem i could help with the tempest test if you needed
14:37:09 mriedem or just do the test in http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/compute/admin/test_servers.py
14:37:43 mriedem the thing about tempest is it's branchless, so even if we fix the bug on master, the fix has to be backported to the stable branches for the tempest change to ever merge
14:38:01 mriedem unless we make that configurable in tempest
14:38:09 mriedem sorry this is probably a ton of information
14:39:17 nkorabli haha, yeaaaah :) Guess I need some time to get it.. But I really want to go through this
14:39:39 openstackgerrit Gábor Antal proposed openstack/nova master: Fix the FakeDriver using same hypervisor names https://review.openstack.org/456237
14:48:26 openstackgerrit Gábor Antal proposed openstack/nova master: [WIP] Transform instance.live_migration_rollback notification https://review.openstack.org/402124
14:51:47 mriedem melwitt: a few comments/questions in https://review.openstack.org/#/c/454352/ but overall it looks good
14:53:08 melwitt mriedem: thanks, will reply to the outstanding comments soon
14:55:13 mriedem nkorabli: i don't see anything in the ML about that bug
14:55:16 mriedem are you sure you sent it?
14:56:17 nkorabli mriedem: I saved our conversation, and going through the links you sent me. I will ping you after, most likely I will have more questions
14:56:54 nkorabli hmm, I am pretty sure I did, but I haven't joined the mailing list before I did it
14:57:31 openstackgerrit Sylvain Bauza proposed openstack/nova-specs master: Proposed block accepting AZ renames https://review.openstack.org/446446
14:57:46 nkorabli mriedem: this was a topic: "[openstack-dev] [openstack-operators] [nova] User that shelves an instance becomes an owner of snapshot for that instance"
15:00:18 nkorabli and I sent it to "openstack-dev@lists.openstack.org, openstack-operators@lists.openstack.org" on the 25th of March
15:00:46 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/nova master: Read Neutron port 'binding_profile' during boot https://review.openstack.org/449257
15:03:49 mriedem nkorabli: you have to join the mailing list before you send something to it
15:03:52 mriedem it was probably rejected
15:04:12 nkorabli ohh, I see. I will do it again, then
15:22:16 openstackgerrit Gábor Antal proposed openstack/nova master: Transform instance.volume_attach.error notification https://review.openstack.org/455801
15:38:37 mriedem lyarwood: comments in https://review.openstack.org/#/c/437070/ - mostly questions about the upgrade impact
15:39:07 openstackgerrit Jianghua Wang proposed openstack/nova-specs master: Support VGPU https://review.openstack.org/450122
15:40:37 mriedem lyarwood: i'm also not sure how you're going to implement a libvirt-specific encryption provider that doesn't live in nova/volume/encryptors, but i think we could make that clean with a stevedore extension
15:41:35 openstackgerrit Jianghua Wang proposed openstack/nova-specs master: Support VGPU https://review.openstack.org/450122
15:41:38 mriedem like we could have 3 encryptors registered, and each encryptor defines a type (so we'd have 1 cryptsetup and 2 luks registered), a weight, and an is_supported() or is_available() method
15:42:23 mriedem so for this case, we filter down to the 2 luks encryptors, then filter based on is_available() - the cryptsetup one we have always returns True, but the qemu one has to check versions. then depending on the final list, we sort them based on weight
15:42:38 mriedem so the qemu one is always weighed higher than the cryptsetup luks one, if we have to pick
15:43:30 mriedem we don't need those implementation details in the spec though, i just got thinking about it
15:51:51 lyarwood mriedem: sorry was afk, reading now.
15:52:24 lyarwood mriedem: upgrade impact is something I missed out, I'll get something in there for that now.
15:54:23 lyarwood mriedem: re stevedore, I'm not sure how that would work tbh, for this to work with libvirt/qemu I assumed we would need to check ahead of connect_volume to know which approach we are going to use.
15:54:35 lyarwood mriedem: that's well ahead of the encryptor.attach_volume calls we currently have
15:55:06 lyarwood mriedem: so unless we rework that flow so we are calling the encryptors before connecting the volume I don't see how that's going to work
15:55:14 lyarwood mriedem: but I'm likely missing something here
15:57:36 openstackgerrit Simon Dodsley proposed openstack/nova-specs master: Enhanced KVM Storage QoS https://review.openstack.org/340168

Earlier   Later