Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-03
21:00:37 mriedem consumers is in the api-ref for placement
21:00:56 mriedem oh nvm it's not
21:00:59 mriedem there must be a change up for that
21:01:04 mriedem avolkov probably knows
21:01:45 dansmith mriedem: and anything else that isn't an instance
21:01:48 melwitt I hadn't seen anything about consumers in https://github.com/openstack/nova/tree/master/nova/api/openstack/placement/handlers either
21:02:14 dansmith like, anything could claim some space on a cinder provider that isn't an instance
21:02:22 exarr Anyone able to offer a decent link to multi-regions for ocata? (Ubuntu)
21:02:32 exarr (as in to learn)
21:03:00 melwitt okay, that's what I was wondering, whether we could assume consumers are instances. so apparently not
21:03:04 dansmith nope
21:03:15 dansmith that's why they're called consumers and not instances :P
21:03:42 melwitt well, yeah. I thought someone had said we could derive it from allocations and I guess I didn't know how else other than consumers
21:04:05 dansmith well same deal, allocations could be for other things
21:04:07 melwitt instance mappings would work but they will also contain deleted instances
21:04:13 dansmith yeah
21:07:45 melwitt my initial thought was, put a deleted column on instance mapping. but that comes with the challenge of "if delete fails, don't set it." maybe if we hooked it up to instance.destroy() and set the flag from there it would work
21:17:46 jaypipes cfriesen: yeah, no way around that (supporting both for a release or two).
21:22:17 efried jaypipes Where do we stand on specs like https://review.openstack.org/#/c/485522/ which include a) enhancements to the existing PCI manager code; which also talk about b) new trait- or inventory-ish additions to the [pci]passthrough_whitelist in same ?
21:23:41 efried jaypipes There's a kind of push for (a) to do stuff we want sooner than it would be possible under NRP/GDM. And (b) is compounding a problem we're explicitly getting rid of... but getting rid of *later*; i.e. it'll all go away at once, so does it matter that we add to it now?
21:23:59 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Add ScaleIO ephemeral storage backend https://review.openstack.org/495922
21:28:46 cfriesen jaypipes: pretty much what I figured. I'll try and respin along the lines of your suggestion. Also, could you take a look at https://review.openstack.org/#/c/339715/ ?
21:29:10 dansmith melwitt: deletes are finished on compute nodes, which can't access that bit
21:29:32 dansmith melwitt: and we also said we weren't going to do soft deleted stuff in the api db, because it will only get _more_ out of sync than it does today
21:30:24 melwitt dansmith: if it's in Instance.destroy wouldn't that happen in conductor? or you're saying cell conductor not supposed to access API DB
21:31:23 dansmith melwitt: cell conductor can't talk to the api db right
21:31:30 melwitt yeah, just brainstorming. AFAIK there's no way to determine instances from placement. I guess could count allocations of "CPU" or something like that?
21:31:46 dansmith except if something outside of nova has allocations for your tenant,
21:31:51 dansmith like bifrost or mogan :)
21:32:30 melwitt would they not use a different resource class than our canned ones?
21:32:39 dansmith it's not NOVA_CPU, it's CPU
21:32:52 dansmith and MEMORY_MB and DISK_GB
21:33:07 dansmith (actually VCPUS, but you get the idea)
21:33:29 openstackgerrit Merged openstack/nova-specs master: Add a spec for minimal cache headers in placement https://review.openstack.org/496853
21:34:25 melwitt so we should abandon the idea of trying to count resources in placement? if something outside nova can consume CPU and RAM, then we wouldn't want to compare those against nova quota
21:34:38 dansmith I guess that's a good point
21:35:31 dansmith at ptg we were talking about using placement to make sure that nova and straight ironic uses don't step on each other's compute nodes
21:36:03 dansmith and this'd be a similar thing if mogan or zun or something like that was in the picture
21:36:07 mriedem dansmith: another fun paging spec https://review.openstack.org/#/c/506030/3
21:36:28 dansmith we could just say that you have to have different tenants, but that's not always going to work and counting usage by other services as quota in nova is just not right at all
21:36:46 melwitt yeah
21:36:57 openstackgerrit Merged openstack/nova-specs master: Add ScaleIO ephemeral storage backend https://review.openstack.org/495922
21:37:18 dansmith mriedem: ah yeah that one has to legit be cells aware
21:40:09 mriedem so begins my great recheckaning
21:41:16 dansmith mriedem: so do I just get all future pagination specs to review?
21:41:18 dansmith I'm so thrilled.
21:41:40 mriedem dansmith: you are mr multi-cells
21:41:41 mriedem so yes
21:41:58 mriedem to be fair, these were all approved back in newton apparently, but never merged
21:42:12 mriedem oh yeah, on that migrations paging one,
21:42:17 mriedem i noted that the marker they propose won't work
21:42:25 dansmith yep
21:45:14 melwitt I know, we could have consumer classes in a class column! "nova_instance"
21:45:31 mriedem consumer_type=instance
21:45:32 mriedem :)
21:45:38 mriedem it would be like osc
21:45:41 dansmith so, I thought at one point about having each instance consume one instance type
21:45:50 dansmith it's breaking the model though
21:46:03 dansmith what we need, IMHO, is the thing I suggested back in bristol when we were talking about this,
21:46:16 dansmith which is a service type on a consume (and maybe resource provider too),
21:46:29 dansmith so we know "this consumer is an instance" and "this provider is a compute node"
21:46:34 dansmith but jaypipes shot me down
21:46:59 melwitt yeah, on the surface I think it makes sense to be able to have some more info about consumers
21:48:00 dansmith IMHO, doing quotas in placement isn't critical and probably not worth that much trouble, at least at the moment
21:48:35 dansmith if people actually start deploying multiple cells and hit dead cells and perf issues, then we might do this to fix that, or we might have to do something totally differently
21:48:42 dansmith depending on what that data tells us
21:48:51 melwitt yeah, I didn't expect it to be this complex when I proposed it, so I'm cool with punting it for later
21:49:55 dansmith yeah, I should have thought of the other-things-consume-stuff thing earlier
21:49:57 dansmith so blame me
21:50:50 melwitt heh
21:59:21 jaypipes efried: I believe I already commented on that particular spec?
21:59:43 jaypipes dansmith: actually it's VCPU, not VCPUS :)
22:00:38 dansmith jaypipes: yeah yeah
22:01:02 jaypipes dansmith: I originally had the can_host attribute of the resource_providers table but edleafe shot me down and said we could just use a trait to indicate a sharing provider.
22:01:16 jaypipes edleafe is now under the bus that jaypipes was under.
22:01:26 dansmith jaypipes: yeah can_host was wrong
22:01:34 jaypipes also, jaypipes now heads to dinner with wifey.'
22:01:43 dansmith we could do it on providers with traits for sure
22:02:24 melwitt we could have a who_dat attribute on consumers
22:05:00 penick hah
22:06:06 efried jaypipes You did, on a couple that had that issue, but didn't address that issue specifically.
22:07:00 efried I mean, I'd like to be able to say, "-1: we're not mucking with the PCI manager." and/or, "-1: we're not going to do any (more) overloading of the whitelist for non-whitelisty stuff."
22:07:37 efried But I don't feel that "we" have fully landed on either policy.
22:08:02 dansmith I do
22:13:00 efried dansmith In the negative?
22:13:33 dansmith efried: I feel like both your -1 reasons are supported by the feelings of people who have expressed feelings on the matter
22:42:34 mriedem instance action events in action http://paste.openstack.org/show/622590/
22:42:46 mriedem so apparently rebuilding a bfv instance does not fail
22:42:48 mriedem sdague: ^
22:43:15 mriedem created a bootable volume with an image, created a server from that volume, then rebuilt it with the same image that is in the volume, no failures
22:46:23 mriedem it won't replace the root disk, but it doesn't explode
22:56:38 cfriesen mriedem: I think I found something a bit "off", though most of the time it shouldn't cause problems. In online_data_migrations() we call aggregate_obj.migrate_aggregates(), which copies the data over to the api_db and then calls db.aggregate_delete() but never deletes the entries in 'aggregate_hosts' or 'aggregate_metadata'
22:57:37 cfriesen mriedem: normally we'd only delete aggregates that don't have any hosts in them, but the migration code doesn't do that check
23:03:15 cfriesen whoops, I'm wrong about not deleting the aggregate_metadata, that's handled in aggregate_delete(). But unless I'm missing something else I don't think we delete all the entries in table 'aggregate_hosts'
23:32:14 openstackgerrit Merged openstack/python-novaclient stable/newton: Fix aggregate_update name and availability_zone clash https://review.openstack.org/507816
#openstack-nova - 2017-10-04
00:11:30 prometheanfire so, what's the story with nova-func tests?
00:16:06 openstackgerrit Ken'ichi Ohmichi proposed openstack/nova master: Remove doc todo related to bug/1506667 https://review.openstack.org/509315
01:52:30 openstackgerrit Merged openstack/nova master: Move ploop commands to privsep. https://review.openstack.org/492325
01:57:12 openstackgerrit melanie witt proposed openstack/nova master: Request zero root disk for boot-from-volume instances https://review.openstack.org/428481
01:57:13 openstackgerrit melanie witt proposed openstack/nova master: Claim and report zero root disk for boot-from-volume instances https://review.openstack.org/428505

Earlier   Later