Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-11-14
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
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 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:28 efried mriedem Thanks, updated to +1
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 pep8: commands succeeded
17:19:37 crlb py27: commands succeeded
17:19:37 crlb jaypipes tox -epy27,pep8 | tee ../nova-patched-tox.log
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 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:31 mriedem fixes bug 1675676
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
17:26:59 sean-k-mooney efried: personally i would see these are two differnt traits request. one is find me a host with X and the second is find me a hypervisor capable of emulating Y and then we take the intersection of both
17:30:17 openstackgerrit Elod Illes proposed openstack/nova master: Use FakeLiveMigrateDriver in notification test https://review.openstack.org/519405
17:30:34 openstackgerrit Eric Fried proposed openstack/nova master: Test helper: validate provider summaries https://review.openstack.org/518982
17:30:56 efried gibi I rebased this on top of the series, and added affordance for traits too ^
17:50:51 bauzas yay, I got a new bouncer \o/
17:58:27 hongbin mriedem: ack
18:04:39 mriedem alaski: didn't you at one point have a doc on your thoughts for the tasks api, or was that just a patch that never merged?
18:05:59 mriedem i found a really old juno spec https://review.openstack.org/#/c/86938/
18:06:40 mriedem oh maybe https://specs.openstack.org/openstack/nova-specs/specs/backlog/approved/instance-tasks.html
18:12:12 mordred mriedem: questoin about scheduler hints ... the API ref https://developer.openstack.org/api-ref/compute/#create-server seems to indicate that os:scheduler_hints can be put as a key on the server dict in the request, or that OS-SCH-HNT:scheduler_hints can be used outside of the server dict.
18:12:54 mordred mriedem: but there's an old guide https://docs.openstack.org/kilo/config-reference/content/section_compute-scheduler.html that shows using os:scheduler_hints at the top level ... and i just got a patch: https://review.openstack.org/#/c/519705/2/shade/openstackcloud.py to move using os:scheduler_hints to outside of the server dict
18:13:29 mordred mriedem: is the story that it always goes into the top level of the payload and that either key works?
18:16:04 mriedem i think the latter, i think it's a top-level key https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/schemas/scheduler_hints.py#L75
18:16:10 mriedem and either works
18:16:25 mriedem https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/scheduler_hints.py#L18
18:17:24 sean-k-mooney for consitnecy sake shade and osc should proably pass scheduler hints the same way
18:17:46 mriedem i don't think you can send it in the server body
18:17:50 mriedem it's a top-level key
18:17:57 mriedem the server create api-ref in nova is just confusing
18:18:04 mriedem "The dictionary of data to send to the scheduler. Alternatively, you can specify OS-SCH-HNT:scheduler_hints as the key in the request body."
18:18:13 mriedem that's just saying, you can use either key

Earlier   Later