Earlier  
Posted Nick Remark
#openstack-nova - 2017-07-27
00:11:30 openstackgerrit Moshe Levi proposed openstack/nova master: hardware offload support for openvswitch https://review.openstack.org/398265
00:13:01 tonyb mikal, melwitt: the etherpad I was thinking of was https://etherpad.openstack.org/p/nova-low-hanging-fruit which has been migrated to the wiki
00:13:27 tonyb So I guess start a new one?
00:13:51 tonyb I know low-hanging-fruit isn't exactly what we were thinking of but I'm easily confused
00:15:12 mikal tonyb: I have a tweak to the localfs patch I'd like to upload before you do any rebasing please
00:15:53 mikal tonyb: I might upload that now unless you shout no in the next ten seconds
00:16:00 tonyb mikal: I was kinda using the 'I' in the sense mikal or tony sense
00:16:00 tonyb mikal: Sure
00:16:05 mikal LOL
00:16:12 mikal We are one entity now?
00:16:18 mikal That must be very embarassing for you
00:16:25 tonyb mikal: as long as you don't touch the last_bytes review go nuts ;P
00:16:41 moshele mriedem: hi
00:16:52 tonyb mikal: only here where privsep is concerend
00:17:09 mikal Oh sigh. I need to rebase. Please hold.
00:17:13 tonyb mikal: It's more of that 'tonyb took my keyboard and wont give it back pair programming'
00:17:26 mikal tonyb: true that. tonyb doesn't know how to share.
00:17:40 tonyb mikal: that's what my teachers said a school
00:17:52 mikal Heh
00:18:09 tonyb mikal: you might want to hold off until last_bytes merged unless that also needs a fix
00:18:19 mikal That didn't
00:18:24 mikal But it seems to hate merging
00:19:03 tonyb the py35 sdvm job seems to fail lots but perhaps it just hates us
00:19:06 mikal Hmmm, 472228 is in the check queue not the gate queue?
00:19:20 tonyb mikal: we had to recheck
00:19:21 mikal Looks like its going to pass there though
00:19:29 tonyb which does both queues
00:19:33 mikal Does it go to the gate queue automagically?
00:19:39 mikal Oh, so it runs all the tests twice?
00:19:46 mikal Thus maximizing the changes of a flakey test?
00:19:55 tonyb if it still has +W it will just move to gate when it gets a +1 from jenkins
00:20:35 tonyb mikal: Yeah but if anything has merged since the check was run then the results could now be wrong so it has to do bith
00:20:40 tonyb *both*
00:21:10 mikal So why not just re-run only the gate job?
00:22:48 tonyb 'cause gate and check have different configs and you could effectivle bypass a job that will fail but not catch it
00:24:34 mikal I hate everything
00:47:59 openstackgerrit yuanyue proposed openstack/nova master: Add a periodic task to destroy ReqSpecs of deleted instances https://review.openstack.org/484694
01:08:15 mikal tonyb: check passed
01:08:29 rm_work anyone know what the var for the nova-cpu config file is in devstack
01:08:30 rm_work like
01:08:39 rm_work https://github.com/problemv/devstack_deploy/blob/master/local.conf#L31-L34
01:08:49 rm_work I have that but it needs to be in nova-cpu conf too i think?
01:08:55 rm_work config file split recently?
01:10:03 tonyb rm_work: That should work. What are you seeing as a problme
01:10:07 tonyb mikal: \o/
01:10:13 rm_work tonyb: it doesn't ... use it?
01:10:18 rm_work apparently there is another conf now
01:10:54 rm_work https://www.irccloud.com/pastebin/8fg3XGaC/
01:11:25 rm_work adding it to nova-cpu.conf seems to work
01:11:30 rm_work but i don't know how to automate it
01:11:34 rm_work $NOVA_CPU_CONF maybe?
01:13:21 tonyb rm_work: where are you getting devstack from?
01:15:22 tonyb rm_work: http://paste.openstack.org/show/616640
01:15:39 tonyb rm_work: I don't see anything in devstack that is splitting things like that
01:16:18 rm_work so you don't have a nova-cpu.conf?
01:17:22 tonyb rm_work: nope: http://logs.openstack.org/28/472228/9/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/91e93eb/logs/etc/nova/
01:17:38 rm_work http://logs.openstack.org/28/472228/9/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/91e93eb/logs/etc/nova/nova-cpu.conf.txt.gz
01:17:42 tonyb rm_work: Oh wait it is there
01:17:47 rm_work with the libvirt section
01:18:02 rm_work as of ... recently maybe?
01:21:40 tonyb rm_work: You're right NOVA_CPU_CONF http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/nova#n54
01:21:48 rm_work cool :) good guess
01:22:36 mriedem rm_work: tonyb: merged yesterday
01:22:50 mriedem check the dev list about multi-tier conductor
01:22:55 tonyb mriedem: Oh I'm not that behind then
01:23:28 rm_work yeah, octavia folks are just *bleeding edge* :P
01:23:34 rm_work we always run into this stuff first
01:23:35 tonyb rm_work: my first grep didn't checkout master (it only downlaoded it) :(
01:24:51 tonyb mriedem: oh the conductor fleet stuff
01:25:45 mriedem yeah
01:25:59 mriedem a change merged today that allows you to disable that behavior if you need to
01:26:15 mriedem https://review.openstack.org/#/c/487485/
01:29:08 mriedem although, even with that set to singleconductor, i'm seeing the superconductor running http://logs.openstack.org/58/487458/2/check/gate-tempest-dsvm-ironic-ipa-wholedisk-bios-agent_ipmitool-tinyipa-ubuntu-xenial/d148ee1/logs/
01:29:16 mriedem dansmith: ^ maybe why the ironic job is still failing?
01:29:41 dansmith mriedem: in single conductor, the super conductor is the only one that gets hit
01:30:07 mriedem but we still start the cell conductor?
01:30:19 dansmith yeah, it was a hack for grenade remember
01:30:19 mriedem i'm seeing a request go through the scheduler, it picks a host, but then i don't see the request going through n-cpu
01:32:09 mriedem req-b1d7d389-f01a-4ea6-8de4-621fc28f7fc7
01:32:17 mriedem http://logs.openstack.org/58/487458/2/check/gate-tempest-dsvm-ironic-ipa-wholedisk-bios-agent_ipmitool-tinyipa-ubuntu-xenial/d148ee1/logs/screen-n-super-cond.txt.gz#_Jul_26_21_32_58_412591
01:32:22 mriedem super conductor just seems to die there
01:32:52 mriedem and i never see req-b1d7d389-f01a-4ea6-8de4-621fc28f7fc7 show up in n-cpu logs
01:33:22 dansmith is that req a boot request?
01:33:33 dansmith you'd never see it hit cpu if it got novalidhost right?
01:33:52 mriedem it didn't get novalidhost
01:33:57 mriedem i see n-sch pick a host
01:34:07 mriedem and yeah that's the boot request
01:34:15 mriedem super-cond, sch and cpu are all using nova.conf
01:34:24 mriedem which points at transport_url = rabbit://stackrabbit:secretrabbit@15.184.66.253:5672/
01:34:52 mriedem db connection is set to nova_cell1
01:34:53 dansmith yeah, which is a pretty normal setup
01:35:09 dansmith is it normal to have cpu deleting tons of orphan nodes?
01:36:08 dansmith and this is single node so no chance we're missing logs from another conductor I guess
01:36:59 mriedem lots of ComputeHostNotFound in the n-cpu logs
01:37:41 mriedem Selected host: (ubuntu-xenial-infracloud-vanilla-10103211, eda7dc99-9e17-479c-b234-9d87956e9c56) ram: 384MB disk: 10240MB io_ops: 0 instances: 0
01:37:41 mriedem this is the host/node that's picked in the scheduler
01:37:42 dansmith so you think conductor got the selected host and cast to compute but it disappeared?
01:37:53 mriedem or conductor didn't get it..
01:38:00 dansmith unfortunately, we don't get to see the _actual_ trnsport_url loaded in compute
01:38:07 dansmith that req showed up in conductor, no?

Earlier   Later