Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-07-03
15:31:52 efried ...which I just realized isn't in the commit message, ima fix that quick.
15:32:08 openstackgerrit Eric Fried proposed openstack/nova-specs master: Add 'flavor-extra-spec-image-property-validation-extended' spec https://review.opendev.org/638734
15:32:42 efried f
15:32:48 efried now ima fix it right
15:33:13 openstackgerrit Eric Fried proposed openstack/nova-specs master: Add 'flavor-extra-spec-image-property-validation-extended' spec https://review.opendev.org/638734
15:35:54 efried stephenfin: I went ahead and made those topic changes https://review.opendev.org/#/q/topic:bp/flavor-extra-spec-image-property-validation-extended
15:36:12 stephenfin efried++ thanks :)
15:37:18 stephenfin That WIP probably needs to be abandoned since we've gone a totally different direction, but that's a job for later this week/next week
15:43:09 openstackgerrit Eric Fried proposed openstack/python-novaclient master: Modify the url of upper_constraints_file https://review.opendev.org/665934
15:45:56 efried mriedem: cross-cell resize got no love this runway slot? :(
15:46:06 efried move back into queue, yah?
15:47:14 mriedem efried: it got some love from gibi and dansmith but yes i have some comments to address from gibi and need to re-queue
15:47:23 efried ight
15:47:50 mriedem are you going to update the etherpad?
15:51:05 mriedem nvm i'll do it
15:55:37 openstackgerrit Merged openstack/nova-specs master: Add 'flavor-extra-spec-image-property-validation-extended' spec https://review.opendev.org/638734
15:56:43 mriedem gerrit is being restarted
15:57:04 efried thanks
15:58:07 openstackgerrit Balazs Gibizer proposed openstack/nova master: Mova consts from neutronv2/api to constants module https://review.opendev.org/668945
15:58:08 openstackgerrit Balazs Gibizer proposed openstack/nova master: Use neutron contants in cmd/manage.py https://review.opendev.org/668946
15:58:08 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add 'resource_request' to neutronv2/constants https://review.opendev.org/668947
15:59:19 mriedem gibi: fyi i'm going through the heal allocations change now
15:59:54 mriedem and thanks for hitting the disabled compute series so fast
16:00:08 gibi mriedem: thanks. Above is the fup I promised to move to use contants instead of string for 'binding:profile' and the rest
16:01:31 gibi mriedem: disabled compute seemed an easy hit, and also I was vocal in the spec so I felt responsible
16:04:07 gibi mriedem: I need to drop soon so I will get back to your comments (if any) on the heal port allocation tomorrow
16:07:23 mriedem yup np
16:14:06 openstackgerrit Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA affinity for vGPUs https://review.opendev.org/650963
16:14:50 bauzas dansmith, efried: thanks for reviewing ^, I just provided some new revision with more explanation about upgrades
16:15:25 bauzas efried: I understand your concerns about this being a legacy mechanism and the fact that we approved the placement nested magic spec, so it could be seen as competitive
16:16:22 bauzas efried: but what I'm trying to explain is that my spec isn't competing with NUMA be modeled in placement, as it just provides a soft affinity check that can still be done once NUMA is modeled with placement
16:16:31 bauzas even the object change
16:16:42 bauzas so we can keep it, and drop it when we want
16:25:09 openstackgerrit Martin Midolesov proposed openstack/nova master: Implementing graceful shutdown. https://review.opendev.org/666245
16:32:36 qqmber hi... since today when I attach a volume (cinder volume), horizon shows that it is attached to the instance (Centos 7). If I run "nova show ID", shows the new volume's ID, but nothing happens on the instance... if it supposed to be in /dev/vdd, I run "sudo dmesg | grep vdd" nothing is shown (inside the instance). Any ideas where should I look for the problem?
16:59:13 sean-k-mooney qqmber: what does lsblk show
16:59:41 sean-k-mooney qqmber: the name you specified is not garunteeded to be the one it gets
16:59:42 qqmber in Nova host or the instance?
16:59:47 sean-k-mooney in the instance
16:59:52 qqmber ok
17:00:39 qqmber sean-k-mooney: not vdd there.. only vda and vdb (vdc is another story)
17:00:41 sean-k-mooney if the attach succeeded i woudl expect tehre to be a new block device that is not mounted but it might have a different name
17:01:18 qqmber I just sent you what I got
17:39:07 dansmith efried: can you save me some reading and summarize the opinion on bauzas' gpu numa spec
17:39:09 dansmith ?
17:40:12 dansmith like, are you saying that we're really far enough along to fully model (and reshape to) gpus under numa nodes with allocation candidates during scheduling to not do any of what he prescribes?
17:40:45 dansmith storing the child providers in the numa object and a weigher to look at it seems like (a) it might be useful for other things and (b) a weigher isn't a huge amount of debt
17:41:28 dansmith like, I can imagine the "show me the instance topology" thing might use some info in that child object to construct a view of where your assigned gpu (or something else) fits into the topop
17:56:10 efried dansmith: We're talking about coding a weigher that would provide a subset of the capability, and be 100% obsolete when we do placement-based topo modeling & affinity.
17:56:19 efried reading material, like the placement side specs & patches?
17:58:09 dansmith efried: even if placement returns an AC with hierarchical allocations for the proper gpus, we'd still have weigher activity to decide which of those we want right?
17:58:29 efried what would we be weighing in that case?
17:58:52 efried like, what's a use case where "pick the first one" isn't right.
17:58:55 dansmith efried: there is always a decision to be made about which allocation we want right?
17:59:42 sean-k-mooney we are weighign host that can fufile numa affitny above those that cant
18:00:12 dansmith placement may return two ACs, one where the gpu is on a node with the minimum amount of memory, and one where there's a bunch extra, and a weigher would choose the latter I would think
18:00:39 dansmith or the weigher would opt for the AC with the best combination of cpu, memory and gpu, especially where there are more than one gpu and you want as even of a distribution as possible
18:01:09 sean-k-mooney the other usecase for the weigher would be to avoid placeing instace on a host with a gpu if they did not request one
18:01:10 efried I thought bauzas's spec proposes that we binarily weigh "satisfies affinity requirements" higher than "doesn't"
18:01:18 sean-k-mooney by weighering them lower
18:01:26 dansmith sean-k-mooney: that's what bauzas' proposed weigher is doing yeah, but I'm saying that may evolve to something still useful after placement is returning ACs with gpu elements
18:01:26 sean-k-mooney we do that in the pci weigher i think
18:01:42 sean-k-mooney right
18:01:42 efried I'm certainly not saying there's no value in a weigher
18:02:11 sean-k-mooney when modeled in placmenet if we have two AC on the same host it coudl weigh the ACs based on some other parmater
18:02:12 efried but weighing "satisfies affinity requirements" is a thing we can do very soon with placement, if we're willing to put the work in it.
18:02:17 dansmith I'm just saying I expect that the bones of the proposed weigher would still be useful after placement is returning more data
18:03:01 dansmith efried: and also, we've been on the verge of being able to do this for a while, so it's easy to never move forward on a sub-optimal approach in favor of something else that never comes,
18:03:26 dansmith so if there's something re-usable about this after the better thing comes, I'm not as concerned about the "100% debt after merge" concern
18:03:31 efried okay, so let's talk about how close we are to being able to move forward:
18:05:31 sean-k-mooney i see tetsuro pushed up https://review.opendev.org/#/c/668376/ on monday but he has -w it so i assume it still have more work to do.
18:06:14 efried For NUMA we need
18:06:14 efried rg-to-rp mappings (implemented, microversion 1.34) https://docs.openstack.org/placement/latest/specs/train/approved/placement-resource-provider-request-group-mapping-in-allocation-candidates.html
18:06:14 efried and pieces from https://docs.openstack.org/placement/latest/specs/train/approved/2005575-nested-magic-1.html as follows
18:06:14 efried arbitrary group suffixes (implemented, microversion 1.33)
18:06:14 efried same_subtree + resourceless request groups (https://review.opendev.org/#/c/668376/ -W as sean-k-mooney says, but pretty close)
18:06:36 efried and then obviously we have to do the things in nova to 1) reshape and 2) request accordingly.
18:06:59 dansmith yeah the reshape is what I'm concerned about.. that delaying us another cycle
18:07:01 efried I feel it is very well understood what 1 and 2 will look like.
18:07:29 sean-k-mooney 1 is https://review.opendev.org/#/q/topic:story/2006068+(status:open+OR+status:merged) right
18:07:50 dansmith those are all placement,
18:07:53 dansmith the reshape is in nova
18:08:13 sean-k-mooney oh ya but the reshap cant happen until the placment stuff is done
18:08:37 dansmith sure, just being clear
18:08:52 dansmith the reshape is more complicated (IMHO, and IME), so unless that's "close" I'd be more concerned
18:08:58 sean-k-mooney im not sure we fully underdand what the reshap will looklike
18:09:00 efried yeah, those are a minor bugfix for rg-to-rp mappings. Really only cdent's is needed, the rest are what-ifs.
18:09:29 efried The nested magic spec has several examples of what the topo will look like
18:09:48 dansmith I think knowing what it will look like is not so much the problem
18:10:38 efried deciding which resources need to go where?
18:10:50 sean-k-mooney yes
18:11:09 dansmith the actual mechanics of doing the reshape.. I know it's doable and we know what the end result will look like
18:11:25 sean-k-mooney for exampel i think cpus are going to need to be moded in a nested resouce provider of the numa node not as an inventory of the numa node
18:12:11 sean-k-mooney hugepages should proably be on the numa node but as a new resouce class per pagesize or as somthign else?
18:12:30 dansmith efried: case in point ^ :)
18:12:31 sean-k-mooney dose memroy_mb stay on the compute resouce proveiider?
18:12:41 dansmith still plenty of discussion to derail the reshape
18:15:48 dansmith efried: anyway, I think you oughta make a clear decision on this point, and -2 bauzas' thing if so, so that the messaging is clear what to expect and focus on
18:16:19 dansmith I'm not saying that's a terrible thing, I just think it's not terrible to continue with both
18:16:35 dansmith obviously I want the pure-placement approach for all the right reasons

Earlier   Later