| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-10 | |||
| 20:06:44 | kfox1111 | pip install python-novaclient? | |
| 20:07:20 | kfox1111 | (novatest)[kfox@mantis ~]$ pip install python-novaclient | |
| 20:07:28 | mriedem | kfox1111: no | |
| 20:07:30 | dansmith | kfox1111: no, he said nova | |
| 20:07:31 | mriedem | "nova" | |
| 20:07:34 | mriedem | just nova | |
| 20:07:51 | mriedem | as it always has been and always will be (until it no longer is) | |
| 20:08:06 | kfox1111 | pip install nova | |
| 20:08:23 | mriedem | there is no nova pip on pypi | |
| 20:08:26 | mriedem | if that's the confusing part | |
| 20:08:29 | mriedem | git clone nova | |
| 20:08:30 | mriedem | cd nova | |
| 20:08:33 | mriedem | pip install . | |
| 20:08:34 | mriedem | ? | |
| 20:08:39 | kfox1111 | pip install python-novaclient does work. | |
| 20:08:50 | kfox1111 | there is something out on pypi there. | |
| 20:08:50 | mriedem | you've never been able to get nova from pypi | |
| 20:08:56 | dansmith | kfox1111: python-novaclient is not nova | |
| 20:09:01 | kfox1111 | ah. | |
| 20:09:02 | kfox1111 | ok. | |
| 20:09:51 | kfox1111 | heh. sure looks like nova to me... | |
| 20:10:18 | kfox1111 | (novatest)[kfox@mantis ~]$ ~/venvs/novatest/bin/nova --help | grep Command | |
| 20:10:22 | kfox1111 | Command-line interface to the OpenStack Nova API. | |
| 20:10:42 | dansmith | the primary binary that novaclient installs is called nova | |
| 20:10:51 | dansmith | that is distinct from the server thing called nova | |
| 20:11:02 | kfox1111 | yeah, totally understood. | |
| 20:11:11 | kfox1111 | I'm just looking for the nova-manage tool. | |
| 20:11:19 | kfox1111 | is that only bundled with the server? | |
| 20:11:21 | dansmith | YES | |
| 20:11:25 | kfox1111 | ah. ok. | |
| 20:11:47 | kfox1111 | I was confused as it does clienty things. but I guess maybe it depends on talking to the server directly. | |
| 20:11:56 | dansmith | it does no clienty things | |
| 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, | |