Earlier  
Posted Nick Remark
#openstack-nova - 2018-04-04
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
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: Avoid unnecessary port update during live migration https://review.openstack.org/556332
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:41 openstackgerrit Matt Riedemann proposed openstack/nova master: Add check if neutron "binding-extended" extension is available https://review.openstack.org/523548
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:42 openstackgerrit Matt Riedemann proposed openstack/nova master: Add VIFMigrateData object for live migration https://review.openstack.org/515423
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:43 openstackgerrit Matt Riedemann proposed openstack/nova master: Add "delete_port_binding" network API method https://review.openstack.org/552170
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:44 openstackgerrit Matt Riedemann proposed openstack/nova master: Implement migrate_instance_start method for neutron https://review.openstack.org/556334
17:11:44 openstackgerrit Matt Riedemann proposed openstack/nova master: Add "activate_port_binding" neutron API method https://review.openstack.org/555947
17:11:45 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Port binding based on events during live migration https://review.openstack.org/434870
17:11:45 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: compute: use port binding extended API during live migration https://review.openstack.org/551371
17:11:46 openstackgerrit Matt Riedemann proposed openstack/nova master: conductor: use port binding extended API in during live migrate https://review.openstack.org/522537
17:12:06 openstackgerrit Merged openstack/nova master: trivial: Fix nits in code comments https://review.openstack.org/558133

Earlier   Later