| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-11-14 | |||
| 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 | |
| 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 | |
| 18:18:30 | mriedem | i don't know why we have 2 keys, i'm assuming v2 api extension fun | |
| 18:18:40 | mriedem | gmann, sdague or oomichi might remember | |
| 18:20:00 | mriedem | mordred: yeah e.g. https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#differenthostfilter | |
| 18:20:05 | mriedem | "With the API, use the os:scheduler_hints key. For example:" | |
| 18:20:40 | mordred | ok. cool. so it just shows up weird in the api ref docs ... | |
| 18:20:49 | mordred | since it's in the same block as key_name and whatnot | |
| 18:20:50 | mriedem | yeah, we should be clear that it's a top-level key | |
| 18:20:53 | mriedem | yup | |
| 18:21:04 | mriedem | i, or someone else, can amend the doc | |