Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-06
20:07:30 bauzas mriedem: +Wd, thanks
20:07:36 efried mriedem: It occurs to me that disabling bits of the service auth token will have impact outside of glance.
20:07:37 bauzas oh man, mox
20:07:59 cdent mriedem: thanks for that final explicit comment
20:09:14 bauzas wow, https://review.openstack.org/#/c/534605/ too
20:09:43 mriedem bauzas: that one is much more focused and easy
20:09:52 mriedem all it is is make the debug option mutable
20:09:58 mriedem with a sighup
20:10:05 mriedem it's not "make all options mutable"
20:10:11 cdent it was initially
20:10:12 bauzas I'm still chilling
20:10:20 cdent but I nipped it
20:10:30 bauzas anyway, time will see
20:11:07 bauzas the problem is not about having a mutable conf opt :)
20:11:34 mriedem cdent: good - that's how i first read that one, until i re-read it
20:11:35 bauzas it's rather about making sure nova can sighub
20:11:45 kashyap dansmith: So, on that potential race-thing, did you see the comment with more Neutron-educated Sean Mooney? He makes a good point when he says:
20:11:54 kashyap "it would be nicer to have a solution that is always guaranteed to work but even with a race it much less likely to be noticed then the race we have today were the RARP packets from qemu are often lost as the nic is not wired up."
20:11:56 mriedem sighub - the special interest group for github
20:12:02 bauzas oops
20:12:09 bauzas sighup :p
20:12:15 bauzas kill -1 :p
20:13:34 bauzas mriedem: oh btw. why have I a plumage for our team ? :p
20:14:09 mriedem bauzas: you're the only one with a high enough plumage score
20:14:20 mriedem french
20:14:28 mriedem mandatory minimum level of plumage
20:15:20 dansmith kashyap: that has nothing to do with the race I was asking about
20:15:37 bauzas mriedem: because we are all cocks ? :)
20:15:49 mriedem ha
20:16:03 kashyap dansmith: Okay, I see -- you're asking the impact of setting it in two places
20:16:15 dansmith kashyap: yes and in two threads
20:16:22 odyssey4me mriedem actually, we have some logs from just the standard upgrade test: http://logs.openstack.org/29/540329/5/check/openstack-ansible-upgrade-ubuntu-xenial/30ae3e2/
20:16:23 kashyap So in the existing code in _live_migration(), guest.migrate() is already called with 'CONF.libvirt.live_migration_bandwidth'. And then...
20:16:41 openstackgerrit Chris Dent proposed openstack/nova master: WIP: Isolate placement database config https://review.openstack.org/541435
20:16:49 kashyap dansmith: A test result with log would convince you I suppose?
20:16:50 odyssey4me mriedem the 'host' folder will have the nova-compute logs, and the 'openstack' folder will have the other nova services logs
20:17:02 dansmith kashyap: no of course not.. if it's a race then a passing test means nothing :)
20:17:03 mriedem odyssey4me: holy wingdings batman http://logs.openstack.org/29/540329/5/check/openstack-ansible-upgrade-ubuntu-xenial/30ae3e2/openstack/openstack1/nova/nova-api-os-compute.log.txt.gz.txt.gz
20:17:15 odyssey4me ouch
20:17:17 mriedem oh here we go http://logs.openstack.org/29/540329/5/check/openstack-ansible-upgrade-ubuntu-xenial/30ae3e2/openstack/openstack1/nova/nova-api-os-compute.log.txt.gz
20:17:19 kashyap dansmith: An automated test that repeats, say 100 times?
20:17:29 openstackgerrit Ken'ichi Ohmichi proposed openstack/nova master: TrivialFix: Add a space between messages https://review.openstack.org/541436
20:17:30 dansmith kashyap: are you joking? I can't tell
20:17:33 kashyap :P
20:17:40 kashyap Okay, it's clearly too late for me
20:17:51 odyssey4me looks like we have a bug in the log collection - I'll figure that out
20:17:57 dansmith kashyap: and if not, no. we have races that sit dormant for years until something changes in infra, things go in a different order, and we start getting breakage
20:18:01 dansmith kashyap: ack
20:18:33 openstackgerrit Ken'ichi Ohmichi proposed openstack/nova master: TrivialFix: Add a space between messages https://review.openstack.org/541436
20:18:49 mriedem odyssey4me: ok here was that error you mentioned http://logs.openstack.org/29/540329/5/check/openstack-ansible-upgrade-ubuntu-xenial/30ae3e2/openstack/openstack1/nova/nova-conductor.log.txt.gz#_2018-02-05_18_19_11_428
20:19:19 odyssey4me mriedem yep, eith the instance error state just a little later
20:21:21 mriedem odyssey4me: i see that nova-manage cell_v2 create_cell didn't exist in newton, so when those commands run, are they against ocata?
20:21:45 odyssey4me yes, in our newton deploy there is no cell management done
20:22:25 kashyap dansmith: Scooping up my final active neurons: You want to see clear _functional test_ evidence that the override of CONF.libvirt.live_migration_bandwidth doesn't happen, yes? (Though, Sahid claims it doesn't.)
20:22:33 odyssey4me mriedem newton only does these: https://github.com/openstack/openstack-ansible-os_nova/blob/stable/newton/tasks/nova_db_setup.yml
20:22:51 dansmith kashyap: no.
20:22:53 mriedem odyssey4me: there are a bunch of errors in the nova-compute logs http://logs.openstack.org/29/540329/5/check/openstack-ansible-upgrade-ubuntu-xenial/30ae3e2/host/nova/nova-compute.log.txt.gz
20:23:08 dansmith kashyap: I want human analysis of whether or not setting the thing to 1 and 100 in two threads is asking for trouble
20:23:48 dansmith kashyap: as far as I can tell, the migration is started with the CONF value, and then set to 1 to slow things down, but there is no locking or mechanism to ensure the slowdown call is done after the value is set to the one from conf
20:24:04 odyssey4me mriedem hmm, even late in the log, yes: http://logs.openstack.org/29/540329/5/check/openstack-ansible-upgrade-ubuntu-xenial/30ae3e2/host/nova/nova-compute.log.txt.gz#_2018-02-05_18_15_57_449
20:24:04 kashyap (Okay, between the two threads where it is being set. Needs more code reading...)
20:24:21 odyssey4me mriedem actually, that seems to recover: http://logs.openstack.org/29/540329/5/check/openstack-ansible-upgrade-ubuntu-xenial/30ae3e2/host/nova/nova-compute.log.txt.gz#_2018-02-05_18_15_57_469
20:24:28 dansmith kashyap: I can ask someone else, I thought you would be able to dig into the libvirt docs and validate or discredit sahid's assertion that it doesn't matter (which doesn't make sense to me)
20:24:31 kashyap dansmith: Yeah, it is started with the CONF value
20:25:03 dansmith kashyap: right, but I don't think there's anything that ensures that that is set before we make the call to slow it down
20:25:15 mriedem odyssey4me: right it logs a warning on the first time it doesn't find it
20:25:50 dansmith kashyap: so it seems to me like it could be started, not reach the point at which the conf value is used, we set the speed limit, then the conf value gets applied
20:25:50 odyssey4me these are somewhat odd though: http://logs.openstack.org/29/540329/5/check/openstack-ansible-upgrade-ubuntu-xenial/30ae3e2/host/nova/nova-compute.log.txt.gz#_2018-02-05_18_14_01_860
20:25:55 kashyap dansmith: Okay, you'd want to know how the two values that are being set are coordinated with some locking mechanism with the underlying libvirt API
20:26:12 dansmith kashyap: no. nevermind, go to sleep, I'll try to dig into it
20:26:52 mriedem odyssey4me: ok so in the console output, we see that compute show up in the service list here http://logs.openstack.org/29/540329/5/check/openstack-ansible-upgrade-ubuntu-xenial/30ae3e2/job-output.txt.gz#_2018-02-05_18_15_43_557748
20:27:03 ameeda_ mriedem: Hello :)
20:28:58 mriedem odyssey4me: it might be worthwhile to run discover_hosts with --verbose http://logs.openstack.org/29/540329/5/check/openstack-ansible-upgrade-ubuntu-xenial/30ae3e2/job-output.txt.gz#_2018-02-05_18_15_48_024543
20:29:02 mriedem to see what it dumps out
20:29:40 mriedem odyssey4me: i do remember that with devstack-based CI, we'd have issues in grenade where nova-compute would take awhile to bring up and create the compute_nodes record, and discover_hosts would miss it
20:30:25 mriedem https://review.openstack.org/#/c/488381/
20:30:36 odyssey4me mriedem yeah, that's why we added the wait until a compute agent was found - that seems to have worked for us so far, but perhaps we need more sheps
20:30:39 mriedem however, you have that "openstack compute service list" check
20:31:32 mordred efried: looks like you have a fun debugging task on your plate
20:31:33 odyssey4me but yeah, lemme add the --verbose CLI option when our debug flag is enabled, which would be very useful here
20:31:45 efried mordred: indeeed
20:33:08 mriedem odyssey4me: are the /etc/ files captured?
20:33:28 odyssey4me mriedem unfortunately not - we had to turn that off 'cos we were eating up all the infra inodes :/
20:33:50 odyssey4me we could add that back, but tar.gz them so we eat fewer inodes :)
20:33:58 mriedem ok, i can't tell if the [database]/connection value in nova.conf that the nova-compute is using is the same database connection as the cell1 this creates
20:36:42 mriedem odyssey4me: anyway i think we can see that the compute_nodes entry is created here for the compute host http://logs.openstack.org/29/540329/5/check/openstack-ansible-upgrade-ubuntu-xenial/30ae3e2/host/nova/nova-compute.log.txt.gz#_2018-02-05_18_15_57_469
20:36:49 mriedem at 18:15:57.469
20:36:58 mriedem it shows up in the service list here:
20:36:58 mriedem http://logs.openstack.org/29/540329/5/check/openstack-ansible-upgrade-ubuntu-xenial/30ae3e2/job-output.txt.gz#_2018-02-05_18_15_43_557748
20:37:09 mriedem "end": "2018-02-05 18:15:43.505982",
20:37:31 odyssey4me mriedem db config template is here, if that helps a bit: https://github.com/openstack/openstack-ansible-os_nova/blob/stable/ocata/templates/nova.conf.j2#L213-L233
20:37:56 odyssey4me each db will have a unique name, and each db user/password will also be unique
20:38:17 dansmith kashyap: I explained my concern in more detail, maybe you could dig into docs/code tomorrow with that extra info to validate one way or the other?
20:39:33 mriedem odyssey4me: looks ok
20:39:37 openstackgerrit melanie witt proposed openstack/nova master: Refine waiting for vif plug events during _hard_reboot https://review.openstack.org/541442
20:41:44 dansmith melwitt: nice
20:41:48 mriedem odyssey4me: also throw the --verbose option on create_cell
20:43:18 mriedem ultimately my guess is discover_hosts isn't picking up the compute host and mapping it to the cell
20:43:26 mriedem just not sure why
20:43:43 mriedem could be a timing issue, but that's what the openstack service list check is for

Earlier   Later