Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-12-17
15:08:45 brandor5 sean-k-mooney: that one I knew about, sorry I should have been more clear... print list of hypervisors with the # of instacnes they have running on them
15:09:00 sean-k-mooney brandor5:actully you will need to add --all-projects "openstack server list --all-projects --host <hostname>"
15:09:09 mriedem brandor5: https://docs.openstack.org/python-novaclient/latest/cli/nova.html#nova-hypervisor-stats
15:09:31 sean-k-mooney oh yes there is ^
15:09:59 sean-k-mooney you can run "openstack hypervisor stats show"
15:10:02 mriedem that doesn't break it down by vm's per hypervisor
15:10:19 brandor5 ha, we're getting close... is it possible to get it broken out?
15:10:28 mriedem is it possible for you to just run two commands?
15:10:39 sean-k-mooney mriedem: it has a running instace count right
15:10:55 brandor5 defintely, just trying to make sure I'm using the right commands... my google-fu has failed me
15:12:00 mriedem hypervisors-list dumps a list of all hypervisors,
15:12:05 mriedem and for each one, there is a 'running_vms' entry
15:12:21 mriedem which is the number of vms on each hypervisor - looking at the code, they don't have to be 'running'
15:12:28 brandor5 that would work
15:12:35 mriedem https://developer.openstack.org/api-ref/compute/?expanded=list-hypervisors-details-detail#list-hypervisors-details
15:13:16 sean-k-mooney isnt that waht https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/hypervisor-stats.html#hypervisor-stats-show does
15:13:29 sean-k-mooney the docs are terible for that command by the way
15:13:52 mriedem https://developer.openstack.org/api-ref/compute/#show-hypervisor-statistics
15:14:01 sean-k-mooney i taught it printed a table with all hyperviros but i dont have a running openstack to test
15:14:31 mriedem report an osc docs bug to provide more details and/or an example output
15:14:43 mriedem i wish the osc docs have example output in all of the commands
15:14:48 spatel I always having issue to find list of vms running on host machine so this is what i did to get work around :)
15:15:05 spatel This is the command... give me what i need :)
15:15:07 spatel mysql -h 172.28.1.183 -u nova --password=1bfa5ea99241c7195ba697f nova -e "select hostname,vm_state,node,availability_zone,vcpus,memory_mb,root_gb from instances WHERE (vm_state='active' OR vm_state='stopped');"
15:15:08 sean-k-mooney ya i should really go do that..
15:15:47 spatel that mysql command it much easier than running API call :)
15:16:12 sean-k-mooney mriedem: brandor5 we have an example here https://docs.openstack.org/nova/pike/admin/common/nova-show-usage-statistics-for-hosts-instances.html
15:16:36 sean-k-mooney mriedem: brandor5 never mind we dont
15:16:51 spatel brandor5: you should read this too https://www.sebastien-han.fr/blog/2012/12/20/where-does-my-instance-run/
15:17:04 brandor5 spatel: thanks, will do
15:17:39 spatel sean-k-mooney: why does nova-manage command not available these days?
15:18:11 spatel i have google it and didn't find clue to install it
15:18:46 mriedem spatel: you mean this? https://docs.openstack.org/nova/latest/cli/
15:19:00 openstack Launchpad bug 1767315 in OpenStack Compute (nova) ""openstack hypervisor stats show" shows wrong memory information" [Undecided,Confirmed] - Assigned to jichenjc (jichenjc)
15:19:00 sean-k-mooney actully this bug has an example https://bugs.launchpad.net/nova/+bug/1767315
15:19:01 gibi mriedem: FYI I sneaked in one more patch to the bandwidth runway slot (handling detach interface) and added a note that the rest of the patches in the series are part of a not completed subfeature
15:19:12 sean-k-mooney mriedem: also i think i should close that bug ^
15:20:15 spatel sean-k-mooney: yes but i didn't find any packet which provide nova-manager command
15:20:52 sean-k-mooney spatel: nova-manage should generally not be used unless you are upgrading
15:21:01 sean-k-mooney there are a few maintance ops
15:21:05 mriedem or installing...
15:21:20 mriedem spatel: where you get the cli is up to the packages/distro you're using
15:21:22 spatel unless is upgrading?
15:21:23 mriedem that's not really a nova question
15:21:44 sean-k-mooney well yes installing too but it should not be used for debuging
15:22:26 sean-k-mooney spatel: oh sorry i taught we were still taking about vm count
15:22:35 spatel yes.. its not nova question but i was just wonder all documents pointing to use nova-manager and i didn't find that command anywhere or any openstack deployment..
15:22:58 sean-k-mooney spatel: it should be installed when you install nova
15:23:58 sean-k-mooney spatel: its a console-script that is generated by setuptools/pbr https://github.com/openstack/nova/blob/master/setup.cfg#L66
15:24:04 spatel its no there.. i have installed all nova utility tools but didn't find that tool
15:24:31 sean-k-mooney spatel: on what distro?
15:24:37 spatel CentOS 7.5
15:24:51 spatel Installation method is Openstack-ansible
15:25:18 sean-k-mooney openstack ansible installs form source right?
15:25:28 sean-k-mooney or are you using nova form the distro rpms
15:25:29 spatel yes they use source
15:25:48 sean-k-mooney then when osa did pip install nova it should have been genreated
15:25:50 spatel openstack-ansible use source from git repo, they don't use RPM
15:26:09 sean-k-mooney spatel: without it they would not have been able to create the nova db and could not run the db migrations
15:26:17 spatel Let me ask openstack-ansible channel and see if they offer any suggestion
15:27:05 odyssey4me spatel nova-manage is in the nova venv, as with all the openstack packages we build
15:27:21 spatel there you are!!
15:27:26 odyssey4me so it'll be /openstack/venvs/nova-<tag>/bin/nova-manage ...
15:28:24 spatel odyssey4me: so that command won't be available in utility container right?
15:28:39 odyssey4me spatel nope, it'll only be on hosts where the nova service is installed
15:29:06 spatel odyssey4me: thank for clarification
15:29:15 odyssey4me it requires database access, so best is to use it from the control plane hosts - compute may not have the db connection string in nova.conf
15:29:20 mriedem gibi: in reading the spec, it looks like we need to handle cleaning up bw allocations when a port is detached - do you have code for that up yet?
15:29:43 mriedem gibi: because it seems we'd want that code in place first, which would be a noop until the server create code lands, right?
15:29:45 gibi mriedem: that is the patch I've just sneak into the list
15:29:54 odyssey4me spatel no problem - happy to assist :)
15:30:07 gibi mriedem: hm regarding the ordering you are right
15:30:54 mriedem also, why aren't the "reject ports with qos" patches first in the series?
15:30:58 gibi mriedem: so this https://review.openstack.org/#/c/622421/6 needs to be earlier in the stack
15:31:14 mriedem i'm just trying to think of the order in which this rolls out,
15:31:34 mriedem where the groundwork is done first so that when the scheduler bits are turned "on" the rest of it is in place
15:31:49 mriedem sort of like how we handle adding new api features which require changes to compute
15:31:53 mriedem we start from the bottom up
15:33:54 gibi mriedem: the API bit here is the neturon API extension that adds the resource_request field to the port
15:33:59 mriedem as of https://review.openstack.org/#/c/567268/ will we be allocating bw resources during server create?
15:34:09 gibi mriedem: if that field is not there then nothing happens in nova
15:34:34 mriedem this right? https://review.openstack.org/#/c/567268/36/nova/network/neutronv2/api.py
15:35:05 openstackgerrit Jack Ding proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.openstack.org/621646
15:36:36 mriedem yeah and that's used here https://review.openstack.org/#/c/567268/36/nova/scheduler/utils.py
15:36:38 gibi mriedem: yes. and that data ends up in the RequestSpec here https://review.openstack.org/#/c/567268/36/nova/compute/api.py@884 which leads to bandwidth allocations
15:36:44 mriedem to build the resource request to allocation candidates
15:36:59 gibi mriedem: yes
15:37:41 mriedem so if we were to merge the first patch in the series, we'd be allocating these things on server create, but not handling them for moves, or port detach
15:38:20 yan0s if I want to have the same set of flavors in two Regions
15:38:30 mriedem gibi: i kind of see two options, neither of which is probably great for you:
15:38:36 yan0s do I need to duplicate them in both Regions?
15:38:52 yan0s or is there another solution for them to exist in just one place?
15:38:53 mriedem 1. re-order the series so the bottom-up changes (nova-compute) happens first and we build to the top where the api transfers the port request to the scheduler
15:39:31 mriedem 2. we don't merge the bottom changes in the series until we're happy with the whole thing, at which point we approve it all and hope it merges in the same day/week
15:40:20 gibi mriedem: there is one catch. Unitl https://review.openstack.org/#/c/590363/27/neutron/services/qos/qos_plugin.py@128 merges there is no resource_request field in the neutron ports. And after that patch merges there is still a manual step to enable the neutron port extension to turn on the whole feature
15:40:22 mriedem yan0s: does nova-api span regions?
15:41:07 mriedem gibi: is there a nova change which depends on that neutron change?
15:41:20 yan0s I'm still just in theory about it
15:41:21 mriedem i would think https://review.openstack.org/#/c/567268/ should depend on https://review.openstack.org/#/c/590363/
15:41:39 gibi mriedem: no direct dependency as if there is no code that fails if the resource_request is missing

Earlier   Later