| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-12 | |||
| 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. | |
| 19:10:41 | jaypipes | jangutter: I don't understand... you said it's not filtering? | |
| 19:11:11 | jangutter | Oh, I mean that if you have two sets of NICs in the same system, things will go... unexpected. | |
| 19:12:55 | jangutter | jaypipes: this is probably good enough (tm) for now in any case, if stashing the PCI address inside a socket path is acceptable. | |
| 19:12:58 | jaypipes | jangutter: you mean if there's, say, a mlnx nic and a netronome nic, and you allow guests to use either of those, there's no way to select which NIC for a flavor, right? | |
| 19:13:12 | jangutter | jaypipes: correct. | |
| 19:13:56 | jaypipes | jangutter: if both are connected to the same physical network, yes, unfortunately that's the case right now. until we land ralonsoh's patch for NIC capabilities. | |
| 19:14:21 | jangutter | jaypipes: yep, so I'm happy to live with that for a first stab. | |
| 19:14:34 | gheorghe_ | mriedem i am using ubuntu, not redhat | |
| 19:16:18 | jaypipes | jangutter: k, good with me. | |
| 19:16:29 | jaypipes | jangutter: happy to hear you've made some good progress! | |
| 19:17:29 | gheorghe_ | mriedem i got libvirt to listen but none of the tutorials online helped :D i just had to dig through config files | |
| 19:18:48 | jangutter | jaypipes: If I can get sean-k-mooney's way to set bridge name added, that means we only add the VIF_TYPE to nova.network.model, the associated _nova_to_osvif_vif_agilio_ovs() to os_vif_util | |
| 19:19:18 | jangutter | jaypipes: (and moshel's _set_config_VIFHostDevice) of course. | |
| 19:20:18 | jaypipes | jangutter: right. the fewer changes, the better :) | |
| 19:20:25 | jangutter | jaypipes: anyway, I'll do my best to get the code uploaded ASAP. | |
| 19:21:30 | jaypipes | jangutter: awesome, thanks! | |
| 19:30:55 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: WIP: Microversion 2.50 - fix quota class sets resource usage https://review.openstack.org/483060 | |
| 19:32:42 | gheorghe_ | mriedem it works now | |
| 19:43:10 | mriedem | gheorghe_: cool - if you have something to fix up the config options help text within nova, that would be appreciated | |
| 19:43:27 | mriedem | or was it libvirt config that you changed? | |
| 19:43:40 | gheorghe_ | i will show you my config for deploying hosts | |
| 19:43:49 | gheorghe_ | it configs nova AND libvirt for migration | |
| 19:43:52 | gheorghe_ | wait a sec | |
| 19:44:57 | gheorghe_ | check at the bottom: https://paste.gnome.org/p9vruj0zw ... as you will see here, this is the unsecure resolution. but it will enable you to migrate. also, it greps IP from a subnet deployed within my test environment | |
| 19:45:38 | gheorghe_ | i just this on every kvm node and it enables nova-compute and migration for kvm | |
| 19:45:47 | gheorghe_ | *i just RUN this | |
| 20:14:21 | jdandrea | For "nova boot" how does one specify metadata with a dictionary value? | |
| 20:14:26 | jdandrea | Trying --meta foo='{"bar": ["baz"]]}}' and it seems to arrive in the scheduler plugin's instance properties as a dict of the form {'foo': '{bar:[baz]}'} instead. | |
| 20:14:36 | jdandrea | Which is not valid JSON nor YAML. Maybe I'm doing something wrong on the cmd line? | |
| 20:15:03 | jdandrea | (I should say the value for foo isn't valid JSON nor YAML.) | |
| 20:15:40 | openstackgerrit | Merged openstack/nova master: doc: Remove cruft from conf.py https://review.openstack.org/478468 | |
| 20:19:18 | mriedem | jdandrea: i think you specify --meta multiple times | |
| 20:19:46 | jdandrea | mriedem - how do you do that to reference a nested key though? | |
| 20:20:01 | jdandrea | So I'd say --meta level_1_key=... something and then somehow refer to a level below level_1_key? | |
| 20:20:15 | mriedem | oh, no | |
| 20:20:46 | jdandrea | I want to provide a value that is itself a dict. So I figure I'd send in a JSON string enclosed in single quotes, but that doesn't quite work. | |