Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-12
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
16:03:55 mriedem so we could sneak it in there i guess
16:04:10 mriedem if type == luks and native_luks_available: use the new hotness
16:04:23 mriedem else call encryptors.get_volume_encryptor as before
16:04:43 lyarwood yup that's what I had in mind
16:05:34 mriedem ok nvm then
16:05:50 openstackgerrit Stephen Finucane proposed openstack/os-vif master: doc: Add glossary https://review.openstack.org/452666
16:05:52 mriedem i don't know how we track the upgrade impact for the old style detach
16:06:09 mriedem can we determine that by looking at the guest config?
16:06:44 lyarwood yeah we should be able to by looking at the disk xml / config object
16:07:12 mriedem could this should work nicely then
16:07:16 mriedem s/could/cool/
16:15:01 openstackgerrit Simon Dodsley proposed openstack/nova-specs master: Enhanced KVM Storage QoS https://review.openstack.org/340168
16:17:23 mriedem sfinucan: it's odd that 'default_schedule_zone' lives in CONF.compute
16:17:30 mriedem well, i guess it's in [DEFAULT] right now
16:17:34 mriedem but it's looked up in the api
16:17:56 mriedem but the option is defined in nova/conf/compute.py; seems that should live in nova/conf/availability_zone.py
16:18:14 mriedem i believe i'll move it
16:19:42 mriedem also, that option is super confusing when we also have default_availability_zone
16:23:46 openstackgerrit Maciej Szankin proposed openstack/nova-specs master: Add API impact to remove-nova-cert spec https://review.openstack.org/456284
16:24:40 macsz mriedem: i added the API impact for os-cloudpipe in https://review.openstack.org/#/c/456284/
16:25:45 mriedem macsz: thanks +W
16:32:52 openstackgerrit Jon Bernard proposed openstack/nova master: Add tempest-dsvm-ceph-rc https://review.openstack.org/456292
16:33:01 openstackgerrit melanie witt proposed openstack/nova-specs master: Amend spec for placement project/user association https://review.openstack.org/454352
16:45:27 openstackgerrit Dan Smith proposed openstack/nova master: Sort CellMappingList.get_all() for safety https://review.openstack.org/443174
16:45:28 openstackgerrit Dan Smith proposed openstack/nova master: Clean up ClientRouter debt https://review.openstack.org/444487
16:45:29 openstackgerrit Dan Smith proposed openstack/nova master: Add workaround to disable group policy check upcall https://review.openstack.org/442736
16:46:07 mriedem dansmith: you might want to get this spec update for melwitt https://review.openstack.org/#/c/454352/
16:54:45 openstackgerrit Jianghua Wang proposed openstack/nova-specs master: Support VGPU https://review.openstack.org/450122
16:57:26 dansmith melwitt: mriedem: am I missing where we say what we do if they use an old microversion and don't provide the user/project?
16:58:52 mriedem dansmith: that's the online data migration hand wave
16:59:00 dansmith no
16:59:08 melwitt dansmith: no, I didn't mention anything specifically about that. I guess I assumed it would just do what it was doing before. which means there we would have to keep two schema versions, one for the new one
16:59:10 dansmith I mean what happens if I call the api with microversion 1.0 and don't provide it
16:59:19 dansmith okay
16:59:45 dansmith I guess in that case we just can't query those things by project, but it's not a huge problem
16:59:48 mriedem right PUT /allocations/consumer_id at 1.0 doesn't require project_id/user_id
16:59:53 mriedem right
16:59:59 dansmith cells meeting now, but will continue when we're done
17:00:04 mriedem we will already have existing allocations that don't have the consumers table populated
17:00:21 melwitt not after the migration though
17:00:24 jianghuaw_ sfinucan, vladikr, jaypipes: Would you please help to have a look at this review: https://review.openstack.org/450122
17:00:26 jianghuaw_ thanks.
17:01:51 vladikr jianghuaw, sure, thanks
17:03:11 openstackgerrit OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/455960
17:12:22 dansmith mriedem: melwitt: so I guess I was just thinking about what happens if we continue to accept calls without the tenant info and keep putting things into the db without them
17:12:50 dansmith I guess it's just tough noogies for the quota stuff but otherwise not a huge deal
17:13:08 melwitt dansmith: oh, hm. I didn't think of that
17:14:04 openstackgerrit Jianghua Wang proposed openstack/nova-specs master: Support VGPU https://review.openstack.org/450122
17:15:16 melwitt dansmith: since we are the ones putting allocations (resource tracker), old computes would be putting allocations without project/user. and that would have happened after the online data migration? or do we have the operator run that after the upgrade is completed
17:15:21 mriedem dansmith: yeah we can't really do anything about it
17:15:51 mriedem melwitt: the old computes can still be posting allocations w/o project/user
17:15:57 mriedem so,
17:16:11 melwitt yeah, I know, but I mean after all computes are upgraded, is that when the online data migration via nova-manage is supposed to be run?
17:16:18 mriedem we could pin the counting quotas stuff on compute level, so we can't rely on placement until all computes are upgraded
17:16:20 melwitt because that would clean it up
17:16:30 mriedem the online data migration can be run whenever i think
17:16:33 mriedem it's idempotent
17:16:46 mriedem this might also be something we need to check in nova-status
17:16:47 melwitt yeah, true can't rely on placement until all computes upgraded

Earlier   Later