Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-27
14:11:20 efried cool
14:12:11 jaypipes stephenfin: and ack on the OVS documentation being awful.
14:12:19 jaypipes OVS-DPDK that is.
14:14:57 dansmith efried: mriedem: I can never remember the moving target of translations.. we're translating exceptions now, but not translating logs _at all_ (even warning) ?
14:15:26 bauzas dansmith: right IIRC
14:15:28 efried dansmith: correct
14:15:49 bauzas because translating logs is too much for the i18n team
14:15:57 bauzas they aren't able to scale
14:16:24 efried Nice patch for a new contributor: remove _Lx from nova.i18n, see what breaks, fix it.
14:17:36 dansmith wtfever
14:18:07 dansmith not marking them means they _can't_ be translated which seems like a stupid step back, but whatever
14:21:09 openstackgerrit Patricia Domingues proposed openstack/nova master: load up the volume drivers by checking architecture https://review.openstack.org/541393
14:23:50 jaypipes efried: "The first time update_provider_tree runs, it reads that config file and sets up the provider tree with types & inventories according to what the admin put in there. Right?" <-- you mean, exactly like my provider-config-file spec enabled?
14:24:56 efried jaypipes: could be, could be. I'm not sure if I read that before it was declared moot, but if I did, I've purged it :(
14:25:47 efried jaypipes: Anyway, it sounds like a lovely idea you had :)
14:26:06 jaypipes efried, bauzas: I'm the person that would shit a brick if you start adding dynamic inventory creation based on whatever a user requested.
14:26:34 efried Yes, but not the only person.
14:26:52 bauzas jaypipes: I'm entering the danger timezone of me needing to go get my children at school
14:27:15 bauzas jaypipes: tl;dr I just want the inventory for that specific physical GPU to be config-driven
14:27:31 bauzas jaypipes: if that sounds crazy, tell me more in 20 mins :)
14:27:35 jaypipes bauzas: yet another whitelist conf option, yes, I know.
14:28:15 openstackgerrit Dan Smith proposed openstack/nova master: Make get_allocation_candidates() honor aggregate restrictions https://review.openstack.org/547990
14:28:16 openstackgerrit Dan Smith proposed openstack/nova master: Add AggregateList.get_by_metadata() query method https://review.openstack.org/544728
14:28:16 openstackgerrit Dan Smith proposed openstack/nova master: Add an index on aggregate_metadata.value https://review.openstack.org/555851
14:28:17 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Honor availability_zone hint via placement https://review.openstack.org/546282
14:28:17 openstackgerrit Dan Smith proposed openstack/nova master: Add require_tenant_aggregate request filter https://review.openstack.org/545002
14:29:12 sahid jaypipes: if you can enqueue this https://review.openstack.org/#/c/511188/ :)
14:29:44 mriedem efried: can we abandon https://review.openstack.org/#/c/497978/ or do you plan on updating it?
14:30:17 efried mriedem: Eventually. But I can abandon for now and resurrect at that time.
14:30:35 mriedem ok. i'm just starting backward for specs, oldest to newest and cleaning out the cruft.
14:30:56 openstackgerrit Balazs Gibizer proposed openstack/nova-specs master: Network bandwidth resource provider https://review.openstack.org/502306
14:31:29 mriedem johnthetubaguy: should we abandon https://review.openstack.org/#/c/438134/ for service-protected-servers? does that align with anything keystone is working on with RBAC?
14:31:32 mriedem edmondsw: ^
14:32:35 edmondsw in a mtg, will look in a few
14:32:44 mriedem dansmith: this was the thing that prompted my ML thread about volume type proxy https://review.openstack.org/#/c/466595/
14:32:53 mriedem i think...
14:33:22 dansmith ack
14:35:47 mriedem bauzas: i'm going to start an ops list thread about https://review.openstack.org/#/c/446446/ since if it's just a bug fix for broken behavior, we don't need a spec or a microversion
14:37:29 bhagyashris Disallow rotation parameter 0 for 'createBackup' API) Request you to review the same.
14:37:29 bhagyashris mriedem, alex_xu_: Hi, I have proposed revised (as per the discussion in Dublin PTG) spec: https://review.openstack.org/#/c/511825/2 (
14:37:54 mriedem bhagyashris: cool i'll review today
14:38:25 alex_xu_ kashyap: strange...I didn't see there is extra_flags in LibvirtConfigGuestCPU obj
14:38:39 alex_xu_ bhagyashris: cool, will try to reach that
14:38:45 kashyap alex_xu_: But, thanks to your comment, I could actually remove another line in the test
14:39:01 alex_xu_ kashyap: np
14:39:14 kashyap alex_xu_: I'll upload a new version once I re-run my local tests.
14:39:21 kashyap alex_xu_: As I caught another bug from a functional test.
14:39:48 kashyap The casing of the config options was lost, after I moved to Oslo StrOpt(). Glad I tested locally w/ both casings
14:39:54 kashyap (Now fixed it)
14:41:14 jaypipes the port binding information in Neutron for that. I still don't see why those should be traits.
14:41:14 jaypipes gibi: "The backend information is needed for the NeutronBackendWeigher that tries to simulate the Neutron backend selection mechanism by implementing a preference order between backends." <-- this is what concerns me about the introduction of those NET_BACKEND_XXX traits. I don't see those traits as being germane to scheduling. Rather, I just see them as being a part of the port configuration information that we send down to os-vif. And we have
14:42:40 alex_xu_ kashyap: actually I mean I didn't find a extra_flags field for the LibvirtConfigGuestCPU even for now...
14:42:55 gibi jaypipes: the backend traits are not needed for the placement query or for the scheduler filters
14:43:04 efried jaypipes: Do you have a spec queued up for NRP-in-a_c yet?
14:43:31 gibi jaypipes: but as the filter scheduler makes the allocation, it implicitly decides about the backend as well
14:43:49 gibi jaypipes: and before the bandwidth feature this decision was made by neutron
14:44:07 gibi jaypipes: but after it, the decision is made by the filter scheduler
14:44:11 bhagyashris mriedem, alex_xu_: thank you :)
14:44:23 gibi jaypipes: so we want to save some of the freedom of neutron here
14:44:25 kashyap alex_xu_: It's not in that class. But take a look at LibvirtConfigCPUFeature()
14:44:38 gibi jaypipes: by adding a weigher that can express backend preference order
14:45:28 kashyap alex_xu_: Typo, actually this one: LibvirtConfigGuestCPUFeature()
14:45:39 jaypipes efried: crap. haven't finished it.
14:45:44 jaypipes efried: I can push what I have.
14:46:08 efried jaypipes: as you see fit. Just thought I'd ask, it being spec review day and all.
14:47:06 openstackgerrit Matthew Booth proposed openstack/nova-specs master: Add serial numbers for local disks https://review.openstack.org/556565
14:47:10 jaypipes efried: ack, thx for the reminder.
14:49:01 sean-k-mooney[m] stephenfin: hi sorry was in a meeting you wanted me to comment on some ovs-dpdk stuff
14:49:27 openstackgerrit Dan Smith proposed openstack/nova-specs master: Amend the member_of spec for multiple query sets https://review.openstack.org/555413
14:49:58 efried dansmith: remove -2 from ^ ?
14:50:11 dansmith efried: yep, I just need to fix a pep8 thing I just noticed
14:50:16 efried o
14:50:27 efried dansmith: Two spots
14:51:10 stephenfin sean-k-mooney[m]: Indeed. sahid was suggesting we could simply rely on NUMA affinity of a vhost-user interface's PMD queues to determine where to place a host
14:51:12 bauzas mriedem: ack, thanks
14:51:23 bauzas mriedem: honestly, I wasn't knowing what to do with this
14:51:32 efried dansmith: While you're at it, "in in"
14:52:46 dansmith efried: ah yeah saw that before and had forgottten it
14:52:48 dansmith tttt
14:53:03 efried dansmith: Please clarify whether the multiple-member_of thing will also be implemented in GET /resource_providers
14:53:36 dansmith efried: ah, I was going to ask if we should do that too, but I expected it would be outside this spec, no?
14:54:32 efried dansmith: Whether it is or not, that should be stated. I could go either way. But slight preference for including it. For a couple of reasons...
14:54:39 dansmith ack
14:55:23 efried dansmith: First, a single microversion introducing multiple-member_of syntax. I like that better than one microversion introducing it for one URI, another for introducing what's effectively the same feature to another URI.
14:55:26 openstackgerrit Dan Smith proposed openstack/nova-specs master: Amend the member_of spec for multiple query sets https://review.openstack.org/555413
14:55:54 efried dansmith: Second, it's actually going to make the code easier to write. Because we currently do the processing of member_of in common code for both; so we can continue to do that.
14:56:00 dansmith efried: sure
14:56:45 sean-k-mooney[m] stephenfin: that wont work als ovs has no idea if there is enough memory on the numa node for the vm also the memory is not allocated until the vhost-user frontend in qemu connects to the vhost-user backend in ovs
14:56:54 efried dansmith: Technically, the Work Items section should be updated...
14:57:15 dansmith efried: for /rps?
14:57:31 efried dansmith: On rereading, it's sufficiently vague to be acceptable as is.
14:57:36 dansmith yeah, I was going to say..
14:57:45 efried dansmith: Which is fine by me; I've always thought that section was pretty much redundant anyway.
14:58:20 efried dansmith: +1. One spec down!
14:58:29 sean-k-mooney[m] stephenfin: the other thing is that when the vhost-user frontend connects to the vhost-user backend in ovs it tries to allocate memory and pmd for the vhost-user interface from on of the numa nodes of the guest automatically
14:58:43 openstackgerrit Jay Pipes proposed openstack/nova-specs master: Handle nested providers for allocation candidates https://review.openstack.org/556873
14:59:50 jaypipes efried: ^
14:59:58 efried jaypipes: ack
15:00:53 mriedem bhagyashris: comments inline https://review.openstack.org/#/c/511825/
15:04:00 jaypipes gibi: maybe I'm just being thick... I still don't get it. You will have multiple backends on the same compute host supporting the same physical networks that support the same vNIC types and you want to be able to choose which backend to allocate a piece of bandwidth from?

Earlier   Later