Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-05
09:41:49 openstackgerrit Kashyap Chamarthy proposed openstack/nova-specs master: cpu-model-selection: s/cpu_models/cpu_model_list/ https://review.openstack.org/640866
09:46:01 openstackgerrit Boxiang Zhu proposed openstack/nova master: Raise error when force_raw_images and images_type are incompatible https://review.openstack.org/640271
09:50:14 openstackgerrit Merged openstack/nova master: Convert driver supported capabilities to compute node provider traits https://review.openstack.org/538498
09:58:02 aspiers \o/ capabilities patch landed \o/
09:58:12 aspiers kashyap: looking
09:59:30 kashyap aspiers: It's a one-worder, but the (long) commit message tells the story
09:59:55 kashyap I'm off from noon; so check back in tonight / tomm.
10:04:39 aspiers kashyap: updated https://review.openstack.org/#/c/640483/ but just realised I didn't address Artom's feedback on the commit message
10:09:06 openstackgerrit Adam Spiers proposed openstack/nova master: Parse elements from virConnectGetCapabilities() https://review.openstack.org/640483
10:09:55 openstackgerrit Sylvain Bauza proposed openstack/nova master: Refactor CONTRIBUTING.rst https://review.openstack.org/640970
10:10:06 aspiers kashyap: addressed in PS3
10:11:55 bauzas stephenfin: gibi: I just wrote https://review.openstack.org/640970 based on some good point from ttx
10:12:04 bauzas feedback welcome
10:14:38 gibi bauzas, kashyap: ack for both patches I will try to look at both after lunch
10:15:38 bauzas gibi: it's not a crucial thing
10:20:35 openstackgerrit Merged openstack/nova master: Make move_allocations handle empty source allocations https://review.openstack.org/636412
10:40:06 openstackgerrit Boxiang Zhu proposed openstack/nova master: Raise error when force_raw_images and images_type are incompatible https://review.openstack.org/640271
10:44:53 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Create PCI tests for NUMA'y tests https://review.openstack.org/640826
10:44:53 openstackgerrit Stephen Finucane proposed openstack/nova master: fakelibvirt: Add ability to generate fake PCI devices https://review.openstack.org/640409
11:24:10 openstackgerrit huanhongda proposed openstack/nova stable/rocky: Fix resource tracker updates during instance evacuation https://review.openstack.org/640982
11:34:20 openstackgerrit Merged openstack/nova master: Fix wrong consumer type in logging https://review.openstack.org/640723
11:49:11 openstackgerrit Balazs Gibizer proposed openstack/nova master: Ensure that bandwidth and VF are from the same PF https://review.openstack.org/623543
11:49:12 openstackgerrit Balazs Gibizer proposed openstack/nova master: Support server create with ports having resource request https://review.openstack.org/636360
11:51:56 gibi stephenfin, bauzas, sean-k-mooney: I've fixed / answered the concerns in https://review.openstack.org/623543
11:54:27 sean-k-mooney gibi: thanks. just going to make tea and il review after. i was more or less happy with it before so i expect it will be fine
11:56:00 gibi sean-k-mooney: thanks
11:57:22 stephenfin sean-k-mooney: Do you know anything about neutron's proxying of the nova metadata service?
11:59:01 sean-k-mooney yes
11:59:10 sean-k-mooney it can do it in two ways
11:59:19 sean-k-mooney either via the dhcp agent or the l3 agent
12:00:08 sean-k-mooney the default is to do it via the l3 agent by seting up a dnat rule in the router namespace to proxy the query to the neutron api
12:01:27 stephenfin sean-k-mooney: and what determines which way is used? I see references to neutron-metadata-agent, but I'm not sure how that fits in
12:01:50 sean-k-mooney if you have an isolated network(one that is not connect to an extrenal network via routers) then you use the dhcp version which used a dhcp option field to pass a route and it does the same dnat in the dhcp namespace
12:01:51 stephenfin sean-k-mooney: or whether nova-api-metadata or nova-api is used in this scenario
12:05:18 sean-k-mooney stephenfin: its determind by 2 or 3 config optiosn let me get them
12:06:46 sean-k-mooney these in the dhcp agent https://github.com/openstack/neutron/blob/master/neutron/conf/agent/dhcp.py#L41-L67
12:07:17 sean-k-mooney and these in the l3 agent https://github.com/openstack/neutron/blob/master/neutron/conf/agent/l3/config.py#L49-L51 https://github.com/openstack/neutron/blob/master/neutron/conf/agent/l3/config.py#L92-L98
12:08:10 sean-k-mooney so by default its enabled in the l3 agent and disabled in the dhcp agent
12:11:28 sean-k-mooney stephenfin: as far as im aware the neutron metadata agent is the thing the proxies the requrest to the nova api and the l3/dhcp agent just nat the requests to the metadata agent
12:12:30 sean-k-mooney so the metadata agent is what actully has the address fo the nova metadata endpong https://github.com/openstack/neutron/blob/a388701ddfe628e9a5bd16a78422164799b11ef8/neutron/conf/agent/metadata/config.py#L47-L53
12:29:32 openstackgerrit Chris Dent proposed openstack/nova master: Correct lower-constraints.txt and the related tox job https://review.openstack.org/622972
12:49:50 sean-k-mooney gibi: so when i was talking about macvtap i was refering to sriov in macvtap mode not the macvtap agent
12:50:31 sean-k-mooney gibi: so if you want to say we support sriov minium bandwith we should test both modes not just direct
12:51:02 sean-k-mooney i guess technically we shoudl test direct_physical to but in that case we are alloccatign the pf to the guest so it gets all the bandwith
12:51:46 sean-k-mooney anyway i dont want to block the patch on this point but currently it looks like you have only been looking a sriov in direct mode
12:55:31 sean-k-mooney for vnic_type=direct_physical we shoudl reserve the remaing bandwtih inventory for the pf as no other instances can use it in addtion to the normal allocation
12:56:13 sean-k-mooney techncially we should do that in some case for vnic_type=direct too as vnic_type=direct is allowed to give you a pf
12:56:36 sean-k-mooney direct_pysical was just intoduced to froce the alloction of a pf
12:58:55 gibi sean-k-mooney: regarding macvtap, if this is done by the sriov agent then I can create an extra functional test in nova to see if the nova side works
12:59:26 sean-k-mooney yep its done basically identically to direct jsut the vnic_type will be macvtap
12:59:32 gibi sean-k-mooney: yes
12:59:58 gibi sean-k-mooney: I will add a functional test for it in a separate patch
13:00:11 sean-k-mooney i basically jsut want to confrim that you dont have a hardcoded check for direct somewhere
13:00:18 gibi sean-k-mooney: regarding allocating a full pf for vnic_type=direct. When does that happen?
13:00:18 sean-k-mooney cool
13:00:37 sean-k-mooney it happens if the pf does not have any vfs
13:01:04 sean-k-mooney of if the admin whitelist pf and never allocates vfs then vnic_type=direct is allowed to used them
13:01:20 sean-k-mooney it was how you did pf passthough before we added direct_physical
13:01:54 sean-k-mooney i can double check if we prevented that when we added direct_physical but i doubt it as it would have been a breaking api change
13:02:20 gibi sean-k-mooney: OK. in this case the first boot will get the whole PF, and the second such boot will fail the pci claim as there is no pci device left
13:02:29 sean-k-mooney yep
13:03:06 sean-k-mooney so it wont break anything but it would be nice to tell placment that the rest of the inventory is reserved/unsuable
13:03:10 gibi sean-k-mooney: so the problem is that placement doesn't track PF inventory to signal that the PF is consumed
13:03:22 sean-k-mooney basically yes
13:03:46 sean-k-mooney ideally we would be asing for two things. 1 pf/vf resouce + x bandwith
13:04:21 sean-k-mooney since we dont track PFs/VFs in placment yet we only ask for the bandwith
13:04:25 gibi sean-k-mooney: OK. as far as I understand the admin needs to configur such PF specially (whitelsit the PF but not the VFs) so we can also ask the admin not to configure bandwidth for that PF as that PF will be consumed in a single piece
13:04:35 sean-k-mooney so this will get fix in train hopefully
13:05:24 sean-k-mooney ya they have to expclity whitelist the pf and that would be resonable intally at least
13:05:28 gibi sean-k-mooney: It will be fun moving the VF inventory to placement
13:05:45 gibi sean-k-mooney: OK then we will handle this case in the documentation for Stein
13:05:57 sean-k-mooney the downside is we wont be able to sue the min bandwith request to select pf with at least X bandwith
13:05:58 artom ~o~
13:06:24 sean-k-mooney e.g. ask for a 10G pf vs a 1G or 40G or 100G pf
13:06:52 sean-k-mooney gibi: and yes moving vfs/pfs to placement will be "fun"
13:07:34 gibi sean-k-mooney: yeah in a mixed environment it will be a limitation
13:07:55 sean-k-mooney its not somthing they could do before so i think its fine
13:08:12 gibi yeah I feel the same
13:08:13 sean-k-mooney it would just be a nice bonus if we could enable that usecase in the future
13:08:43 sean-k-mooney but to do that we need to get a few other things in place
13:08:57 mdbooth lyarwood: You there? Still looking at your cinder tempest failure.
13:09:12 mdbooth It's pretty weird. Have you had any insight?
13:09:20 gibi sean-k-mooney: totally agree
13:10:58 sean-k-mooney anyway i responded to your replys on patchset 39 and im now going through patchset 40 but honestly i think future change can likely be done in followup patches as part fo train.
13:13:23 gibi sean-k-mooney: and now I've responded in your responses in PS 39 :)
13:19:21 lyarwood mdbooth: no, are you looking at the latest failures?
13:19:30 lyarwood mdbooth: I was waiting for CI to report back before taking another look
13:20:48 mdbooth lyarwood: I've been looking into the failures from yesterday or the day before?
13:21:13 mdbooth I'm currently suspecting a cinder race, tbh.
13:21:21 mdbooth Rather than a tempest race, that is.
13:23:02 lyarwood mdbooth: ack, I updated both changes this morning and they appear to be failing in the check queue. Once they report back I'll take a look to see if it's the same issue.
13:26:30 mdbooth lyarwood: I'll have a look at the new ones. I know what I'm looking for, now.
13:27:52 mdbooth lyarwood: In the one I've been looking into, we can see in both the tempest and c-api logs that cinder returns a 404 for the volume, then fails to delete the type because it still has a volume.
13:28:54 mdbooth I couldn't see any other volume in the logs, so my guess is that the cinder REST api is returning a 404 before updating whatever triggers the failure to delete the type.
13:29:11 sean-k-mooney gibi: oh i didnt know rodolfo had revied the minium bandwith work for ovs. it was merged in the past and then reverted as we found edgecase that did not work. i guess he has figured out how to work aroudn them good to know
13:29:27 mdbooth We can see in the c-vol logs that the volume deletion actually completes *after* the type deletion starts, so c-api is returning a 404 *before* the deletion completes.
13:29:32 bauzas gibi: ack, will review it later
13:34:45 gibi sean-k-mooney: yeah it is good that rodolfo managed to do that
13:34:47 gibi bauzas: thanks
13:35:51 sean-k-mooney it looks like tunneled netowrk support is still pendign but that was one of the things that did not work last time that ended up with the feature beign reverted

Earlier   Later