Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-01-21
12:01:42 openstackgerrit sean mooney proposed openstack/nova master: Libvirt: do not set mac when unplugging macvtap vf https://review.openstack.org/624842
12:01:43 openstackgerrit sean mooney proposed openstack/nova master: Allow per-port modification of vnic_type and profile https://review.openstack.org/607365
12:01:43 openstackgerrit sean mooney proposed openstack/nova master: Add get_instance_pci_request_from_vif https://review.openstack.org/619929
12:01:44 openstackgerrit sean mooney proposed openstack/nova master: SR-IOV Live migration indirect port support https://review.openstack.org/620115
12:01:45 openstackgerrit sean mooney proposed openstack/nova master: [WIP] libvirt: auto detach/attach sriov ports on migration https://review.openstack.org/629589
12:05:01 openstackgerrit sean mooney proposed openstack/nova master: Libvirt: do not set mac when unplugging macvtap vf https://review.openstack.org/624842
12:05:02 openstackgerrit sean mooney proposed openstack/nova master: Allow per-port modification of vnic_type and profile https://review.openstack.org/607365
12:05:02 openstackgerrit sean mooney proposed openstack/nova master: Add free for claimed, allocated devices https://review.openstack.org/616120
12:05:03 openstackgerrit sean mooney proposed openstack/nova master: SR-IOV Live migration indirect port support https://review.openstack.org/620115
12:05:03 openstackgerrit sean mooney proposed openstack/nova master: Add get_instance_pci_request_from_vif https://review.openstack.org/619929
12:05:04 openstackgerrit sean mooney proposed openstack/nova master: [WIP] libvirt: auto detach/attach sriov ports on migration https://review.openstack.org/629589
12:38:54 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add test to check os_vif.internal.command.ip.exists https://review.openstack.org/632077
12:52:51 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Cleanup device at the end of 'test_iproute_object_closes_correctly' test https://review.openstack.org/629112
12:57:47 ralonsoh jaypipes, hi. I added the cleanup to avoid leaving any device created in the system if the test goes wrong
13:02:55 jaypipes ralonsoh: morning! :)
13:03:22 jaypipes ralonsoh: was I correct though, that line 183/4 is doing that delete?
13:03:58 ralonsoh jaypipes, yes, the device is being deleted in this line, but this cleanup is just for precaution
13:04:10 jaypipes ralonsoh: the delete of the link itself should be done with an addCleanup() call, but AFAICT, the self._del_device() is ensuring that the other device(s) are deleted appropriately, right?
13:04:36 jaypipes ralonsoh: sure, since the _delete_device() method is idempotent, it won't hurt.
13:05:35 ralonsoh jaypipes, yes, that's the point
13:09:09 jaypipes ralonsoh: ack, ok, I'll push it through.
13:10:04 jaypipes ralonsoh: done
13:10:21 ralonsoh jaypipes, thanks!
13:15:30 sean-k-mooney so looking at https://review.openstack.org/#/c/629112/4..5/os_vif/tests/functional/internal/command/ip/test_impl_pyroute2.py we are just being extra safe by registering both cleanup function
13:15:40 sean-k-mooney ralonsoh: jaypipes ^
13:16:50 ralonsoh sean-k-mooney, yes, to ensure, in case of any problem, we delete both devices
13:16:50 openstackgerrit Natal Ngétal proposed openstack/nova master: [Configuration] Clean up .gitignore references to personal tools https://review.openstack.org/632086
13:16:53 sean-k-mooney ralonsoh: jaypipes that said wont hte device created on line 193 actully be called test_dev_9.100 as it is a vlan100 subport
13:17:14 sean-k-mooney actully i guess that is just a convention
13:17:26 sean-k-mooney it will actully be called test_dev_9
13:17:29 sean-k-mooney ok
13:17:49 ralonsoh sean-k-mooney, well yes, and the same in test_add_vlan
13:18:38 sean-k-mooney ya if we were using ifconfig the dev.vlan name would be required i think but since we are using ip link to create them we are free to call them whatever we like
13:21:58 sean-k-mooney ill need to resping the change to the release repo so ill pick up the 4 patch in that chain when i do for the 1.14.0 release
13:24:38 sean-k-mooney stephenfin: are you to quckly review some os-vif changes. im +2 on all of them but could you take a look at them https://review.openstack.org/#/c/631829/3
13:24:51 sean-k-mooney *are you free
13:40:25 openstackgerrit Merged openstack/os-resource-classes master: Add PCPU standard resource class https://review.openstack.org/631711
13:52:14 edleafe I know we skipped one conference; can't remember which
13:52:32 edleafe wrong window
13:55:46 efried n-sch meeting in 5 minutes in #openstack-meeting-alt. Expect it to be a short one.
14:03:26 openstackgerrit Natal Ngétal proposed openstack/nova master: [Configuration] Clean up .gitignore references to personal tools https://review.openstack.org/632086
14:37:50 sean-k-mooney jaypipes: thanks for the +w i forgot stephenfin is on PTO today
14:38:41 jaypipes sean-k-mooney: no problemo.
14:46:32 gibi mriedem: hi, I see that jaypipes already +2 the ensure consumer status check but I have a question in https://review.openstack.org/#/c/631671/7/placement/cmd/status.py@51
14:49:20 mriedem gibi: so a consumer record for allocations but no generation?
14:49:24 mriedem i don't think that's possible...
14:49:34 mriedem the consumer generation would start at 0 if it's new
14:50:12 gibi mriedem: based on your docstring I felt that you wanted to detect this case as well with the query but I don't think that the current query detects that
14:50:31 mriedem the consumers table defaults generation to 0 so as long as there is a consumers table record, i think it has a generation
14:50:55 gibi mriedem: OK, then I just overreacted. thanks for the explanation
14:51:09 mriedem np
14:52:50 mriedem gibi: while you're here, and you've been on the per-aggregate weights patch, i had a usage/behavior question about one of the weighers which you might have an opinion https://review.openstack.org/#/c/628163/12/nova/tests/unit/scheduler/weights/test_weights_compute.py@95
14:54:30 mriedem i'd ask dan but he's out this week
14:57:02 mriedem stephenfin: easy cleanup patch on which you have context https://review.openstack.org/#/c/628205/
14:57:36 sean-k-mooney mriedem: stephenfin is on PTO today he will be back tomorrow
14:58:28 mriedem ah yes MLK day in ireland...
14:58:46 sean-k-mooney no he just took today off
14:58:56 sean-k-mooney i think he was at a gig over the weekend or something
15:00:38 gibi mriedem: looking...
15:01:29 sean-k-mooney actully he may been skying the cleanups make sense to me.
15:04:15 gibi mriedem: I tend to agree to simply document that min in case of build_failure weigher means the min of the configured weights not the calculated (and negated) weights
15:13:02 mriedem gibi: ok so you wouldn't change anything about the docs here? https://review.openstack.org/#/c/628163/13/doc/source/user/filter-scheduler.rst@508
15:13:28 mriedem i had started commenting on that about whether or not we should mention something about that, or give an example, but when i read what i'd add it just makes it more confusing
15:15:59 mriedem i left a comment that i can't come up with a good comment, +2
15:19:11 gibi mriedem: I think that doc is correct from external perspective
15:19:41 gibi mriedem: and I agree configuring weighers are hard, and this patch now makes it even more complex
15:20:37 mriedem heh
15:20:48 mriedem time for edleafe's scheduler dry run API
15:21:17 gibi is it a test environment for scheduler config? :)
15:23:36 edleafe gibi: the idea was to pass in a request and some target hosts, and have the scheduler return the hosts that would have passed, but not actually build anything on those hosts
15:24:32 edleafe It would have been useful for the Watcher project to know if they try to move an instance to a host whether the new host was a valid target
15:25:44 gibi edleafe: I see. It is interesting
15:26:28 edleafe gibi: now what they do is try to move it and catch the failure. It's slow and expensive
15:28:03 cdent I am slow and expensive
15:30:25 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: docs: Update references to "QEMU-native TLS" document https://review.openstack.org/631283
15:30:25 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: A few miscellaneous items related to "native TLS" https://review.openstack.org/630980
15:35:33 gibi edleafe: in return, such a dryrun might return True for a host but then the actual scheduling will fail a due to races
15:35:43 gibi edleafe: but I see that this is a tradeoff
15:37:45 edleafe gibi: sure, that's always been understood, and things like total available resources are already able to be known. What it *would* do is help with things like affinity/anti-affinity, aggs, etc., that are pure nova-isms
15:38:07 gibi edleafe: yeah, make sense
16:12:22 gibi mriedem: btw, as dansmith is on vacation, I
16:12:39 gibi mriedem: btw, as dansmith is on vacation, I'd like to ask your oppinion on my answer in the bandwidth ML thread
16:12:59 gibi mriedem: of course if your oppinion is to wait for dansmith then I will wiat
16:13:02 gibi wait
16:14:56 sean-k-mooney gibi: by the way i was not arguing that all features reqire move support just that numa is not a good example :)
16:15:20 gibi sean-k-mooney: yeah. I could use other example like virt driver support for certain operations
16:15:47 sean-k-mooney yep ironic does not really have much of a choice
16:17:11 sean-k-mooney gibi: speaking of ironic i assume there is noting in pricipal stopping bw based schduling from being extended to ironic if the appropriate ml2 drivers were extended
16:17:39 gibi sean-k-mooney: yes and no. From nova perspective nothing prevents ironic to handle bandwidth
16:17:54 sean-k-mooney you would just need to update the ml2 drivers for the tor switch
16:17:56 gibi sean-k-mooney: from neutron perspective I'm not sure bandwidht allocation can be enforced
16:18:23 gibi sean-k-mooney: if you use the tor for it then it is not the same bandwidth as in case of libvirt and sriov
16:18:42 sean-k-mooney gibi: yes and no
16:19:02 gibi sean-k-mooney: in theory we can extend the current bandwidth support for the tor switch in in case of libvirt + sriov
16:19:37 sean-k-mooney gibi: well for the libvirt case to include the tor means hierarcical port binding
16:19:53 sean-k-mooney but for ironic the tor is the l1 port binding
16:20:11 sean-k-mooney anyway that is for the future
16:20:21 gibi sean-k-mooney: yes :)
16:22:03 gibi sean-k-mooney: my problem with dansmith mail is that I thought that microversion can be used to signal a new, supported use case, if the change affect an API behavior. But from the mail it seems that is only true for complete feature
16:22:08 cfriesen sean-k-mooney: PCI/SRIOV question for you. with the upstream code, how do you ensure that an instance that requests a PCI NIC ends up on a compute node that has physical NICs on the desired physical network? Is that just host aggregates? As I recall, the network-aware scheduling stuff never landed.

Earlier   Later