Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-07
15:58:31 idlemind hmm still can't get svm (amd nested) presented to a guest instance ... it's enabled on both hosts (cat /sys/module/kvm_amd/parameters/nested = 1). cpu_mode is host-passthrough and i see the model name correctly matches the underlying hardware directly but svm isn't picked up by the guest os
16:02:02 cdent mriedem: when you have a moment can you let me know what you'd like to have in place (spec, blueprint, whatever) to get the -2 lifted from https://review.openstack.org/#/c/362766/ (that's the optional placement db stuff). thanks.
16:06:57 mriedem cdent: reading the notes on the -2, it sounds like we talked about it at one point in a nova meeting and asked for a spec to cover the details of the change, how it gets rolled into CI (maybe the nova-next job?), and how to avoid whatever issue we had when it was merged and then reverted in newton (which i wasn't involved with at the time)
16:07:22 mriedem as dansmith mentioned at the ptg, you could run a separate placement db today,
16:07:39 mriedem if you point the nova.conf placement is using at a different placement database using the nova_api schema
16:07:46 cdent mriedem: aye
16:08:03 mriedem which in a spec i guess just goes under 'alternatives'
16:08:52 cdent now that that stuff is within a suite of other changes would you suggest that the spec covers all of it (in one spec) or something else?
16:09:31 mriedem suite of other changes == moving imports around?
16:10:31 cdent moving imports, moving objects into placemnet hierarchy, changing db config to use its own code (instead of the nova one which does more than needed)
16:11:01 mriedem i wouldn't lump that into the 'be able to run nova-api and placement-api on the same host with a single config but different dbs' thing
16:11:11 mriedem that other stuff is more general 'extract placement'
16:11:21 mriedem of which the separate db is a part
16:11:32 cdent ✔
16:11:54 mriedem another alternative to this,
16:12:24 mriedem is you could run nova-api and placement-api on the same host, not venv/containers, but if you had a config file strictly for placement, then you'd just run the placement service using that config file
16:13:16 mriedem nova-api --config-file /etc/nova/nova.conf && placement-api --config-file /etc/nova/placement.conf ?
16:14:50 cdent the way I did it in the current change was done that way mostly to make "doing stuff in devstack (and thus CI)" relatively easy: add a single config setting, set it, done
16:15:14 mriedem which might be how everyone else deploys everything today,
16:15:30 cdent the container experiments I'm doing use a custom config file for the container, which is a severely curtailed nova.conf
16:15:50 mriedem so unless i'm missing something, it seems to be a trade off between ease of deployment for nova + placement with a single config file, vs nova not doing this and just leaving it up to packagers/deployment tooling to handle the split if they want a split
16:16:22 mriedem eventually once placement is split out and has it's own placement.conf, it would just have a single [database] option group right?
16:16:50 cdent My feeling is that the optional config thing is just a convenience to make life easier (for us and other people) during whatever length of transition we have.
16:17:08 cdent It, uh, leaves options open...
16:17:18 mriedem pun intended
16:18:29 mriedem well i guess specaroo that thing, list the alternatives vs what this would buy people, and then maybe we can get some operator/deployment tooling folks feedback on the options and see if it justifies doing this
16:18:32 cdent when extraction happens I'd been inclined to continue naming the database.connection as placement_database.connection because it means we can add some other database later without whatever-ness
16:18:57 cdent roger. con aye. ten degrees down bubble
16:19:22 mriedem ftr, i'd also like just to defer to melwitt :)
16:19:33 cdent mriedem: sure, but it's your -2
16:19:39 mriedem yeah
16:21:02 openstackgerrit Eric Berglund proposed openstack/nova master: WIP: PowerVM Driver: Localdisk https://review.openstack.org/549300
16:25:19 openstackgerrit Eric Berglund proposed openstack/nova master: WIP: PowerVM Driver: Localdisk https://review.openstack.org/549300
16:29:26 openstackgerrit Merged openstack/nova master: hyper-v: Logs tips on PortBindingFailed https://review.openstack.org/539584
16:29:36 hrw anyone with spare time to look at PCIe hotplug patch? https://review.openstack.org/#/c/545034/ one
16:29:41 openstackgerrit Merged openstack/nova stable/queens: Pass user context to virt driver when detaching volume https://review.openstack.org/550220
16:37:01 stephenfin hrw: Done, and sorry for the delay. It looks pretty good to me. Just a couple of nits in there
16:37:15 hrw stephenfin: thx
16:38:42 hrw stephenfin: good comments
16:38:48 hrw stephenfin: discussion was on irc
16:39:21 openstackgerrit Merged openstack/python-novaclient master: Add os-testr in test-requirements.txt https://review.openstack.org/550329
16:39:29 stephenfin ralonsoh, sean-k-mooney: Dumb question, but could either of you clarify the difference between provider network and physical network?
16:40:31 stephenfin ralonsoh, sean-k-mooney: I _think_ a physical network is just a arbitrary string used to identify networks that are wired up together, so multiple provider networks on the same host could have the same physnet
16:40:35 sean-k-mooney stephenfin: a provider netwok is a l2 network that is affinitised to a phyical network. e.g. vlan 100 + physnet1 defines the wirelevel segmenation of the neutron network
16:41:05 sean-k-mooney vlan 100 + physnet2 can be a different neutorn netwok.
16:41:28 stephenfin sean-k-mooney: Right. Neutron doesn't have anything like a phynet object though, right? It's a just an attribute of the provider network?
16:41:57 sean-k-mooney stephenfin: correct physnet is just a name given to a specific copper/optical network
16:41:58 stephenfin hrw: Np. If you can get a link to the IRC discussion, that would be helpful. If not, maybe libvirt has this documented somewhere?
16:42:20 sean-k-mooney stephenfin: correct its just an attibute of the neutron network not an object
16:42:26 hrw stephenfin: was not documented. and we discussed glitches too
16:43:05 sean-k-mooney stephenfin: its defined by this api https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/provider_net.py
16:43:15 idlemind grr; this is killing me, still no svm passed into the guest i've tried changing the machine type .. can i force the feature via metadata into the libvirt xml somehow?
16:43:39 stephenfin sean-k-mooney: Awesome. So one provider network will be associated with one physnet. I assume you could have multiple provider networks using the same physnet?
16:43:54 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API https://review.openstack.org/482226
16:43:57 stephenfin Not that you'd want to/need to, but out of curiosity
16:44:08 sean-k-mooney stephenfin: that depend on the network type
16:44:42 sean-k-mooney you can only have one flat network per provider but you can also have 4096 vlan networks and 4096^2 QinQ networks
16:46:00 stephenfin sean-k-mooney: Ah, ok, so the VLAN case is why we should track physnet for that configuration option rather than provider network
16:46:01 sean-k-mooney its common to use the flat network as you wan uplink and then vlan networks for tenants on a singel physnet
16:47:07 andreaf mriedem I think that's something that changed on Tempest side because it used to work
16:47:12 stephenfin Seeing as each provider network will be using the same physical network and therefore the same OVS bridge and NICs (in the simple case)
16:47:40 andreaf mriedem the regex I mean - mtreinish could be something related to the changes we had around tempest run recently?
16:49:55 sean-k-mooney stephenfin: yes. this is why you dont want to use network affinity but rather us the physnet to aggregate many networks
16:50:59 stephenfin sean-k-mooney: Excellent. Thanks for the info :)
16:52:20 sean-k-mooney stephenfin: this might be useful too https://github.com/openstack/neutron/blob/master/doc/source/admin/intro-os-networking.rst#provider-networks
16:52:55 stephenfin sean-k-mooney: Sounds good. I'd been relying on this one so far https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/networking_guide/sec-connect-instance#using_flat_provider_networks
16:54:07 claudiub stephenfin: that looks like a spec-ial ocasion for a guiness. :D
16:54:39 openstackgerrit Marcin Juszkiewicz proposed openstack/nova master: Allow to configure amount of PCIe ports https://review.openstack.org/545034
16:55:03 hrw stephenfin: comments addressed. channel was not publically logged from what I see so no log
16:55:18 stephenfin hrw: Cool. Thanks for checking that out
16:55:31 hrw stephenfin: thanks for looking ;)
16:56:07 hrw stephenfin: like I said at PTG: addressing comments quickly allows to keep reviewer's attention to go for a second look ;)
16:57:12 openstackgerrit Dan Smith proposed openstack/nova master: Run post-test archive against cell1 https://review.openstack.org/550194
16:57:13 openstackgerrit Dan Smith proposed openstack/nova master: Add simple db purge command https://review.openstack.org/550171
16:57:13 openstackgerrit Dan Smith proposed openstack/nova master: Add --purge helper flag to archive_deleted_rows https://review.openstack.org/550182
16:57:14 openstackgerrit Dan Smith proposed openstack/nova master: Make nova-manage db purge take --all-cells https://review.openstack.org/550502
16:57:46 stephenfin hrw: I kind of think that warning is necessary. If you don't have that, how will the operator know their specially configured option is doing zilch?
16:57:46 sean-k-mooney stephenfin: its rather old but i used to send people this https://web.archive.org/web/20151006051825/https://www.rdoproject.org//Networking_in_too_much_detail to understand how openstack networking works with ovs but the offical netwoking guide is now pretty good too
16:57:52 idlemind holy fork; if i manually edit the vm w/virsh and add <feature policy='require' name='svm'>/> and reboot the instance in openstack i get svm passed into the guest ... i imagine this could get lost if the vm is migrated?
16:57:54 openstackgerrit Surya Seetharaman proposed openstack/nova master: [WIP] Allow scheduling only to enabled cells (Filter Scheduler) https://review.openstack.org/550527
16:58:34 hrw stephenfin: are there all options covered with such warning?
16:58:37 idlemind and there doesn't seem to be a way to force feature policy 'require' into kvm / libvirt vm definitions am i right?
16:58:45 idlemind (through metadata of an image)
16:58:47 hrw stephenfin: openstack logs are already overloaded with text in them
16:59:03 sean-k-mooney idlemind: it will remain untill a hard reboot is done or any other event that cause the xml to be regenerated(migration resize, hard reboot)
16:59:11 hrw like 100 characters of some random uuid like stuff before any useful data goes
16:59:31 idlemind sean-k-mooney thanks; anyway to get openstack to persistently add a feature 'require' statement for libvirt?
17:00:02 sean-k-mooney idlemind: i belive there is a way via image metadata
17:00:04 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: hyper-v: Logs tips on PortBindingFailed https://review.openstack.org/550529
17:00:39 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add abstract OVSDB API https://review.openstack.org/476612
17:01:03 stephenfin hrw: We do tend to warn for things like that alright, e.g. [1]. Not sure how consistent we are though. [1] https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L548-L562
17:01:26 stephenfin hrw: I could be wrong though. Perhaps mriedem or someone could weigh in?
17:01:45 hrw stephenfin: those you linked are close to log.error() level like
17:01:55 idlemind sean-k-mooney i've been trying but failing it would seem cim_pasd_instructionsetextension seems to be close but those values don't trickle into libvirt at least w/host-passthrough on
17:02:10 stephenfin Doesn't that seem sane though? I mean, we told nova to do something and it can't do it
17:02:19 stephenfin Someone should probably be told about that
17:02:27 mriedem what is the question?
17:02:45 stephenfin mriedem: comment here https://review.openstack.org/#/c/545034/13/nova/virt/libvirt/driver.py
17:02:46 hrw stephenfin: those warnings you linked are 'read, fix or things may blow' rather than 'ouch, you set option you do not need'
17:02:54 sean-k-mooney idlemind: what is you usecase that you want to enable

Earlier   Later