Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-09-13
21:52:02 melwitt because the default thing in the unit tests makes it act like single cell I guess
21:52:35 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Target context when setting instance to ERROR when over quota https://review.openstack.org/503839
21:52:41 mriedem yeah ^
21:52:47 mriedem if you remove the fix, that shows the failure
21:52:59 mriedem melwitt: this isn't even multi-cell
21:53:13 mriedem this is just our cell db fixture lying for us
21:53:31 melwitt yeah, okay
21:56:30 mtreinish dansmith: if you were curious (which I know you aren't): http://stestr.readthedocs.io/en/latest/MANUAL.html#combining-test-results and http://stestr.readthedocs.io/en/latest/MANUAL.html#running-tests describe those options I was using
22:06:17 dansmith mtreinish: cool
22:08:17 melwitt mriedem: I wonder if we should just make sure default compute cell != default cell when untargeted in nova/test.py
22:08:38 melwitt because that also makes the test fail with InstanceNotFound. if I make default=True for cell2 instead of cell1
22:10:17 openstackgerrit Merged openstack/nova master: Fix missed chown call https://review.openstack.org/503079
22:10:36 openstackgerrit Chris Dent proposed openstack/nova master: WIP: [placement] POST /allocations to set allocations for >1 consumers https://review.openstack.org/500073
22:10:42 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Removing versioning from resource_provider objects https://review.openstack.org/502164
22:10:43 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Unregister the ResourceProviderList object https://review.openstack.org/502162
22:10:43 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Unregister the ResourceProvider object https://review.openstack.org/502163
22:10:44 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Unregister the Inventory object https://review.openstack.org/502161
22:10:45 openstackgerrit Chris Dent proposed openstack/nova master: Move project_id and user_id to Allocation object https://review.openstack.org/500410
22:10:45 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Unregister the InventoryList object https://review.openstack.org/502160
22:10:46 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Unregister the AllocationList object https://review.openstack.org/502158
22:10:47 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Unregister the UsageList object https://review.openstack.org/502156
22:10:47 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Unregister the Allocation object https://review.openstack.org/502159
22:10:48 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Unregister the ResourceClassList object https://review.openstack.org/502154
22:10:48 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Unregister the Usage object https://review.openstack.org/502157
22:10:49 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Unregister the ResourceClass object https://review.openstack.org/502155
22:10:50 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Unregister the TraitList object https://review.openstack.org/502152
22:10:51 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Unregister the Trait object https://review.openstack.org/502153
22:10:51 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Allow _set_allocations to delete allocations https://review.openstack.org/501051
22:45:49 openstackgerrit Matt Riedemann proposed openstack/nova master: Target context when setting instance to ERROR when over quota https://review.openstack.org/503839
22:45:56 mriedem melwitt: ok ^ is the best i can do today
22:47:02 melwitt mriedem: okay, will review
#openstack-nova - 2017-09-14
00:52:58 openstackgerrit Merged openstack/nova master: Fix test runner config issues with os-testr 1.0.0 https://review.openstack.org/503811
00:53:25 openstackgerrit Merged openstack/nova master: Cleanup running of osprofiler tests https://review.openstack.org/503831
02:32:17 openstackgerrit Michael Still proposed openstack/nova master: Add a file like proxy for reading files with privsep https://review.openstack.org/503893
03:35:38 openstackgerrit Jianghua Wang proposed openstack/nova-specs master: Support virtual GPU resources https://review.openstack.org/450122
03:37:57 openstackgerrit Lajos Katona proposed openstack/nova master: Add functional migrate force_complete test https://review.openstack.org/496202
03:40:24 openstackgerrit Lajos Katona proposed openstack/nova master: Add functional migrate force_complete test https://review.openstack.org/496202
04:18:23 openstackgerrit Lajos Katona proposed openstack/nova master: Add functional for live migrate delete https://review.openstack.org/499583
05:01:44 sapd_ Hi everyone, I'm using openstack pike. I create a queue named eventqueues, I bind this queue to nova exchange and configure notify vm state on nova-compute - notifications section. But when consume this queue, I can't get any message.
08:17:36 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Migration from ``ip`` commands to ``pyroute2`` https://review.openstack.org/484386
08:56:53 openstackgerrit Yikun Jiang proposed openstack/nova master: Add @targets_cell for live_migrate_instance method in conductor https://review.openstack.org/503601
08:59:49 openstackgerrit Yikun Jiang proposed openstack/nova master: Add @targets_cell for live_migrate_instance method in conductor https://review.openstack.org/503601
09:13:00 Mr_Smurf Could someone explain to me why it is allowed to attach an interface to an instance for a non admin user when it has shared and external router, but not when the nework is not shared?
09:13:09 Mr_Smurf https://github.com/openstack/nova/commit/a98aa603550ad4d9f8d16de8c7acd0819680a028
09:14:05 Mr_Smurf why bypass the policy file in one case but not the other?
09:58:52 openstackgerrit Elod Illes proposed openstack/nova master: WIP: Add instance.interface_attach notification https://review.openstack.org/503089
12:02:13 rabel could someone please review https://review.openstack.org/#/c/402632/ ? it is more or less ready since january
13:34:51 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Migration from ``ip`` commands to ``pyroute2`` https://review.openstack.org/484386
14:29:52 pooja Hi.. I had a question around configuring nova-scheduler in the control plane. For scalability, is it possible to run multiple nova-scheduler processes like api and conductor?
14:30:51 pooja As I understand, the host manager needs to be aware of all provisioning ops so it may not be possible. Any thoughs? Thanks!
14:54:43 johnthetubaguy gmann: here we go https://review.openstack.org/#/c/435484
14:54:56 gmann johnthetubaguy: thanks
15:08:34 openstackgerrit Merged openstack/os-vif master: Add ``HostPortProfileInfo`` class https://review.openstack.org/441590
15:11:40 bauzas pooja: you can technically run multiple scheduler services, but since the in-memory state of the objects isn't shared between all schedulers, you can face race conditions at limits, when your cloud capacity is close to be full
15:13:19 bauzas pooja: that is currently being tackled by the fact the scheduler (since Ocata) now uses a Placement API service that is giving it a shared view of the state of the cloud, but that's only for a couple of resource classes (RAM and CPU, disk as well but still incorrectly reported if disks are shared between computes)
15:16:27 melwitt bauzas: I thought claims in the scheduler made it so running multiple schedulers won't reschedule because of different in-memory states?
15:17:02 bauzas melwitt: for CPU, RAM and disk, yes
15:25:49 smcginnis Video link from John explaining new attach https://www.youtube.com/watch?v=mrgPt0c3cUw
15:26:12 openstackgerrit Ed Leafe proposed openstack/nova-specs master: Return Selection Objects https://review.openstack.org/498830
15:30:45 mriedem sdague: replied to your -1 in https://review.openstack.org/#/c/493323/
15:34:41 mriedem sdague: the way the code series goes, everything is keyed off whether or not the bdm.attachment_id is set, and that's only ever set for a *new* attachment using the new flow, which is the very last patch in the series,
15:34:54 mriedem and that doesn't turn on until (1) all computes are upgraded and (2) cinder 3.44 is available
15:35:01 mriedem so people can roll upgrade to this functionality
15:35:16 sdague https://github.com/openstack/nova/blob/cfdec41eeec5fab220702efefdaafc45559aeb14/nova/compute/api.py#L3741-L3745 that's not called now?
15:35:32 mriedem no, because if bdm.attachment_id is None: will be True
15:36:18 sdague ok
15:36:35 mriedem sdague: https://review.openstack.org/#/c/330285/136/nova/compute/api.py@3581
15:36:49 sdague that seems dangerous to be implicitly working like this, vs some real const to ensure we don't go down this path
15:38:22 mriedem we do the min compute service version check like this everywhere
15:39:49 sdague I guess I'd feel more comfortable with if bdm.version >= 3.44 instead of if bdm.attachment_id == None
15:39:52 sdague conceptually
15:40:18 sdague anyway, that's fine. It's just not as obvious as I'd ideally like on it
15:40:45 bauzas edmondsw_: so, about https://review.openstack.org/#/c/422696/ I checked the guidelines we have for Nova
15:41:10 bauzas edmondsw_: https://docs.openstack.org/nova/latest/contributor/microversions.html#f2
15:42:00 bauzas edmondsw_: changing from a unclear 400 to a clearer 401 looks like legit as not requiring a microversion
15:43:24 bauzas sdague: am I correct? changing from 400 to 401 doesn't require a microversion, right?
15:43:31 bauzas alex_xu: ^
15:46:49 openstackgerrit Matt Riedemann proposed openstack/nova master: DNM: test new style volume attach with live migration https://review.openstack.org/481290
15:47:48 sdague bauzas: honestly, we most don't try to change those things
15:48:17 edmondsw_ bauzas that doesn't talk about 401. And it isn't consistent with http://specs.openstack.org/openstack/api-wg/guidelines/api_interoperability.html#evaluating-api-changes
15:49:02 edmondsw_ sdague we should definitely update one or the other of what bauzas linked and what I linked to be consistent...
15:49:55 edleafe edmondsw_: bauzas: generally, changing a 400 to a 401 would require a microversion bump.
15:49:57 sdague I've got to think through that neutron patch and understand
15:49:59 bauzas sdague: what would you recommend ?
15:50:04 bauzas okay
15:50:09 bauzas thanks
15:50:17 sdague I don't have the brain power in discussion rooms to think that one through right now
15:50:22 bauzas np
15:51:21 bauzas edleafe: well, I understanding the reasoning that API consumers need a programmatical way to identify what error they got and do things accordingly
15:51:41 sdague I honestly don't think that 401 is generically understood to be token expired
15:52:01 sdague which puts this into the category of churn change
15:52:21 bauzas the problem with the error code we returned was that it was implying some misconfig
15:52:44 edmondsw sdague definely doesn't mean token expired... it means unauthorized, which could be token expired but could also be token was never valid
15:53:04 sdague edmondsw: right, which means that the change doesn't give any more ability to automatically recover
15:53:13 sdague which is the justification for the change
15:53:20 edmondsw but in a path like this, we know it was valid originally, so we know the change is that it has expired
15:53:37 edmondsw sdague no, because of what I just added
15:53:54 edleafe edmondsw: right, the general pattern for 401 is to retry once, and if that fails, give up
15:54:11 edleafe (retry auth, not the original call)
15:54:20 edmondsw edleafe right

Earlier   Later