Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-12
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
17:21:09 melwitt mriedem: can we do something to check computes version to have a conditional in the code on when to start calling placement maybe?
17:21:56 dansmith the online migration doesn't really need to happen if the compute side will heal like it does today
17:22:00 melwitt is that what you meant by pinning it?
17:23:49 melwitt dansmith: that's an interesting point. the RT is constantly doing a "update allocations" and the upgraded computes would update them with the project/user
17:24:20 melwitt so the only allocations that would get missed are ones with a down compute or some such thing
17:24:28 dansmith right
17:24:38 dansmith and I would think that we could just do away with the migration entirely,
17:24:50 dansmith especially since that's kindof a placement-side thing
17:24:51 dansmith and being in nova is kinda icky from a separation point of view
17:26:06 melwitt yeah ... just thinking, if a compute is down, that means its allocations don't get included in the person's usage. which seems right on the surface, but if it's a temporary thing then when the compute comes back up, they could go over quota
17:26:29 dansmith melwitt: just like losing a cell, but it's only a window where it matters,
17:26:37 dansmith and if they're over quota they're over quota
17:26:50 dansmith would be an easy reno I think
17:28:00 melwitt dansmith: what about what I mentioned earlier, do you think there's a way we could do an if/else to decide whether to call to placement for usages based on whether the service version is new enough or something?
17:28:36 dansmith melwitt: well, kinda have to have some gate for that anyway, even if we had the online migration, since that runs late
17:28:57 dansmith it's unfortunate to have counting code we only use in that window, but.. otherwise we have to wait a cycle, so probably worth it
17:30:00 melwitt yeah
17:32:18 mriedem i'm wholly dissatisfied with the new bed set that just showed up
17:32:21 mriedem le sigh
17:33:06 mriedem melwitt: yeah i meant a conditional, like we have in the filter scheduler in ocata
17:36:13 melwitt mriedem: k, I'll update the spec. looks like I would have benefited from an "Upgrade impact" template section but maybe I still wouldn't have though of these :P
17:36:41 mriedem melwitt: we could/should add one to the template
17:36:44 mriedem to think about stuff like this
17:37:03 mriedem you can totally take the lead on adding that :)

Earlier   Later