Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-31
15:01:54 bauzas acceptable
15:04:35 gibi mriedem: fyi, this is can be merged now: https://review.openstack.org/#/c/533608 as the ocata backport has been merged as well
15:05:50 mriedem gibi: yeah i thought that was already done
15:06:48 efried Thanks gibi!
15:21:15 gibi ralonsoh__: hi! Do you plan to propose https://review.openstack.org/#/c/502306/14/specs/queens/approved/bandwidth-resource-provider.rst to rocky?
15:26:12 tssurya melwitt : I just wanted to confirm something, since quota calculation uses scatter_gather_all_cells, the whole process is a parallel process right when it comes to querying each cell DB ?
15:26:40 dansmith tssurya: yeah
15:26:43 tssurya melwitt : so we don't have to worry much about the performance in Pike with regards to this aspect
15:26:52 tssurya dansmith : thanks
15:29:27 tssurya dansmith : also regarding the status of our solution for calculating quotas when a cell is down, we realized that in Pike no vm creation would take place at all if any of the cell is down since it would raise exception at this point : https://github.com/openstack/nova/blob/cb1e763df76e21b5382872c89dd169ecb152c420/nova/api/openstack/compute/servers.py#L494
15:29:41 dansmith bauzas: can you please look at this? https://review.openstack.org/#/c/532924/
15:30:35 dansmith tssurya: ah yeah, we need to fix that
15:31:00 dansmith tssurya: I think we can pretty much remove that check now since the version we're checking for should be out of the support window
15:31:32 tssurya dansmith : so I will submit a POC for this and nova list, but we can discuss more of this in the ptg after we find a solution to deal with differentiating deleted instances from living ones
15:31:48 dansmith in the future when we need to do that sort of thing we'll need to decide what the plan is if a cell doesn't come back with that answer
15:32:22 dansmith tssurya: I really don't think we're going to find such a solution without replicating more data up top, but.. yeah, sounds good
15:33:34 tssurya because even for the quotas solution (which was to allow vm creation if a project doesn't have any instances in the cell that is down) it would change to not allowing vm creation if there are any instance_mappings in that cell :(
15:33:51 dansmith yeah
15:34:18 dansmith that might not be a problem depending on how you distributed people (i.e. keep tenants to a subset of cells), but yeah fair enough
15:34:21 ralonsoh__ gibi, sean-k-mooney: I no longer work in OpenStack for the moment. Please, ask sean-k-mooney about the plans to propose it for the next release cycle
15:34:24 tssurya dansmith : how I found this - # TODO(melwitt): Counting across cells for instances means we will miss counting resources if a cell is down. In the future, we should query placement for cores/ram and InstanceMappings for instances (once we are deleting InstanceMappings when we delete instances).
15:34:37 tssurya however*
15:35:11 tssurya so hopes up for the last part "once we are deleting InstanceMappings when we delete instances"
15:35:24 dansmith tssurya: yeah so we could try to leverage placement here in some way, but it would be a rather inefficient merge of "does placement know about any of these instance mappings"
15:35:25 sean-k-mooney ralonsoh__: propose which?
15:35:45 ralonsoh__ sean-k-mooney, gibi: https://review.openstack.org/#/c/502306/14/specs/queens/approved/bandwidth-resource-provider.rst
15:35:46 dansmith tssurya: we can't delete instancemappings when we delete instances
15:36:46 tssurya dansmith: yea probably, but is there a way we could included a status for the mappings ?
15:37:19 dansmith tssurya: that's what I meant about "replicating more data"
15:37:25 dansmith we said we weren't going to do that, so we'd have to discuss whether or not we're going to violate that design point or not
15:37:49 tssurya dansmith: hmm okay,
15:38:03 dansmith tssurya: maybe we could do something like delete the reqspec (if we don't already) when we delete an instance, and then not include instances with no requestspec that do have a mapping?
15:38:39 dansmith tssurya: I think bauzas was going to clean that up (delete reqspec on delete) but not sure if he ever did
15:38:41 tssurya dansmith : we don't delete request_spec as of now,
15:38:50 tssurya but yes that would also work
15:38:55 gibi ralonsoh__: thanks for the info
15:38:57 dansmith that would be better IMHO
15:39:03 tssurya if we could delete specs when we delete the instances
15:39:14 gibi sean-k-mooney: do you plan to re-propose https://review.openstack.org/#/c/502306/14/specs/queens/approved/bandwidth-resource-provider.rst ?
15:39:48 tssurya dansmith : no he didn't because we did something similar to instance_mappings clean up during archival
15:40:07 tssurya so now we purge mappings and specs in the same way
15:40:30 dansmith yeah, okay, well, I think it'd make sense to do it that way, but we can discuss at the PTG
15:40:41 tssurya dansmith : yes sounds good :)
15:42:36 cdent bauzas: you happy to put your +W back on https://review.openstack.org/#/c/519462/ now that gate is a bit happier?
15:43:01 bauzas cdent: it requires a manual rebase
15:43:12 bauzas there is a merge conflict
15:44:26 cfriesen johnthetubaguy: you around?
15:46:11 openstackgerrit Chris Dent proposed openstack/nova master: Log options at debug when starting API services under wsgi https://review.openstack.org/519462
15:46:18 cdent bauzas: ^
15:47:48 bauzas cdent: fast-approved
15:47:57 cdent thanks
15:48:09 bauzas thanks, that's not that I was lazy, but I have other things on the gas
15:48:52 mriedem dansmith: tssurya: https://review.openstack.org/#/c/391060/
15:48:57 bauzas dansmith: yup, I did
15:49:43 bauzas but it requires some cleanup
15:49:44 dansmith bauzas: did what?
15:49:51 mriedem that patch i just linked
15:50:15 bauzas yup, that
15:50:15 dansmith bauzas: I've been pinging you for two weeks to look at this, can you please look at it? https://review.openstack.org/#/c/532924/
15:50:23 bauzas dansmith: on it
15:50:46 bauzas dansmith: it was on an open tab
15:51:00 dansmith bauzas: okay well, never heard a peep so I didn't know
15:51:08 bauzas my bad
15:53:16 tssurya mriedem : thanks, so that means we do not agree to deleting the specs when deleting the instances right ?
15:53:43 hrw https://imgur.com/a/3b22r - graphical console on arm64 out of box (with https://review.openstack.org/#/c/538003/ applied) mriedem
15:55:34 mriedem tssurya: well, i don't agree with the assertion that if the instance fails to be deleted, losing the request spec is ok
15:55:49 mriedem because we have fallback code all over the place from the newton transition to reqspecs for old instances
15:56:05 mriedem as i said in that patch, a lot of that fallback code is best effort but shouldn't really be relied upon
15:56:11 bauzas maciejjozefczyk: dansmith: there could be a flip logic where some cloud could have computes nova.confs with allocation ratios equal to 0.0
15:56:45 bauzas maciejjozefczyk: dansmith: in that case, when upgrading to Queens, I guess we should still make sure to correctly normalize the ratios the other way, nope ?
15:57:11 maciejjozefczyk bauzas: hey
15:57:23 tssurya mriedem : right, makes sense
15:58:26 melwitt mriedem: ack
16:03:05 mriedem hrw: left some comments
16:03:23 maciejjozefczyk bauzas: I dont know, Its said that in Newton it should be moved to default values, and its Queens now.
16:03:53 bauzas maciejjozefczyk: yup, I'm just thinking about flipping the problem
16:03:53 hrw mriedem: thx
16:04:20 bauzas maciejjozefczyk: say we have a pike compute, and a queens cloud
16:04:49 bauzas maciejjozefczyk: the old pike compute would store in its DB the unnormalized ratios, ie. 0.0, right?
16:04:53 hrw mriedem: will reply
16:05:04 maciejjozefczyk bauzas: right
16:05:08 bauzas maciejjozefczyk: in that case, what works now that we normalize those ratios by the object layer
16:05:34 bauzas maciejjozefczyk: if we cut that logic and just takes what we get from the DB, then we need to be careful about those pike nodes
16:06:15 bauzas maciejjozefczyk: I'm trying to evaluate hard https://review.openstack.org/#/c/532924/6/nova/objects/compute_node.py@185 and its impact with a pike node
16:06:56 maciejjozefczyk bauzas: you're right
16:07:14 openstackgerrit Matt Riedemann proposed openstack/nova master: Mention required traits in the flavors user docs https://review.openstack.org/539300
16:07:14 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix nits in support traits changes https://review.openstack.org/537351
16:07:15 openstackgerrit Matt Riedemann proposed openstack/nova master: Add functional tests for traits-based scheduling https://review.openstack.org/539310
16:07:19 mriedem efried: fixed that comment ^
16:07:20 mriedem thanks
16:07:35 mriedem efried: also, your two irc nicks in here is driving me nuts
16:07:52 cfriesen design question...now that we have objects.Service.get_minimum_version(), does the RPC version really serve any purpose anymore?
16:08:09 efried mriedem: sorry, was keeping the old one around for logs. Guess there's no reason to keep it logged in, tho.
16:08:21 bauzas maciejjozefczyk: wait, I'm not saying we have a problem yet
16:12:39 maciejjozefczyk bauzas: In this particular case when pike compute has in db 0.0 _from_db_object() method will change 0.0 to default value from oslo.config
16:12:53 maciejjozefczyk L185 so the effect would be the same
16:13:34 bauzas maciejjozefczyk: right, I just left a comment
16:14:18 bauzas maciejjozefczyk: if people started to touch their nova.conf, whatever it's Pike or Queens, we take that conf value
16:14:19 maciejjozefczyk bauzas: The only thing for now is the topic on openstack-dev: What about aggregation groups and its metadatas?
16:14:19 openstackgerrit Claudiu Belu proposed openstack/nova master: hyper-v: Logs tips on PortBindingFailed https://review.openstack.org/539584

Earlier   Later