| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-31 | |||
| 14:56:45 | mriedem | under doc/source/cli | |
| 14:57:00 | mriedem | it's just a restructured text file | |
| 14:58:01 | ameeda | great , what I should write there ? | |
| 14:58:11 | mriedem | ameeda: dude | |
| 14:58:23 | mriedem | i'm not going to write the patch fo you | |
| 14:58:24 | mriedem | *for | |
| 14:58:29 | gibi | jaypipes, mriedem: the first patch in efried's series needs a second core https://review.openstack.org/#/c/521098 the rest is +Wd | |
| 14:58:45 | ameeda | mriedem: sorry :$ | |
| 14:58:46 | mriedem | see how existing entries document CLI options, take a stab at doing similar for the missing option, and then post it for review and get feedback | |
| 14:58:49 | ameeda | Thank you !! | |
| 14:59:12 | mriedem | gibi: if it was a rebase you can just fast approve | |
| 14:59:58 | gibi | mriedem: it was a manual rebase, but yeah, I can fast approve it, sure. | |
| 15:00:29 | mriedem | we need some cores to look at this too https://review.openstack.org/#/c/537351/ | |
| 15:00:35 | mriedem | fixes nits in alex's traits series | |
| 15:01:26 | bauzas | mriedem: are we considering https://review.openstack.org/#/c/537351/4 not impact by FF ? | |
| 15:01:29 | bauzas | impacted* | |
| 15:01:49 | mriedem | bauzas: it's docs and nit cleanups | |
| 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 | 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:15 | bauzas | yup, that | |
| 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 | hrw | mriedem: thx | |
| 16:03:53 | bauzas | maciejjozefczyk: yup, I'm just thinking about flipping the problem | |
| 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 | |