| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-12 | |||
| 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 | |
| 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 | |