Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-05
16:29:58 efried ...
16:30:19 mriedem gibi: yeah true
16:32:35 jaypipes wouldn't it be great if Nvidia developers actually participated in the community of people trying to enable their hardware? :(
16:33:46 efried mriedem: responded
16:35:15 mriedem efried: fwiw i also commented in bauzas's change that we should just do that mdev naming conversion from dashes to underscores in _get_mediated_device_information
16:35:24 mriedem so callers, like the libvirt driver and your test, don't need to care about that conversion
16:35:37 mriedem gah https://review.openstack.org/#/c/639647/
16:35:49 mriedem i was going to -1 because there are other follow ups from this series i'd like to see
16:35:51 mriedem i guess i'll do those
16:36:38 efried mriedem: So do you want me to fix the test patch, or are you going to fup?
16:37:34 mriedem i'm gonna fup all night long
16:37:46 efried ight
16:39:00 openstackgerrit Surya Seetharaman proposed openstack/nova master: Delete orphaned RS and IM records of archived instances https://review.openstack.org/560042
16:40:14 openstackgerrit Balazs Gibizer proposed openstack/nova master: Support server create with ports having resource request https://review.openstack.org/636360
16:40:52 gibi mriedem: fixed your comments in ^^
16:41:11 sean-k-mooney jaypipes: ya nvida and opensource is not really a thing...
16:41:38 sean-k-mooney jaypipes: unless its there "opensouce" project
16:42:59 mriedem melwitt: there is a lot of stuff in https://blueprints.launchpad.net/nova/stein that is going to be deferred, do you want to just start moving stuff out now to make that page more clear?
16:43:10 mriedem https://etherpad.openstack.org/p/nova-stein-blueprint-status is getting to be kind of a mess
16:43:32 mriedem so would be nice if the bp pages in lp was cleaned up, or https://etherpad.openstack.org/p/nova-stein-blueprint-status was cleaned up to remove stuff that's either done or not going to make it
16:43:43 melwitt mriedem: yeah :( I can try
16:44:07 mriedem well if you're working on the counting stuff that's probably higher priority
16:46:10 melwitt dansmith: I updated the user_id patch last night to remove the loading stuff, fyi. from your comment it sounds like the only thing missing is to do a log message in case someone tries to load an unset user_id
16:46:41 sean-k-mooney am should we just add another heading for defered stuff at the bottom.
16:46:42 melwitt mriedem: oh, sorry I misunderstood "do you want to ...". yeah, I think that is fine
16:46:56 bauzas mriedem: sorry, missed your comments on the naming thing
16:47:04 bauzas and I was off here for an hour
16:51:51 openstackgerrit Chris Friesen proposed openstack/nova master: Handle missing exception in instance creation code https://review.openstack.org/641082
16:53:19 openstackgerrit Balazs Gibizer proposed openstack/nova master: Ensure that bandwidth and VF are from the same PF https://review.openstack.org/623543
16:53:20 openstackgerrit Balazs Gibizer proposed openstack/nova master: Support server create with ports having resource request https://review.openstack.org/636360
16:54:27 cfriesen mriedem: fix for PciInvalidAlias issue. I reported a bug for it too.
16:54:46 mriedem cfriesen: but you got a 500 for that in the api with devstack?
16:55:00 cfriesen mriedem: yes, see above
16:55:17 cfriesen here are the logs: http://paste.openstack.org/show/747295/
16:56:18 cfriesen CLI output is in the bug: https://bugs.launchpad.net/nova/+bug/1818701
16:56:20 openstack Launchpad bug 1818701 in OpenStack Compute (nova) "invalid PCI alias in flavor results in HTTP 500 on instance create" [Medium,In progress] - Assigned to Chris Friesen (cbf123)
16:58:37 mriedem cfriesen: ok just robustify the test and i'm +2
17:00:11 openstackgerrit Theodoros Tsioutsias proposed openstack/nova master: Add requested_networks to RequestSpec https://review.openstack.org/570201
17:00:12 openstackgerrit Theodoros Tsioutsias proposed openstack/nova master: Enable rebuild for instances in cell0 https://review.openstack.org/570203
17:01:45 mriedem gibi: can we mark this complete? https://blueprints.launchpad.net/nova/+spec/use-nested-allocation-candidates
17:02:14 gibi mriedem: there is one intentionally open patch https://review.openstack.org/#/c/608298/
17:02:32 gibi mriedem: it is an edge case that we don't need in nova right now
17:02:34 mriedem "This cannot happen today but will in the future, when cpu and memory resource are moved to the NUMA RP and servers"
17:02:42 gibi mriedem: exactly
17:02:47 mriedem correct, so i'd just say it becomes a part of those bps when they happen
17:03:01 gibi mriedem: OK. I agree. Let's mark the bp completed
17:04:37 mriedem done
17:04:55 openstackgerrit Chris Friesen proposed openstack/nova master: Handle missing exception in instance creation code https://review.openstack.org/641082
17:05:12 cfriesen mriedem: I also robustified the other PCI test
17:05:17 mriedem oh my
17:05:20 mriedem that's a -5
17:05:44 mriedem i hope you ran fast8
17:05:47 mriedem but +2
17:06:09 cfriesen I can break out the other test as a separate commit if you want...
17:06:16 mriedem i'm just joking
17:06:45 mriedem -5 is a joke unless we're talking about forced cold migration
17:11:39 sean-k-mooney i tought forced migrations tradtional add a couple fo factorals added on like so -5!!
17:12:47 mriedem -5?!?!??!!
17:12:54 mriedem jazz it up however you want
17:13:49 melwitt reshaper + func test is finally on its way to the sarlacc pits \o/
17:14:22 dansmith melwitt: oh, I saw the comment wasn't on the latest PS, but I hadn't gone back to see what had changed
17:15:12 melwitt dansmith: understood. just giving you the 411
17:21:28 mriedem mdbooth: you might want to take a look at this https://review.openstack.org/#/c/613039/
17:21:33 mriedem if it has a chance of making stein
17:21:52 mriedem it does have test coverage... https://review.openstack.org/#/c/623483/
17:21:58 mdbooth mriedem: ack, thanks
17:30:35 openstackgerrit Matthew Booth proposed openstack/nova master: Don't age swap files in the image cache https://review.openstack.org/641093
17:35:38 mriedem aspiers: correct me if i'm wrong, but up to https://review.openstack.org/#/c/638680/ we advertise that a compute will support sev but up to that point we don't actually configure anything in a guest that requires sev, right?
17:36:16 mriedem so if we were to merge that code in stein, we'd be saying "these computes support sev" but you can't actually schedule servers to them and get sev in the guest, yeah?
17:38:19 mriedem i.e. something is yet to build on this https://review.openstack.org/#/c/636318/
17:38:58 mriedem all of this being done in parallel series makes it hard to track
17:41:30 dansmith someone should +W this: https://review.openstack.org/#/c/641021/
17:43:23 melwitt you can't +W it bc it's your patch. I can look
17:44:31 bauzas I can take a look if needed
17:44:36 bauzas I still have 30 mins left
17:44:47 dansmith it's easy, you all should be fighting over it
17:45:10 bauzas I haven't followed the cross-cell resize series but looks like it's unrelated
17:45:22 bauzas so I can chime in
17:46:41 cfriesen philosophical question for people. if we resize to the same instance type, should we validate the extra-specs again in case they've been changed since we booted? I kind of think yes.
17:47:52 melwitt bauzas: you can have it :)
17:47:58 dansmith cfriesen: I think yes
17:47:58 sean-k-mooney cfriesen: 1 yes 2 we proably should make exta-specs imunteable at some point once a flavor is in use
17:47:58 cfriesen (or is that disallowed and only actually happens on migrations?)
17:48:07 bauzas cfriesen: yes please
17:48:13 cfriesen it's confusing, there's something related to cell types in here
17:48:41 melwitt cfriesen: I think yes too
17:49:03 bauzas cfriesen: the problem is that we put too many things in extra sepcs
17:49:15 sean-k-mooney is there any reason we dont allow you to set extraspec when creating a flavor so we can make the whole thing readonly
17:49:19 bauzas we should at least validate those specs before calling the scheduler
17:49:56 cfriesen I'm looking at https://github.com/openstack/nova/blob/master/nova/compute/api.py#L3541 which seems to indicate that you're not supposed to resize to the same flavor, but there's an exception for a "compute" cell type
17:49:57 sean-k-mooney i guess maybe because resize is a cold migration?
17:50:16 openstackgerrit Merged openstack/nova master: Stub out port binding create/delete in NeutronFixture https://review.openstack.org/636413
17:50:42 mdbooth lyarwood: Would you also be able to pontificate upon https://review.openstack.org/#/c/613039/ ?
17:51:12 openstackgerrit Merged openstack/python-novaclient master: Microversion 2.71 - show server group https://review.openstack.org/640657
17:51:16 mdbooth lyarwood: FWIW I'll be +1 on that assuming the tests are good, but I don't have time to look now.
17:52:06 cfriesen sean-k-mooney: yeah, but the comments say that for migration "flavor_id" is None.
17:53:32 sean-k-mooney cfriesen: right well resize and colde migrate are the same thing in nova except resize change the flavor and migrate does not
17:53:59 stephenfin gibi: Sorry for the delay. +2'd now :)
17:54:24 cfriesen sean-k-mooney: yeah, but there's some cells complication apparently: https://bugs.launchpad.net/nova/+bug/1243816
17:54:26 openstack Launchpad bug 1243816 in OpenStack Compute (nova) "migrate fails with cells" [Undecided,Fix released] - Assigned to Chris Behrens (cbehrens)

Earlier   Later