Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-12-10
15:46:21 kashyap lyarwood: What about Bregret?
15:46:46 kashyap lyarwood: I mean, what are you "dealing" with? Aren't you just supposed to just "suffer the consequences", or you have the power to "do something"? :D
15:47:33 kashyap lyarwood: Oh ... disregard me; just "caught up" with the Tories.
15:47:58 stephenfin jangutter: Reviewed https://review.openstack.org/#/c/607610/. Looks good to me, for the most part, the few updates suggested by others aside
15:48:10 stephenfin jangutter: If you rework today, let me know and I'll swing by again
15:48:53 jangutter stephenfin: thanks, respinning!
16:00:25 jangutter sean-k-mooney: any objection to choosing "Option 1" in the spec now?
16:00:54 sean-k-mooney jangutter: i have not looked in a while but didnt i say that in a previous version
16:01:55 sean-k-mooney ah its still at the same version so sure
16:02:04 jangutter sean-k-mooney: yeah, doing a respin now, just wanted to make doubly sure. I mean, I sold a _lot_ of tickets to "Sean vs Jay's punch-the-ginger contest".
16:03:49 sean-k-mooney jangutter: every know you dont punch ginger people in case its contagious :P
16:04:34 jangutter sean-k-mooney: that's why boxing gloves were developed to be so thick.
16:05:17 sean-k-mooney if you want to leave it till later to decide we can but you already have patches for option 1
16:05:39 sean-k-mooney my main concern was serialiastion size
16:06:55 sean-k-mooney we can adress that at a later date in other ways
16:11:28 openstackgerrit Jack Ding proposed openstack/nova-specs master: Select cpu model from a list of cpu models https://review.openstack.org/620959
16:14:55 openstackgerrit Ben Nemec proposed openstack/nova master: Migrate upgrade checks to oslo.upgradecheck https://review.openstack.org/603499
16:40:13 openstackgerrit Jan Gutter proposed openstack/nova-specs master: Spec to implement os-vif generic datapath offloads https://review.openstack.org/607610
16:58:17 melwitt o/
16:59:03 sean-k-mooney melwitt: o/
17:02:10 sean-k-mooney johnthetubaguy: o/ care to take another look at https://review.openstack.org/#/c/591607/11
17:20:14 melwitt mriedem: I was thinking we should cancel the dec 20 nova meeting bc efried_cya_jan is out and I think dansmith is out that day too. and I was considering taking the day off as well
17:21:49 mriedem shrug
17:21:50 mriedem i'll be around
17:21:55 mriedem i can run it if needed
17:22:42 dansmith I won't be
17:25:20 melwitt mriedem: ok, if you are able to run it then that works too. I was thinking there might be a lack of quorum
17:26:04 s10 Please review backports for https://review.openstack.org/#/q/topic:bug/1806064
17:28:14 sean-k-mooney lyarwood: ^ that proably for you
17:43:32 jangutter mriedem: would you be able to take a look at https://review.openstack.org/#/c/607610/ in your copious free time...? Jay's already +2'ed the previous revision.
17:44:15 mriedem uhh
17:48:10 sean-k-mooney by the way was there a proposal to do another spec review day tomorow or was i imagining that
17:49:26 melwitt sean-k-mooney: I suggested it and we discussed it in the nova meeting and decided to give it a miss. I replied on the ML accordingly
17:49:45 sean-k-mooney melwitt: ah ok
17:53:25 openstackgerrit Surya Seetharaman proposed openstack/python-novaclient master: API microversion 2.68: Handles Down Cells https://review.openstack.org/579563
17:53:26 mriedem lbragstad: have you seen this? http://logs.openstack.org/81/606981/4/check/tempest-slow/fafde23/controller/logs/screen-n-api.txt.gz#_Dec_08_01_45_42_745709
17:55:24 mriedem seems like something in an api-paste middleware
17:55:38 mriedem b/c it's logged before we call the actual controller method to handle that request
17:57:25 mriedem oh i bet i know what it is
17:57:32 lbragstad it's related to https://review.openstack.org/#/c/619260/3/oslo_policy/policy.py
17:57:59 mriedem nova's RequestContext calls check_is_admin during init
17:58:02 mriedem which is for every request
17:58:34 lbragstad does that call enforce()?
17:59:23 mriedem calls return _ENFORCER.authorize('context_is_admin', target, credentials)
17:59:55 mriedem which calls enforce
17:59:59 lbragstad ah - it does
18:00:00 lbragstad right
18:00:04 lbragstad makes sense
18:00:41 lbragstad oh - weird, target is being overloaded as credentials?
18:00:59 lbragstad i suppose, is it too early in the pipeline for nova to know what the actual target is?
18:01:04 mriedem yeah
18:01:08 lbragstad huh
18:01:13 lbragstad interesting
18:01:28 mriedem remember this? https://review.openstack.org/#/c/564349/
18:03:12 lbragstad oh - yeah... kinda
18:04:32 lbragstad looks like that would still address the issue
18:05:00 mriedem this is where we get _DeprecatedPolicyValues https://github.com/openstack/oslo.context/blob/0daf01065d1d51694e06aaecb3dcf4dcc78710fe/oslo_context/context.py#L318
18:05:04 mriedem passing that in as the target
18:05:23 lbragstad right
18:05:38 lbragstad you should be able to pass context objects as credentials
18:05:59 lbragstad but we don't really link anything about target to context
18:06:00 lbragstad at least in oslo.policy
18:06:28 mriedem seems we should just pass target={}
18:06:30 mriedem since we don't know
18:07:06 lbragstad (we wanted to use context objects as a replacement for a dictionary called credentials since it makes things easier for services using oslo.policy - instead of just assuming service developers know what to put in credentials or how the internals of oslo.policy parses it)
18:07:37 lbragstad and it relays a bunch of useful information about the user making the request - which is what credentials was trying achieve anyway
18:08:22 lbragstad but yeah - if you don't know anything about the target, an empty dictionary would seem safer than overloading target as a set of context attributes
18:12:00 lbragstad for example - in keystone we protect APIs like this https://github.com/openstack/keystone/blob/master/keystone/api/users.py#L137
18:12:31 lbragstad we look at the context object associated with the request and generate "credentials" https://github.com/openstack/keystone/blob/master/keystone/common/rbac_enforcer/enforcer.py#L380
18:12:44 lbragstad and then pass that to oslo.policy https://github.com/openstack/keystone/blob/master/keystone/common/rbac_enforcer/enforcer.py#L81-L82
18:18:10 openstackgerrit Dan Smith proposed openstack/nova master: Make compute rpcapi version calculation check all cells https://review.openstack.org/623284
18:18:10 openstackgerrit Dan Smith proposed openstack/nova master: Make service.get_minimum_version_all_cells() cache the results https://review.openstack.org/623283
18:19:33 openstackgerrit Georg Hoesch proposed openstack/nova master: refactor get_console_output() for console logfiles https://review.openstack.org/575735
18:38:19 dtrainor Howdy. I'm trying to troubleshoot a failed deployment that ultimately results in "Message: No valid host was found. There are not enough hosts available., Code: 500". Digging deeper, it looks like RamFilter is returning 0 hosts because the hosts appears to return a value of 0 MB RAM http://paste.openstack.org/show/736921/
18:38:35 etp Do max_placement_results and host aggregates/AggregateInstanceExtraSpecsFilter work together or am I looking at configuration error? Say cloud has 100 hypervisors, max_placement_results = 10, two host aggregates 50 hypervisors each, flavor extra specs matching latter aggregate with hypervisors 51-100
18:38:59 dtrainor the nodes get properly introspected. the introspection data is good. there may be a bug in the Ravello hypervisor that this is being deployed on which ahs been known to return 0MB if the host BIOS returned a negative number (read something about an overcommit ratio sometimes causing this)
18:42:02 dtrainor I'm using all default values for this downstream queens deployment. The flavors show a minimum requirement of 4096MB, that's the only place I can find this number occurring.
18:50:07 dansmith etp: 10 is small enough that you're likely to not get back any hosts in the aggregate you're looking for yeah
18:50:27 dansmith etp: unless you're enabling a request filter in nova that helps to ensure that you do
18:50:38 dansmith which is currently az or tenant filtering
18:53:58 TheJulia Hopefully someone can help jog my memory... A long time ago I remember there was a discussion of how nova represents a baremetal node being torn down. I believe the state then and now is that the instance is generally "ACTIVE" until the node is actually deleted, and I think the motivation behind that was resource accounting wise. Does anyone remember this discussion (it would have been 2+ years ago I think)
18:57:42 dansmith TheJulia: the instance goes away immediately, AFAIK, as that's the way delete is supposed to work, but nova tries to make the node not schedule-able until the cleaning is done
18:58:06 mriedem dtrainor: you shouldn't need the RamFilter in queens
18:58:13 TheJulia I've got a QE person reporting that they are seeing it sit in "ACTIVE" until cleaning is over
18:58:17 dansmith the strategy we proposed for doing this betterly was to set the reserved amount of resource equal to the total for a node so that it appeared to not have any room until after it's cleaning
18:58:25 mriedem dtrainor: the placement service does the filtering on MEMORY_MB
18:58:30 TheJulia and I thought there was some reason for that, just struggling to decompress those memories
18:58:37 dansmith TheJulia: okay I could be wrong, but I don't think that's what is supposed to happen
18:59:33 etp dansmith: tnx, we have only one az atm and aggregate should be for all tenants so I think request filter doesn't help here, I'll revert config back to default
18:59:39 mriedem dtrainor: you're scheduling to baremetal nodes there?
19:00:10 mriedem dtrainor: if those are baremetal nodes, you should read up on https://docs.openstack.org/ironic/latest/install/configure-nova-flavors.html
19:01:43 mriedem dtrainor: i guess the Core/Ram/Disk filters weren't deprecated until stein but they should have been since pike i think https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#ramfilter
19:01:55 dansmith TheJulia: self.ironicclient.call("node.set_provision_state", node.uuid,
19:01:56 dansmith "deleted")
19:02:09 dansmith TheJulia: does that take a long time?
19:02:26 TheJulia dansmith: that can take hours upon hours depending on the hardware the operator configuration
19:02:40 dansmith TheJulia: yeah, looks like that has a poll loop after it
19:02:43 TheJulia dansmith: to be precise, that should return immediately
19:02:48 TheJulia but the background it runs for a long time
19:02:50 dtrainor sorry, i'm back. mriedem, I'm familiar with that doc, yep. I'm familiar with how it's scheduled and can even make this deployment work on different platforms, e.g. on top of different hardware. that's what leaves me puzzled.

Earlier   Later