| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-18 | |||
| 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 | |
| 13:46:06 | mriedem | so how are we going to get this information from the virt driver when we're doing it in the scheduler | |
| 13:47:17 | mriedem | oh it looks like sahid just implemented this for the libvirt driver | |
| 13:47:53 | efried | mriedem Link? | |
| 13:48:07 | efried | Is this something all drivers (including OOT) will need to make changes for? | |
| 13:48:20 | mriedem | https://review.openstack.org/#/c/385364/ | |
| 13:48:27 | mriedem | wait link to what? | |
| 13:48:41 | mriedem | efried: claims in the scheduler spec https://review.openstack.org/#/c/437424/ | |
| 13:48:56 | efried | Yeah, that. Thanks. | |
| 13:49:26 | efried | mriedem FYI: https://github.com/openstack/nova-powervm/blob/master/nova_powervm/virt/powervm/driver.py#L249 | |
| 13:51:26 | mriedem | btw, the fact we can pass in 3 different things to this... | |
| 13:51:33 | efried | Yeah... awkward | |
| 13:51:35 | mriedem | terrible | |