| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-10 | |||
| 20:12:15 | dansmith | it does direct-to-the-database things, which is why it is very tightly coupled to the server code | |
| 20:12:21 | kfox1111 | ah. ok. | |
| 20:12:33 | kfox1111 | one other quiestion... | |
| 20:12:40 | kfox1111 | in the docs, I found this: | |
| 20:12:43 | kfox1111 | nova-manage cell_v2 discover_hosts | |
| 20:12:54 | kfox1111 | but not much on how you decide which cell gets which hosts. | |
| 20:13:00 | mriedem | sec | |
| 20:13:17 | mriedem | https://docs.openstack.org/developer/nova/man/nova-manage.html#nova-cells-v2 | |
| 20:13:24 | mriedem | you might be looking at old docs, ^ is much more detailed | |
| 20:13:34 | mriedem | also https://docs.openstack.org/developer/nova/cells.html | |
| 20:13:39 | mriedem | is the super detailed version | |
| 20:13:40 | kfox1111 | ah. nice. thank you. :) | |
| 20:13:51 | mriedem | to explain what cells v1 and cells v2 is | |
| 20:13:55 | mriedem | and the commands for cells v2 setup | |
| 20:14:02 | mriedem | and scenarios for installing or upgrading to cells v2 | |
| 20:14:31 | mriedem | by default, every nova deployment starting in ocata is a single-cell cells v2 deployment | |
| 20:14:47 | mriedem | we don't support multiple cells v2 cells in ocata | |
| 20:14:53 | mriedem | working on that for pike | |
| 20:15:09 | mriedem | if dansmith would stop answering questions in channel and fix his series :P | |
| 20:15:12 | kfox1111 | ah. ok. thats good to know too. :) | |
| 20:15:23 | kfox1111 | thanks for the info. | |
| 20:15:34 | mriedem | dansmith is also presenting on all this at the forum if you'll be there | |
| 20:15:37 | dansmith | mriedem: um excuse me, but there are four in the gate right now | |
| 20:15:39 | mriedem | plus a forum session | |
| 20:16:09 | mriedem | not this motherscratcher https://review.openstack.org/#/c/442736/ | |
| 20:16:14 | kfox1111 | oh. one more. is there a way to list out the cells and what hosts are in what cells? | |
| 20:16:26 | kfox1111 | just to ensure all the compute nodes are registered that I'm expecting for debuggging. | |
| 20:16:33 | dansmith | kfox1111: seriously.. look at the docs | |
| 20:17:05 | mriedem | there is a nova-manage cells_v2 list_cells command | |
| 20:17:16 | mriedem | don't think we have one to list the host mappings per cell yet | |
| 20:17:17 | kfox1111 | dansmith: it may be obvious to you, but I'm not seeing it. | |
| 20:17:29 | kfox1111 | ah. thats why I didn't see it. thanks. | |
| 20:17:30 | mriedem | https://docs.openstack.org/developer/nova/man/nova-manage.html#nova-cells-v2 | |
| 20:17:35 | mriedem | nova-manage cell_v2 list_cells | |
| 20:17:39 | dansmith | mriedem: discover_hosts is idempotent and --verbose will list the hosts for each | |
| 20:17:58 | kfox1111 | so, I just gotta run discover_hosts if I'm unsure if all are bound. | |
| 20:18:12 | mriedem | dansmith: that's not mentioned in the man page for discover_hosts | |
| 20:18:13 | mriedem | but ok | |
| 20:18:20 | bauzas | call me dumb, but I can't find where in the RT code instance.claim() is defined as a contextmanager?! The Claim object itself is not having __enter__ and __exit__ | |
| 20:18:31 | mriedem | we could expand list_cells to show hosts in a given cell | |
| 20:18:34 | dansmith | kfox1111: you can only have one cell with hosts right now, so .. either they're mapped there or they're not | |
| 20:18:45 | mriedem | bauzas: the parent noopclaim class | |
| 20:18:52 | bauzas | oh shit, nvm | |
| 20:18:59 | bauzas | mriedem: yup, just missed that | |
| 20:19:04 | kfox1111 | dansmith: yeah. but I'm just trying to overify if thats the case or not. | |
| 20:19:15 | kfox1111 | there are two states there. :) | |
| 20:19:20 | dansmith | kfox1111: have you created other cell databases? | |
| 20:19:20 | bauzas | grmblbl, it's late | |
| 20:19:36 | dansmith | kfox1111: if so, then you messed up anyway and if not, then no hosts are registered in a nonexistent database | |
| 20:19:47 | kfox1111 | dansmith: yeah. I have all the code for creation in. it works most of the time. but if a race condition happans and the cell is created before the compute, | |
| 20:19:47 | mriedem | kfox1111: dansmith: to be clear, we can expand list_cells for more info, we talked about that in ocata i think, i think it'd be useful | |
| 20:19:57 | kfox1111 | I wana ensure that all the nodes madie it into the cell. | |
| 20:20:08 | kfox1111 | just running discover_hosts again should fix it. | |
| 20:20:19 | kfox1111 | but was looking for more info to look for the condition. | |
| 20:20:25 | mriedem | reporting clis will be nice for people rolling into this that are new to it | |
| 20:20:25 | kfox1111 | but that doesn't seem like its there yet. thats fine. | |
| 20:20:38 | mriedem | "it" == cells v2 | |
| 20:20:46 | kfox1111 | just rerunning discover_hosts will be an ok workournd for now. | |
| 20:21:10 | kfox1111 | yeah. I'm comming from many years of nova deployments. the cell v2 stuff is all very new to me. | |
| 20:21:21 | dansmith | discovering and listing hosts per cell is nearly the same operation | |
| 20:21:34 | dansmith | there's not much point in listing alone | |
| 20:21:37 | kfox1111 | yeah. but one makes changes, the other does not. | |
| 20:21:45 | kfox1111 | yes, there is. | |
| 20:21:59 | mriedem | the point is i'm afraid of unexpected changes | |
| 20:22:01 | kfox1111 | one tells you why something migh have failed in the past. | |
| 20:22:06 | mriedem | so just read-only type commands i'm happy with | |
| 20:22:07 | kfox1111 | the other fixes an issue. | |
| 20:22:33 | dansmith | kfox1111: discover_hosts differentiates between hosts that are existing and added, | |
| 20:22:34 | dansmith | but that's fine | |
| 20:22:38 | kfox1111 | those are potentially different operations to an operator trying to understand and fix their system. | |
| 20:22:49 | dansmith | for people with thousands of hosts, the list is not super pointful, IMHO | |
| 20:23:05 | kfox1111 | I'm only in the hundereds. | |
| 20:23:07 | kfox1111 | ;) | |
| 20:25:47 | kfox1111 | anyway. as an op, its not very intuitive to go looking for "how do I find out what hosts are bound to what cell" and expect "bind hosts to cell" to be the right answer. just fyi. might be a good faq item at least. | |
| 20:26:51 | dansmith | if you want to list hosts in a cell, | |
| 20:27:01 | dansmith | you would use the regular host list thing pointing at a cell config file | |
| 20:27:11 | dansmith | which we can automate from the top level for sure, | |
| 20:27:43 | dansmith | but it just seems not that useful to me to get 10k hosts in a list to find if host N is in cell M | |
| 20:27:46 | dansmith | but clearly it is | |
| 20:27:59 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Document and provide useful error message for volume-backed backup https://review.openstack.org/452970 | |
| 20:27:59 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-ref: move createBackup to server-actions https://review.openstack.org/452971 | |
| 20:28:00 | openstackgerrit | Matt Riedemann proposed openstack/nova master: 2.43: Remove Location header from createImage and createBackup responses https://review.openstack.org/455443 | |
| 20:28:50 | mriedem | dansmith: you mean nova-manage host list right? | |
| 20:28:53 | mriedem | pointing at the cell config? | |
| 20:28:58 | dansmith | yar | |
| 20:29:00 | mriedem | ok | |
| 20:29:08 | mriedem | maybe i'll start a FAQs section to the cells page | |
| 20:29:11 | mriedem | i thought about that at one point | |
| 20:29:15 | mriedem | same for placement | |
| 20:29:32 | mriedem | because there was a couple of weeks around ocata rc when i felt like we were answering the same questions over and over | |
| 20:30:26 | mriedem | oh snap today is supposed to be mitaka eol | |
| 20:36:17 | bauzas | mriedem: dansmith: cdent: edleafe: possibly a misunderstanding of me, but I thought we finally ended up saying that we would use the RequestSpec object as the conveyor for the RPC bus ? | |
| 20:36:46 | cdent | bauzas: mriedem wants it over rpc but not in the requestspec object | |
| 20:36:48 | bauzas | mriedem: dansmith: cdent: edleafe: but etherpad tells me we agreed it would be a separate RPC arg | |
| 20:37:13 | bauzas | okay, tbh, I'm not opiniated at all | |
| 20:37:38 | bauzas | cdent: anyway, seems an implementation detail to me (well, to a certain point since it requires RPC version bumps) | |
| 20:38:48 | dansmith | bauzas: the etherpad is right | |
| 20:39:33 | bauzas | roger. | |
| 20:41:32 | mriedem | -2 to stuffing the allocation list into the requestspec | |
| 20:41:40 | mriedem | the request spec is ALREADY an arg on the rpc call | |