| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-12 | |||
| 16:03:33 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Add parameters in cold migrate action https://review.openstack.org/410042 | |
| 16:04:07 | ralonsoh | mriedem: thanks for your comments! | |
| 16:04:15 | gibi | bauzas: OK. I will leave soon for today but just ping me tomorrow if you have questions | |
| 16:04:57 | bauzas | gibi: that's not necessary :) | |
| 16:05:34 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Add functional tests for cold migration to same host https://review.openstack.org/414926 | |
| 16:05:43 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Add functional tests for cold migration to same host https://review.openstack.org/414926 | |
| 16:07:55 | gibi | bauzas: there are patches up to help keeping the style of the sample files consistent. I left the links under your comment | |
| 16:08:02 | bauzas | ++ | |
| 16:08:25 | bauzas | not really super important, but for review time, it helps | |
| 16:10:17 | gibi | bauzas: I agree | |
| 16:14:05 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: List/show all server migration types (2/2) https://review.openstack.org/459483 | |
| 16:28:34 | mriedem | jaypipes: given sdague was +2 on https://review.openstack.org/#/c/454322/ and is out for the rest of this week, if you're cool with it, want to just fast approve that one? | |
| 16:28:54 | jaypipes | mriedem: done | |
| 16:28:58 | mriedem | thanks | |
| 16:32:08 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Add Neutron port capabilities to devspec in request https://review.openstack.org/451777 | |
| 16:36:10 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Remove plug_ovs_hybrid, unplug_ovs_hybrid https://review.openstack.org/483030 | |
| 16:36:11 | openstackgerrit | Stephen Finucane proposed openstack/nova master: tests: Remove useless test https://review.openstack.org/483031 | |
| 16:38:35 | edleafe | 1/away | |
| 16:38:39 | edleafe | geez | |
| 16:43:08 | bauzas | edleafe: 2/there | |
| 16:43:19 | edleafe | bauzas: :) | |
| 16:57:36 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: add claim_resources() to report client https://review.openstack.org/482382 | |
| 16:57:37 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: claim resources in filter scheduler https://review.openstack.org/482383 | |
| 16:58:29 | jaypipes | edleafe, mriedem, bauzas, dansmith: ^^ squashed the "alternate destinations" patch into the claim resources in filter scheduler patch and re-ordered the patches so the add claim_resources() to report client can be reviewed ahead of the claim in scheduler patch. | |
| 16:58:36 | jaypipes | still need to handle the cells thing. | |
| 17:01:22 | mriedem | ok | |
| 17:17:19 | mriedem | gmann: https://review.openstack.org/#/c/467999/ needs some work | |
| 17:17:23 | mriedem | it's merged but the docs are lacking | |
| 17:21:19 | edleafe | jaypipes: regarding filtering alternates by cell, feel free to take as much of this as works: https://review.openstack.org/#/c/465768/8/nova/scheduler/filter_scheduler.py@181 | |
| 17:27:24 | openstackgerrit | Merged openstack/python-novaclient master: Microversion 2.49 - Virt device tagged attach https://review.openstack.org/480392 | |
| 18:16:25 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: WIP: Microversion 2.50 - fix quota class sets resource usage https://review.openstack.org/483060 | |
| 18:36:09 | cdent | edleafe: filtering rps by traits: https://review.openstack.org/#/c/474602/ still alive? | |
| 18:39:35 | gheorghe_ | is there something wrong with migrations on ocata? my VMs are on the same host after migration...always... | |
| 18:40:12 | mriedem | gheorghe_: are there errors in the logs? | |
| 18:40:21 | mriedem | are you doing cold migration, live migration, or resize? | |
| 18:40:42 | mriedem | there are no known issues, upstream integration test for migrations is fine | |
| 18:43:40 | rm_work | Hey, I'm about to look into making keypairs be project-level scope instead of user+project | |
| 18:43:41 | rm_work | Just wondering if there is some easy way to just enable this | |
| 18:43:43 | rm_work | or if someone has already done this before | |
| 18:43:56 | rm_work | (not necessarily to push upstream, we just need this in our cloud) | |
| 18:44:03 | rm_work | ^^ before anyone freaks out | |
| 18:44:13 | mriedem | rm_work: ask melwitt - quotas could be a problem | |
| 18:44:22 | rm_work | we currently have quotas as -1 for keypairs | |
| 18:44:34 | rm_work | so i'm not especially concerned | |
| 18:44:47 | rm_work | but i'll take that note down | |
| 18:45:17 | gheorghe_ | mriedem i am doing live migration, with block and without block (i also have some VMs on iscsi target) and in both cases the migration is not reporting any errors, but the VM stays on the same host | |
| 18:45:29 | mriedem | gheorghe_: then something is failing | |
| 18:45:41 | rm_work | melwitt: have you worked on keypairs per project? | |
| 18:45:42 | mriedem | and it's either rolling back to the source host, or it's never even getting to the destination host | |
| 18:46:54 | melwitt | rm_work: what do you mean by make it project scope instead of project+user? do you mean set a limit across a project and count allocated keypairs only across a project? | |
| 18:46:58 | gheorghe_ | mriedem, i don't see anything in /var/log/libvirt/qemu# so i suspect something is failing on nova level | |
| 18:47:41 | rm_work | melwitt: I mean, if user A on project X uploads a keypair, we want user B on project X to also see that keypair in that project | |
| 18:47:46 | rm_work | and be able to use it | |
| 18:47:51 | melwitt | oh, I see | |
| 18:48:08 | rm_work | in most other clouds, this is the way key auth works | |
| 18:48:41 | rm_work | and users are incredibly confused when they set up keypairs and then their service account or whatever goes to create a VM and errors out because the keypair isn't there (but THEY see it) | |
| 18:49:40 | rm_work | and rather than try to educate/correct an ongoing set of users who have experience with other clouds or make an expectation based on how *everything else* works, we'd rather just ... enable the functionality they expect, because I can't see a good reason not to :P | |
| 18:49:41 | rm_work | it's just public keys... | |
| 18:49:50 | rm_work | my public key is posted on my website... | |
| 18:50:08 | mriedem | gheorghe_: sure, and that should be in the /var/log/nova logs | |
| 18:50:20 | rm_work | melwitt: have you worked on anything like this? | |
| 18:50:37 | melwitt | rm_work: yeah, use case makes sense. I haven't heard of anyone doing it before though. I'm not sure what it would take, whether it would be hard. AFAIK it can't just be easily enabled | |
| 18:50:44 | rm_work | kk | |
| 18:50:52 | gheorghe_ | mriedem i get only info messages within /var/log/nova ... if you want, i can try i migration now and give you the nova logs. do you want to see the ones from controller or the ones from kvm? | |
| 18:51:10 | mriedem | gheorghe_: i don't want to debug your logs no | |
| 18:51:18 | edleafe | cdent: yes, the filtering by traits is still alive. It can also be adapted for filtering the new allocation candidates method. | |
| 18:51:21 | mriedem | gheorghe_: run it with debug=True in the nova.conf on all nodes, computes and controller | |
| 18:52:19 | mriedem | and then i'd trace the request id through the nova-api, conductor and compute logs | |
| 18:52:35 | gheorghe_ | request id returns only an info message | |
| 18:52:49 | mriedem | the request id is logged with all messages for the given request context | |
| 18:52:57 | mriedem | so if you have debug logging enabled, you should be able to see it there also | |
| 18:53:34 | mriedem | e.g. http://logs.openstack.org/90/481290/3/check/gate-tempest-dsvm-multinode-live-migration-ubuntu-xenial/fcc4b2f/logs/screen-n-cpu.txt.gz#_Jul_08_18_07_57_384617 | |
| 18:53:45 | gheorghe_ | omg mariedem i actually found something | |
| 18:53:49 | mriedem | req-df8aac96-7d4f-4652-9237-d6da65164ee5 is the request id | |
| 18:54:03 | gheorghe_ | https://paste.gnome.org/pg7hkufiz | |
| 18:54:13 | gheorghe_ | i will troubleshoot this, brb | |
| 18:54:48 | mriedem | yup that would make it fail | |
| 18:56:47 | gheorghe_ | kvm-04 is not even listening on 16509 | |
| 18:59:11 | rm_work | melwitt: ah, I was wrong about keypairs already being associated with a project | |
| 18:59:21 | rm_work | they are purely user associated at the moment :( | |
| 18:59:40 | gheorghe_ | mriedem does it work only with insecure conn? https://paste.gnome.org/pfdfgbkaj | |
| 18:59:41 | rm_work | so yeah pretty big change I think T_T | |
| 19:03:49 | melwitt | rm_work: *looks* yeah, I didn't know project_id isn't even part of the data model. so yeah, much bigger change than I was thinking too | |
| 19:03:53 | mriedem | gheorghe_: there are lots of different ways to configure it i think, | |
| 19:03:57 | mriedem | devstack uses ssh | |
| 19:04:16 | mriedem | you could also run in tunneled mode but that slows it down | |
| 19:04:52 | gheorghe_ | mriedem this is not devstack, this is the tutorial with 1 controller and 4 kvm hosts | |
| 19:05:14 | mriedem | sure | |
| 19:05:17 | mriedem | that's not my point though | |
| 19:05:32 | mriedem | also, which tutorial? | |
| 19:05:37 | mriedem | and https://docs.openstack.org/security-guide/instance-management/security-services-for-instances.html#instance-migrations | |
| 19:06:38 | mriedem | also https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_openstack_platform/7/html-single/migrating_instances/ | |
| 19:08:10 | jangutter | jaypipes: so I got succesful plugging with an external os-vif + neutron plug-in. | |
| 19:08:19 | jaypipes | jangutter: \0/ | |
| 19:08:37 | jangutter | jaypipes: Yep. Nova changes were tiny. There are two hitches though. | |
| 19:09:03 | jangutter | jaypipes: one is that stashed the PCI address inside the vhost-user socket path. | |
| 19:09:30 | jangutter | jaypipes: and the second is that there's no filtering for the Agilio NICs. it's basically picking anything that says it's an ethernet VF. | |
| 19:09:51 | jangutter | jaypipes: the second is the one we know about. | |
| 19:09:59 | jaypipes | jangutter: put the Netronome vendor_id and product_id in the pci_passthrough_whitelist. | |
| 19:10:21 | jangutter | jaypipes: yep, that I did. And it's working as expected. | |