Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-11-14
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: bandwidth param should be set in guest migrate https://review.openstack.org/519635
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: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: Handle InstanceNotFound when setting password via metadata https://review.openstack.org/519659
17:02:41 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Fix CellDatabases fixture swallowing exceptions https://review.openstack.org/519702
17:02:57 sean-k-mooney efried: i would assume that the virt driver would restore it as it can tell the differece between new hardware was added and the operator deleted it
17:03:04 efried right
17:03:24 sean-k-mooney efried: the virt driver would have to have a blacklist to support operators removing traits in this case
17:03:33 efried ugh
17:03:35 sean-k-mooney e.g. in the nova.conf
17:04:43 mriedem efried: replied to your question in https://review.openstack.org/#/c/515418/ about stable policy for fixing 500 errors
17:04:45 efried sean-k-mooney Is one idea that the operator sets host traits via nova.conf?
17:04:46 sean-k-mooney efried: im not sure you sould want to remove traits as an operator
17:05:28 efried mriedem Thanks, updated to +1
17:05:28 sean-k-mooney efried: there was a proposal to allow the operator to add traits via nova.conf but not to set them.
17:05:50 efried sean-k-mooney Sorry, I didn't follow that. add but not set ?
17:06:29 sean-k-mooney e.g. so they could lable nic with things like hardware offload capable, which would be unioned with the set of traits discovered by the virt dirver
17:06:44 sean-k-mooney so append traits but override via config
17:07:33 sean-k-mooney this is all tided to your generic device manager work though so it will change as that evolves.
17:07:43 mriedem hongbin: can you add the conflicts note to the commit message for this backport? https://review.openstack.org/#/c/515418/1
17:07:46 mriedem see details inline
17:12:23 efried sean-k-mooney Okay, yeah, I remember talking about a conf file-based black/white/trait-list for devices. So the multiple-sources-for-traits thing is something we'll have to deal with one way or another.
17:13:01 efried sean-k-mooney But the point remains that there will be some traits the virt driver should set, and some that should be set "externally" (be it from conf, osc, other service, magic wand, whatever).
17:13:14 sean-k-mooney efried: yes mid term we should have resouce providers and traits created by neutron for bandwith based scheuling in rocky
17:13:17 efried sean-k-mooney And (I guess on a case by case basis) we'll have to decide which of those is appropriate for which.
17:13:42 efried sean-k-mooney So for the case of secure boot capability, I contend that one should be okay for the virt driver to detect.
17:14:06 efried Because it's something that's either on or off for the entire life of the n-cpu process; and it's something that the virt driver can easily detect.
17:14:30 sean-k-mooney efried: yes. i would agree. if we can rely on the presence to also indicate that its enabled we remove the need for states at least for the nova case
17:14:43 sean-k-mooney efried: for ironic that will not work however
17:15:18 efried sean-k-mooney This may be a case where the difference is made in one's choice of words.
17:16:03 sean-k-mooney well ideally i should use the same trait to represent secure boot will be used regradless of if its ironic
17:16:08 sean-k-mooney or nova vms
17:16:23 sean-k-mooney or zun containers for that matter
17:16:29 efried sean-k-mooney The host is capable of hosting secure boot VMs. If you say it like that, I think you can get away with it.
17:16:55 efried sean-k-mooney But if you say, "The host is capable of hosting secure boot VMs, but only if the secure boot feature is enabled," that's where you'll get into trouble.
17:17:21 sean-k-mooney efried: that not what im asking for. im asking for a host that iteslf is useing secure boot that can host my vm.
17:17:34 efried sean-k-mooney A host that was brought up without secure boot enablement is NOT CAPABLE OF HOSTING SECURE BOOT VMS. Ergo it should not have the trait.
17:17:37 sean-k-mooney the contraint is on the host not the vm. the vm could be bios booting
17:17:46 efried Yeah, I understand.
17:18:35 sean-k-mooney secure boot vms could imply that the vm is also useing uefi secure boot too
17:19:01 efried sean-k-mooney That's a sidetrack to the discussion.
17:19:34 efried sean-k-mooney What we're trying to get at here is that you want to be able to specify in your flavor: SECURE_BOOT_CAPABLE - and have your VM land on a host that's secure boot capable.
17:19:37 crlb jaypipes tox -epy27,pep8 | tee ../nova-patched-tox.log
17:19:37 crlb py27: commands succeeded
17:19:37 crlb pep8: commands succeeded
17:20:48 sean-k-mooney efried: or i specify SECURE_BOOT_CAPABLE and i land on a hypvervior(in the xen/kvm meaning) that can excute the vm kernel using a uefi bootload with secureboot enabel in the vm
17:21:05 sean-k-mooney we have to be able to treet both seperatly

Earlier   Later