Earlier  
Posted Nick Remark
#openstack-nova - 2017-12-14
17:10:01 bauzas stephenfin: I just found those https://review.openstack.org/#/c/361140/6..7/specs/ocata/approved/share-pci-between-numa-nodes.rst
17:10:27 bauzas stephenfin: oops https://review.openstack.org/#/c/361140/6/specs/ocata/approved/share-pci-between-numa-nodes.rst@69
17:10:53 bauzas honestly, we're late in the cycle so your concern is valid
17:11:02 stephenfin bauzas: That's the one. There's also this discussion on the need for both flavor extra spec and image metadata https://review.openstack.org/#/c/361140/19/specs/pike/approved/share-pci-between-numa-nodes.rst@59
17:11:02 bauzas but I do feel it's a PITA for operators
17:11:48 stephenfin )note that I mixed up the use of flavors extra specs vs image metadata - it's *operators* that would set the former and not user)
17:12:13 stephenfin bauzas: Would a TODO to resolve that in a future effort be reasonable? I'm pretty sure I can revive the spec I talked about
17:12:17 bauzas stephenfin: well, PS19 convo is strictier than the one I found
17:12:29 openstackgerrit Claudiu Belu proposed openstack/nova master: tests: fixes mock autospec usage https://review.openstack.org/447505
17:12:31 bauzas stephenfin: it's more about whether we need to use image metadata
17:12:49 stephenfin Indeed. Different argument but in a similar area
17:12:50 bauzas here, I still think it's understandable to do such things because users need a way to ask for a policy
17:12:58 stephenfin Here's the spec I was talking about https://review.openstack.org/#/c/382382/
17:13:30 stephenfin We can use that determine what we want to do going forward
17:13:38 bauzas stephenfin: documenting the flaws of using flavor metadata for such things is indeed a necessary thing to do
17:14:03 bauzas I'd recommend operators to *not* use flavor metadata if they don't know their users
17:14:47 stephenfin I'd also like to use something like JSONSchema (though maybe not that) to validate flavour extra specs and determine what things can't be used together
17:15:07 stephenfin ...with exceptions for custom flavour properties
17:15:35 bauzas in my mind, flavors take precedence over images
17:15:44 bauzas because they are admin-driven
17:15:54 bauzas so, your call, man
17:15:56 stephenfin bauzas: Aye, that's how I see them too
17:16:29 stephenfin But I don't want a user to think "I've got a strictly-pinned NUMA device" when they actually don't
17:16:40 stephenfin cos the operator set the policy to 'preferred'
17:16:45 bauzas right
17:16:46 stephenfin for resource usage reasons or whatever
17:16:50 bauzas but users won't know anyway
17:17:02 stephenfin They won't?
17:17:11 bauzas how could they ?
17:17:15 openstackgerrit Merged openstack/nova master: Fix disk size during live migration with disk over-commit https://review.openstack.org/524681
17:17:21 openstackgerrit Merged openstack/nova stable/ocata: Only query BDMs once in API during rebuild https://review.openstack.org/525665
17:17:34 bauzas do we expose the topology to the users ? hell no, of course
17:17:47 bauzas ah, that
17:18:04 bauzas well, two cases, and that requires looking at code
17:18:16 bauzas #1 either we fail and we reschedule to another host
17:18:21 bauzas which could eventually fail too
17:18:26 bauzas #2 or we make it full stop
17:18:33 bauzas and then we error out
17:18:45 bauzas either way, the user experience isn't terrible
17:18:51 stephenfin Oh, actually, #1 would actually happen
17:19:04 stephenfin because the NUMATopologyFilter (eventually) calls those functions
17:19:25 bauzas isn't that called by the compute service?
17:19:31 stephenfin That too, yes
17:19:36 stephenfin It's this call
17:20:34 stephenfin https://github.com/openstack/nova/blob/master/nova/scheduler/filters/numa_topology_filter.py#L94-L98
17:20:46 bauzas man, I got 3 days of legal and accouting training, but I don't know what hurts more : that or discussing PCI scheduling
17:20:57 stephenfin Hahaha
17:21:01 mriedem jaypipes: is an alter statement on a column type change idempotent? https://review.openstack.org/#/c/528012/1/nova/db/sqlalchemy/api_migrations/migrate_repo/versions/051_request_spec_spec_mediumtext.py
17:21:04 mriedem if it's already that type?
17:21:13 stephenfin Don't worry - jaypipes and co are going to save us with nested-rps
17:21:26 stephenfin And if they don't - guaranteed job security :P
17:21:58 bauzas having a job security doesn't mean brain sanity
17:22:22 mriedem gd 11:30 already
17:22:44 bauzas 11:22 technically
17:22:53 mriedem not in minnesota
17:23:21 bauzas Minnesota is that better from other states that it saves 8 mins for every worker ?
17:23:29 stephenfin bauzas: But yeah, that call ends up here https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L1436
17:23:36 mriedem bauzas: it is; that's why our taxes are high
17:24:02 bauzas mriedem: I'm sure we beat your state
17:24:04 stephenfin which then calls in here, where we _eventually_ raise the exception https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L1513
17:24:20 mriedem bauzas: sure, but,
17:24:31 mriedem we don't get 50% of the month off for PTO :P
17:25:04 bauzas jeez
17:25:07 bauzas touché
17:25:53 bauzas stephenfin: so, give me a sec to rephrase that
17:26:12 bauzas stephenfin: you mean that the policy check will be done primarly by the scheduler then ?
17:26:31 bauzas I need to rereview then the implications
17:26:35 stephenfin It'll be done twice - once by the scheduler and once when we're booting
17:26:45 stephenfin Because races are possible
17:26:49 bauzas yeah, but totally not at the same time :)
17:26:57 stephenfin Indeed :)
17:27:18 stephenfin So, per above, what a user will see is a failure to find suitable hosts
17:27:19 bauzas so, say we raise an exception, all of that stuff if called by the filter, right?
17:27:35 stephenfin All of what stuff?
17:27:35 bauzas s/if/is
17:28:37 bauzas stephenfin: https://review.openstack.org/#/c/527472/4/nova/virt/hardware.py@1197 is called eventually by the filter ?
17:28:56 stephenfin Yes
17:29:09 stephenfin Ditto for https://review.openstack.org/#/c/527472/4/nova/virt/hardware.py@1184
17:29:44 bauzas stephenfin: so that worst than a reschedule
17:29:49 bauzas that's
17:30:05 bauzas stephenfin: if the filter raises an exception, the whole scheduling process fails
17:30:34 bauzas I need to test that, but I'm pretty it goes into ERROR/scheduling
17:30:46 bauzas oh man, fat fingers
17:31:43 vivsoni__ mriedem: Hi
17:32:37 stephenfin bauzas: Ack. I'm going to test it now myself with CPU policies
17:32:51 bauzas stephenfin: I need to bail out, family duty
17:32:56 bauzas ++
17:33:10 stephenfin A-ok. I'm gone tomorrow but I'll be around Monday if you've questions
17:33:31 mriedem vivsoni__: hi
17:34:04 bauzas stephenfin: drop me a note about your findings and if that's not a full scheduling break, then +2 on the last PS
17:34:20 stephenfin bauzas: Spot on. Enjoy family time :)
17:34:28 bauzas if that's a full scheduling stop then I'm pretty -1 on the existing
17:34:47 bauzas or make the filter resilient to errors
17:35:04 vivsoni__ mriedem: Need your input in resolving tempest Test case "tempest.api.compute.volumes.test_attach_volume.AttachVolumeShelveTestJSON.test_detach_volume_shelved_or_offload_server"
17:35:25 vivsoni__ hpe ci is failing because of that
17:37:05 openstackgerrit Ade Lee proposed openstack/nova master: Add flag to make glance image verification optional https://review.openstack.org/528017
17:39:32 vivsoni__ mriedem: In this TC 'connector', which is passed to cinder vendor driver's 'initialize_connection' & 'terminate_connection' is empty
17:43:21 vivsoni__ basically the driver's 'def initialize_connection' is not called, when 'attach_volume' is called https://github.com/openstack/tempest/blob/master/tempest/api/compute/volumes/test_attach_volume.py#L252
17:43:59 vivsoni__ its failing here https://github.com/openstack/tempest/blob/master/tempest/api/compute/volumes/test_attach_volume.py#L253
17:46:01 mriedem vivsoni__: that's because nova doesn't call initialize_connection anymore

Earlier   Later