Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-04
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
16:54:05 mriedem as mentioned in the commit message, we could arguably say that we assume computes in the same cell to be using the same networking backend and just apply the config from the source host

Earlier   Later