Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-11-14
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
17:21:18 sean-k-mooney but i think we are violently agreeing mostly :)
17:21:20 efried sean-k-mooney That's fine; so they're separate traits
17:21:44 efried sean-k-mooney What you *don't* want is to have the scheduler decide on a host, send the boot request, and then have virt punt because it can't do secure boot, resulting in retries, which are limited to the cell, etc. etc.
17:22:13 sean-k-mooney one one trait againts too different things e.g. traits against the host and traits againts the virtulisation context.
17:22:34 sean-k-mooney efried: yes that would be bad
17:23:06 sean-k-mooney * that was ment to be or one trait.
17:23:09 mriedem bauzas: dansmith: sdague: i'm thinking we want these in for ocata and newton before eol too, since i'll be cutting a release today or tomorrow for that cve https://review.openstack.org/#/q/Icb418f2be575bb2ba82756fdeb67b24a28950746
17:23:31 mriedem fixes bug 1675676
17:23:31 openstack bug 1719730 in OpenStack Compute (nova) ocata "duplicate for #1675676 Reschedule after the late affinity check fails with "'NoneType' object is not iterable"" [High,In progress] https://launchpad.net/bugs/1719730 - Assigned to Matt Riedemann (mriedem)
17:23:53 efried sean-k-mooney Ah, so now we're talking about overloading the trait semantic to say, "not only do I want to make sure I wind up on a SECURE_BOOT_CAPABLE host, I also want this vm to be secure boot."
17:24:02 efried sean-k-mooney And *that* is the cardinal sin according to the PTB.
17:24:20 efried sean-k-mooney They would have you specify that second thing via some completely separate mechanism.
17:24:40 efried sean-k-mooney Perhaps image metadata; perhaps a different extra_spec; perhaps some other confy thing...
17:24:55 sean-k-mooney efried: the traith that you use for secure boot should not change based on the compute context you choose
17:25:08 sean-k-mooney e.g. it should be the same for vm,baremetal and contianer
17:25:27 sean-k-mooney in the ironic case the compute context is the same as the host
17:25:32 efried sean-k-mooney I'm on board with that.
17:25:39 sean-k-mooney in the containter and vm case the are not
17:26:02 sdague mriedem: make it so
17:26:05 sdague i.e. +A
17:26:46 mriedem thanks

Earlier   Later