| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-11-14 | |||
| 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 | |
| 18:22:21 | mordred | cool. thanks! | |
| 18:23:10 | openstackgerrit | Elod Illes proposed openstack/nova master: Transform instance-live_migration_pre notification https://review.openstack.org/482070 | |
| 18:24:10 | mriedem | the example request shows it's top-level too | |
| 18:24:10 | mriedem | https://developer.openstack.org/api-ref/compute/#create-server | |
| 18:24:27 | mriedem | so that helps somewhat | |
| 18:27:52 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-ref: make a note about os:scheduler_hints being a top-level key https://review.openstack.org/519717 | |
| 18:27:56 | mriedem | mordred: see if this floats your boat ^ | |
| 18:28:46 | jaypipes | crlb: I'll pull your patch and run locally and see what's up. | |
| 18:29:05 | mordred | mriedem: yes! that's super helpful | |
| 18:30:10 | mriedem | cburgess: semi interesting live migration abort scenario for you | |
| 18:30:29 | cburgess | OK shoot | |
| 18:30:32 | mriedem | cburgess: today you can list in-progress live migrations for a given server | |
| 18:30:33 | mriedem | https://github.com/openstack/nova/blob/16.0.0/nova/db/sqlalchemy/api.py#L4789 | |
| 18:30:38 | mriedem | if it's in one of those 4 states ^ | |
| 18:30:50 | mriedem | however, you can only abort a running migration https://github.com/openstack/nova/blob/16.0.0/nova/compute/api.py#L3952 | |
| 18:31:05 | mriedem | presumably because the migration transitions fast enough that it gets to the hypervisor and starts running | |
| 18:31:08 | mriedem | however, | |
| 18:31:21 | mriedem | we have this max_concurrent_live_migrations config option in compute which defaults to 1, | |
| 18:31:36 | mriedem | so you could be trying to move 10 instances off a host via live migration, and by default those are all going to queue up, | |
| 18:31:48 | mriedem | let's say you wanted to abort half of those (1 in 10 are running) | |
| 18:31:53 | mriedem | the abort would fail | |
| 18:32:47 | cburgess | mriedem Give me a few... sorry had someone talking to me | |
| 18:32:51 | mriedem | one solution is just bump up your max_concurrent_live_migrations value to 10, but then you hit issues with running a bunch of migrations at once | |
| 18:32:58 | mriedem | np, just looking for some ops feedback | |
| 18:33:55 | alaski | mriedem: there was http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/backlog/approved/instance-tasks.rst | |
| 18:34:35 | mriedem | alaski: yup i found it later via google, i was mistakenly searching the nova docs | |
| 18:34:43 | alaski | cool | |
| 18:38:42 | openstackgerrit | Hongbin Lu proposed openstack/nova stable/pike: Handle exception on adding secgroup https://review.openstack.org/515418 | |
| 18:40:33 | openstackgerrit | Hongbin Lu proposed openstack/nova stable/ocata: Handle exception on adding secgroup https://review.openstack.org/515421 | |
| 18:42:44 | jaypipes | crlb: https://pastebin.com/maKwN7pM -- failures are reproduceable for me. Only suggestion I have is do an rm -rf .tox/ and then retry the tox -epy27,pep8. Other than that... perhaps you forgot to git review and push your latest changes to gerrit? | |
| 18:43:13 | efried | crlb If you run tox with -r it'll rebuild the venv. | |