Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-18
09:13:13 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Support tag instances when boot https://review.openstack.org/394321
09:23:37 alex_xu gcb: done
09:43:26 openstackgerrit Alex Xu proposed openstack/nova master: Deprecate Multinic, floatingip action and os-virtual-interface API https://review.openstack.org/457181
10:05:46 openstackgerrit falseuser proposed openstack/nova master: [BugFix] Check the instance task status to release the memory quota for vram https://review.openstack.org/456050
10:15:17 johnthetubaguy cdent: am I right to worry about this one? https://review.openstack.org/#/c/448791/7
10:15:37 cdent johnthetubaguy: reading
10:17:07 gcb alex_xu: thanks
10:18:30 cdent johnthetubaguy: your comments are mostly reasonable (and you did find a bug), but I'm not sure you should "worry"?
10:18:44 johnthetubaguy cdent: heh, I am just a worrier
10:19:08 johnthetubaguy cdent: s/1.5/1.6/ I guess?
10:19:30 cdent the pattern for how to deal with microversions in the gabbi tests has yet to emerge, in that particular file it is "put diferences near to one another so we can compare"
10:19:42 johnthetubaguy cdent: I was curious about the gabby stuff, do we really want to modify those old tests to request a different version?
10:19:42 cdent but it might be better to do what you suggest "group the new version"
10:19:56 cdent the 1.5, 1.6 thing is the bug
10:20:20 johnthetubaguy yeah, but those tests, we should probably best both request no version, and request 1.6 I guess?
10:20:28 cdent the use of a version is to be explicit in the test so that it is clear that we are instentionally saying "I want a version that has a version I know" rather than "I want the default version"
10:20:44 cdent the intention isn't to test that microversions work
10:20:48 cdent that's tested elsewhere
10:21:03 cdent the intention is to test that the behavior at known microversions is what we expect, and to be explicit about it
10:21:07 cdent however
10:21:31 cdent given that you found a bug in reading the code that the tests did not catch, there's probably an adjustment that needs to be made
10:22:28 johnthetubaguy I know before in nova-api we said, test bottom, test top, test change points
10:23:14 cdent that might be a good idea, but we haven't established that yet
10:23:14 johnthetubaguy we missed some of the test change points in the past though, and end up with a discontinuity in bits of the API being supported, i.e. we missed the "change" point that needed testing
10:23:28 johnthetubaguy not in placement, I think that was assumed in nova-api
10:23:46 cdent I'll look at making it more betterer
10:24:25 johnthetubaguy cdent: I guess I just like seeing tests not changed when I don't want the behaviour to change, if that makes sense
10:24:38 cdent yeah, that makes sense
10:24:49 johnthetubaguy I just don't trust my eyes to review that stuff properly
10:25:31 cdent I think adding instead of changing is probably a good idea. It is a bit harder to do cleanly in the gabbi stuff because we're in a single session there and I really want to avoid this situation where we create giant gabbi files. Might need to do some of it in separate files.
10:25:43 johnthetubaguy testing all those negative tests for top a middle makes no sense to me either, so clearly a middle ground there
10:25:51 johnthetubaguy yeah, thats true
10:27:13 johnthetubaguy I was thinking you just repeat one negative test with version 1.6, to confirm it works, a test to confirm the API is removed in 1.7, just leave the old tests as they are, and test the new 1.7 in isolation, was what I was thinking?
10:27:22 johnthetubaguy not sure if that fits with what you were thinking?
10:28:59 cdent it sounds reasonable, I'll have to see what comes out when I start playing with it properly.
10:29:12 johnthetubaguy yeah
10:31:15 cdent but yeah, thank you, is very good input
10:31:38 johnthetubaguy no worries, happy to help
10:37:57 cdent johnthetubaguy: on the RT, the fallback was something that matt said ought to happen, to be extra nice. I'm not sure about adding the warning. Is that the usual behavior? Seems noisy to me.
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)

Earlier   Later