Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-01
14:52:58 jaypipes kevinbenton: the habit later?
14:53:12 jaypipes kevinbenton: yup, see ya in the office.
14:53:15 kevinbenton jaypipes: ack
15:03:30 tojuvone Guess we hit the PBR 2.0.0 thingy with pep8
15:05:02 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP objects: Add attachment_id to BlockDeviceMapping https://review.openstack.org/437665
15:05:02 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP compute: Move detach logic from manager into driver BDM https://review.openstack.org/439520
15:07:20 openstackgerrit Timofey Durakov proposed openstack/python-novaclient master: Deperecate cell_name cli arg for migration-list https://review.openstack.org/439141
15:12:05 mriedem sfinucan: nevermind, we can take your change to deprecate the firewall_driver option and i'll rebase my change on top of it to change the default to the noop driver
15:12:18 mriedem that will work nicely, yes very nice indeed....muwahahah
15:13:03 sileht Hi nova devs, any idea why we get: http://logs.openstack.org/10/439510/4/check/gate-telemetry-dsvm-integration-gnocchi-ubuntu-xenial/07bd989/logs/screen-n-api.txt.gz#_2017-03-01_14_07_46_133
15:13:27 edmondsw johnthetubaguy could you take a quick look at https://review.openstack.org/#/c/389314 ? Other commenters are holding it up waiting for your feedback
15:13:41 mriedem sileht: did nova-manage db sync run after the cell0 db was mapped?
15:13:54 mriedem i.e. run nova-manage cell_v2 map_cell0 and then run nova-manage db sync
15:13:56 sileht mriedem, we just setup devstack
15:14:05 sileht mriedem, it should do it for us, no ?
15:14:20 mriedem well let's see
15:14:38 sileht mriedem, here: http://logs.openstack.org/10/439510/4/check/gate-telemetry-dsvm-integration-gnocchi-ubuntu-xenial/07bd989/logs/devstacklog.txt.gz#_2017-03-01_14_07_18_983
15:14:39 mriedem nova_cell0 is created here http://logs.openstack.org/10/439510/4/check/gate-telemetry-dsvm-integration-gnocchi-ubuntu-xenial/07bd989/logs/devstacklog.txt.gz#_2017-03-01_13_57_36_563
15:14:52 mriedem map_cell0 is called here http://logs.openstack.org/10/439510/4/check/gate-telemetry-dsvm-integration-gnocchi-ubuntu-xenial/07bd989/logs/devstacklog.txt.gz#_2017-03-01_14_07_18_983
15:15:18 mriedem nova-manage db sync is called here http://logs.openstack.org/10/439510/4/check/gate-telemetry-dsvm-integration-gnocchi-ubuntu-xenial/07bd989/logs/devstacklog.txt.gz#_2017-03-01_13_57_36_581
15:15:28 mriedem so db sync was called before map_cell0
15:15:36 mriedem so the cell0 db schema isn't migrated
15:15:52 sileht mriedem, so it's a devstack bug ?
15:15:58 mriedem "WARNING: cell0 mapping not found - not syncing cell0."
15:16:15 mriedem sileht: if it were, i'd think all of the jobs would be broken
15:16:46 dims mriedem : tools/discover_hosts.sh does not run in their case
15:16:46 sileht mriedem, our gate is mostly broken, most of the time we got the error, but sometimes it passes
15:17:00 dims mriedem : so they don't run "nova-manage cell_v2 discover_hosts --verbose"
15:17:20 sileht dims, do we miss something in project-config ?
15:17:49 dims sileht : remember this one - http://git.openstack.org/cgit/openstack-dev/devstack/commit/tools/discover_hosts.sh?id=5c6aa56e11b2dc79adc70154187d3a029e8e0976
15:18:17 mriedem dims: this isn't a multinode job so i don't think they need discover_hosts as long as simple_cell_setup is getting run
15:18:21 sileht dims, yes, but that was for another job
15:18:27 mriedem which is does here http://logs.openstack.org/10/439510/4/check/gate-telemetry-dsvm-integration-gnocchi-ubuntu-xenial/07bd989/logs/devstacklog.txt.gz#_2017-03-01_14_07_22_457
15:18:37 dansmith missing cell0 means we're not even getting to discover hosts
15:18:42 dims ah, ignore me then
15:18:46 mriedem sileht: so someone else had a similar sounding issue with using a devstack plugin
15:18:55 mriedem where it was getting called in the wrong order, i think it was shade
15:19:14 mriedem mordred: remember that thing where a devstack plugin was being called from post-stack or test hooks or something?
15:19:24 mriedem so n-api was up before cell0 was synce
15:19:28 mriedem *synced
15:19:30 openstackgerrit Ed Leafe proposed openstack/nova master: placement: ironic inventory reporting https://review.openstack.org/437602
15:19:50 edleafe jaypipes: ^^ fixed the pep8, and took the liberty of changing the name
15:20:14 sileht mriedem, oh maybe because each time a project that add a new wsgi vhost to apache, it is restarted
15:20:28 asettle mriedem: you are the lucky receiver of the table update; https://wiki.openstack.org/wiki/CrossProjectLiaisons#Documentation (this is where we keep all our liaisons)
15:21:00 mordred mriedem: yah
15:21:05 mordred mriedem: that was a lot of fun
15:21:31 mriedem mordred: remember the details? sounds like gnocchi jobs might be doing the same
15:21:51 mriedem http://logs.openstack.org/10/439510/4/check/gate-telemetry-dsvm-integration-gnocchi-ubuntu-xenial/07bd989/logs/devstack-gate-post_test_hook.txt.gz
15:22:00 mordred yah ... one sec, lemme find our fix patch
15:22:32 mordred mriedem: https://review.openstack.org/#/c/427390/
15:22:57 mordred so for us "start_nodepool" needs to not happen until the cloud is actually, you know, up and running
15:23:06 mordred we do that in test-config now
15:23:36 mordred sileht: ^^
15:23:41 mriedem sileht: so the gnocchi test hook might be trying to hit nova-api at the wrong point in the bring up sequence
15:24:06 mordred yah. that's what we were trying to do - nova was not happy about it
15:24:21 mriedem also https://review.openstack.org/#/c/427392/
15:24:26 mriedem ^ still needs to go in
15:24:42 mriedem and i think would help here, but there is still likely a bug in the consuming plugin
15:25:08 sileht mriedem, we start ceilometer and gnocchi during the extra step, not the the post-config
15:26:55 mriedem i've got to run to a meeting, bbiab
15:33:43 alex_xu jaypipes: sorry, I can't make a hangout, baby is sleeping. everybody just keep quiet...
15:36:35 dims alex_xu : :)
15:36:43 jaypipes alex_xu: k, no worries. let's comment on the patch, ok?
15:36:55 jaypipes edleafe: cool, thanks. I'm fixing up dansmith's PS5 comments now.
15:37:45 alex_xu jaypipes: that is ok for me, or you want to discuss on the irc, i still wake up
15:38:34 jaypipes alex_xu: k.
15:39:24 jaypipes alex_xu: so I don't actually think we should have a separate GET /traits/namespace REST API endpoint. And I think that GET /traits?namespace=* should be GET /traits?starts_with=XXX
15:40:47 alex_xu jaypipes: ok, i guess i remember the wrong one
15:41:33 alex_xu jaypipes: so you expect GET/traits?starts_with=CUSTOM:GPU, that is just a prefix, not really a namespace defined in the os-traits?
15:42:07 jaypipes alex_xu: yes, exactly.
15:42:48 alex_xu jaypipes: sorry, may i ask what is the point between the choice of "namespaces=*" and "starts_with"?
15:47:26 alex_xu dims: i also type the keyboard softly...
15:47:39 dims awwwww alex_xu
15:50:24 jaypipes alex_xu: actually, I think GET /traits?name=starts_with:XXX would be more in-line with the API WG filtering guidelines? https://github.com/openstack/api-wg/blob/master/guidelines/pagination_filter_sort.rst
15:51:14 jaypipes alex_xu: I know that there isn't a guideline specifically for prefix matching, but the other filter guidelines are similar. name=in:X,Y, start=ge:2017-01-01, etc
15:52:02 jaypipes alex_xu: in this case, all we're doing is a prefix match. There's really nothing about namespaces that is specific to the query.
15:52:15 mriedem +1 to /traits?name=starts_with:XXX
15:52:50 mriedem we have something like this today: GET /resource_providers?resources=VCPU:2,MEMORY_MB:1024,DISK_GB:50
15:53:02 mriedem and
15:53:03 mriedem /resource_providers?member_of=in:{agg1_uuid},{agg2_uuid},{agg3_uuid}
15:53:04 jaypipes alex_xu: and doing it this way would allow us, for example, to do something like GET /traits?name=contains:GPU or something similar, whereas you couldn't do that with namespace=XXX
15:54:01 alex_xu jaypipes: contains:GPU just should have bad performance even with db index?
15:55:24 jaypipes alex_xu: yes, absolutely, but that doesn't mean people won't find it useful ;)
15:56:16 jaypipes alex_xu: in any case, my point is that if we do name=starts_with:XXX, then we keep our API more in-line with the API WG recommendations and leave our options open in future to how users can query the placement API. Agree?
15:56:37 alex_xu jaypipes: yes, i agree
15:58:44 alex_xu jaypipes: mriedem, wait, the current proposal have a API "GET /traits?tratis=a,b,c", it is ok with "GET /traits?traits=start_with:xxx"?
16:02:18 mriedem what are the semantics of traits=a,b,c?
16:02:30 mriedem is that an in?
16:02:41 mriedem traits in (a, b, c) or an intersection?
16:02:52 alex_xu mriedem: yes
16:02:57 mriedem or is that, give me details about traits a, b, and c?
16:03:13 jaypipes mriedem: yup, traits?name=in:a,b,c
16:03:27 jaypipes IN == ANY()
16:03:36 alex_xu ah...name=in:
16:03:46 mriedem yeah we have that for resource_providers already
16:03:53 mriedem for finding resource providers in a given set of aggregates
16:04:03 mriedem /resource_providers?member_of=in:{agg1_uuid},{agg2_uuid},{agg3_uuid}
16:04:26 mriedem bauzas at one point had something similar for getting resource providers by name
16:04:45 alex_xu jaypipes: mriedem I think i got all that point now
16:05:27 alex_xu i will update the spec and validate more, mriedem jaypipes thanks

Earlier   Later