| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-04 | |||
| 13:59:43 | edleafe | efried: [t 2tEe] | |
| 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] | |
| 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 | dansmith | cdent: *on this | |
| 14:33:29 | mriedem | just smaller scope of changes | |
| 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 | 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:47:27 | dansmith | belmoreira: because instance_extra post-dates cellsv1 and isn't sync'd AFAIK | |
| 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 resource providers by forbidden traits in db https://review.openstack.org/556472 | |
| 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:29 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Parse forbidden traits in query strings https://review.openstack.org/556819 | |
| 15:49:29 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Support forbidden traits in API https://review.openstack.org/556820 | |
| 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 | |
| 16:39:05 | lbragstad | melwitt: no problem - let me know if you still want to go through the scope_types thing, too (cc mriedem) | |
| 16:45:58 | johnthetubaguy | lbragstad: I keep meaning to hit that one too | |
| 16:50:38 | mriedem | dansmith: on the heels of this wait_for_instance_event thing, i'm probably going to need a handle to the registered events so that i can cancel them, related to the TODO here https://review.openstack.org/#/c/558001/1/nova/compute/manager.py@6100 | |
| 16:51:04 | mriedem | i.e. i need to start waiting before calling the dest compute which returns a flag telling me if i should in fact be waiting | |
| 16:51:15 | mriedem | if dest says it doesn't care, then i need not wait | |
| 16:51:50 | dansmith | um, I'm not sure I understand | |
| 16:52:06 | mriedem | this is the thing where the source waits for vif plugged events, | |
| 16:52:13 | mriedem | pre_live_migration on the dest host does the vif plugging, | |
| 16:52:14 | mriedem | source is waiting | |
| 16:52:20 | dansmith | as long as you do your call to the remote side within the "with wait_for_events.." then whatever | |
| 16:52:28 | dansmith | oh so you don't hang exiting the with? | |
| 16:52:30 | mriedem | the change adds a config option to enable this, because we know some backends in neutron won't send the event unless the port host binding changes | |
| 16:52:57 | mriedem | well, the dest could set the flag saying don't wait, because it's using opendaylight or something | |