Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-04
13:53:38 efried mriedem: right. Was allowable before dansmith's patch on your change.
13:54:07 dansmith belmoreira: hmm, are you saying that back when you ran the keypair migration they weren't sync'd down to the v1 cell databases and thus nothing happened?
13:55:26 dansmith efried: everyone copied the first implementation in libvirt I imagine, which was luckily done the more explicit way..I checked all the in-tree drivers
13:55:31 efried edleafe: Still not sure I follow. If you're using <1.8, you'll get generations incremented under the covers and you'll never know about it. As soon as you start using the new microversion (the one you're writing), you'll see the generation (whatever it is) when you GET, and you'll push it back when you PUT/POST. That's as it should be. But that behavior ought to be the same regardless of what we do with the proj/user
13:55:37 efried dansmith: nod
13:56:06 efried edleafe: The proj/user isn't required even at 1.8, is it?
13:56:33 efried hm, looks like the user_id isn't marked as optional.
13:56:59 efried sorry, neither is marked as optional.
13:57:36 efried but are they in fact required? (That would seem weird, tbh)
13:58:27 efried edleafe: But my point is that you would already have this weirdness if you straddled microversions like that. You would have to deal with the fact that proj/user were null before (whether it's because the record doesn't exist or because the record exists with nulls in it) and now are required (or whatever).
13:58:51 edleafe efried: they are required >=1.8
13:59:09 efried edleafe: We're probably talking in circles around an issue that's insignificant if it even exists at all.
13:59:23 efried Is there any reason we can't make those fields nullable?
13:59:43 purplerbot <edleafe> It's a teeny behavior change, but a real edge of an edge case [2018-04-04 13:46:43.828800] [n 2tEe]
13:59:43 edleafe efried: [t 2tEe]
14:00:02 edleafe Like, if you're a purist...
14:00:06 efried and make the logic that returns them tolerate <record absent> and <record present with nulls> with the same result.
14:00:52 edleafe sure, nulls would have to work in all cases
14:01:13 edleafe ok, let me make that change to the consumers table and see how that works
14:02:05 efried ++
14:08:57 openstackgerrit Surya Seetharaman proposed openstack/nova master: Cleanup RP and HM records while deleting a compute service. https://review.openstack.org/554920
14:13:56 openstackgerrit Merged openstack/nova master: Teardown networking when rolling back live migration even if shared disk https://review.openstack.org/555481
14:25:08 belmoreira dansmith: sorry was away... yes, the migration was only correctly done in top DB
14:25:46 dansmith belmoreira: but you mean the top api cell db, not the api_db, yes?
14:26:24 belmoreira yes, the top DB in cellsV1
14:26:35 dansmith belmoreira: we just removed the code that did that migration, but even still, it would be out of the ordinary to make nova-manage reach across cellsv1 DBs
14:28:48 belmoreira dansmith: yes I saw that the code was removed. But when running nova-manage in cells DBs it should go to nova_api for the keypair
14:29:29 belmoreira I can cook something to keep me going but not sure how many people will have the same problem when moving to cellsV2
14:29:39 dansmith oh..wait,
14:29:42 efried dansmith, mriedem: Any reason we should be waiting to merge https://review.openstack.org/#/c/558648/ ?
14:29:56 efried (and... what's Kevin's IRC nick?)
14:30:25 dansmith belmoreira: you're saying if you run the migration against a child cell it doesn't look to api_db for the keypair, but does if you run it against the api cell?
14:30:26 mriedem Vek
14:30:48 efried k, not on. Just wondering why he didn't +W it.
14:31:30 dansmith efried: *shrug* if it works I guess it's fine, I have no strong opinions
14:31:43 efried dansmith: ight, done.
14:32:12 mriedem efried: that patch doesn't cover fast8
14:32:15 mriedem which is the only thing i use
14:32:36 mriedem *only thing i use for pep8 locally
14:32:50 dansmith that's all I use too,
14:32:59 dansmith but it's run by a script, so maybe it's a different issue?
14:33:22 dansmith oh, I guess it's the same as pep8 actually
14:33:26 mriedem yeah
14:33:29 mriedem just smaller scope of changes
14:33:29 dansmith cdent: *on this
14:33:36 dansmith yeah
14:33:43 dansmith I thought it was different for some reason
14:33:49 belmoreira dansmith: no, what I was trying to say is that the original migration was not considering cells. It was only looking to the keypairs in the same DB. But, maybe we can have a new migration to look into the nova_api DB for the keypair when running nova-manage in child cells
14:33:51 mriedem efried: removing your -W doesn't pull it out of the queue
14:34:03 sean-k-mooney fast8 just runs pep8 on the files you changed in the current patch or working tree
14:34:09 efried mriedem: I suspected that might be the case :(
14:34:13 sean-k-mooney its a nice speed up
14:34:17 openstackgerrit Matt Riedemann proposed openstack/nova master: Default to py3 for the pep8 tox env because it's stricter https://review.openstack.org/558648
14:34:23 mriedem that pulled it out
14:34:24 dansmith belmoreira: oh, did that one come before the ->api_db migration? it's not in my tree so I didn't go look
14:34:29 dansmith belmoreira: that makes more sense, but also.. :/
14:35:06 efried mriedem: thanks. It also occurs to me: does setting basepython actually do anything given that the commands are being run from within a sh script?
14:35:56 mriedem efried: not sure, unless that's the version of python 'installed' into the venv
14:36:06 mriedem and then the script runs in that venv
14:36:20 belmoreira dansmith: yes, it was before the keypair migration to nova_api
14:36:32 dansmith mriedem: I think it's the version that gets linked to bin/python yeah
14:36:58 dansmith so if that script is just running "python ..." then ...
14:37:03 efried dansmith, mriedem: It's not.
14:37:20 efried The script runs flake8, which is a python script with its own #!
14:38:05 dansmith right, but does the pip install from the basepython link it thusly?
14:38:08 efried ah, which in the venv does indeed invoke `python`
14:38:42 efried ...the venv's python. So yeah, should work.
14:55:34 openstackgerrit Artom Lifshitz proposed openstack/nova-specs master: Fix typos in NUMA-aware live migration https://review.openstack.org/558842
14:57:27 artom bauzas, ^^
15:03:28 bauzas specs cores, easy +W on https://review.openstack.org/#/c/558842/ (typos fixes)
15:20:59 tblakes mriedem: gibi: When you have a chance, could you please review the updated changes for https://review.openstack.org/#/c/555812/?
15:24:38 openstackgerrit melanie witt proposed openstack/nova master: Default to py3 for the pep8 tox env because it's stricter https://review.openstack.org/558648
15:31:53 efried tblakes: FYI, gibi is on vacation for another week and a half. (Honeymoon)
15:33:53 tblakes efried: Thank you for the heads up.
15:46:25 belmoreira dansmith: also, it's not only the migration. New instances don't have the keypair (NULL) defined in instance_extra in child cells DBs when running cellsV1. It's only in the top DB of cellsV1.
15:47:04 belmoreira dansmith: running ocata
15:47:27 dansmith belmoreira: because instance_extra post-dates cellsv1 and isn't sync'd AFAIK
15:47:27 openstackgerrit Lee Yarwood proposed openstack/nova stable/pike: libvirt: Block swap volume attempts with encrypted volumes prior to Queens https://review.openstack.org/543569
15:48:19 belmoreira dansmith: the keypair, because other fields are
15:48:40 dansmith belmoreira: other fields of instance_extra?
15:49:26 belmoreira dansmith: yes, for example flavor
15:49:28 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Filter allocation candidates by forbidden traits in db https://review.openstack.org/556660
15:49:28 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Filter resource providers by forbidden traits in db https://review.openstack.org/556472
15:49:29 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Support forbidden traits in API https://review.openstack.org/556820
15:49:29 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Parse forbidden traits in query strings https://review.openstack.org/556819
15:52:22 dansmith belmoreira: okay maybe we added something for flavor, I need to go look
16:11:40 belmoreira dansmith: humm... vcpu_model in instance_extra is also not sync. It only exists in the top DB in cellsV1
16:13:43 sean-k-mooney belmoreira: the vcpu_model should be stored in the instance object itself in the celldb no?
16:16:24 belmoreira sean-k-mooney: not sure if I'm understanding to what you are referring
16:18:43 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION for "Rocky" https://review.openstack.org/558783
16:18:54 sean-k-mooney so the vcpu modle is stored in instance extra as declared here https://github.com/openstack/nova/blob/master/nova/objects/instance.py#L58-L60. so you are saying in the cell1 db that field is not populated on the instance record but it is in the api db?
16:20:22 sean-k-mooney belmoreira: vcpu_model is also declared as an instance field here https://github.com/openstack/nova/blob/master/nova/objects/instance.py#L211 so i assumed it would be stored in the instnace object iteslef not in instrance_extra
16:20:32 dansmith sean-k-mooney: he's talking about cellsv1
16:20:34 belmoreira sean-k-mooney: I'm using cellsV1. the vcpu_model is in the top DB (cellsV1) but then is not sync to the child cells DBs
16:20:35 dansmith which is more complicated
16:21:49 belmoreira dansmith sean-k-mooney: thanks for the help. I need to leave now
16:21:54 sean-k-mooney dansmith: ya i have kindof hopped to never need to know how v1 worked.
16:37:37 lbragstad melwitt: we have another iteration of the default roles specification up for review (re: the identity intregration track from dublin) in case you're still interested in taking a look
16:38:19 lbragstad https://review.openstack.org/#/c/523973/ consists of the latest changes
16:38:28 melwitt lbragstad: great, thanks for the heads up

Earlier   Later