| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-04 | |||
| 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 | |
| 16:54:08 | dansmith | so you can just raise in there and catch it outside the context manager.. something like "raise BelayThatOrderCapN()" | |
| 16:54:27 | dansmith | I don't think you need anything more complicated than that | |
| 16:55:18 | mriedem | raise from within the wait_for_instance_event context? | |
| 16:55:23 | dansmith | yeah | |
| 16:56:00 | mriedem | wouldn't that call the error_callback registered with the event? | |
| 16:56:34 | dansmith | not if you don't have one, which you don't right? but either way, handle it in the error_callback if you want | |
| 16:57:10 | dansmith | er, no | |
| 16:57:18 | dansmith | actually if you raise yourself then it doesn't call error_callback even | |
| 16:57:23 | dansmith | that's only if the event fails | |
| 16:57:29 | dansmith | so just raise | |
| 16:58:41 | mriedem | yeah, flow control might get a bit wonky in this code, will have to deal with that | |
| 16:59:25 | mriedem | with the rpc change to the migrate data object we can't backport this either, but it's been such a latent issue maybe it's not something we really care about backporting anyway | |
| 16:59:39 | dansmith | I dunno, you're already catching exceptions around the context manager, so I would think it's just a catch/log/ignore and fall through sort of deal | |
| 17:00:09 | dansmith | oh, well, I guess you need to do that inside maybe | |
| 17:00:10 | dansmith | anyway | |
| 17:00:17 | dansmith | easier that building a cancel mechanism I think | |
| 17:00:24 | dansmith | *than | |
| 17:00:46 | mriedem | yeah i can also refactor our the existing meat if necessary for the part that actually calls the driver to transfer the guest | |
| 17:00:55 | mriedem | these live migration methods tend to get overly complicated | |
| 17:01:00 | dansmith | aye | |
| 17:01:01 | mriedem | *out | |
| 17:11:40 | openstackgerrit | Matt Riedemann proposed openstack/nova master: DRY up test_rollback_live_migration_set_migration_status https://review.openstack.org/555489 | |
| 17:11:40 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Avoid unnecessary port update during live migration https://review.openstack.org/556332 | |
| 17:11:41 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Wait for network-vif-plugged before starting live migration https://review.openstack.org/558001 | |
| 17:11:41 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add check if neutron "binding-extended" extension is available https://review.openstack.org/523548 | |
| 17:11:42 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add "bind_ports_to_host" neutron API method https://review.openstack.org/523604 | |
| 17:11:42 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add VIFMigrateData object for live migration https://review.openstack.org/515423 | |
| 17:11:43 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: libvirt: use dest host vif migrate details for live migration https://review.openstack.org/551370 | |
| 17:11:43 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add "delete_port_binding" network API method https://review.openstack.org/552170 | |