Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-07-03
14:52:08 adrianc sure thx for uploading the new PS
15:08:04 cdent efried: I've been waiting for you +1/2 on https://review.opendev.org/#/c/612497/ before reviewing it, assuming until it meets your expectations it wasn't worth the effort. So I'll probably get to it tomorrow morning...
15:08:37 efried cdent: I'm working through it (again) now.
15:08:57 efried your input would be valuable at this stage anyway, but I understand wanting to wait until the dust settles a bit.
15:10:17 cdent i've also already crested my 8 hour limit aleady today (was up early to work with some folk in china), so unless I get an afflatus this evening, it'll be manana
15:12:37 kashyap johnthetubaguy: Ping^2, maybe now you're about :-) -- Want to get the Secure Boot spec across the line? -- https://review.openstack.org/#/c/506720/ )
15:14:17 efried apparently cdent should stock bean-o
15:18:56 dansmith mriedem: I think I could probably slam your experimental job add patch amirite?
15:20:20 mriedem the ovs hybrid plug one? yeah.
15:22:59 dansmith mriedem: yeah
15:23:21 dansmith so slammed.
15:28:00 bauzas efried: gibi: johnthetubaguy: any reason why https://review.opendev.org/#/c/638734/8 wasn't +W yet ? I'm also cool with it, so I wonder why we hold it
15:28:31 efried bauzas: We're waiting for alex_xu to re-ack at this point.
15:28:39 bauzas ack, thanks
15:28:49 bauzas we basically already agreed on it at the PTG
15:29:05 bauzas so I'm not sure why we need to wait more but okay :)
15:29:25 bauzas the key part of the validation would be more controversial
15:29:40 bauzas but just checking the value looks just cool and simple
15:29:43 bauzas efried: ^
15:29:50 bauzas I mean, plain simple
15:30:03 bauzas from a spec perspective, we can nitpick on the implementation tho
15:30:29 efried I'll go ahead and merge it.
15:31:04 bauzas cool
15:31:38 efried stephenfin: assuming you didn't want to change the bp name?
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: Add 'resource_request' to neutronv2/constants https://review.opendev.org/668947
15:58:08 openstackgerrit Balazs Gibizer proposed openstack/nova master: Use neutron contants in cmd/manage.py https://review.opendev.org/668946
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 sean-k-mooney we do that in the pci weigher i think
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:42 efried I'm certainly not saying there's no value in a weigher
18:01:42 sean-k-mooney right
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 same_subtree + resourceless request groups (https://review.opendev.org/#/c/668376/ -W as sean-k-mooney says, but pretty close)
18:06:14 efried arbitrary group suffixes (implemented, microversion 1.33)
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 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 For NUMA we need

Earlier   Later