Earlier  
Posted Nick Remark
#openstack-nova - 2020-08-27
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
17:08:16 sean-k-mooney that part of the grenade theory of upgrades workflow
17:08:18 gmann dansmith: this will change the default for nova - https://github.com/openstack/oslo.policy/blob/a626ad12fe5a3abd49d70e3e5b95589d279ab578/oslo_policy/opts.py#L121
17:08:21 dansmith sean-k-mooney: right
17:08:37 dansmith gmann: right, I see it now
17:08:56 dansmith gmann: but we can't just change the default and break everyone, even if the workaround is to change the config or copy the file, IMHO
17:09:25 gmann dansmith: but at some point we have to do that right? may be upgrade check in this cycle with warning and next cycle change default ?
17:09:30 dansmith that passes grenade because we don't override any policy I imagine, but if we did it'd be broken
17:09:51 dansmith gmann: yep, we can do that, warn now switch next
17:10:40 gmann ok. and with new tools operator have time for converting to yaml file too other than default one.
17:11:13 sean-k-mooney we shoudl add a nova status check too
17:11:40 sean-k-mooney because tehy should convert on victoria before upgrading idealy
17:11:45 gmann yeah its there but with failure which i can convert to warning for this cycle
17:12:20 gmann https://review.opendev.org/#/c/748059/1/nova/cmd/status.py

Earlier   Later