| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-12 | |||
| 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 :) | |
| 17:37:12 | melwitt | yeah. can't hurt, could possibly help | |
| 17:37:30 | melwitt | yes, I can do that :) | |
| 17:44:53 | melwitt | mriedem: do you have an opinion on whether or not to have the online migration? dansmith pointed out that new computes will heal existing allocation records. the only allocations that wouldn't get updated are ones for say, a down compute | |
| 18:03:52 | mriedem | reading back | |
| 18:04:38 | mriedem | yeah i think we could drop the online migration if it's self healing | |
| 18:04:53 | mriedem | old computes won't self heal for this, but we won't use it if we have old computes | |
| 18:04:56 | mriedem | so that problem solves itself | |
| 18:04:57 | mriedem | i think | |
| 18:05:08 | mriedem | melwitt: dansmith: ^ | |
| 18:05:32 | melwitt | thanks mriedem | |
| 18:57:41 | openstackgerrit | Lee Yarwood proposed openstack/nova-specs master: Libvirt: Native LUKS file and host device decryption by QEMU https://review.openstack.org/437070 | |
| 19:04:29 | mriedem | dansmith: ^ lgtm now | |
| 19:04:34 | mriedem | pretty straightforward | |
| 19:05:07 | mriedem | i'm a gonna run to home depot to get some plywood, bbiab | |