Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-12
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
20:19:19 sdague anyone else want to +A to fix the dhcp_v6 lie? https://review.openstack.org/#/c/450297/ :)
20:19:51 bauzas in case people wanna bite a spec proposal :) https://review.openstack.org/#/c/446446/
20:20:45 bauzas oh oops PS5 is already commented :)
20:44:06 openstackgerrit Jan Gutter proposed openstack/nova-specs master: Spec to enable Netronome SmartNIC support https://review.openstack.org/456386
20:56:40 openstackgerrit Peter Hamilton proposed openstack/nova-specs master: Add support for certificate validation https://review.openstack.org/357151
20:59:42 openstackgerrit Kaitlin Farr proposed openstack/nova master: Remove backend dependency for key types https://review.openstack.org/456204
21:00:16 openstackgerrit Jan Gutter proposed openstack/nova-specs master: Spec to enable Netronome SmartNIC support https://review.openstack.org/456386
21:15:00 openstackgerrit Jan Gutter proposed openstack/nova-specs master: Spec to enable Netronome SmartNIC support https://review.openstack.org/456386
21:19:02 openstackgerrit Steven Webster proposed openstack/nova master: Race condition between audit and migrate/resize revert https://review.openstack.org/400995
21:23:27 rajathagasthya Hello! I just ran a bandit check on nova master and I see a couple of high severity jinja2 autoescape warning: http://paste.openstack.org/show/606352/
21:23:30 rajathagasthya Would there be any objection to submitting a patch setting autoescapt=True?
21:23:50 openstackgerrit Steven Webster proposed openstack/nova master: Fix mitaka online migration for PCI devices https://review.openstack.org/456397
21:33:07 jangutter Hi! I'm the person who submitted the netronome-smartnic-enablement spec. Would anyone perhaps have spare cycles to review?
21:51:39 mriedem where is the admin_api policy rule defined, because i don't see it in nova's policy.json and i don't see it in keystone
21:52:37 mriedem dansmith: ew see this? https://review.openstack.org/#/c/456397/
21:56:15 dansmith mriedem: well, I guess we now know how many people are(n't) using those kinds of devices
21:56:48 efried jangutter Reviewed, for what it's worth :)
21:56:53 mriedem 1s of 2s of users
21:57:04 jangutter Thanks!
21:58:38 openstackgerrit melanie witt proposed openstack/nova-specs master: Amend spec for placement project/user association https://review.openstack.org/454352
22:14:18 openstackgerrit Jan Gutter proposed openstack/nova-specs master: Spec to enable Netronome SmartNIC support https://review.openstack.org/456386
22:14:23 openstackgerrit Takashi NATSUME proposed openstack/nova-specs master: List/show all server migration types https://review.openstack.org/407237
22:39:04 suresh hi, I am not able to install nova-api and nova-placement-api together in ubuntu, due to conflict of packages........is it a bug or can someone help me with it.....please
22:40:11 mriedem dansmith: claims in conductor was approved http://forumtopics.openstack.org/cfp/details/63
22:40:21 mriedem even though it should have probably been renamed now :)
22:40:25 dansmith cool
22:40:36 dansmith meh, we'll surprise people
22:40:43 mriedem suresh: check https://docs.openstack.org/ocata/install-guide-ubuntu/
22:40:54 mriedem the docs team hit some package issues when writing the install guide
22:41:01 mriedem so those are either fixed or documented in there now

Earlier   Later