Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-12
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.
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

Earlier   Later