| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-03 | |||
| 18:35:02 | exarr | Anyone around I can ask about rabbit connection problems? :-( | |
| 18:35:06 | exarr | Invalid credentials it says. So I readd the user, change password, check the transtport_url details, all seems correct. | |
| 18:35:09 | exarr | rabbit logs say "AMQPLAIN login refused: user 'openstack' - invalid credentials" | |
| 18:35:14 | exarr | Seems clear cut, huh? | |
| 18:40:55 | mriedem | exarr: are you using ocata+? | |
| 18:41:21 | mriedem | if so, you have to make sure the transport_url in your cell mappings records match | |
| 18:45:26 | openstackgerrit | Eric Berglund proposed openstack/nova master: WIP(5): PowerVM driver: ovs vif https://review.openstack.org/422512 | |
| 18:56:28 | exarr | mriedem: Ocata, yes. | |
| 18:56:35 | exarr | Just updated to latest today | |
| 18:56:57 | exarr | transport_url in the cell mapping? oooh. Let me have a look, thanks :-) | |
| 18:59:10 | mriedem | nova-manage cell_v2 list_cells | |
| 18:59:49 | mriedem | exarr: if you had to change the transport_url in config, the cell mappings are probably stale | |
| 18:59:58 | mriedem | and that's what's being used when switching rpc context at runtime | |
| 19:00:23 | mriedem | you can use the nova-manage cell_v2 update_cell command to update the transport_url for a given cell if needed | |
| 19:00:59 | mriedem | esberglu: i've left some comments in https://review.openstack.org/#/c/503061/ but you can address those in a follow up if you want, or don't, whatever | |
| 19:05:05 | openstackgerrit | Merged openstack/nova-specs master: PowerVM Driver Integration (Queens) https://review.openstack.org/503061 | |
| 19:05:17 | exarr | mriedem: hmmm. I think I have updated as you suggested. However I am still encountering the same problem. | |
| 19:07:09 | exarr | It's very much as though the credentials are simply incorrect, or rabbit is not allowing the authentication ptotocol. | |
| 19:07:15 | exarr | *protocol | |
| 19:07:37 | exarr | Can I check the cell mapping details somehow? :-/ | |
| 19:08:02 | mriedem | nova-manage cell_v2 list_cells --verbose | |
| 19:08:19 | mriedem | will dump the cells and their transport_url as they are stored in the db | |
| 19:08:36 | mriedem | keep in mind that if you update the cell's transport_url, you'll have to restart some services because those values are cached in memory | |
| 19:08:55 | exarr | mriedem: ahhh. I'll restart the machine, that should help. | |
| 19:09:01 | exarr | thanks for helping a noob. | |
| 19:10:09 | esberglu | mriedem: I can fix it quick in that review. Unless you guys don't want to have to re-review, you seem busy atm | |
| 19:10:24 | esberglu | In that case I'll take care of it later | |
| 19:10:28 | mriedem | exarr: also fyi https://docs.openstack.org/nova/pike/user/cells.html#faqs | |
| 19:10:47 | mriedem | see #2 | |
| 19:11:21 | exarr | mriedem: I could bloody kiss you. | |
| 19:11:29 | dansmith | ew, a bloody kiss? | |
| 19:11:31 | dansmith | sounds terrible. | |
| 19:11:40 | mriedem | only on goth thursdays please | |
| 19:11:47 | exarr | :-) | |
| 19:23:27 | openstackgerrit | Chris Dent proposed openstack/nova-specs master: Add spec for symmetric GET and PUT of allocations https://review.openstack.org/508164 | |
| 19:28:19 | penick | And now I have an image of mriedem dressed up as The Crow. | |
| 19:29:02 | cdent | penick: my eyes! | |
| 19:29:09 | penick | You're welcome. | |
| 19:32:27 | openstackgerrit | Chris Dent proposed openstack/nova-specs master: Add spec for symmetric GET and PUT of allocations https://review.openstack.org/508164 | |
| 19:33:30 | melwitt | I wish I knew why we didn't already have disk quota in nova | |
| 19:34:14 | penick | I thought it used to be there, but left when cinder split out | |
| 19:34:27 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] gabbi tests for shared custom resource class https://review.openstack.org/485209 | |
| 19:35:00 | melwitt | let me check the archived scrolls | |
| 19:35:34 | cdent | I’m now picturing melwitt (in the boots) sitting in dark loft with mriedem as crow “I wish I knew why…” | |
| 19:35:34 | penick | I think it was in folsom, but got 'et by the Grizzly | |
| 19:36:13 | cdent | mriedem gets up slowly from his crushed velvet chair | |
| 19:36:30 | cdent | fist clenched he walks to the broken window | |
| 19:36:34 | cdent | and shouts into the city | |
| 19:36:37 | melwitt | lol | |
| 19:37:06 | penick | I just assumed that was how his home office was configured | |
| 19:37:09 | cdent | WE STIILL DON’T KNOW | |
| 19:37:24 | sdague | I really don't think it was ever implemented | |
| 19:37:25 | penick | mriedem is an enigma wrapped in a tortilla | |
| 19:37:34 | sdague | I thought I ran this code stream a couple months ago | |
| 19:38:19 | sdague | because quota only matters for the things you have the least of | |
| 19:38:52 | melwitt | yeah, so far not finding anything in the folsom-eol tag | |
| 19:38:52 | sdague | using local disk that's just there doing nothing on computers was never the limiting factor for rax | |
| 19:38:54 | mriedem | disk quota also gets goofed up when you're talking about boot from volume | |
| 19:39:14 | sdague | mriedem: right, there is quota on volumes, because that's off the expensive storage units | |
| 19:39:25 | mriedem | is it that time of the week to link in that change again? | |
| 19:39:39 | cdent | the words dripped from mriedem’s black lips | |
| 19:39:40 | cdent | boot | |
| 19:39:41 | cdent | from | |
| 19:39:44 | cdent | volume | |
| 19:39:49 | mriedem | https://review.openstack.org/#/c/428481/ | |
| 19:40:02 | melwitt | so not only will ppl be complaining about consuming > 0 disk with BFV they'll also complain about consuming > 0 quota with BFV | |
| 19:40:28 | sdague | heh | |
| 19:40:37 | sdague | yeh, well landing that would clearly be a prereq | |
| 19:41:11 | sdague | I guess disk quota only really makes sense when your instances are all on network storage like ceph or nfs, right? | |
| 19:41:17 | melwitt | I have at least two patches that are like "the patches that shall not be named" | |
| 19:41:30 | sdague | which basically didn't work back then anyway | |
| 19:41:32 | melwitt | that one and then there's the thrice reverted bug fix one | |
| 19:43:20 | melwitt | sdague: hm, yeah ... the spec says they want to be able to bill for storage and restrict storage and currently the only way to do that is with cinder volumes | |
| 19:43:20 | mriedem | heh https://review.openstack.org/#/c/218639/ still around | |
| 19:43:31 | mriedem | when is the last time someone ran the auto-abandon script | |
| 19:44:01 | sdague | mriedem: it's been a while | |
| 19:45:34 | mriedem | several other bugs like this: create instance, attach volume, snapshot instance (the snapshot image has bdms in it now), create another instance, rebuild that 2nd instance with the snapshot image with image-defined-bdms, kablammo | |
| 19:45:52 | sdague | melwitt: right, I guess if you have flavors with a wide range of disk storage sizes, vs. coupling them to the mem/cpu sizing | |
| 19:47:05 | sdague | mriedem: so... I feel like there were enough interesting side conversations about the key_pair thing that they probably warrent a summary email, they will not capture very cleanly in 2 specs and 4 irc threads | |
| 19:47:10 | sdague | I can write that up if you like | |
| 19:47:34 | melwitt | yeah, must be. I haven't really heard this come up before, so it's probably like you said, for most ppl the limiting factor is cpu/mem | |
| 19:48:17 | mriedem | sdague: that's probably a good idea | |
| 19:53:09 | mriedem | is any of the accessIPv4 still valid? | |
| 19:53:16 | mriedem | *accessIPv4 stuff | |
| 19:53:30 | mriedem | that seems to be another one of those legacy things which we don't test but it's all over the api | |
| 19:53:38 | mriedem | like diskConfig | |
| 19:54:27 | sdague | it's user facing | |
| 19:54:32 | sdague | and user updatable | |
| 19:54:43 | sdague | sometimes it gets filled out, depending on the config | |
| 19:55:06 | sdague | if you update it yourself, we don't validate it, it's just reflected | |
| 19:55:23 | sdague | mriedem: ok, because it's been a while, a rebuild doesn't go through the scheduler, right? | |
| 19:55:47 | sdague | you get to rebuild in place, which means it's probably faster because your base image is already tehre | |
| 19:55:51 | sdague | correct? | |
| 19:56:02 | mriedem | sdague: rebuild (not evacuate) bypasses the scheduler yes | |
| 19:56:04 | sdague | I'm trying to make sure I cover all the reasons this could be interesting | |
| 20:00:28 | sdague | also, out of curiosity, because of the user scoping of keys, if you rebuild someone else's instance in the same project today, does it actually scope check the key and not add it? | |
| 20:02:16 | penick | that's an interesting question | |
| 20:03:46 | mriedem | sdague: you mean in the proposed spec? | |
| 20:03:48 | mriedem | or today? | |
| 20:04:01 | mriedem | because you can't change the key on rebuild today, hence the spec | |