| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-12 | |||
| 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 | |
| 16:01:42 | mriedem | i probably need to go through and look at the flow too | |
| 16:03:29 | mriedem | lyarwood: oh i see, in attach_volume in the driver we call connect_volume before encryptor.attach_volume | |
| 16:03:49 | mriedem | and libvirt driver has it's own _get_volume_encryptor | |