| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-12 | |||
| 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. | |
| 20:20:57 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: WIP: Microversion 2.50 - fix quota class sets resource usage https://review.openstack.org/483060 | |
| 20:20:58 | jdandrea | And I can't remove the single quotes without it going sideways. | |
| 20:21:33 | jdandrea | My problem is what I get on the inside doesn't appear to be valid JSON or YAML, so I can't even string load it. | |
| 20:23:21 | mriedem | the CLI isn't expect the value to be itself a dict, so it does a single split and assumes it's a string, which it is - and it's not going to unpack that | |
| 20:23:26 | mriedem | return dict(v.split('=', 1) for v in metadata) | |
| 20:23:29 | mriedem | is what the cli code is doing | |
| 20:24:07 | jaypipes | jdandrea: who let you in here!? :P | |
| 20:24:15 | jdandrea | jaypipes - STOP FOLLOWING ME. :p | |
| 20:24:19 | jaypipes | hehe | |
| 20:24:21 | jdandrea | lol | |
| 20:25:11 | jdandrea | mriedem Right, that makes sense. So the trick is to encode it such that it lands in the plugin as something that can be converted sanely. | |
| 20:25:21 | openstackgerrit | Merged openstack/nova master: doc: Use consistent author, section for man pages https://review.openstack.org/482960 | |
| 20:25:56 | openstackgerrit | Merged openstack/nova master: doc: Remove dead plugin https://review.openstack.org/478469 | |
| 20:26:40 | mriedem | jdandrea: hmm, do you need to encode it somehow? | |
| 20:26:49 | mriedem | i'm not sure what's goofing it up when it gets over into the API | |
| 20:27:10 | jdandrea | mriedem Yeah, I'm not either. Pondering. | |
| 20:27:18 | mriedem | urlencode? | |
| 20:27:22 | jdandrea | Mayyyyybe. | |
| 20:27:25 | jdandrea | Plausible. | |
| 20:27:31 | mriedem | i'm totally guessing | |