Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-05-13
10:05:05 stephenfin Yeah, but change the URL to https://releases.openstack.org/constraints/upper/queens
10:05:14 ralonsoh stephenfin, perfect. Thanks!!
10:05:42 stephenfin (And include a 'NOTE(ralonsoh):' in the commit message saying that, so people know wtf happened in the future :D)
10:06:26 ralonsoh stephenfin, perfect
10:19:31 openstackgerrit Balazs Gibizer proposed openstack/nova master: Defaults missing group_policy to 'none' https://review.opendev.org/657796
10:24:03 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif stable/queens: add upper_constraints support https://review.opendev.org/658780
10:24:36 ralonsoh stephenfin, please feel free to modify the commit message to add a good NOTE https://review.opendev.org/#/c/658780/
10:24:46 ralonsoh stephenfin, yours will be better than mine
10:29:04 stephenfin ralonsoh: done
10:29:12 ralonsoh stephenfin, thanks!
10:33:26 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif stable/queens: add upper_constraints support https://review.opendev.org/658780
10:35:18 openstackgerrit Merged openstack/python-novaclient master: Tiny fix of documentation https://review.opendev.org/657522
10:44:48 openstackgerrit Hamdy Khader proposed openstack/nova master: Process VIF type ovs-dpdk for dpdk representor ports https://review.opendev.org/658785
10:47:55 openstackgerrit Hamdy Khader proposed openstack/os-vif master: Plug ovs-dpdk vif port type for dpdk representor integration https://review.opendev.org/658786
10:54:26 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif stable/queens: Prevent "qbr" Linux Bridge from replying to ARP messages https://review.opendev.org/655694
11:41:30 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif stable/queens: add upper_constraints support https://review.opendev.org/658780
11:44:54 openstackgerrit Rodrigo Barbieri proposed openstack/nova stable/queens: [DEBUG] Add functional confirm_migration_error test https://review.opendev.org/658136
12:38:11 openstackgerrit Surya Seetharaman proposed openstack/python-novaclient master: Microversion 2.73: Support adding the reason behind a server lock https://review.opendev.org/648659
12:47:58 openstackgerrit Merged openstack/nova master: api-ref: fix mention of all_tenants filter for non-admins https://review.opendev.org/657620
12:58:53 openstackgerrit Merged openstack/nova master: Update Python 3 test runtimes for Train https://review.opendev.org/657941
13:39:58 kashyap efried: When you're about, thanks for the feedback on the 'traits' thingie. While I don't want to belabor this, please see the "Another Idea" section here: https://review.opendev.org/#/c/655193/4
13:40:27 kashyap efried: If you (and any others) think that's sensible (I think it is, FWIW), I'll go and file a bug to track it.
13:40:35 kashyap (And of course, then fix it :D)
13:40:47 efried kashyap: ack, looking.
13:41:29 kashyap (Sorry for the broken formatting; I wrote it locally in plain text and posted it there. As typing in the tiny window of Grrrrit was infuriating.)
13:43:20 efried kashyap: You know you can resize the tiny window, right?
13:43:25 efried handle on the bottom right
13:43:35 kashyap efried: No, I didn't realize that
13:43:40 efried re intel vs amd, it sounds like you're agreeing with me? or not?
13:43:45 kashyap Ha!
13:43:48 kashyap (Just saw that)
13:44:36 efried brb, gotta med a cat
13:44:43 kashyap efried: You mean, on having the generic *_CURE traits?
13:44:44 kashyap Sure
13:45:31 kashyap (I need to go into a 20-min meeting in 16 min, then be here for 30 min, then head out to catch a train back home)
13:45:35 openstackgerrit chenker proposed openstack/python-novaclient master: Optimize limit option docs string description for novaclient https://review.opendev.org/643035
13:45:38 dtantsur hi folks! how crazy would it be to backport https://review.opendev.org/#/c/563722/ ? it's a bug fix, but it adds new driver calls..
13:48:25 kashyap efried: When you're back: on picking Intel/AMD-specific traits, I think we should try not to "abstract" them out, and have separate traits per vendor, for clarity. (Open to change my mind if I missed to consider something more important.)
13:49:05 kashyap dtantsur: Looks fairly invasive to me. Depends on how far you want to backport
13:49:28 kashyap dtantsur: Also, how 'important' it is - as in, if the bug is severe, then probably you might get away with it
13:49:29 dtantsur I'm mostly interested in queens
13:49:42 efried kashyap: Intel/AMD I'm just talking about making the namespaces more distinctive.
13:49:49 efried kashyap: tbc, I agree that we should keep the granular traits.
13:50:05 efried And making rollup traits, if we do it at all, could still be done later.
13:50:07 kashyap Ah, okay. efried -- Sorry, more distinctive, how?
13:50:20 kashyap efried: Yeah, good point (that the door is open for roll-up for future).
13:50:42 efried like hw/cpu/x86/intel and hw/cpu/x86/amd
13:51:43 efried kashyap: but my point about the granular traits with no rollups is that they don't help operators unless they're okay predetermining whether they want amd or intel.
13:51:49 efried because we don't have required=in: yet
13:52:03 dtantsur people suspect it may be the cause or one of the causes of https://bugzilla.redhat.com/show_bug.cgi?id=1560690#c60
13:53:56 kashyap efried: Yeah, okay, I agree with the making more distinctive part.
13:53:56 openstack bugzilla.redhat.com bug 1560690 in openstack-heat "Re-deployment of overcloud fails with: ResourceInError: resources.OpenShiftWorker: Went to status ERROR due to "Message: Build of instance c7c5191b-59ed-44a0-8b2a-0f68e48e9a52 aborted: Failure prepping block device., Code: 500"" [High,Assigned] - Assigned to jkreger
13:53:57 kashyap efried: I.e. Nova traversing /sys/devices/system/cpu/vulnerabilities/meltdown (and /sys/devices/system/cpu/vulnerabilities/spectre_*) -- if either of them report vulnerable, then warn that future Nova will refuse to launch VMs on that host
13:53:57 kashyap efried: What do you think about the 'sysfs' thingie?
13:53:57 dansmith IMHO
13:53:57 kashyap efried: Right - I see that point. Hmm, damn "real world"
13:53:57 dansmith dtantsur: doesn't seem too crazy
13:54:14 kashyap )
13:54:14 kashyap (And next release, make it good on the warning promise.
13:54:25 efried kashyap: Reporting generically "vulnerable" as opposed to "mitigation" - sure, that's fine by me, whatever the implementation winds up being.
13:55:19 kashyap efried: Right. I was just noting the notion of what the 'sysfs' reports. If you're _secure_, it is represented as: (You have) "Mitigation": $MITIGATION
13:55:22 efried kashyap: I don't think we should enforce "you can't land on a vulnerable host" across the board. There are surely some environments where they don't care (if all vms in the az are trusted, or whatever)
13:55:41 kashyap efried: Yeah, I hear ya.
13:55:56 efried kashyap: being able to expose that as a trait, where it's not intel/amd specific, is the part I care about.
13:56:20 efried whether it's positive or negative, or how it's determined, I trust you :)
13:56:31 efried so
13:56:33 efried for this patch
13:56:36 efried fix the typo
13:56:58 efried make intel and amd namespaces and move the granular traits appropriately
13:57:00 efried done
13:57:02 efried yah?
13:57:18 kashyap efried: Yeah, makes sense.
13:57:37 efried and then make a new patch with the 'vulnerable' thing in the generic x86 namespace in whatever form you decide will work.
13:58:12 kashyap Nod
13:58:57 kashyap efried: Thanks for your time and discussion!
13:59:13 efried thanks for your patience
14:25:38 openstackgerrit Balazs Gibizer proposed openstack/nova master: Defaults missing group_policy to 'none' https://review.opendev.org/657796
14:35:21 openstackgerrit Rodrigo Barbieri proposed openstack/nova stable/rocky: [DEBUG] Add functional confirm_migration_error test https://review.opendev.org/658834
14:54:46 johnthetubaguy stephenfin: added a -2 as this looks like an API change that breaks our microversion contract, would be great if you can double check my reasoning on there: https://review.opendev.org/#/c/350299
14:56:53 stephenfin johnthetubaguy: Ack. I'll take a look
14:57:03 johnthetubaguy thanks
15:02:32 sean-k-mooney johnthetubaguy: ya i think that proably should have a micro version bump if we make that change
15:03:47 johnthetubaguy its a deprecated API now, so I think we just block it? seems harsh though
15:04:30 johnthetubaguy one alternative is to error with conflict when ports that have a floating ip are changed via that API, as we know something odd happens
15:04:56 sean-k-mooney johnthetubaguy: i was thinking something similar
15:05:12 sean-k-mooney but i was not sure we were allowed to
15:05:46 sean-k-mooney personally i would prefer that you were requried to disassociate the fip first
15:06:02 johnthetubaguy its borderline...
15:06:16 sean-k-mooney but again that would need a micro version too right
15:07:47 sean-k-mooney what we could do is just remove the fixed ip but not the port id from the floating ip
15:08:11 johnthetubaguy hmm, I though that is what happened today?
15:08:22 johnthetubaguy oh wait, I see what you mean now
15:08:52 johnthetubaguy hmm, that is probably more surprising at this point
15:09:02 sean-k-mooney if the port has multiple fixed ips and you dont specify one when setting the fip assocation it just uses the first
15:09:27 johnthetubaguy hmm, re-reading
15:09:48 sean-k-mooney so if the port has multiple fixed ips i dont know if you would expect it to be retarged to one of the others or not
15:12:40 artom efried, https://review.opendev.org/#/c/603955/12/specs/train/approved/nova-cyborg-interaction.rst@249
15:12:47 artom See PS11, L250
15:13:31 efried thanks artom
15:14:11 sean-k-mooney anyway i can see the logic of removing the fip association and also of not. since we dont know what we should do i feel raising an error is best but honestly i would be fine with doing nothing and not merging the patch also.

Earlier   Later