Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-04
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
16:53:08 mriedem so then we want the source to not wait the 5 minutes and then die
16:53:21 dansmith right, but you've already entered the context manager at the point at which you realize the destination says not to wait yeah?
16:53:31 mriedem right, not yet in this patch, but that's the TODO
16:53:35 dansmith yeah,
16:53:36 mriedem to avoid a race window

Earlier   Later