Earlier  
Posted Nick Remark
#openstack-nova - 2017-04-18
10:38:19 johnthetubaguy cdent: we sometimes only warn the first time, but that does overcomplicate things
10:38:38 johnthetubaguy cdent: maybe debug is best, I am just thinking about scratching my head debugging things in the future really
11:15:04 cdent johnthetubaguy: ah, part of the reason for those explicit microversions is because the tests in tha file are using a default of 'latest'
11:15:22 johnthetubaguy cdent: ah... I missed that
11:16:08 cdent I still think there are some good cleanups that can be made based on your idea though.
11:17:15 openstackgerrit Mikhail Feoktistov proposed openstack/nova master: libvirt: Virtuozzo containers config drive support https://review.openstack.org/449818
11:31:41 openstackgerrit Alex Xu proposed openstack/nova master: Fix the evacuate API without json-schema validation in 2.13 https://review.openstack.org/457577
11:32:13 alex_xu sdague: ^ a easy fix, but do you have any suggestion about how to test it?
11:39:52 cdent johnthetubaguy: you're having a banner day: you've caused me to find what might be a bug in gabbi
11:46:10 sdague alex_xu: the way that stack is written, not really
11:48:25 sdague alex_xu: it would be a little interesting if instead of the function stack the decorator was registering alias entries for every microversion, so you could see if they were missing
12:17:03 openstackgerrit Chris Dent proposed openstack/nova master: Update resource tracker to PUT custom resource classes https://review.openstack.org/456915
12:17:04 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Idempotent PUT /resource_classes/{name} https://review.openstack.org/448791
12:17:14 openstackgerrit Monty Taylor proposed openstack/python-novaclient master: Add novaclient client_name and client_version to user-agent https://review.openstack.org/456638
12:17:40 cdent mordred: did you see the comment I've just left on ^?
12:17:53 mordred cdent: nope! missed it - looking
12:18:16 mordred cdent: ah- so, for that case, "app_name" is the thing the person should be setting
12:18:21 mordred and it gets set on the Session
12:18:34 cdent meh, ETOOMANYKNOBS
12:19:00 mordred cdent: (or, if they're doing something like shade and making a client that other apps use, there is another nob - but this should work in all those cases)
12:20:02 mordred one could argue in favor of exposing app_name in novaclient constructor to allow a user to set it for the cases where novaclient creates the session for the user -but honestly - I think that falls into "just create the session yourself and pass it in" :)
12:20:05 cdent so often in these things it seems like we are creating abstractions for stuff that has normal real world names and interaction mode (such as "user-agent")
12:32:02 mordred yah
12:32:12 mordred cdent: well, that's because abstractions make everytihng better
12:32:20 cdent I heard that somewhere
12:35:25 sdague mordred: https://review.openstack.org/#/c/456344/ ... no special ports on keystone, also it was interesting what fell out of that in the process
12:35:47 mordred sdague: zomg I'm so excited about that
12:52:33 alex_xu sdague: ah, thanks, let me thinking how to make it happen
12:53:39 sdague alex_xu: I think it would require a more substantial rewrite here
12:53:46 sdague honestly, we should fix this issue
12:54:17 sdague but I think in general there are some changes to the way these decorators work that might make it harder to make mistakes like this
12:57:03 mordred sdague: on the novaclient patch above - you think docstring is a good place to document?
12:58:28 sdague mordred: wherever makes it so it ends up here - https://docs.openstack.org/developer/python-novaclient/api.html
12:58:34 mordred kk
13:00:46 bauzas mordred: sdague: I think a reno patch is good enough for documenting that https://review.openstack.org/#/c/456638/3
13:01:21 bauzas of course amending the doc is the better approach, but a note would help people knowing the new possibility
13:01:40 bauzas (and the alternative)
13:03:26 sdague bauzas: it's a client api, I'd rather just make it clear how to set the agent string up front
13:03:27 openstackgerrit Monty Taylor proposed openstack/python-novaclient master: Add novaclient client_name and client_version to user-agent https://review.openstack.org/456638
13:03:30 mordred how's that?
13:03:51 alex_xu sdague: all the versioned method are stored in the a class method, I think I can check that list
13:03:59 sdague I always think about how clear it is in these docs - http://search.cpan.org/dist/libwww-perl/lib/LWP.pm#An_Example
13:04:34 sdague mordred: works for me
13:04:45 sdague mordred: thanks
13:05:33 bauzas sdague: I totally agree with you, I'm just advocating on a rather operator/end-user perspective
13:05:45 mordred sdague: woot!
13:06:03 bauzas meaning that I should see my UA logs be changed once I start using the new release of novaclient
13:06:38 bauzas mordred: +W'aboom
13:07:27 mordred \o/
13:07:32 mordred I have made a success today!
13:09:59 bauzas always a pleasure to come back from an holiday period by helping others :)
13:10:57 mriedem o/
13:11:10 bauzas 'supp
13:26:03 mriedem bauzas: have you gone through the latest comments in the claims in scheduler spec? https://review.openstack.org/#/c/437424/
13:26:43 bauzas mriedem: yup, I was waiting for all the folks to be around before pinging all of you
13:27:01 bauzas mriedem: looks like the consensus changed ?
13:27:26 bauzas mriedem: now, the compute node should HTTP get the list of allocations instead of having those passed thru RPC, correct?
13:28:13 bauzas mriedem: also, seems like there was kind of a confusion where the POST allocations should be called, ie. in the conductor vs. scheduler
13:28:22 openstackgerrit Roman Podoliaka proposed openstack/osc-placement master: tests: add a hook for functional testing in the gate https://review.openstack.org/452122
13:28:48 bauzas FWIW, I thought we all agreed to have the conductor doing that
13:28:58 bauzas (during the hangout)
13:29:16 mriedem bauzas: i thought that when i thought, incorrectly, that the conductor got the list of filtered and weighed hosts
13:29:42 bauzas yup
13:29:48 mriedem we could do it in either, but it seems to me it would be better to retry by just hitting the next host in the list of already filtered hosts, in the scheduler,
13:30:03 mriedem rather than having conductor ask the scheduler to pull a fresh new set all over again
13:30:12 andreykurilin hi folks! Could someone look at small (+9, -5) patch to novaclient https://review.openstack.org/#/c/450763/ ?
13:30:24 bauzas tbc, the conductor only get a subset of hosts returned by the scheduler, not all the accepted nodes
13:30:37 bauzas where the default subset is 1
13:31:31 bauzas mriedem: the problem wasn't really with the POST logic, rather the DELETE allocation logic when rescheduling or moving the instance
13:31:32 mriedem right, i didn't realize that until yesterday
13:31:50 mriedem bauzas: i think it's fine to do the delete in conductor on reschedules
13:31:53 bauzas mriedem: given the scheduler doesn't know whether it's a boot request, or a move
13:31:58 mriedem like we do for cleaning up bdms and ports
13:32:05 bauzas okay
13:32:08 bauzas fine by me then
13:32:16 bauzas that's 2 distinct situations
13:32:25 mriedem ok, think you can have the spec updated today?
13:32:45 bauzas we could POST the allocation in the current synchronous method we have
13:32:50 mriedem andreykurilin: why does that really need to change? does it just bug you? or is something building on that later?
13:33:04 bauzas and then DELETE allocations for reschedules/moves in the conductor
13:33:12 bauzas mriedem: yup, was planning to
13:33:26 mriedem bauzas: post somewhere in here? https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L124
13:33:32 bauzas nope
13:34:20 mriedem https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L80 ?
13:34:23 bauzas mriedem: within consume_from_request https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L131
13:34:33 bauzas because it's a synchronous method
13:34:54 bauzas I mean there is a semaphore
13:35:02 bauzas synchronous section of code
13:35:27 bauzas dammit, 3.5 days out of OpenStack and my English is still on holiday :/
13:35:29 mriedem so https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L271
13:35:50 bauzas probablement oui
13:36:10 bauzas but that's an implementation detail IMHO
13:36:17 andreykurilin mriedem: I just saw an usage of that method in some script and it was not clear what does it accept without searching at docs.o.o/nova (usually, looking at novaclient's docstring is enough)
13:41:13 mriedem do we have some sort of memory overhead estimate code in the virt drivers that impacts scheduling via the resource tracker?
13:42:08 mriedem ah estimate_instance_overhead
13:43:55 mriedem wow that's a fun method, it can get 1 of 3 different input parameter types
13:45:02 mriedem bauzas: hmm, so that's going to be something interesting that will have to be taken into account to do claims in the scheduler
13:45:13 mriedem totally coincidental but someone internal was asking about this for kvm
13:45:22 efried mriedem I know the PowerVM code for estimate_instance_overhead is... interesting.
13:45:32 mriedem but i see RT.instance_claim calls estimate_instance_overhead on the virt driver

Earlier   Later