Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-20
14:29:32 mriedem gibi: if you do that, anyone that doesn't have that code in their cloud can have users still attaching those kinds of ports
14:30:08 mriedem if we consider it a bug that we don't support ports with qos policies, then we should make that a hard failure (bug fix) and then add a new microversion which adds the support for those types of ports
14:31:08 gibi mriedem: so making it a hard failure is a bugfix, I like that
14:31:17 alex_xu_ emm...wait, we don't check the network has qos policy, we check the port has required resource or not. That is something new added in neutron
14:31:33 mriedem gibi: well that's what we did for the bfv rebuild case
14:32:30 gibi alex_xu_: required resources is just another representation of the QoS policy to let neutron do the transformation between QoS policy entity on the API to the resource classes and traits in the Placement
14:32:49 mriedem tbh, we're inconsistent on this type of thing. with the multiattach support in queens, we check if the volume is multiattach and if the microversion is high enough (2.60) and if not, we fail. but i'm pretty sure in pike you could probably attach a multiattach volume to at least one instance at a time without failures.
14:33:40 alex_xu_ gibi: the neutron side add 'resources' field to the port API by extension? or just add directly?
14:33:41 gibi cdent, edleafe, mriedem: I start to get convinced that making the API hardfail instead of accept and lie is a bugfix
14:35:06 mriedem so the bug is today we are potentially over-subscribing the qos bandwidth right?
14:35:10 mriedem for a given network
14:35:15 gibi alex_xu_: that will come from the QoS neutron plugin based on my current understanding
14:35:36 gibi alex_xu_: the neutron spec will describe this in detail (writing is in progress)
14:35:59 mriedem the neutron qos stuff has been around for a long time hasn't it? kind of surprised no one hasn't already reported this as a bug.
14:36:24 gibi mriedem: yes, SRIOV ports with QoS minimum bandwidth policies are not properly enforced and the minimum bandwidth cannot be garanteed
14:36:39 gibi mriedem: only SRIOV ports supporting minimum bandwidth policies
14:37:39 gibi mriedem: and there was a release notes that stated the problem
14:37:47 gibi mriedem: https://github.com/openstack/neutron/blob/49d614895f44c44f9e1735210498facf1886c404/releasenotes/notes/qos-min-egress-bw-rule-b1c80f5675a4c1c3.yaml
14:38:33 gibi mriedem: so maybe the deployers read the release notes and understood that the support for the minimum bandwidth rule is incomplete
14:38:49 mriedem added in newton
14:38:53 gibi mriedem: yes
14:39:30 mriedem looks like the policy defaults allow only admins to create these types of policies
14:39:33 mriedem so there is at least that
14:42:42 openstackgerrit Surya Seetharaman proposed openstack/nova master: Add disabled field to CellMapping object https://review.openstack.org/550090
14:42:43 openstackgerrit Surya Seetharaman proposed openstack/nova master: Add CellMappingList.get_all_enabled() query method https://review.openstack.org/550188
14:42:43 openstackgerrit Surya Seetharaman proposed openstack/nova master: Allow scheduling only to enabled cells (Filter Scheduler) https://review.openstack.org/550527
14:42:49 bauzas sean-k-mooney[m]: jaypipes: stephenfin: soft -1 on https://review.openstack.org/#/c/545951/2 but I need to understand why we can't just get the port info in the conductor, and pass the traits to the scheduler
14:43:36 bauzas I could be wrong but AFAIK we haven't said why it wasn't possible to do the above ^
14:57:02 dansmith jaypipes: sean-k-mooney[m]: do either of you know if/when we can remove the old vif plugging stuff from the libvirt driver? i.e. everything reachable past the "if not os-vif" line?
14:57:37 openstackgerrit Ed Leafe proposed openstack/nova master: Address issues raised in adding member_of to GET /a-c https://review.openstack.org/554357
14:57:39 edleafe efried: ^^ yay pep8!
15:14:48 mriedem dansmith: presumably once all of the legacy methods in libvirt/vif.py are converted to using os-vif objects
15:15:21 dansmith mriedem: I don't know how to tell that. are those just linux bridge and ovs right now?
15:16:03 mriedem look in nova.network.os_vif_util at the _nova_to_osvif_vif_* methods that raise NotImplementedError
15:16:06 mriedem there are quite a few
15:16:23 stephenfin dansmith: Yeah, once all of those have been converted
15:17:09 stephenfin jaypipes and I have discussed it before. The IVS driver has been converted to an os-vif plugin but I don't know about the rest of them. We might need to jettison them or bring them into os-vif core
15:17:10 dansmith is that actually happening in the background?
15:17:27 stephenfin Just this one so far https://bugs.launchpad.net/bugs/1704129
15:17:28 openstack Launchpad bug 1704129 in networking-bigswitch "Add an IVS os-vif plugin" [Undecided,New] - Assigned to Aditya Vaja (wolverine-av)
15:17:33 dansmith couldn't we remove the ones from our tree that are converted already?
15:17:41 stephenfin They should already be removed
15:18:13 stephenfin e.g. OVS and linuxbridge
15:18:26 dansmith there are several still that have a method and just pass
15:18:39 dansmith are those converted and "removed" or are those things we just don't do anything for?
15:19:02 mriedem can you give an example?
15:19:04 stephenfin For example?
15:19:17 dansmith def plug_802qbg(self, instance, vif):
15:19:17 dansmith pass
15:19:23 stephenfin I went through and removed some others ones a while back. IIRC, everything else was still needed. See commit 1b872996d08b01a1b8a1e82d13d6d7b06bc3aa01
15:19:40 mriedem ok that's in nova.virt.libvirt.vif
15:19:54 dansmith I was probably reading ivs and ovs and just assumed we had orphaned all this code, but if we're removing them as we can, that's cool
15:19:55 dansmith mriedem: right
15:20:14 mriedem i guess there is no plug for 802qbg but there is a get_config method for it
15:20:57 stephenfin Hmm, I'm not sure about that one. We do getattr magic somewhere in there so it's tricky to figure out what's called and what's dead
15:21:13 mriedem 2.1 is changed to 21
15:21:15 mriedem so it becomes 802qbg
15:21:25 mriedem the os-vif conversion code looks for _nova_to_osvif_vif_802_1qbg
15:21:31 mriedem because the vif type is "802.1qbg"
15:23:09 stephenfin Which raised NotImplemented?
15:23:14 stephenfin *raises
15:23:16 mriedem yes
15:23:34 mriedem i don't know why we don't have to plug/unplug those, but we have to get the config apparently for the guest
15:24:21 mriedem um https://github.com/openstack/os-vif/blob/master/os_vif/objects/vif.py#L263
15:24:25 mriedem https://github.com/openstack/os-vif/blob/master/os_vif/objects/vif.py#L277
15:24:30 mriedem seems we could convert two right there
15:25:00 dansmith the reason I'm asking is around removing our linux_net module
15:25:05 openstackgerrit Jackie Truong proposed openstack/nova master: Add trusted_certs to instance_extra https://review.openstack.org/537897
15:25:05 openstackgerrit Jackie Truong proposed openstack/nova master: Add trusted_certs object https://review.openstack.org/489408
15:25:06 openstackgerrit Jackie Truong proposed openstack/nova master: Implement certificate_utils https://review.openstack.org/479949
15:25:06 openstackgerrit Jackie Truong proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204
15:25:18 dansmith it's really hard to tell if/when it's used right now
15:26:30 stephenfin this is for nova-network deletion, I assume?
15:27:53 dansmith not really, although that's part of it.. the linux_net module uses a lot of config in conf/network that we can't remove when we nuke nova-net
15:31:24 dansmith mriedem: are you cool with backporting this? https://review.openstack.org/#/c/552691/
15:33:37 mriedem sure
15:37:09 openstackgerrit Matt Riedemann proposed openstack/nova master: Don't log a warning for InstanceNotFound with deleted VIFs https://review.openstack.org/554591
15:43:10 mriedem welp, volume multiattach does'nt work with libvirt 4.0.0 in the queens UCA
15:44:41 mnaser mriedem: honest question is there multiattach tempeset jobs
15:45:07 mriedem hells yes
15:45:11 mriedem https://review.openstack.org/#/c/554317/
15:45:40 mriedem looks like the shareable flag isn't getting set in the disk config xml for some reason, should be relatively easy to figure out why
15:45:55 mnaser mriedem: so does that mean that a certain company is releasing things without possibly running tempest jobs
15:45:56 mriedem i've just been getting distracted with the amount of bullshit warnings in the n-cpu logs
15:46:23 mriedem mnaser: libvirt is open source yeah? but even still, i wouldn't expect them to test openstack stuff against their code.
15:46:33 mriedem or qemu for that matter
15:46:44 mnaser well not libvirt but if uca ships libvirt 4.0.0
15:46:49 mnaser i'd expect that they tested all of them together
15:47:19 mriedem i don't expect ubuntu / canonical to test all of the permutations of openstack features
15:47:31 mriedem since multiattach is optional too
15:47:44 mriedem maybe if it were part of the interop guidelines, but it's not
15:50:29 openstackgerrit Dan Smith proposed openstack/nova stable/queens: Add --by-service to discover_hosts https://review.openstack.org/554600
15:52:33 openstackgerrit Stephen Finucane proposed openstack/nova master: Add CPUWeigher https://review.openstack.org/379525
15:53:33 openstackgerrit Dan Smith proposed openstack/nova stable/queens: Add --by-service to discover_hosts https://review.openstack.org/554600
15:54:50 openstackgerrit Dan Smith proposed openstack/nova stable/pike: Add --by-service to discover_hosts https://review.openstack.org/554603
15:56:20 openstackgerrit Tyler Blakeslee proposed openstack/nova stable/queens: Add method repr() to NovaException https://review.openstack.org/554604
16:03:54 openstackgerrit Tyler Blakeslee proposed openstack/nova master: Add method repr() to NovaException https://review.openstack.org/554607
16:30:36 openstackgerrit Tyler Blakeslee proposed openstack/nova master: Add method repr() to NovaException https://review.openstack.org/554607
16:36:46 ameeda Hi, I try to create stack using rest api. current api version is V1 . I POST request with auth key , I got this error message { "explanation": "The server could not comply with the request since it is either malformed or otherwise incorrect.", "code": 400, "error": { "message": "The server could not comply with the request since it is either malformed or otherwise incorrect.", "traceback": null,
16:41:53 kashyap Hmm, `git fetch origin` again failing for me, with 'origin' == https://git.openstack.org/openstack/nova.git

Earlier   Later