Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-05
15:53:03 stephenfin I can figure out what network I have but then I need to map that network to a given NUMA node
15:53:39 stephenfin and that information lives on each individual host, either as a configuration option or something else
15:53:55 sean-k-mooney stephenfin: well you can have enough info in the schduler if you populated it in the host state object. placement does not know about it however unlees the compute agent puts it in placement too
15:54:13 stephenfin so it looks like I'm going to have to pass it back to the scheduler via the host state object, which I'm not sure I want to do
15:54:21 stephenfin sean-k-mooney: yup, exactly
15:54:28 sean-k-mooney stephenfin: i had assumed you were going to addd the network stuff to the numa topology blob
15:55:24 openstackgerrit Matt Riedemann proposed openstack/nova master: doc: add a link in the install guides about configuring neutron https://review.openstack.org/559115
15:55:49 sean-k-mooney so the compute agent would read the config opptions and populated the numa info for the backend into the numatopology blob then the numa topology filter which gets that blob in the host_State object can make desions about the host
15:57:02 openstackgerrit Matt Riedemann proposed openstack/nova master: Update the cells FAQs and scheduler maintenance docs. https://review.openstack.org/556459
15:57:43 stephenfin sean-k-mooney: Hmm, I hadn't considered that. I'd been adding additional fields and then got stuck because I had a network from the user and physnet name from the host
15:57:54 sean-k-mooney stephenfin: your only other option bar modleing it in placement which is the long term answer is to not scheduler based on the numa constriats and retry if you cannont fit the insance on the compute node that was selected
15:57:55 stephenfin *I had considered that but...
15:58:41 sean-k-mooney stephenfin: well you have more then the network
15:58:58 sean-k-mooney your stuff assumed that the vm was booted with a nuton port
15:59:10 stephenfin so network and port IDs
15:59:11 stephenfin ?
15:59:27 sean-k-mooney in that case we already pull back the full neutron port object to check if its an sriov port
15:59:46 sean-k-mooney so you can ask neutron for the physnet and put that in the instance request object
16:00:04 sean-k-mooney you can also determin if its a tunneled/routed port
16:00:31 stephenfin sean-k-mooney: Yup, I've been charting that this afternoon :D http://paste.openstack.org/show/718499/
16:01:06 sean-k-mooney stephenfin: thats how the nic feature based schduling works :)
16:01:27 stephenfin ralonsoh_'s patches?
16:01:31 sean-k-mooney yep
16:01:46 stephenfin (I've been meaning to re-review those but they were failing CI last I checked)
16:02:05 sean-k-mooney we extend the pci requst spec object to carry the feature flags
16:02:59 sean-k-mooney stephenfin: i belive the bandwidth spec was suggestion adding an arry of networkRequstsSepcs to the instance request object
16:03:37 stephenfin I need to reread that one too so. That's exactly what I'd done
16:04:01 sean-k-mooney stephenfin: oh and i started rebasing rodoflos patches yesterday
16:04:18 stephenfin Only, like I said, it seemed useless to me because I didn't want to be querying neutron for more information from the scheduler
16:04:19 sean-k-mooney i hope to have them back up tomrowo or monday
16:04:31 stephenfin sean-k-mooney: Sounds good. I can review once they're done
16:04:35 stephenfin *ready
16:05:22 stephenfin sean-k-mooney: I'll push up what I have probably some time tomorrow
16:05:33 stephenfin Try not to laugh too hard. It's strewn with TODOs :D
16:05:34 sean-k-mooney well i broke them more in the refactor. once they are back passing unuit test i will need to do some more testing with real hardware so they wont be "ready" untill later next week but they can still be reviewed
16:05:54 stephenfin Yeah, that's fine. I can do some basic validation too
16:06:02 stephenfin ...given that I actually have hardware again
16:06:31 sean-k-mooney well im currently doing the rebase work in a vm so need to deploy on real hard ware to test after that is done.
16:12:16 mriedem efried: imacdonn: i've updated https://review.openstack.org/#/c/554577/ to depend on your nova change
16:13:34 efried mriedem: cool
16:30:05 mriedem kashyap: holy wow everything volume-related failed in your patch http://logs.openstack.org/84/534384/24/check/tempest-full/c7c0cbe/
16:30:09 mriedem congratulations on breaking cinder
16:31:03 kashyap mriedem: I suppose you're referring to: https://review.openstack.org/#/c/558783/
16:31:05 mriedem it's not related to your patch, just looks like c-vol is having a very bad time http://logs.openstack.org/84/534384/24/check/tempest-full/c7c0cbe/controller/logs/screen-c-vol.txt.gz?level=TRACE
16:31:06 kashyap ?
16:31:16 mriedem no
16:31:21 mriedem https://review.openstack.org/#/c/534384/
16:31:43 kashyap Ah, that one
16:32:25 kashyap mriedem: I go do a plain 'recheck', or does it require a more deeper incantation?
16:32:32 mriedem just recheck it
16:32:43 kashyap Done
16:33:13 kashyap mriedem: Too eager to jump the gun, eh :P
16:34:38 melwitt triaging this bug about disk_available_least going negative for an image-based instance with 0 GB disk flavor. proposal is to reject such requests with 400 (which would require a microversion, I think). additional thoughts welcome https://bugs.launchpad.net/nova/+bug/1758278
16:34:38 openstack Launchpad bug 1758278 in OpenStack Compute (nova) "disk_available_least become a negative value unexpectedly" [Undecided,New]
16:36:14 kashyap dansmith: Thanks for the fast-approve, and the eagle eyes, as usual.
16:38:41 jaypipes efried, pls see my response on https://review.openstack.org/#/c/556873
16:38:52 efried jaypipes: ack
16:39:27 mriedem dansmith: if you're done with your meeting, this will close out the cell-disable bp https://review.openstack.org/#/c/556459/
16:39:32 mriedem just the final docs patch
16:51:20 melwitt can someone remind me, in this last comment from belmiro, did he mean cells v2 instead of cells v1 or? https://bugs.launchpad.net/nova/+bug/1761197
16:51:20 openstack Launchpad bug 1761197 in OpenStack Compute (nova) "Not defined keypairs in instance_extra cellsV1 DBs" [Undecided,New] - Assigned to Surya Seetharaman (tssurya)
17:01:42 openstackgerrit Arvind Nadendla proposed openstack/nova master: Update ImageMetaProp object to expose traits https://review.openstack.org/557795
17:02:29 arvindn051 dansmith: jaypipes: updated code per comment(changed name of the field)
17:14:35 jaypipes dansmith: you good with it, I'm good with it.
17:14:56 dansmith I'm under a pile of other stuff right now,
17:14:58 dansmith hence me ignoring pings
17:14:59 dansmith sorry
17:15:02 dansmith will look later
17:15:59 jaypipes dansmith: no worries. I left a +2 on it.
17:26:20 sean-k-mooney jaypipes: just thinking back over your cpu spec and some of the other granualr requests discussions. have we finalised on the fact that numbered request groups will be guraenteed to be form different RPs
17:29:53 efried sean-k-mooney: Nobody has proposed a spec change
17:31:18 sean-k-mooney efried: hum ok in the current form if they are in the same request group are all resouces in that group required form the same subtree?
17:31:56 sean-k-mooney efried: ill read the sepc to confim just tought i would ask if you knew off the top of your head
17:32:09 efried if in the same numbered request group, they'll land in the same provider
17:32:38 efried in the unnumbered group, can be spread around the tree
17:32:38 sean-k-mooney efried: same provider or "same proviers or one of its childern"
17:33:56 melwitt tssurya: in this bug in belmiro's last comment, did he mean keypair isn't in instance_extra with cells v2? the comment says "cells v1" https://bugs.launchpad.net/nova/+bug/1761197
17:33:56 openstack Launchpad bug 1761197 in OpenStack Compute (nova) "Not defined keypairs in instance_extra cellsV1 DBs" [Undecided,New] - Assigned to Surya Seetharaman (tssurya)
17:34:17 efried sean-k-mooney: same provider. The only thing we have today (impl or design) that uses children is the concept of grouping as a tree. Nothing in placement deals with hierarthies or branches or subtrees etc
17:34:57 efried hierarchies, that is
17:35:02 melwitt fwiw, I checked a recent devstack of mine and see keypairs in instance_extra in the nova_cell1 database, so if there's a bug in ocata, it looks like it got fixed somehow later
17:35:27 melwitt (assuming cells v2 was what he meant)
17:36:19 sean-k-mooney efried: so you can never have a numbered resouce group containig CPUs and virtual fucntions and find a host as they will be from diffrent RPs in a subtree of a compute host
17:36:21 tssurya melwitt: no its in cellsv1 that we have this issue
17:36:38 melwitt tssurya: ah, okay. thanks for confirming
17:37:03 jaypipes sean-k-mooney: that is correct.
17:37:11 jaypipes sean-k-mooney: and we are aware that is a problem.
17:37:16 sean-k-mooney jaypipes: ok
17:37:53 efried sean-k-mooney: That's correct, given your premise.
17:38:01 openstackgerrit Merged openstack/nova master: Add nova-status check for ironic flavor migration https://review.openstack.org/527541
17:38:01 tssurya no problem :), yea its a weird thing happening between the two migrations in newton, one moving keypairs from the cellsDB keypairs table to instance_extra.keypairs and two moving the instance_extra.keypairs up to the apidb
17:38:27 tssurya and for the new instance currently created we don't have any instance_extra.keypairs and instance_extra.vcpu_models
17:38:32 tssurya instances**
17:38:39 sean-k-mooney i was talking to xlinx at the ptg after teh cyborg session ended. they reached out to me during the week to follow up and i suggested a solution that should still work for them provided we require they come form the same provider
17:39:15 sean-k-mooney efried: jaypipes it would still work with subtrees potetailly but it may also not
17:41:58 melwitt tssurya: yeah ... the way cells v1 works is it will write the instance data to the API level DB first, then sync the instances table down to child cell, and I assume instance_extra must not be part of that
17:42:18 melwitt so you'll never see instance_extra in child cells AFAIK
17:42:34 tssurya yes , this is what we are also thinking
17:42:46 tssurya I mean we have instance_extra, but some fields are not being synced
17:43:02 melwitt oh, so some fields and not others

Earlier   Later