Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-08-27
15:40:20 sean-k-mooney ya for cold migation
15:40:26 sean-k-mooney but also the hack for live
15:40:35 sean-k-mooney where we dont set them or something
15:41:54 sean-k-mooney this https://github.com/openstack/nova/blob/f521f4dbace0e35bedd089369da6f6969da5ca32/nova/compute/resource_tracker.py#L303-L314
15:42:11 artom gibi, so https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L223 is the live migration claim creation method, that creates the migration context with the old and new NUMA topologies by calling down to _move_claim()
15:42:53 artom gibi, and yeah, sean-k-mooney found my TODO about converging the 2 (NUMA and SRIOV live migration)
15:43:39 artom gibi, the live migration claim is created on the destination at https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L7670
15:43:40 sean-k-mooney right which i objected too at the time and still do unless we remove the migration_data object
15:43:56 sean-k-mooney and and a couple of other things
15:44:14 sean-k-mooney like moving claims for spawn and other vent to the conductor
15:44:25 sean-k-mooney or ideally earlier
15:44:28 artom gibi, and then we eventually save the dest stuff (like numa topology) here: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L8587
15:45:13 sean-k-mooney artom: if its not clear as far as i am concerned the main reason we have races with numa is due to claims beign done on the compute node. that is what placment and numa in plamcnet was ment to solve
15:46:24 sean-k-mooney or we could have fixed it years ago if claims were dont in the scuderler of conductor
15:46:39 sean-k-mooney gibi: https://github.com/openstack/nova/blob/f521f4dbace0e35bedd089369da6f6969da5ca32/nova/compute/resource_tracker.py#L328
15:46:59 sean-k-mooney gibi: you need to use the new_numa_topology for the migration context
15:47:13 artom sean-k-mooney, it's not so much *where* they're done, it's that scheduling and claiming happened in 2 steps
15:47:30 sean-k-mooney artom: yes which is where they are done
15:47:32 artom sean-k-mooney, but yeah, claiming in the scheduler would have fixed that, because we could have made schedule + claim atomic
15:47:42 sean-k-mooney yes
15:47:53 sean-k-mooney which is what i argured for befor placment was created
15:48:06 artom Yeah, I could get behind that
15:48:13 artom But it's moot at this point
15:48:19 artom For better or worse
15:48:33 mriedem search is busted in the docs https://docs.openstack.org/nova/latest/search.html?q=cross_az_attach - click on one of those
15:48:55 sean-k-mooney oh it is
15:48:58 sean-k-mooney did we move things
15:49:11 gibi sean-k-mooney, artom: thanks I think I see it now
15:49:12 sean-k-mooney availability-zonesundefined
15:49:17 artom Where did the 'undefined' in that URL come from?
15:49:26 artom gibi, that's actually impressive that you do :)
15:49:28 sean-k-mooney so we are not substituing somthing
15:49:43 gibi artom: I see from where I need to use the topology
15:50:12 gibi artom: honeslty I don't have the brainpower to deeploy follow the argument about claims vs pci_tracker
15:50:13 sean-k-mooney migration_contex.new_toplogy
15:50:18 mriedem https://bugs.launchpad.net/nova/+bug/1893238
15:50:18 openstack Launchpad bug 1893238 in OpenStack Compute (nova) "nova document search result links not working" [Undecided,New]
15:50:54 sean-k-mooney ha we must have chagne some of the shinx setting
15:51:49 gibi ohh, nova meeting starts in 9 minutes in #openstack-meeting-3
15:53:00 bauzas this meeting time kills me :(
15:53:33 gibi bauzas: how can I help?
15:53:45 bauzas nothing really, I'll attend
15:53:57 bauzas but please, be short :)
15:54:09 gibi I will try
15:58:54 openstackgerrit Artom Lifshitz proposed openstack/nova master: post live migration: don't call Neutron needlessly https://review.opendev.org/747451
16:00:20 stephenfin artom: got a flake8 issue on https://review.opendev.org/#/c/747451/
16:00:38 artom gdi
16:01:50 openstackgerrit Artom Lifshitz proposed openstack/nova master: trivial: Remove useless comment https://review.opendev.org/748475
16:02:06 artom stephenfin, in the meantime, here's that useless comment removal ^^
16:04:01 stephenfin +2
16:04:57 openstackgerrit Artom Lifshitz proposed openstack/nova master: post live migration: don't call Neutron needlessly https://review.opendev.org/747451
16:50:14 artom lyarwood, melwitt, wanna take a gander at https://review.opendev.org/#/c/747451/?
16:51:08 lyarwood artom: I can try
16:51:16 artom lyarwood, cheers!
16:53:28 gibi gmann: sorry I totally forget you a second time too
16:53:36 gibi gmann: /o\
16:53:56 gibi gmann: is there anything important from API side?
16:56:21 gmann gibi: ah yeah me too :). just json to yaml migration, anyways let me get oslo tooling in for that and then we can talk on nova patch - https://review.opendev.org/#/q/topic:bp/policy-json-to-yaml+(status:open+OR+status:merged)
16:57:22 gibi gmann: seems like a fairly easy nova change
16:58:01 gibi gmann: if the oslo change lands before the non-client library freeze then we can try to land the nova change before m3
16:58:25 gmann yeah. i hope at least with upgrade checks, changing the default value would not break operators but dansmith or johnthetubaguy can corret me
16:58:48 gmann gibi: yeah that is the plan. i think we can merge the olso change by tomorrow
16:59:06 gibi cool, let's get back to this tomorrow or next week
16:59:12 gibi I have to drop now
16:59:14 gmann yup
16:59:51 gibi o/
17:00:23 dansmith gmann: json still works, right?
17:00:57 gmann dansmith: yeah it will work but default value of policy_file will change. https://review.opendev.org/#/c/748059/1/nova/policy.py
17:01:02 dansmith yaml is the default for the generation, right? I wouldn't think any problem on upgrade that wouldn't happen if we overwrote their file with fresh jsson anyway
17:01:08 dansmith oh
17:01:24 gmann i mean is anyone has policy.json then it has to be converted to policy,yaml
17:01:44 dansmith wait, they *have* to convert to yaml?
17:03:00 gmann yeah because of extension name change in default value. json formatted still work though
17:03:16 dansmith you mean if they take the default
17:03:18 dansmith file name
17:03:21 gmann yes
17:03:23 sean-k-mooney you need to use yaml to use some of the feautures
17:03:35 dansmith sean-k-mooney: yeah that's not what we're talking about
17:03:42 sean-k-mooney ah ok
17:04:01 gmann converting json formatted to yaml is separate thing and they can do in their own time and we provide tool also for that.
17:04:12 dansmith gmann: ah so, wait, we don't have a policy file conf, is that right?
17:04:27 gmann we do have
17:04:47 sean-k-mooney gmann: i assume the tool just does yaml.dump(json.loads(file))
17:04:52 sean-k-mooney or similar
17:04:53 dansmith gmann: where is it?
17:05:05 sean-k-mooney e.g. parse the profile then dump it in the other format
17:05:22 gmann sean-k-mooney: more than that - https://review.opendev.org/#/c/748055/4//COMMIT_MSG@17
17:05:23 dansmith sean-k-mooney: we're talking about breaking existing people, not generation right now
17:05:55 sean-k-mooney we kind of need to do this in a falback way
17:06:09 sean-k-mooney check for policy.json then check for policy.yaml right
17:06:18 sean-k-mooney and fail if we find both
17:06:36 dansmith sean-k-mooney: exactly, that's what I'm getting at
17:06:38 gmann dansmith: this is per service option - https://github.com/openstack/oslo.policy/blob/a626ad12fe5a3abd49d70e3e5b95589d279ab578/oslo_policy/opts.py#L48
17:06:41 dansmith prefer yaml, but fall back to json
17:07:08 sean-k-mooney just prefer or hard error if both
17:07:08 dansmith gmann: ack, so where is that DEFAULT_POLICY_FILE thing used?
17:07:21 dansmith oh jeez, I see
17:07:26 dansmith right under it, sorry :P
17:07:34 dansmith but yeah, we *have* to fall back IMHO
17:08:01 sean-k-mooney to fultile on upgrade we dont change config right

Earlier   Later