Earlier  
Posted Nick Remark
#openstack-nova - 2018-12-17
14:21:44 spatel application*
14:21:44 sean-k-mooney not you will have to set all the default too
14:21:49 sean-k-mooney *note
14:22:21 sean-k-mooney we use pythongs loggin framework so you can filter logs by module
14:22:34 spatel so i have to set all default list in nova.conf including nova.pci.utils=ERROR right?
14:23:21 sean-k-mooney i think so that said i have never tried to limit logs from nova its self but i think that will work
14:23:36 spatel i will give it a try on lab :)
14:23:44 spatel thanks for the tip :)
14:24:11 openstack Launchpad bug 1807251 in OpenStack Dashboard (Horizon) "Horizon Overview summary showing wrong numbers " [Undecided,Incomplete]
14:24:11 spatel sean-k-mooney: check this out https://bugs.launchpad.net/horizon/+bug/1807251
14:26:44 openstack Launchpad bug 1808738 in OpenStack Compute (nova) "No net device was found for VF" [Undecided,New]
14:26:44 spatel sean-k-mooney: you can close this issue with your comments https://bugs.launchpad.net/nova/+bug/1808738
14:27:29 openstackgerrit Jack Ding proposed openstack/nova master: Improve libvirt image and snapshot handling https://review.openstack.org/616692
14:28:07 sean-k-mooney im triaging it currently as low as the wraning is noisy as you said and does not explain why it happens.
14:28:26 sean-k-mooney but it can fill your disk which is annoying.
14:29:17 spatel sean-k-mooney: it would be good if adjust code to understand behavior and don't sent WARNING
14:29:24 openstackgerrit Jack Ding proposed openstack/nova master: Correct instance port binding for rebuilds/reboots https://review.openstack.org/603844
14:31:27 sean-k-mooney spatel: i was thinking of bumping it down to debug
14:31:54 sean-k-mooney spatel: ther freatre that need the netdev to exist but none that are critical
14:32:25 sean-k-mooney the main one being nic feature based schduling which is only half implemnted
14:32:46 sean-k-mooney so its not very usfull currently since it does not work
14:33:59 sean-k-mooney you may also be unable to use vnic_type=macvtap
14:37:11 mriedem gibi: we have a runways queue spot open https://etherpad.openstack.org/p/nova-runways-stein but i'm not sure if we should put your 2nd mention of https://blueprints.launchpad.net/nova/+spec/bandwidth-resource-provider in there or just assume it will be covered by the existing entry?
14:37:23 mriedem they are all in a series so i'm not sure why you had that in the etherpad twice
14:49:17 lyarwood mriedem: https://review.openstack.org/#/c/579004/6/nova/virt/block_device.py - I'm trying to follow up on your comments here, quick question if you have a second. In the case where the BDM doesn't have an attachment_id can we just create one or do we still need to use the v2 APIs?
14:50:23 lyarwood cinderv2 is deprecated but I'm not sure if the intention here was to always assume that we had access to cinderv3 when updating the connection_info here or not.
14:50:47 mriedem cinder v3.0 is backward compatible with v2 apis
14:51:07 mriedem so if we have a legacy attachment (no attachment_id in the bdm) we can use the old initialize_connection flow
14:52:08 mriedem converting legacy attachments to "new style" attachments in refresh_connection_info is an interesting thought,
14:52:18 mriedem but since this is something that needs to be backported, i would avoid that in this change
14:53:09 mriedem we definitely do need to get code in to start migrating the old style attachments ( https://review.openstack.org/#/c/541420/ https://review.openstack.org/#/c/549130/ )
14:53:17 mriedem otherwise we'll never be able to drop those old flows
14:54:38 lyarwood ack yeah thanks just had to remind myself about the v2/v3 compat, that somehow slipped my mind.
14:54:53 lyarwood and yeah this is getting backported if it ever lands
14:55:01 lyarwood so converting isn't helpful here yet
14:55:15 lyarwood maybe in a follow up, unless you're already doing that in the above changes
15:01:42 mriedem i'm not
15:02:10 mriedem we really have two things that need to be done: 1. bfv where nova-compute creates new volumes needs to use the new flow, that's the first patch above,
15:02:23 mriedem 2. migrate existing attachments, which can only be done on the compute b/c we need the host connector
15:02:28 mriedem that's the 2nd patch
15:02:54 mriedem it does that on n-cpu startup in a separate thread on each compute using a specialized db query to try and make this as targeted as possible, because i think that's what we talked about doing in dublin,
15:03:37 mriedem but in berlin there were suggestions of just migrating on first access of a legacy attachment, like maybe during move operations or reboot (like refresh_connection_info),
15:03:44 mriedem so idk where we are on migrating existing attachments
15:03:53 gibi mriedem: regarding runways. You are correct, everything related to bandwidth is in a single chain of commits. I just finished the second set of commits _after_ the first set was already in the queue
15:04:06 mriedem we need to have some kind of data migration though otherwise we can't ever drop the old code paths
15:04:09 gibi mriedem: and I did not want to change an item in the queue
15:04:25 spatel sean-k-mooney: sorry i was in meeting my IRC client kick me out
15:04:41 mriedem gibi: ok. fwiw when i'm looking at the runways queues i'm just going through the series until i can't go anymore
15:04:52 mriedem but maybe you're just trying to chunk these up since it's a lot of changes
15:04:55 lyarwood mriedem: yeah I'd be in favor of the original 2 tbh, otherwise who knows when the attachments would be migrated if ever.
15:05:12 openstack Launchpad bug 1808738 in OpenStack Compute (nova) "No net device was found for VF" [Low,Triaged]
15:05:12 sean-k-mooney spatel: i triaged https://bugs.launchpad.net/nova/+bug/1808738
15:05:27 gibi mriedem: I'm OK to merge the two bwm entry into a single one
15:05:35 mriedem gibi: also, ftr, one of my goals this week (before i'm out next week) is to get through your bw provider series; i'm re-reading the spec now
15:05:36 sean-k-mooney spatel: the horizon bug seams to be waiting on there responce after you followed up
15:05:37 gibi mriedem: it will be a looong one
15:05:58 mriedem gibi: ok i merged them in
15:06:03 gibi mriedem: thanks
15:06:06 mriedem gibi: are you around this week?
15:06:23 gibi mriedem: I'm available until end of Thursday
15:06:45 brandor5 hello everyone: Is there a cli command to list the # of instances on a host?
15:06:54 mriedem ok, that works. i have to get my end of year appraisal stuff done by eow too. :(
15:07:08 sean-k-mooney brandor5: yes i belive so one sec
15:07:20 gibi mriedem: on Friday I start my vacation and I will be back on 7th
15:07:24 brandor5 sean-k-mooney: cool, thank you very much
15:07:38 sean-k-mooney brandor5: openstack server list --host <hostname>
15:08:01 sean-k-mooney brandor5: you will need to be an admin i think to run that
15:08:15 mriedem brandor5: i assume you're more looking for something like this https://docs.openstack.org/python-novaclient/latest/cli/nova.html#nova-hypervisor-show
15:08:21 gibi mriedem: tomorrow I will be on and off during my afternoon but I will prioritize the bandwidth stuff if any
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?

Earlier   Later