Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-12
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
19:05:10 dansmith okay
19:27:56 openstackgerrit Mathieu Gagné proposed openstack/nova-specs master: Nova support for attached volume extend https://review.openstack.org/453272
19:37:10 openstackgerrit Mathieu Gagné proposed openstack/nova-specs master: Nova support for attached volume extend https://review.openstack.org/453272
19:53:41 openstack Launchpad bug 1682222 in OpenStack Compute (nova) "Instance deployment failure due to neutron syntax error" [Undecided,New]
19:53:41 rajinir https://bugs.launchpad.net/nova/+bug/1682222 is causing the ironic CIs to fail
19:55:15 openstackgerrit Mario Villaplana proposed openstack/nova master: virt/ironic: Implement rescue and unrescue https://review.openstack.org/416487

Earlier   Later