Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-11-14
16:01:38 mriedem tristanC: +2s on https://review.openstack.org/#/q/I11746d1ea996a0f18b7c54b4c9c21df58cc4714b
16:01:40 tristanC dansmith: thanks, appreciated the fast review!
16:01:41 dansmith mriedem: tristanC I just hit the last one
16:01:46 dansmith heh, yep
16:01:48 mriedem dansmith: thanks
16:02:05 mriedem i will assume bauzas is on the same call
16:02:08 jaypipes crlb: how are you running tox locally?
16:02:15 jaypipes crlb: do this: tox -epy27,pep8
16:02:23 jaypipes crlb: and you'll see the same errors.
16:02:31 tristanC i'm waiting for vmt +2 on the ossa (https://review.openstack.org/519686) to send the advisory
16:04:54 mriedem ack
16:05:35 bauzas mriedem: thanks for helping with https://review.openstack.org/#/c/519662/
16:05:54 sean-k-mooney mriedem: so looking at the nova_api db the host_mappins is empty as is the compute_nodes table in the cell1 db however the devstack@n-cpu.service is running on the hsot according to systemctl
16:05:55 bauzas and thanks for the tests
16:06:17 mriedem tristanC: small typo in your patch
16:10:47 sean-k-mooney mriedem: huh i just realised there is a giant Guru Meditation report dump in the nova-compute journalctl log. is there a partcalar part that i should read in that to figure out what failed
16:11:25 mriedem i think that happens when you kill the service?
16:11:40 mriedem i'd check for errors in the n-cpu logs about why the compute node record wasn't created
16:12:06 mriedem are the conductor services running?
16:12:23 jaypipes sean-k-mooney: the guru part.
16:14:28 bauzas mriedem: dansmith: FWIW, I'm having a big problem with my IRC bouncer so for the moment, I'm not getting a notify if someone asks me
16:14:46 bauzas mriedem: but yeah, just saw your pings
16:17:24 sean-k-mooney mriedem: according to openstack compute service list yes. that said on ubuntu i actully have a tracback and a libvirt issue. on centos it prints no No Traceback! in one of the green tread imediatly after connecting to libvirt
16:18:41 mriedem efried: remember that ksa adapter bug i pointed out to you on saturday? did that amount to anything?
16:18:50 mriedem person was having failures connecting to glance
16:18:56 openstackgerrit Matthew Booth proposed openstack/nova stable/pike: libvirt: Don't VIR_MIGRATE_NON_SHARED_INC without migrate_disks https://review.openstack.org/519632
16:18:56 openstackgerrit Matthew Booth proposed openstack/nova stable/pike: libvirt: bandwidth param should be set in guest migrate https://review.openstack.org/519631
16:19:15 efried mriedem I don't believe it was a ksa adapter thing. I responded in the bug report. I think they had either their conf or their catalog misconfigured.
16:19:39 mriedem ok you must have invalidated the bug?
16:19:47 efried mriedem I marked it as Incomplete
16:19:52 mriedem oh ok
16:20:15 efried mriedem From what I could tell, they were running pike, so it would be before my ksa adapter code, FWIW.
16:20:57 efried I mean, still going through ksa adapters & sessions ultimately
16:23:04 openstackgerrit Matt Riedemann proposed openstack/nova master: doc: fix link to creating unit tests in contributor guide https://review.openstack.org/519482
16:23:42 mriedem bauzas: don't forget the two changes below https://review.openstack.org/#/c/519684/
16:24:20 bauzas done
16:25:06 mriedem thanks. dansmith ^ when you're off your call
16:25:52 mriedem tristanC: changes are all approved, just need to approve the dependencies on the newton change
16:25:58 mriedem i'll request releases on all stable branches once those are merged
16:26:01 openstackgerrit Jianghua Wang proposed openstack/nova master: XenAPI: create vGPU for instance https://review.openstack.org/516899
16:26:17 mriedem and then we'll eol newton
16:32:37 prometheanfire mriedem: https://review.openstack.org/#/c/519672/ doesn't apply to 16.0.2 cleanly, are we expecting releases soon with the fix (for pike/ocata at least)?
16:33:47 mriedem prometheanfire: "(10:25:59 AM) mriedem: i'll request releases on all stable branches once those are merged"
16:34:05 prometheanfire thanks, just rejoined the channel at 10:33
16:34:09 mriedem doh
16:34:12 prometheanfire :P
16:36:37 dansmith mriedem: got them sorry
16:36:53 mriedem thanks, np
16:37:14 mriedem welcome back to the land of the (koala) free
16:40:32 dansmith you mean "welcome back to the land of internet"
16:40:43 dansmith and yes, it's good to be back on the right side of the wet noodle
16:43:54 mriedem tonyb: would you be against changing this release note on stable/pike to be 'fixes' or 'other' rather than 'features'? https://review.openstack.org/#/c/513717/4/releasenotes/notes/bug-1721179-87bc7b64215944c0.yaml
16:44:01 mriedem i don't want to alarm people reading stable patch release notes
16:44:57 sean-k-mooney efried: just comming to the end of the video on Ironic-Nova traits discussion. given the audiunce and topic it makes sense that only the ironic case was discussed but everything discussed also need to work with just plain nova
16:45:09 efried sean-k-mooney Yup.
16:45:18 efried sean-k-mooney Somehow...
16:45:52 sean-k-mooney efried: so with nova i need to be able to request the vm to be placed on a hypervior with secure boot enabled on the host not the vm
16:46:44 efried sean-k-mooney Does enabling secure boot on the hypervisor entail bouncing the compute service?
16:47:10 sean-k-mooney efried: i expcitly do not want to enabled it. i want to find a hypervisor with it enabled
16:47:38 sean-k-mooney efried: the config map thing iss irrelevent in this case as i do dont want to change configuration
16:48:15 sean-k-mooney efried: but yes it would require a host reboot to chage secureboot and it would require the host os is signed and the signing key is sored in the firmware
16:48:51 efried sean-k-mooney Okay, great. What I'm getting at is: if you enable secure boot on a hypervisor, and you have to restart the host (or at least restart the compute service) then we can make the case that the virt driver should set the SECURE_BOOT_CAPABLE trait on that host's RP.
16:49:05 efried sean-k-mooney Then you can just make your flavor require the SECURE_BOOT_CAPABLE trait and you're good.
16:49:25 sean-k-mooney efried: nope that was specifically reject at teh ptg. that is what i proposed
16:49:31 efried sean-k-mooney But if secure boot was something you could just flip on and off at will, then jaypipes would freak out if you had the virt driver detect that setting and add/remove the trait on the fly.
16:50:21 sean-k-mooney efried: no in a nova compute case its done once when you deploy the compute node. or infrequeently as a maintence envent on the compute node by the operator
16:50:51 efried sean-k-mooney As far as I'm concerned, if you have to reboot the whole host, all bets are off as far as traits are concerned. That's not a "dynamic trait". You could be adding or removing all kinds of capabilities across that reboot.
16:51:21 sean-k-mooney efried: yep i could have change the cpus or ram or anything
16:51:34 efried sean-k-mooney That's MHO; jaypipes or dansmith may wish to take a firmer stance.
16:51:57 sean-k-mooney efried: but specifcally dicovering if secure boot was enable or even the boot mode was reject as something the nova compute agent can do at the PTG
16:52:22 openstackgerrit Matthew Booth proposed openstack/nova stable/ocata: libvirt: Don't VIR_MIGRATE_NON_SHARED_INC without migrate_disks https://review.openstack.org/519636
16:52:22 openstackgerrit Matthew Booth proposed openstack/nova stable/ocata: libvirt: bandwidth param should be set in guest migrate https://review.openstack.org/519635
16:52:38 efried sean-k-mooney By compute "agent", do you mean the virt driver?
16:53:16 sean-k-mooney i mean nova compute agent e.g. devstack@n-cpu.service which includes the virt dirver
16:53:42 efried sean-k-mooney Hum, okay, that doesn't seem like the right thing. If not the compute agent deciding what traits to set on the host RP, then who?
16:54:16 sean-k-mooney efried: see lines 548-558 https://etherpad.openstack.org/p/nova-ptg-queens
16:54:48 sean-k-mooney efried: the stading policy on https://docs.openstack.org/nova/latest/contributor/policies.html#metrics-gathering was sighted as the reson to not allow this
16:56:25 mriedem gibi: dansmith: do you remember fixing a bug in the target_cell fixture stuff where it was swallowing exceptions?
16:56:41 dansmith I think so
16:56:42 mriedem i thought that was fixed as part of the instance list series
16:56:53 mriedem ok i'll dig
16:56:55 efried sean-k-mooney Metrics seems like a poor analogy
16:57:39 gibi mriedem: yes, it rings a bell
16:57:43 mriedem https://github.com/openstack/nova/commit/af05d6208b4f95f1d9b882ed376552b75bb87506#diff-04a5f91f2963947e47ab25a8b291617a
16:57:46 mriedem consider the bell rung
16:58:12 dansmith mriedem: https://review.openstack.org/#/c/506312/
16:58:22 dansmith heh
16:58:27 mriedem yup cool
16:58:29 sean-k-mooney efried: i agree. i really do think this should be something the compute agent/virt driver discovers hence my original proposal but the ask was to have an external enity other then nova set these traits on the compute node
16:58:31 mriedem part of that is going to pike
16:58:50 efried sean-k-mooney What external entity??
16:58:56 efried sean-k-mooney The operator??
16:59:27 efried sean-k-mooney I guess in the case of ironic they said it would be the ironic inspector and/or operator manually adding traits.
16:59:32 sean-k-mooney efried: anything that was not nova. i was planning to use a systemd script that invoked the openstack client as a workaround
17:00:05 efried sean-k-mooney That just seems like unnecessary work for something that could so easily be automated in the virt driver.
17:00:13 sean-k-mooney efried: yes in the ironic case it would be ironic itself, feed by the inspector
17:01:49 sean-k-mooney efried: yes jaypipes dansmith strongly express a preference to not have the virt driver do this though. it was 4 oclock on fiday and everyone wanted to leave at that point so maybe in light of the ironic call there opipion has changed
17:02:00 efried sean-k-mooney Presumably it's not illegal for virt to set *any* traits on the host RP. So now we've got multiple different sources for traits. Who's the source of truth? If the operator deletes a trait that was set by virt, does it stay gone, or does virt restore it next time the pt runs?
17:02:41 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Fix CellDatabases fixture swallowing exceptions https://review.openstack.org/519702
17:02:41 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Handle InstanceNotFound when setting password via metadata https://review.openstack.org/519659

Earlier   Later